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.
+<p>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.</p>
- - 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
+<p>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.</p>
- - smtp
- - imap
- - nfs
- - ldap
- - ntp
- - X11
- - syslog
- - ODF
- - text
- - html
- - rst
+<p>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.</p>
+
+<p>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.</p>
-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.
+<p>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.</p>
-I would like to have one computer object representing each computer in
+<p>In <a href="http://www.skolelinux.org/">Debian Edu/Skolelinux</a>,
+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.</p>
+
+<p>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.</p>
-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.
+<p>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.</p>
-Active Directory have done a better job than unix heads like myself in
-this regard. Time to start a new IETF work goup?
+<p>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?</p>
--- /dev/null
+Title: Returning from Skolelinux developer gathering
+Tags: english, debian, debian edu, nuug
+Date: 2009-03-29 21:00
+
+<p>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. :)</p>
projects / homepage.git / commitdiff