- <div class="entry">
- <div class="title"><a href="Standardize_on_protocols_and_formats__not_vendors_and_applications.html">Standardize on protocols and formats, not vendors and applications</a></div>
- <div class="date">2009-03-30 11:50</div>
- <div class="body">
-<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 open 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>
-
-<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>
-
-<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 at any moment, 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>
-</div>
- <div class="tags">
-
-
-
- Tags: <a href="tags/debian">debian</a>, <a href="tags/english">english</a>, <a href="tags/nuug">nuug</a>, <a href="tags/standard">standard</a>.
-
- </div>
- </div>
- <div class="padding"></div>
-
- <div class="entry">
- <div class="title"><a href="Returning_from_Skolelinux_developer_gathering.html">Returning from Skolelinux developer gathering</a></div>
- <div class="date">2009-03-29 21:00</div>
- <div class="body">
-<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>
-</div>
- <div class="tags">
-
-
-
- Tags: <a href="tags/debian">debian</a>, <a href="tags/debian edu">debian edu</a>, <a href="tags/english">english</a>, <a href="tags/nuug">nuug</a>.
-
- </div>
- </div>
- <div class="padding"></div>
-
- <div class="entry">
- <div class="title"><a href="Time_for_new__LDAP_schemas_replacing_RFC_2307_.html">Time for new LDAP schemas replacing RFC 2307?</a></div>
- <div class="date">2009-03-29 20:30</div>
- <div class="body">
-<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>
-
-<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.</p>
-
-<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>
-
-<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>
-</div>
- <div class="tags">
-
-
-
- Tags: <a href="tags/debian">debian</a>, <a href="tags/debian edu">debian edu</a>, <a href="tags/english">english</a>, <a href="tags/nuug">nuug</a>.
-
- </div>
- </div>
- <div class="padding"></div>
-
projects / homepage.git / blobdiff