Updated.

diff --git a/blog/data/2009-02-18-protokoll-og-format.txt b/blog/data/2009-02-18-protokoll-og-format.txt
index d206eb5b7470520d9c762f3f4c00db94ca629056..4d8ff96ba8f0ea88d93ab777c5cec5faf2cf8429 100644 (file)
--- 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
 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>

diff --git a/blog/data/2009-03-29-ldap-schema-needed.txt b/blog/data/2009-03-29-ldap-schema-needed.txt
index b2bf817732f620f2dd1644bec27ddb9f59564fb8..b1063a2e40a38f6451d1ecb2c59c386f8b03e72f 100644 (file)
--- 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
 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.
 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>

diff --git a/blog/data/2009-03-29-skolelinux.txt b/blog/data/2009-03-29-skolelinux.txt
new file mode 100644 (file)
index 0000000..8797550
--- /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
+
+<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>