-<p>Jeg ble glad da regjeringen
-<a href="http://www.digi.no/817635/her-er-statens-nye-it-standarder">annonserte</a>
-versjon 2 av
-<a href="http://www.regjeringen.no/upload/FAD/Vedlegg/IKT-politikk/Referansekatalogen_versjon2.pdf">statens
-referansekatalog over standarder</a>, men trist da jeg leste hva som
-faktisk var vedtatt etter
-<a href="http://www.regjeringen.no/nb/dep/fad/dok/horinger/horingsdokumenter/2009/horing---referansekatalog-versjon-2.html">høringen</a>.
-De fleste av de valgte åpne standardene er gode og vil bidra til at
-alle kan delta på like vilkår i å lage løsninger for staten, men
-noen av dem blokkerer for de som ikke har anledning til å benytte
-spesifikasjoner som krever betaling for bruk (såkalt
-royalty-betaling). Det gjelder spesifikt for H.264 for video og MP3
-for lyd. Så lenge bruk av disse var valgfritt mens Ogg Theora og Ogg
-Vorbis var påkrevd, kunne alle som ønsket å spille av video og lyd
-fra statens websider gjøre dette uten å måtte bruke programmer der
-betaling for bruk var nødvendig. Når det nå er gjort valgfritt for
-de statlige etatene å bruke enten H.264 eller Theora (og MP3 eler
-Vorbis), så vil en bli tvunget til å forholde seg til
-royalty-belastede standarder for å få tilgang til videoen og
-lyden.</p>
-
-<p>Det gjør meg veldig trist at regjeringen har forlatt prinsippet om
-at alle standarder som ble valgt til å være påkrevd i katalogen skulle
-være uten royalty-betaling. Jeg håper det ikke betyr at en har mistet
-all forståelse for hvilke prinsipper som må følges for å oppnå
-likeverdig konkurranse mellom aktørene i IT-bransjen. NUUG advarte
-mot dette i
-<a href="http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2">sin
-høringsuttalelse</a>, men ser ut til å ha blitt ignorert.</p>
+<p>For some years now, I have wondered how we should handle laptops in
+Debian Edu. The Debian Edu infrastructure is mostly designed to
+handle stationary computers, and less suited for computers that come
+and go.</p>
+
+<p>Now I finally believe I have an sensible idea on how to adjust
+Debian Edu for laptops, by introducing a new profile for them, for
+example called Roaming Workstations. Here are my thought on this.
+The setup would consist of the following:</p>
+
+<ul>
+
+ <li>During installation, the user name of the owner / primary user of
+ the laptop is requested and a local home directory is set up for
+ the user, with uid and gid information fetched from the LDAP
+ server. This allow the user to work also when offline. The
+ central home directory can be available in a subdirectory on
+ request, for example mounted via CIFS. It could be mounted
+ automatically when a user log in while on the Debian Edu network,
+ and unmounted when the machine is taken away (network down,
+ hibernate, etc), it can be set up to do automatic mounting on
+ request (using autofs), or perhaps some GUI button on the desktop
+ can be used to access it when needed. Perhaps it is enough to use
+ the fish protocol in KDE?</li>
+
+ <li>Password checking is set up to use LDAP or Kerberos
+ authentication when the machine is on the Debian Edu network, and
+ to cache the password for offline checking when the machine unable
+ to reach the LDAP or Kerberos server. This can be done using
+ <a href="http://www.padl.com/OSS/pam_ccreds.html">libpam-ccreds</a>
+ or the Fedora developed
+ <a href="https://fedoraproject.org/wiki/Features/SSSD">System
+ Security Services Daemon</a> packages.</li>
+
+ <li>File synchronisation with the central home directory is set up
+ using a shared directory in both the local and the central home
+ directory, using unison.</li>
+
+ <li>Printing should be set up to print to all printers broadcasting
+ their existence on the local network, and should then work out of
+ the box with CUPS. For sites needing accurate printer quotas, some
+ system with Kerberos authentication or printing via ssh could be
+ implemented.</li>
+
+ <li>For users that should have local root access to their laptop,
+ sudo should be used to allow this to the local user.</li>
+
+ <li>It would be nice if user and group information from LDAP is
+ cached on the client, but given that there are entries for the
+ local user and primary group in /etc/, it should not be needed.</li>
+
+</ul>
+
+<p>I believe all the pieces to implement this are in Debian/testing at
+the moment. If we work quickly, we should be able to get this ready
+in time for the Squeeze release to freeze. Some of the pieces need
+tweaking, like libpam-ccreds should get support for pam-auth-update
+(<a href="http://bugs.debian.org/566718">#566718</a>) and nslcd (or
+perhaps debian-edu-config) should get some integration code to stop
+its daemon when the LDAP server is unavailable to avoid long timeouts
+when disconnected from the net. If we get Kerberos enabled, we need
+to make sure we avoid long timeouts there too.</p>
+
+<p>If you want to help out with implementing this for Debian Edu,
+please contact us on debian-edu@lists.debian.org.</p>