From: Petter Reinholdtsen Date: Sun, 29 Mar 2009 21:28:26 +0000 (+0000) Subject: Updated. X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/commitdiff_plain/17663f4b507f9a77277fedb661a53a0bd65f825b?hp=e934bed999bdfe5d2788e2bb5dd6212b311a9bad Updated. --- diff --git a/blog/data/2009-02-18-protokoll-og-format.txt b/blog/data/2009-02-18-protokoll-og-format.txt index d206eb5b74..4d8ff96ba8 100644 --- a/blog/data/2009-02-18-protokoll-og-format.txt +++ b/blog/data/2009-02-18-protokoll-og-format.txt @@ -1,28 +1,30 @@ Title: Standardize on protocols and formats, not vendors and applications -Tags: english, nuug -Date: 2009-02-18 11:50 -Publish: 2010-01-01 +Tags: english, nuug, standard, debian +Date: 2009-03-30 11:50 +Publish: 2009-03-30 -Where I work, one of the decisions taken a long time ago that has -stood out as a very good base to build computer systems on, is the -decision to standardize on network protocols and exchange formats -instead of applications. +

Where I work at the University of Oslo, one decision stand out as a +very good one to form a long lived computer infrastructure. It is the +simple one, lost by many in todays computer industry: Standardize on +open network protocols and exchange/storage formats, not applications. +Applications come and go, while protocols and files tend to stay, and +thus one want to make it easy to change application and vendor, while +avoiding conversion costs and locking users to a specific platform or +application.

- - on network protocols and exchange formats - - open standards is a clear advantage - - give support on applications - - allow other apps - - allow us to change clients and keep the servers, or replace the - servers and keep the clients +

This approach make it possible to replace the client applications +independently of the server applications. One can even allow users to +use several different applications as long as they handle the selected +protocol and format. In the normal case, only one client application +is recommended and users only get help if they choose to use this +application, but those that want to deviate from the easy path are not +blocked from doing so.

- - smtp - - imap - - nfs - - ldap - - ntp - - X11 - - syslog - - ODF - - text - - html - - rst +

It also allow us to replace the server side without forcing the +users to replace their applications, and thus allow us to select the +best server implementation over time, when scale and resouce +requirements change.

+ +

I strongly recommend standardizing - on open network protocols and +open formats, but I would never recommend standardizing on a single +application that do not use open network protocol or open formats.

diff --git a/blog/data/2009-03-29-ldap-schema-needed.txt b/blog/data/2009-03-29-ldap-schema-needed.txt index b2bf817732..b1063a2e40 100644 --- a/blog/data/2009-03-29-ldap-schema-needed.txt +++ b/blog/data/2009-03-29-ldap-schema-needed.txt @@ -1,30 +1,36 @@ -Title: Time to replace the LDAP schemas in RFC 2307 +Title: Time for new LDAP schemas replacing RFC 2307? Tags: nuug, english, debian edu, debian -Date: 2009-03-29 12:00 -Publish: 2010-01-01 +Date: 2009-03-29 20:30 -The state of standardized LDAP schemas on Linux is far from optimal. -In Debian Edu, we would like to store information about users, SMB -clients/hosts, filegroups, netgroups (users and hosts), DHCP and DNS -configuration, and LTSP configuration in LDAP. These objects have a -lot in common, but with the current LDAP schemas it is not possible to -have one object per entity. For example, one need to have at least -three LDAP objects for a given computer, one with the SMB related -stuff, one with DNS information and another with DHCP information. In -addition, it is impossible to implement quick queries for netgroup -membership, because of the way NIS triples are implemented. I believe -it is time for a few RFC specifications to cleam up this mess. The -old RFC 2307 do not scale when it comes to netgroups, and the schema -used by DNS servers and DHCP servers do not integrate properly with -RFC 2307 and each other. +

The state of standardized LDAP schemas on Linux is far from +optimal. There is RFC 2307 documenting one way to store NIS maps in +LDAP, and a modified version of this normally called RFC 2307bis, with +some modifications to be compatible with Active Directory. The RFC +specification handle the content of a lot of system databases, but do +not handle DNS zones and DHCP configuration.

-I would like to have one computer object representing each computer in +

In Debian Edu/Skolelinux, +we would like to store information about users, SMB clients/hosts, +filegroups, netgroups (users and hosts), DHCP and DNS configuration, +and LTSP configuration in LDAP. These objects have a lot in common, +but with the current LDAP schemas it is not possible to have one +object per entity. For example, one need to have at least three LDAP +objects for a given computer, one with the SMB related stuff, one with +DNS information and another with DHCP information. The schemas +provided for DNS and DHCP are impossible to combine into one LDAP +object. In addition, it is impossible to implement quick queries for +netgroup membership, because of the way NIS triples are implemented. +It just do not scale. I believe it is time for a few RFC +specifications to cleam up this mess.

+ +

I would like to have one LDAP object representing each computer in the network, and this object can then keep the SMB (ie host key), DHCP (mac address/name) and DNS (name/IP address) settings in one place. -It need to be efficently stored to make sure it scale well. +It need to be efficently stored to make sure it scale well.

-I would also like to have a quick way to map from a user or computer -and to the net group this user or computer is a member. +

I would also like to have a quick way to map from a user or +computer and to the net group this user or computer is a member.

-Active Directory have done a better job than unix heads like myself in -this regard. Time to start a new IETF work goup? +

Active Directory have done a better job than unix heads like myself +in this regard, and the unix side need to catch up. Time to start a +new IETF work group?

diff --git a/blog/data/2009-03-29-skolelinux.txt b/blog/data/2009-03-29-skolelinux.txt new file mode 100644 index 0000000000..879755018d --- /dev/null +++ b/blog/data/2009-03-29-skolelinux.txt @@ -0,0 +1,19 @@ +Title: Returning from Skolelinux developer gathering +Tags: english, debian, debian edu, nuug +Date: 2009-03-29 21:00 + +

I'm sitting on the train going home from this weekends Debian +Edu/Skolelinux development gathering. I got a bit done tuning the +desktop, and looked into the dynamic service location protocol +implementation avahi. It look like it could be useful for us. Almost +30 people participated, and I believe it was a great environment to +get to know the Skolelinux system. Walter Bender, involved in the +development of the Sugar educational platform, presented his stuff and +also helped me improve my OLPC installation. He also showed me that +his Turtle Art application can be used in standalone mode, and we +agreed that I would help getting it packaged for Debian. As a +standalone application it would be great for Debian Edu. We also +tried to get the video conferencing working with two OLPCs, but that +proved to be too hard for us. The application seem to need more work +before it is ready for me. I look forward to getting home and relax +now. :)