-
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.
-
-
LDAP/Kerberos + nscd + libpam-ccreds + libpam-mklocaluser/pam_mkhomedir
-
-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
-
bug #568577 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.
-
-
These packages need to be installed and configured
-
-
-libnss-ldapd libpam-ldapd nscd libpam-ccreds libpam-mklocaluser
-
-
-
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.
-
-
Because nscd do not have a default configuration fit for offline
-caching until bug #485282
-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
-LDAP for Mobile Laptops
-instructions by Flyn Computing.
-
-
- 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
-
-
-
While we wait for a mechanism to update /etc/nsswitch.conf
-automatically like the one provided in
-bug #496915, 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:
-
-
-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
-
-
-
The important parts are that ldap is listed last for passwd, group,
-shadow and netgroup.
-
-
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.
-
-
LDAP/Kerberos + nss-updatedb + libpam-ccreds +
- libpam-mklocaluser/pam_mkhomedir
-
-
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.
-
-
LDAP/Kerberos + sssd + libpam-mklocaluser
-
-
A more flexible and robust setup than the nscd combination
-mentioned earlier that has shown up recently, is the
-sssd package from Redhat.
-It is part of the FreeIPA 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
-sssd package
-was missing in Debian, I ended up co-maintaining it with Werner, and
-version 1.2 is now in testing.
-
-
These packages need to be installed and configured to get the
-roaming setup I want
-
-
-libpam-sss libnss-sss libpam-mklocaluser
-
-
-The complete setup of sssd is done by editing/creating
-
/etc/sssd/sssd.conf.
-
-
-[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
-
-
-
I got the same problem here with certificate checking. Had to set
-"ldap_tls_reqcert = never" to get it working.
-
-
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.
-
-
If you want to help out with implementing this for Debian Edu,
-please contact us on debian-edu@lists.debian.org.
+
Tidlig i januar oppdaget vi i
+OpenStreetmap.org-prosjektet
+at Oslo kommune har tatt i bruk OpenStreetmap.org for å vise frem
+hvor
+piggdekkavgiften gjelder, dvs. kommunegrensa. Ã
rsaken til at
+denne siden bruker OpenStreetmap.org og ikke kommunens eget
+kartgrunnlag, er ganske absurd. Kommunens kart vedlikeholdes og
+styres av Plan og Bygningsetaten, mens det er Samferdselsetaten som
+styrer med piggdekkavgift og som har laget siden om piggdekkavgiften.
+I avtalen mellom Samferdselsetatet og Plan og Bygningsetaten om bruk
+av kommunens kart står det at kartet kun kan brukes internt, og dermed
+ikke publiseres på Internet. Oslo kommune forbyr altså Oslo kommune å
+publisere informasjon om sin kommunegrense på Internet. Ironien er
+upåklagelig, og årsaken er som alltid penger.
+
+
Vi i OpenStreetmap.org-prosjektet synes det er veldig gledelig at
+Oslo kommune vil bruke kartet vårt, men det var et lite problem rundt
+bruken av kommunegrensen. Den kommer fra kartverkets N5000-kart, som
+i følge kartverket har nøyaktighet på 2 km. Et kart over hvor
+piggdekkavgiften gjelder bør ha høyere nøyaktighet enn det for å unngå
+konflikter, så det var dermed viktig for oss å forbedre nøyaktigheten
+for Oslogrensa.
+
+
For litt over 2 uker siden ringte jeg derfor til Kartverket, for å
+høre om de kunne bidra. Jeg lurte på om de enten hadde noen
+datakilder med kommunegrensen i Oslo som vi ikke kjente til, eller om
+de kunne forklare hvordan vi kunne gjenskape kommunegrensen på bakken
+ved å følge en beskrivelse av grensen eller finne grensepunkter
+etc.
+
+
For å ta det siste først, så var det beste forslaget der å bruke
+kartet tilgjengelig fra
+norgeskart.no til å slå opp
+gårds- og bruksnummer for eiendommer som grenset til kommunegrensa, og
+så be om innsyn i matrikkelen for hver av disse eiendommene og gå opp
+grensen basert på informasjon fra matrikkelen. Det fantes antagelig
+også noen grensesteiner som var merket på bakken, men de kjente ikke
+til noen offentlig kilde med informasjon om hvor disse steinene sto.
+Dette er en ganske arbeidskrevende oppgave, som får vente til en annen
+gang.
+
+
For alternative datakilder vi ikke kjente til, så var det ingen som
+hadde gode forslag når det gjaldt datakilder fra kartverket. Men en
+nevnte at det kunne være enklere å få ut data fra veidatabasen til
+vegvesenet, f.eks. de punktene der veier inn og ut av Oslo byttet
+kommune. Dette ble jeg forklart var trivielt å hente ut (mindre enn 1
+minutts jobb), men vedkommende jeg snakket med kunne ikke avgjøre om
+vi kunne få disse punktene uten bruksbegrensninger.
+
+
Og tilgang uten bruksbegrensninger er viktig for OpenStreetmap.org,
+da det skal være tillatt å bruke OpenStreetmap.org-data til å lage
+kommersielle tjenester og kopiere, endre og distribuere
+OpenStreetmap.org-data uten begrensninger. Jeg gjorde det derfor
+klart for de jeg snakket med hos Kartverket at jeg kun var interessert
+i å motta data som kunne legges inn i OpenStreetmap.org uten
+bindinger. Fikk f.eks. tilbud om å få "test-data" av kommunegrensen
+for Oslo til internt bruk og måtte takke nei.
+
+
Ideen om veidatabasen var interessant, og jeg fulgte den opp
+videre. Ble satt videre til noen som kanskje kunne avgjøre om jeg
+fikk disse punktene uten bruksbegresninger, og etter en kort og
+interessant samtale fikk jeg ja til å få kopi av punktene der
+Oslogrensa krysser vei. De ble
+sendt
+til kart-listen i SOSI-format, og i løpet av noen dager brukt til
+å justere kommunegrensa for Oslo slik at den nå har nøyaktighet på
+noen meter der den krysser vei. Har fått tilbakemelding fra noen som
+har tilgang til Oslo kommunes kart at nøyaktigheten var blitt mye
+bedre. :)
+
+
Det burde ikke være nødvendig å gjøre en slik innsats for å få vite
+hvor kommunegrensene går. En skulle jo tro dette var offentlig
+informasjon uten bruksbegrensing, og Gustav Fosseid og Magne Mæhre har
+et prosjekt gående for å be om innsyn i nettopp denne informasjonen.
+De har bedt om elektronisk kopi av kartkoordinatene for
+kommunegrensene i endel kommuner på østlandet i sitt Fri Geo Norge-prosjekt, og har
+fått avslag i første instans og klagesvar fra fylkesmannen i sin klage
+på avslaget. Er spent på fortsettelsen, og gir dem all min hjelp og
+støtte i arbeidet med å få frigjort det som burde vært offentlig
+informasjon.