-<p>For a laptop, centralized user directories and password checking is
-a bit troubling. Laptops are typically used also when not connected
-to the network, and it is vital for a user to be able to log in or
-unlock the screen saver also when a central server is unavailable.
-This is possible by caching passwords and directory information (user
-and group attributes) locally, and the packages to do so are available
-in Debian. Here follow two recipes to set this up in Debian/Squeeze.
-It is also possible to set up in Debian/Lenny, but require more manual
-setup there because pam-auth-update is missing in Lenny.</p>
-
-<h2>LDAP/Kerberos + nscd + libpam-ccreds + libpam-mklocaluser/pam_mkhomedir</h2>
-
-This is the traditional method with a twist. The password caching is
-provided by libpam-ccreds (version 10-4 or later is needed on
-Squeeze), and the directory caching is done by nscd. The directory
-lookup and password checking is done using LDAP. If one want to use
-Kerberos for password checking the libpam-ldapd package can be
-replaced with libpam-krb5 or libpam-heimdal. If one is happy having a
-local home directory with the path listed in LDAP, one can use the
-pam_mkhomedir module from pam-modules to make this happen instead of
-using libpam-mklocaluser. A setup for pam-auth-update to enable
-pam_mkhomedir will have to be written until a fix for
-<a href="http://bugs.debian.org/568577">bug #568577</a> is in the
-archive. Because I believe it is a bad idea to have local home
-directories using misleading paths like /site/server/partition/, I
-prefer to create a local user with the home directory in /home/. This
-is done using the libpam-mklocaluser package.</p>
-
-<p>These packages need to be installed and configured</p>
-
-<blockquote><pre>
-libnss-ldapd libpam-ldapd nscd libpam-ccreds libpam-mklocaluser
-</pre></blockquote>
-
-<p>The ldapd packages will ask for LDAP connection information, and
-one have to fill in the values that fits ones own site. Make sure the
-PAM part uses encrypted connections, to make sure the password is not
-sent in clear text to the LDAP server. I've been unable to get TLS
-certificate checking for a self signed certificate working, which make
-LDAP authentication unsafe for Debian Edu (nslcd is not checking if it
-is talking to the correct LDAP server), and very much welcome feedback
-on how to get this working.</p>
-
-<p>Because nscd do not have a default configuration fit for offline
-caching until <a href="http://bugs.debian.org/485282">bug #485282</a>
-is fixed, this configuration should be used instead of the one
-currently in /etc/nscd.conf. The changes are in the fields
-reload-count and positive-time-to-live, and is based on the
-instructions I found in the
-<a href="http://www.flyn.org/laptopldap/">LDAP for Mobile Laptops</a>
-instructions by Flyn Computing.</p>
-
-<blockquote><pre>
- debug-level 0
- reload-count unlimited
- paranoia no
-
- enable-cache passwd yes
- positive-time-to-live passwd 2592000
- negative-time-to-live passwd 20
- suggested-size passwd 211
- check-files passwd yes
- persistent passwd yes
- shared passwd yes
- max-db-size passwd 33554432
- auto-propagate passwd yes
-
- enable-cache group yes
- positive-time-to-live group 2592000
- negative-time-to-live group 20
- suggested-size group 211
- check-files group yes
- persistent group yes
- shared group yes
- max-db-size group 33554432
- auto-propagate group yes
-
- enable-cache hosts no
- positive-time-to-live hosts 2592000
- negative-time-to-live hosts 20
- suggested-size hosts 211
- check-files hosts yes
- persistent hosts yes
- shared hosts yes
- max-db-size hosts 33554432
-
- enable-cache services yes
- positive-time-to-live services 2592000
- negative-time-to-live services 20
- suggested-size services 211
- check-files services yes
- persistent services yes
- shared services yes
- max-db-size services 33554432
-</pre></blockquote>
-
-<p>While we wait for a mechanism to update /etc/nsswitch.conf
-automatically like the one provided in
-<a href="http://bugs.debian.org/496915">bug #496915</a>, the file
-content need to be manually replaced to ensure LDAP is used as the
-directory service on the machine. /etc/nsswitch.conf should normally
-look like this:</p>
-
-<blockquote><pre>
-passwd: files ldap
-group: files ldap
-shadow: files ldap
-hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
-networks: files
-protocols: files
-services: files
-ethers: files
-rpc: files
-netgroup: files ldap
-</pre></blockquote>
-
-<p>The important parts are that ldap is listed last for passwd, group,
-shadow and netgroup.</p>
-
-<p>With these changes in place, any user in LDAP will be able to log
-in locally on the machine using for example kdm, get a local home
-directory created and have the password as well as user and group
-attributes cached.
-
-<h2>LDAP/Kerberos + nss-updatedb + libpam-ccreds +
- libpam-mklocaluser/pam_mkhomedir</h2>
-
-<p>Because nscd have had its share of problems, and seem to have
-problems doing proper caching, I've seen suggestions and recipes to
-use nss-updatedb to copy parts of the LDAP database locally when the
-LDAP database is available. I have not tested such setup, because I
-discovered sssd.</p>
-
-<h2>LDAP/Kerberos + sssd + libpam-mklocaluser</h2>
-
-<p>A more flexible and robust setup than the nscd combination
-mentioned earlier that has shown up recently, is the
-<a href="https://fedorahosted.org/sssd/">sssd</a> package from Redhat.
-It is part of the <a href="http://www.freeipa.org/">FreeIPA</A> project
-to provide a Active Directory like directory service for Linux
-machines. The sssd system combines the caching of passwords and user
-information into one package, and remove the need for nscd and
-libpam-ccreds. It support LDAP and Kerberos, but not NIS. Version
-1.2 do not support netgroups, but it is said that it will support this
-in version 1.5 expected to show up later in 2010. Because the
-<a href="http://packages.qa.debian.org/s/sssd.html">sssd package</a>
-was missing in Debian, I ended up co-maintaining it with Werner, and
-version 1.2 is now in testing.
-
-<p>These packages need to be installed and configured to get the
-roaming setup I want</p>
-
-<blockquote><pre>
-libpam-sss libnss-sss libpam-mklocaluser
-</pre></blockquote>
-
-The complete setup of sssd is done by editing/creating
-<tt>/etc/sssd/sssd.conf</tt>.
-
-<blockquote><pre>
-[sssd]
-config_file_version = 2
-reconnection_retries = 3
-sbus_timeout = 30
-services = nss, pam
-domains = INTERN
-
-[nss]
-filter_groups = root
-filter_users = root
-reconnection_retries = 3
-
-[pam]
-reconnection_retries = 3
-
-[domain/INTERN]
-enumerate = false
-cache_credentials = true
-
-id_provider = ldap
-auth_provider = ldap
-chpass_provider = ldap
-
-ldap_uri = ldap://ldap
-ldap_search_base = dc=skole,dc=skolelinux,dc=no
-ldap_tls_reqcert = never
-ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
-</pre></blockquote>
-
-<p>I got the same problem here with certificate checking. Had to set
-"ldap_tls_reqcert = never" to get it working.</p>
-
-<p>With the libnss-sss package in testing at the moment, the
-nsswitch.conf file is update automatically, so there is no need to
-modify it manually.</p>
-
-<p>If you want to help out with implementing this for Debian Edu,
-please contact us on debian-edu@lists.debian.org.</p>
+<p>I dag la jeg inn en kommentar på en sak hos NRKBeta
+<a href="http://nrkbeta.no/2010/10/27/bakom-blindpassasjer-del-1/">om
+hvordan TV-serien Blindpassasjer ble laget</a> i forbindelse med at
+filmene NRK la ut ikke var tilgjengelig i et
+<a href="http://www.digistan.org/open-standard:definition">fritt og
+åpent format</a>. Dette var det jeg skrev publiserte der 07:39.</p>
+
+<p><blockquote>
+<p>"Vi fikk en kommentar rundt måten streamet innhold er beskyttet fra
+nedlasting. Mange av oss som kan mer enn gjennomsnittet om systemer
+som dette, vet at det stort sett er mulig å lure ut ting med den
+nødvendige forkunnskapen."</p>
+
+<p>Haha. Å streame innhold er det samme som å laste ned innhold, så å
+beskytte en stream mot nedlasting er ikke mulig. Å skrive noe slikt
+er å forlede leseren.</p>
+
+<p>Med den bakgrunn blir forklaringen om at noen rettighetshavere kun
+vil tillate streaming men ikke nedlasting meningsløs.</p>
+
+<p>Anbefaler forresten å lese
+<a href="http://blogs.computerworlduk.com/simon-says/2010/10/drm-is-toxic-to-culture/index.htm">http://blogs.computerworlduk.com/simon-says/2010/10/drm-is-toxic-to-culture/index.htm</a>
+om hva som ville være konsekvensen hvis digitale avspillingssperrer
+(DRM) fungerte. Det gjør de naturligvis ikke teknisk - det er jo
+derfor de må ha totalitære juridiske beskyttelsesmekanismer på plass,
+men det er skremmende hva samfunnet tillater og NRK er med på å bygge
+opp under.</p>
+</blockquote></p>
+
+<p>Ca. 20 minutter senere får jeg følgende epost fra Anders Hofseth i
+NRKBeta:</p>
+
+<p><blockquote>
+<p>From: Anders Hofseth &lt;XXX@gmail.com>
+<br>To: "pere@hungry.com" &lt;pere@hungry.com>
+<br>Cc: Eirik Solheim &lt;XXX@gmail.com>, Jon Ståle Carlsen &lt;XXX@gmail.com>, Henrik Lied &lt;XXX@gmail.com>
+<br>Subject: Re: [NRKbeta] Kommentar: "Bakom Blindpassasjer: del 1"
+<br>Date: Sat, 30 Oct 2010 07:58:44 +0200</p>
+
+<p>Hei Petter.
+<br>Det du forsøker dra igang er egentlig en interessant diskusjon,
+men om vi skal kjøre den i kommentarfeltet her, vil vi kunne bli bedt
+om å fjerne blindpassasjer fra nett- tv og det vil heller ikke bli
+særlig lett å klarere ut noe annet arkivmateriale på lang tid.</p>
+
+<p>Dette er en situasjon NRKbeta ikke ønsker, så kommentaren er
+fjernet og den delen av diskusjonen er avsluttet på nrkbeta, vi antar
+konsekvensene vi beskriver ikke er noe du ønsker heller...</p>
+
+<p>Med hilsen,
+<br>-anders</p>
+
+<p>Ring meg om noe er uklart: 95XXXXXXX</p>
+</blockquote></p>
+
+<p>Ble så fascinert over denne holdningen, at jeg forfattet og sendte
+over følgende svar. I og med at debatten er fjernet fra NRK Betas
+kommentarfelt, så velger jeg å publisere her på bloggen min i stedet.
+Har fjernet epostadresser og telefonnummer til de involverte, for å
+unngå at de tiltrekker seg uønskede direkte kontaktforsøk.</p>
+
+<p><blockquote>
+<p>From: Petter Reinholdtsen &lt;pere@hungry.com>
+<br>To: Anders Hofseth &lt;XXX@gmail.com>
+<br>Cc: Eirik Solheim &lt;XXX@gmail.com>,
+<br> Jon Ståle Carlsen &lt;XXX@gmail.com>,
+<br> Henrik Lied &lt;XXX@gmail.com>
+<br>Subject: Re: [NRKbeta] Kommentar: "Bakom Blindpassasjer: del 1"
+<br>Date: Sat, 30 Oct 2010 08:24:34 +0200</p>
+
+<p>[Anders Hofseth]
+<br>> Hei Petter.</p>
+
+<p>Hei.</p>
+
+<p>> Det du forsøker dra igang er egentlig en interessant diskusjon, men
+<br>> om vi skal kjøre den i kommentarfeltet her, vil vi kunne bli bedt om
+<br>> å fjerne blindpassasjer fra nett- tv og det vil heller ikke bli
+<br>> særlig lett å klarere ut noe annet arkivmateriale på lang tid.</p>
+
+<p>Godt å se at du er enig i at dette er en interessant diskusjon. Den
+vil nok fortsette en stund til. :)</p>
+
+<p>Må innrømme at jeg synes det er merkelig å lese at dere i NRK med
+vitende og vilje ønsker å forlede rettighetshaverne for å kunne
+fortsette å legge ut arkivmateriale.</p>
+
+<p>Kommentarer og diskusjoner i bloggene til NRK Beta påvirker jo ikke
+faktum, som er at streaming er det samme som nedlasting, og at innhold
+som er lagt ut på nett kan lagres lokalt for avspilling når en ønsker
+det.</p>
+
+<p>Det du sier er jo at klarering av arkivmateriale for publisering på
+web krever at en holder faktum skjult fra debattfeltet på NRKBeta.
+Det er ikke et argument som holder vann. :)</p>
+
+<p>> Dette er en situasjon NRKbeta ikke ønsker, så kommentaren er fjernet
+<br>> og den delen av diskusjonen er avsluttet på nrkbeta, vi antar
+<br>> konsekvensene vi beskriver ikke er noe du ønsker heller...</p>
+
+<p>Personlig ønsker jeg at NRK skal slutte å stikke hodet i sanden og
+heller være åpne på hvordan virkeligheten fungerer, samt ta opp kampen
+mot de som vil låse kulturen inne. Jeg synes det er en skam at NRK
+godtar å forlede publikum. Ville heller at NRK krever at innhold som
+skal sendes skal være uten bruksbegresninger og kan publiseres i
+formater som heller ikke har bruksbegresninger (bruksbegresningene til
+H.264 burde få varselbjellene i NRK til å ringe).</p>
+
+<p>At NRK er med på DRM-tåkeleggingen og at det kommer feilaktive
+påstander om at "streaming beskytter mot nedlasting" som bare er egnet
+til å bygge opp om en myte som er skadelig for samfunnet som helhet.</p>
+
+<p>Anbefaler &lt;URL:<a href="http://webmink.com/2010/09/03/h-264-and-foss/">http://webmink.com/2010/09/03/h-264-and-foss/</a>> og en
+titt på
+&lt;URL: <a href="http://people.skolelinux.org/pere/blog/Terms_of_use_for_video_produced_by_a_Canon_IXUS_130_digital_camera.html">http://people.skolelinux.org/pere/blog/Terms_of_use_for_video_produced_by_a_Canon_IXUS_130_digital_camera.html</a> >.
+for å se hva slags bruksbegresninger H.264 innebærer.</p>
+
+<p>Hvis dette innebærer at NRK må være åpne med at arkivmaterialet ikke
+kan brukes før rettighetshaverene også innser at de er med på å skade
+samfunnets kultur og kollektive hukommelse, så får en i hvert fall
+synliggjort konsekvensene og antagelig mer flammer på en debatt som er
+langt på overtid.</p>
+
+<p>> Ring meg om noe er uklart: XXX</p>
+
+<p>Intet uklart, men ikke imponert over måten dere håndterer debatten på.
+Hadde du i stedet kommet med et tilsvar i kommentarfeltet der en
+gjorde det klart at blindpassasjer-blogpostingen ikke var riktig sted
+for videre diskusjon hadde dere i mine øyne kommet fra det med
+ryggraden på plass.</p>
+
+<p>PS: Interessant å se at NRK-ansatte ikke bruker NRK-epostadresser.</p>
+
+<p>Som en liten avslutning, her er noen litt morsomme innslag om temaet.
+&lt;URL: <a href="http://www.archive.org/details/CopyingIsNotTheft">http://www.archive.org/details/CopyingIsNotTheft</a> > og
+&lt;URL: <a href="http://patentabsurdity.com/">http://patentabsurdity.com/</a> > hadde vært noe å kringkaste på
+NRK1. :)</p>
+
+<p>Vennlig hilsen,
+<br>--
+<br>Petter Reinholdtsen</p>