diff --git a/blog/After_6_years_of_waiting__the_Xreset_d_feature_is_implemented.html b/blog/After_6_years_of_waiting__the_Xreset_d_feature_is_implemented.html
index 8ae15c3d3f..26af1c352e 100644
--- a/blog/After_6_years_of_waiting__the_Xreset_d_feature_is_implemented.html
+++ b/blog/After_6_years_of_waiting__the_Xreset_d_feature_is_implemented.html
@@ -71,7 +71,7 @@ similar to how they use the Xsession.d framework today.
diff --git a/blog/Automatic_Munin_and_Nagios_configuration.html b/blog/Automatic_Munin_and_Nagios_configuration.html
index 4a723e6394..36b87c39f8 100644
--- a/blog/Automatic_Munin_and_Nagios_configuration.html
+++ b/blog/Automatic_Munin_and_Nagios_configuration.html
@@ -98,7 +98,7 @@ everything is taken care of.
diff --git a/blog/Avisene_i_endring.html b/blog/Avisene_i_endring.html
index bc64573092..47ab77e7e5 100644
--- a/blog/Avisene_i_endring.html
+++ b/blog/Avisene_i_endring.html
@@ -59,7 +59,7 @@ eksisterer. Det blir spennende å se hva vi ender opp med.
diff --git a/blog/Debian_Edu___Skolelinux_based_on_Lenny_released__work_continues.html b/blog/Debian_Edu___Skolelinux_based_on_Lenny_released__work_continues.html
index 687ba886c6..5c1fadc2a3 100644
--- a/blog/Debian_Edu___Skolelinux_based_on_Lenny_released__work_continues.html
+++ b/blog/Debian_Edu___Skolelinux_based_on_Lenny_released__work_continues.html
@@ -67,7 +67,7 @@ and have just a few weeks or months to make it happen.
diff --git a/blog/Debian_boots_quicker_and_quicker.html b/blog/Debian_boots_quicker_and_quicker.html
index 5840fe328a..c2e0303313 100644
--- a/blog/Debian_boots_quicker_and_quicker.html
+++ b/blog/Debian_boots_quicker_and_quicker.html
@@ -99,7 +99,7 @@ insserv'. Will need to test if that work. :)
diff --git a/blog/Digitale_b__ker_uten_digitale_restriksjonsmekanismer__DRM__b__r_f___mva_fritak.html b/blog/Digitale_b__ker_uten_digitale_restriksjonsmekanismer__DRM__b__r_f___mva_fritak.html
index 7d26e5bc7d..21aa2a6f80 100644
--- a/blog/Digitale_b__ker_uten_digitale_restriksjonsmekanismer__DRM__b__r_f___mva_fritak.html
+++ b/blog/Digitale_b__ker_uten_digitale_restriksjonsmekanismer__DRM__b__r_f___mva_fritak.html
@@ -84,7 +84,7 @@ der for å se hva de har.
diff --git a/blog/Digitale_restriksjonsmekanismer_fikk_meg_til____slutte____kj__pe_musikk.html b/blog/Digitale_restriksjonsmekanismer_fikk_meg_til____slutte____kj__pe_musikk.html
index 402004e522..aec99cf51c 100644
--- a/blog/Digitale_restriksjonsmekanismer_fikk_meg_til____slutte____kj__pe_musikk.html
+++ b/blog/Digitale_restriksjonsmekanismer_fikk_meg_til____slutte____kj__pe_musikk.html
@@ -76,7 +76,7 @@ Kommer neppe til å ta i bruk Blueray, og ei heller de nye DRM-greiene
diff --git a/blog/FAD_lanserer_reiseregningsskjema_som_fri_programvare.html b/blog/FAD_lanserer_reiseregningsskjema_som_fri_programvare.html
index a7027ae839..55ef4e6c69 100644
--- a/blog/FAD_lanserer_reiseregningsskjema_som_fri_programvare.html
+++ b/blog/FAD_lanserer_reiseregningsskjema_som_fri_programvare.html
@@ -130,7 +130,7 @@ gjorde det litt vanskeligere for brukeren.
diff --git a/blog/F__rste_NUUG_fordrag_sendt_p___TV.html b/blog/F__rste_NUUG_fordrag_sendt_p___TV.html
index cf0f75da03..b7e2dc9b35 100644
--- a/blog/F__rste_NUUG_fordrag_sendt_p___TV.html
+++ b/blog/F__rste_NUUG_fordrag_sendt_p___TV.html
@@ -70,7 +70,7 @@ meg, Tollef og alle andre de som deltok på møtet på TV.
diff --git a/blog/Fiksgatami_begynner____ta_form.html b/blog/Fiksgatami_begynner____ta_form.html
index 07e757777f..80fd3698c1 100644
--- a/blog/Fiksgatami_begynner____ta_form.html
+++ b/blog/Fiksgatami_begynner____ta_form.html
@@ -71,7 +71,7 @@ med dem. Dette blir bra.
diff --git a/blog/Fildeling_er_lovlig___ulovlig_fildeling_er_ulovlig.html b/blog/Fildeling_er_lovlig___ulovlig_fildeling_er_ulovlig.html
index d77602e589..0df1144292 100644
--- a/blog/Fildeling_er_lovlig___ulovlig_fildeling_er_ulovlig.html
+++ b/blog/Fildeling_er_lovlig___ulovlig_fildeling_er_ulovlig.html
@@ -69,7 +69,7 @@ og fildeling av slike filer er fullt ut lovlig.
diff --git a/blog/Frikanalen_og_jul_i_studentr__det.html b/blog/Frikanalen_og_jul_i_studentr__det.html
index 59d72b36f3..1549ecd02f 100644
--- a/blog/Frikanalen_og_jul_i_studentr__det.html
+++ b/blog/Frikanalen_og_jul_i_studentr__det.html
@@ -92,7 +92,7 @@ NUUG lykkes med å få ut sine opptak med like stor suksess.
diff --git a/blog/Hva_er_egentlig_en___pen_standard_.html b/blog/Hva_er_egentlig_en___pen_standard_.html
index 973c34afbb..333e1dbeee 100644
--- a/blog/Hva_er_egentlig_en___pen_standard_.html
+++ b/blog/Hva_er_egentlig_en___pen_standard_.html
@@ -151,7 +151,7 @@ av en standard for at en standard skal kunne kalles fri og åpen.
diff --git a/blog/Hvorfor_jeg_ikke_bruker_eFaktura.html b/blog/Hvorfor_jeg_ikke_bruker_eFaktura.html
index c9be122174..06dac48192 100644
--- a/blog/Hvorfor_jeg_ikke_bruker_eFaktura.html
+++ b/blog/Hvorfor_jeg_ikke_bruker_eFaktura.html
@@ -81,7 +81,7 @@ liker rett og slett ikke dagens faktureringsmodeller.
diff --git a/blog/IDG_mener_linux_i_servermarkedet_vil_vokse_med_21__i_2009.html b/blog/IDG_mener_linux_i_servermarkedet_vil_vokse_med_21__i_2009.html
index bdeabd5fd4..1af770c7f0 100644
--- a/blog/IDG_mener_linux_i_servermarkedet_vil_vokse_med_21__i_2009.html
+++ b/blog/IDG_mener_linux_i_servermarkedet_vil_vokse_med_21__i_2009.html
@@ -61,7 +61,7 @@ bakgrunnskunnskapen kan jeg godt tro at IDG er inne på noe.
diff --git a/blog/Idea_for_storing_LTSP_configuration_in_LDAP.html b/blog/Idea_for_storing_LTSP_configuration_in_LDAP.html
index d81ba4b3ed..0932f6e0a8 100644
--- a/blog/Idea_for_storing_LTSP_configuration_in_LDAP.html
+++ b/blog/Idea_for_storing_LTSP_configuration_in_LDAP.html
@@ -127,7 +127,7 @@ personal home page over at redhat.com.
diff --git a/blog/Internet_leverand__rer_er_ikke_vokterne_av_sine_kunders_nettbruk.html b/blog/Internet_leverand__rer_er_ikke_vokterne_av_sine_kunders_nettbruk.html
index 0344983dd6..0aea7c714d 100644
--- a/blog/Internet_leverand__rer_er_ikke_vokterne_av_sine_kunders_nettbruk.html
+++ b/blog/Internet_leverand__rer_er_ikke_vokterne_av_sine_kunders_nettbruk.html
@@ -77,7 +77,7 @@ publiseres med mer brukervennlige vilkår, som CC-BY og lignende.
diff --git a/blog/KDM_fail_at_boot_with_NVidia_cards___and_no_one_try_to_fix_it_.html b/blog/KDM_fail_at_boot_with_NVidia_cards___and_no_one_try_to_fix_it_.html
index fa3073a503..e0e933fbb0 100644
--- a/blog/KDM_fail_at_boot_with_NVidia_cards___and_no_one_try_to_fix_it_.html
+++ b/blog/KDM_fail_at_boot_with_NVidia_cards___and_no_one_try_to_fix_it_.html
@@ -76,7 +76,7 @@ but I am pretty sure that waiting for each other is not it.
diff --git a/blog/Kerberos_for_Debian_Edu_Squeeze_.html b/blog/Kerberos_for_Debian_Edu_Squeeze_.html
index 416eb98285..f02b77317b 100644
--- a/blog/Kerberos_for_Debian_Edu_Squeeze_.html
+++ b/blog/Kerberos_for_Debian_Edu_Squeeze_.html
@@ -89,7 +89,7 @@ up in a few days.
diff --git a/blog/Korrupsjon_p___h__yeste_niv___.html b/blog/Korrupsjon_p___h__yeste_niv___.html
index bdeb5988eb..e0b3d89836 100644
--- a/blog/Korrupsjon_p___h__yeste_niv___.html
+++ b/blog/Korrupsjon_p___h__yeste_niv___.html
@@ -69,7 +69,7 @@ Sverige blir søndagskolefortellinger i sammenligning.
diff --git a/blog/LUMA__a_very_nice_LDAP_GUI.html b/blog/LUMA__a_very_nice_LDAP_GUI.html
index e4947dcbdf..39b9fa95a7 100644
--- a/blog/LUMA__a_very_nice_LDAP_GUI.html
+++ b/blog/LUMA__a_very_nice_LDAP_GUI.html
@@ -83,7 +83,7 @@ changes, it will not be an option for Debian Edu based on Squeeze.
diff --git a/blog/Litt_om_valgfusk_og_problemet_med_elektronisk_stemmegiving.html b/blog/Litt_om_valgfusk_og_problemet_med_elektronisk_stemmegiving.html
index 9bc63020e6..0525630705 100644
--- a/blog/Litt_om_valgfusk_og_problemet_med_elektronisk_stemmegiving.html
+++ b/blog/Litt_om_valgfusk_og_problemet_med_elektronisk_stemmegiving.html
@@ -82,7 +82,7 @@ inneholdt i Iran hvis de ikke hadde hemmelige valg?
diff --git a/blog/Magnetstripeinnhold_i_billetter_fra_Flytoget_og_Hurtigruten.html b/blog/Magnetstripeinnhold_i_billetter_fra_Flytoget_og_Hurtigruten.html
index 6e0c4c63a6..7298358bfa 100644
--- a/blog/Magnetstripeinnhold_i_billetter_fra_Flytoget_og_Hurtigruten.html
+++ b/blog/Magnetstripeinnhold_i_billetter_fra_Flytoget_og_Hurtigruten.html
@@ -107,7 +107,7 @@ ser jeg mye korrespondanse mellom påtrykk og magnetstripe.
As reported earlier, the last few days I have looked at how Debian
+Edu clients are configured, and tried to get rid of all hardcoded
+configuration settings on the clients. I believe the work to be
+mostly done, and the clients seem to work just fine with dynamically
+generated configuration.
+
+
What is the point, you might ask? The point is to allow a Debian
+Edu desktop to integrate into an existing network infrastructure
+without any manual configuration.
+
+
This is what happens when installing a Debian Edu client here at
+the University of Oslo using PXE. With the PXE installation, I am
+asked for language (Norwegian Bokmål), locality (Norway) and keyboard
+layout (no-latin1), Debian Edu profile (Roaming Workstation), if I
+accept to reformat the hard drive (yes), if I want to submit info to
+popcon.debian.org (no) and root password (secret). After answering
+these questions, the installer goes ahead and does its thing, and
+after around 50 minutes it is done. I press enter to finish the
+installation, and the machine reboots into KDE. When the machine is
+ready and kdm asks for login information, I enter my university
+username and password, am told by kdm that a local home directory has
+been created and that I must log in again, and finally log in with the
+same username and password to the KDE 4.4 desktop. At no point during
+this process did it ask for university specific settings, and all the
+required configuration was dynamically detected using information
+fetched via DHCP and DNS. The roaming workstation is now ready for
+use.
+
+
How was this done, you might wonder? First of all, here is the
+list of things that need to be configured on the client to get it
+working properly out of the box:
+
+
+
IP address/netmask and DNS server.
+
Web proxy URL.
+
LDAP server for NSS directory information (user, group, etc).
+
Kerberos server for PAM password checking.
+
SMB mount point to access the network home directory. (*)
+
Central syslog server to send syslog messages to. (*)
+
Sitesummary collector URL to submit info to central server. (*)
+
+
+
(Hm, did I forget anything? Let me knew if I did.)
+
+
The points marked (*) are not required to be able to use the
+machine, but needed to provide central storage and allowing system
+administrators to track their machines. Since yesterday, everything
+but the sitesummary collector URL is dynamically discovered at boot
+and installation time in the svn version of Debian Edu.
+
+
The IP and DNS setup is fetched during boot using DHCP as usual.
+When a DHCP update arrives, the proxy setup is updated by looking for
+http://wpat/wpad.dat and using the content of this WPAD file to
+configure the http and ftp proxy in /etc/environment and
+/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP
+hook to ensure that the client stops using the Debian Edu proxy when
+it is moved outside the Debian Edu network, and instead uses any local
+proxy present on the new network when it moves around.
+
+
The DNS names of the LDAP, Kerberos and syslog server and related
+configuration are generated using DNS information at boot. First the
+installer looks for a host named ldap in the current DNS domain. If
+not found, it looks for _ldap._tcp SRV records in DNS instead. If an
+LDAP server is found, its root DSE entry is requested and the
+attributes namingContexts and defaultNamingContext are used to
+determine which LDAP base to use for NSS. If there are several
+namingContexts attibutes and the defaultNamingContext is present, that
+LDAP subtree is used as the base. If defaultNamingContext is missing,
+the subtrees listed as namingContexts are searched in sequence for any
+object with class posixAccount or posixGroup, and the first one with
+such an object is used as the LDAP base. For Kerberos, a similar
+search is done by first looking for a host named kerberos, and then
+for the _kerberos._tcp SRV record. I've been unable to find a way to
+look up the Kerberos realm, so for this the upper case string of the
+current DNS domain is used.
+
+
For the syslog server, the hosts syslog and loghost are searched
+for, and the _syslog._udp SRV record is consulted if no such host is
+found. This algorithm works for both Debian Edu and the University of
+Oslo. A similar strategy would work for locating the sitesummary
+server, but have not been implemented yet. I decided to fetch and
+save these settings during installation, to make sure moving to a
+different network does not change the set of users being allowed to
+log in nor the passwords required to log in. Usernames and passwords
+will be cached by sssd when the user logs in on the Debian Edu
+network, and will not change as the laptop move around. For a
+non-roaming machine, there is no caching, but given that it is
+supposed to stay in place it should not matter much. Perhaps we
+should switch those to use sssd too?
+
+
The user's SMB mount point for the network home directory is
+located when the user logs in for the first time. The LDAP server is
+consulted to look for the user's LDAP object and the sambaHomePath
+attribute is used if found. If it isn't found, the home directory
+path fetched from NSS is used instead. Assuming the path is of the
+form /site/server/directory/username, the second part is looked up in
+DNS and used to generate a SMB URL of the form
+smb://server.domain/username. This algorithm works for both Debian
+edu and the University of Oslo. Perhaps there are better attributes
+to use or a better algorithm that works for more sites, but this will
+do for now. :)
+
+
This work should make it easier to integrate the Debian Edu clients
+into any LDAP/Kerberos infrastructure, and make the current setup even
+more flexible than before. I suspect it will also work for thin
+client servers, allowing one to easily set up LTSP and hook it into a
+existing network infrastructure, but I have not had time to test this
+yet.
+
+
If you want to help out with implementing these things for Debian
+Edu, please contact us on debian-edu@lists.debian.org.
diff --git a/blog/Norge_trenger_en_personvernforening.html b/blog/Norge_trenger_en_personvernforening.html
index 9cb601a8d1..05f63a1757 100644
--- a/blog/Norge_trenger_en_personvernforening.html
+++ b/blog/Norge_trenger_en_personvernforening.html
@@ -66,7 +66,7 @@ nå får vi se om noen er enig.
diff --git a/blog/Opphavet_til_Skolelinux_prosjektet.html b/blog/Opphavet_til_Skolelinux_prosjektet.html
index c97a4e9f51..6c374395f2 100644
--- a/blog/Opphavet_til_Skolelinux_prosjektet.html
+++ b/blog/Opphavet_til_Skolelinux_prosjektet.html
@@ -81,7 +81,7 @@ Resten er historie. :)
diff --git a/blog/Parallellized_boot_is_now_the_default_in_Debian_unstable.html b/blog/Parallellized_boot_is_now_the_default_in_Debian_unstable.html
index 7bba169c6b..6c0bd46be8 100644
--- a/blog/Parallellized_boot_is_now_the_default_in_Debian_unstable.html
+++ b/blog/Parallellized_boot_is_now_the_default_in_Debian_unstable.html
@@ -79,7 +79,7 @@ list of usertagged bugs related to this.
diff --git a/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html b/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html
index 7c06a1a036..838163adc5 100644
--- a/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html
+++ b/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html
@@ -92,7 +92,7 @@ list of usertagged bugs related to this.
diff --git a/blog/Parallellizing_the_boot_in_Debian_Squeeze___ready_for_wider_testing.html b/blog/Parallellizing_the_boot_in_Debian_Squeeze___ready_for_wider_testing.html
index ea3e3c3c9d..db7bcdc781 100644
--- a/blog/Parallellizing_the_boot_in_Debian_Squeeze___ready_for_wider_testing.html
+++ b/blog/Parallellizing_the_boot_in_Debian_Squeeze___ready_for_wider_testing.html
@@ -88,7 +88,7 @@ list of usertagged bugs related to this.
diff --git a/blog/Regjerningen_forlater_prinsippet_om_ingen_royalty_betaling_i_standardkatalogen_versjon_2.html b/blog/Regjerningen_forlater_prinsippet_om_ingen_royalty_betaling_i_standardkatalogen_versjon_2.html
index 4536886d0b..885c461bd8 100644
--- a/blog/Regjerningen_forlater_prinsippet_om_ingen_royalty_betaling_i_standardkatalogen_versjon_2.html
+++ b/blog/Regjerningen_forlater_prinsippet_om_ingen_royalty_betaling_i_standardkatalogen_versjon_2.html
@@ -82,7 +82,7 @@ høringsuttalelse, men ser ut til å ha blitt ignorert.
diff --git a/blog/Reprap_bygging_i_p__sken.html b/blog/Reprap_bygging_i_p__sken.html
index 66e23f5dd7..23e967a6e0 100644
--- a/blog/Reprap_bygging_i_p__sken.html
+++ b/blog/Reprap_bygging_i_p__sken.html
@@ -106,7 +106,7 @@ kommer til å bruke denne plasttypen som håndterer temperaturer mellom
diff --git a/blog/Reprap_pakke_tapt_i_posten.html b/blog/Reprap_pakke_tapt_i_posten.html
index 719769e16c..77f789adba 100644
--- a/blog/Reprap_pakke_tapt_i_posten.html
+++ b/blog/Reprap_pakke_tapt_i_posten.html
@@ -62,7 +62,7 @@ lenge alt er klart til Go Open
diff --git a/blog/Sikkerhet_til_sj__s_trenger_sj__kart_uten_bruksbegresninger.html b/blog/Sikkerhet_til_sj__s_trenger_sj__kart_uten_bruksbegresninger.html
index 43797b7df3..a42dcd13c1 100644
--- a/blog/Sikkerhet_til_sj__s_trenger_sj__kart_uten_bruksbegresninger.html
+++ b/blog/Sikkerhet_til_sj__s_trenger_sj__kart_uten_bruksbegresninger.html
@@ -106,7 +106,7 @@ det viser at behovet for fribruks-sjøkart er til stedet.
diff --git a/blog/Standardize_on_protocols_and_formats__not_vendors_and_applications.html b/blog/Standardize_on_protocols_and_formats__not_vendors_and_applications.html
index c500bce08d..f7ee4f04fb 100644
--- a/blog/Standardize_on_protocols_and_formats__not_vendors_and_applications.html
+++ b/blog/Standardize_on_protocols_and_formats__not_vendors_and_applications.html
@@ -78,7 +78,7 @@ application that do not use open network protocol or open formats.
diff --git a/blog/Taking_over_sysvinit_development.html b/blog/Taking_over_sysvinit_development.html
index 9552222f10..a5c614b698 100644
--- a/blog/Taking_over_sysvinit_development.html
+++ b/blog/Taking_over_sysvinit_development.html
@@ -75,7 +75,7 @@ distributions are moving to upstart as a syvinit replacement.
diff --git a/blog/The_sorry_state_of_multimedia_browser_plugins_in_Debian.html b/blog/The_sorry_state_of_multimedia_browser_plugins_in_Debian.html
index 005320dabf..9e00438fb1 100644
--- a/blog/The_sorry_state_of_multimedia_browser_plugins_in_Debian.html
+++ b/blog/The_sorry_state_of_multimedia_browser_plugins_in_Debian.html
@@ -71,7 +71,7 @@ be the only one fitting our needs. :/
diff --git a/blog/Vitenskapens_dogmer___.html b/blog/Vitenskapens_dogmer___.html
index b4d59e69a3..e169e497e7 100644
--- a/blog/Vitenskapens_dogmer___.html
+++ b/blog/Vitenskapens_dogmer___.html
@@ -121,7 +121,7 @@ skyskrapere. Takke meg til en tur til månen.
diff --git a/blog/When_web_browser_developers_make_a_video_player___.html b/blog/When_web_browser_developers_make_a_video_player___.html
index 99dc0b8318..929e7b57fa 100644
--- a/blog/When_web_browser_developers_make_a_video_player___.html
+++ b/blog/When_web_browser_developers_make_a_video_player___.html
@@ -95,7 +95,7 @@ sure hope it was using the announced Ogg Theora support. :)
diff --git a/blog/archive/2008/11/index.html b/blog/archive/2008/11/index.html
index e10ada30ff..a192a184d5 100644
--- a/blog/archive/2008/11/index.html
+++ b/blog/archive/2008/11/index.html
@@ -216,7 +216,7 @@ lenge alt er klart til Go Open
diff --git a/blog/archive/2009/03/index.html b/blog/archive/2009/03/index.html
index 81ec81608b..ff412095f5 100644
--- a/blog/archive/2009/03/index.html
+++ b/blog/archive/2009/03/index.html
@@ -716,7 +716,7 @@ application that do not use open network protocol or open formats.
diff --git a/blog/archive/2009/08/index.html b/blog/archive/2009/08/index.html
index fe266f4627..2c2e172f33 100644
--- a/blog/archive/2009/08/index.html
+++ b/blog/archive/2009/08/index.html
@@ -229,7 +229,7 @@ det viser at behovet for fribruks-sjøkart er til stedet.
diff --git a/blog/archive/2010/02/index.html b/blog/archive/2010/02/index.html
index d8011f63fd..b772345e53 100644
--- a/blog/archive/2010/02/index.html
+++ b/blog/archive/2010/02/index.html
@@ -82,7 +82,7 @@ and have just a few weeks or months to make it happen.
diff --git a/blog/archive/2010/05/index.html b/blog/archive/2010/05/index.html
index 42f80a2866..03e0e363ae 100644
--- a/blog/archive/2010/05/index.html
+++ b/blog/archive/2010/05/index.html
@@ -617,7 +617,7 @@ list of usertagged bugs related to this.
diff --git a/blog/archive/2010/06/index.html b/blog/archive/2010/06/index.html
index 16730512d8..cc0d6ce5a3 100644
--- a/blog/archive/2010/06/index.html
+++ b/blog/archive/2010/06/index.html
@@ -1016,7 +1016,7 @@ changes, it will not be an option for Debian Edu based on Squeeze.
diff --git a/blog/archive/2010/08/08.rss b/blog/archive/2010/08/08.rss
index 585a0b050b..680e0f0431 100644
--- a/blog/archive/2010/08/08.rss
+++ b/blog/archive/2010/08/08.rss
@@ -333,5 +333,125 @@ it. :)</p>
+
+ No hardcoded config on Debian Edu clients
+ http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html
+ http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html
+ Mon, 9 Aug 2010 20:15:00 +0200
+
+<p>As reported earlier, the last few days I have looked at how Debian
+Edu clients are configured, and tried to get rid of all hardcoded
+configuration settings on the clients. I believe the work to be
+mostly done, and the clients seem to work just fine with dynamically
+generated configuration.</p>
+
+<p>What is the point, you might ask? The point is to allow a Debian
+Edu desktop to integrate into an existing network infrastructure
+without any manual configuration.</p>
+
+<p>This is what happens when installing a Debian Edu client here at
+the University of Oslo using PXE. With the PXE installation, I am
+asked for language (Norwegian Bokmål), locality (Norway) and keyboard
+layout (no-latin1), Debian Edu profile (Roaming Workstation), if I
+accept to reformat the hard drive (yes), if I want to submit info to
+popcon.debian.org (no) and root password (secret). After answering
+these questions, the installer goes ahead and does its thing, and
+after around 50 minutes it is done. I press enter to finish the
+installation, and the machine reboots into KDE. When the machine is
+ready and kdm asks for login information, I enter my university
+username and password, am told by kdm that a local home directory has
+been created and that I must log in again, and finally log in with the
+same username and password to the KDE 4.4 desktop. At no point during
+this process did it ask for university specific settings, and all the
+required configuration was dynamically detected using information
+fetched via DHCP and DNS. The roaming workstation is now ready for
+use.</p>
+
+<p>How was this done, you might wonder? First of all, here is the
+list of things that need to be configured on the client to get it
+working properly out of the box:</p>
+
+<ul>
+<li>IP address/netmask and DNS server.</li>
+<li>Web proxy URL.</li>
+<li>LDAP server for NSS directory information (user, group, etc).</li>
+<li>Kerberos server for PAM password checking.</li>
+<li>SMB mount point to access the network home directory. (*)</li>
+<li>Central syslog server to send syslog messages to. (*)</li>
+<li>Sitesummary collector URL to submit info to central server. (*)</li>
+</ul>
+
+<p>(Hm, did I forget anything? Let me knew if I did.)</p>
+
+<p>The points marked (*) are not required to be able to use the
+machine, but needed to provide central storage and allowing system
+administrators to track their machines. Since yesterday, everything
+but the sitesummary collector URL is dynamically discovered at boot
+and installation time in the svn version of Debian Edu.</p>
+
+<p>The IP and DNS setup is fetched during boot using DHCP as usual.
+When a DHCP update arrives, the proxy setup is updated by looking for
+http://wpat/wpad.dat and using the content of this WPAD file to
+configure the http and ftp proxy in /etc/environment and
+/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP
+hook to ensure that the client stops using the Debian Edu proxy when
+it is moved outside the Debian Edu network, and instead uses any local
+proxy present on the new network when it moves around.</p>
+
+<p>The DNS names of the LDAP, Kerberos and syslog server and related
+configuration are generated using DNS information at boot. First the
+installer looks for a host named ldap in the current DNS domain. If
+not found, it looks for _ldap._tcp SRV records in DNS instead. If an
+LDAP server is found, its root DSE entry is requested and the
+attributes namingContexts and defaultNamingContext are used to
+determine which LDAP base to use for NSS. If there are several
+namingContexts attibutes and the defaultNamingContext is present, that
+LDAP subtree is used as the base. If defaultNamingContext is missing,
+the subtrees listed as namingContexts are searched in sequence for any
+object with class posixAccount or posixGroup, and the first one with
+such an object is used as the LDAP base. For Kerberos, a similar
+search is done by first looking for a host named kerberos, and then
+for the _kerberos._tcp SRV record. I've been unable to find a way to
+look up the Kerberos realm, so for this the upper case string of the
+current DNS domain is used.</p>
+
+<p>For the syslog server, the hosts syslog and loghost are searched
+for, and the _syslog._udp SRV record is consulted if no such host is
+found. This algorithm works for both Debian Edu and the University of
+Oslo. A similar strategy would work for locating the sitesummary
+server, but have not been implemented yet. I decided to fetch and
+save these settings during installation, to make sure moving to a
+different network does not change the set of users being allowed to
+log in nor the passwords required to log in. Usernames and passwords
+will be cached by sssd when the user logs in on the Debian Edu
+network, and will not change as the laptop move around. For a
+non-roaming machine, there is no caching, but given that it is
+supposed to stay in place it should not matter much. Perhaps we
+should switch those to use sssd too?</p>
+
+<p>The user's SMB mount point for the network home directory is
+located when the user logs in for the first time. The LDAP server is
+consulted to look for the user's LDAP object and the sambaHomePath
+attribute is used if found. If it isn't found, the home directory
+path fetched from NSS is used instead. Assuming the path is of the
+form /site/server/directory/username, the second part is looked up in
+DNS and used to generate a SMB URL of the form
+smb://server.domain/username. This algorithm works for both Debian
+edu and the University of Oslo. Perhaps there are better attributes
+to use or a better algorithm that works for more sites, but this will
+do for now. :)</p>
+
+<p>This work should make it easier to integrate the Debian Edu clients
+into any LDAP/Kerberos infrastructure, and make the current setup even
+more flexible than before. I suspect it will also work for thin
+client servers, allowing one to easily set up LTSP and hook it into a
+existing network infrastructure, but I have not had time to test this
+yet.</p>
+
+<p>If you want to help out with implementing these things for Debian
+Edu, please contact us on debian-edu@lists.debian.org.</p>
+
+
+
diff --git a/blog/archive/2010/08/index.html b/blog/archive/2010/08/index.html
index a7a068cec3..606cc1fec5 100644
--- a/blog/archive/2010/08/index.html
+++ b/blog/archive/2010/08/index.html
@@ -380,6 +380,139 @@ it. :)
+ Tags: debian edu, english, nuug.
+
+
+
+
+
+
As reported earlier, the last few days I have looked at how Debian
+Edu clients are configured, and tried to get rid of all hardcoded
+configuration settings on the clients. I believe the work to be
+mostly done, and the clients seem to work just fine with dynamically
+generated configuration.
+
+
What is the point, you might ask? The point is to allow a Debian
+Edu desktop to integrate into an existing network infrastructure
+without any manual configuration.
+
+
This is what happens when installing a Debian Edu client here at
+the University of Oslo using PXE. With the PXE installation, I am
+asked for language (Norwegian Bokmål), locality (Norway) and keyboard
+layout (no-latin1), Debian Edu profile (Roaming Workstation), if I
+accept to reformat the hard drive (yes), if I want to submit info to
+popcon.debian.org (no) and root password (secret). After answering
+these questions, the installer goes ahead and does its thing, and
+after around 50 minutes it is done. I press enter to finish the
+installation, and the machine reboots into KDE. When the machine is
+ready and kdm asks for login information, I enter my university
+username and password, am told by kdm that a local home directory has
+been created and that I must log in again, and finally log in with the
+same username and password to the KDE 4.4 desktop. At no point during
+this process did it ask for university specific settings, and all the
+required configuration was dynamically detected using information
+fetched via DHCP and DNS. The roaming workstation is now ready for
+use.
+
+
How was this done, you might wonder? First of all, here is the
+list of things that need to be configured on the client to get it
+working properly out of the box:
+
+
+
IP address/netmask and DNS server.
+
Web proxy URL.
+
LDAP server for NSS directory information (user, group, etc).
+
Kerberos server for PAM password checking.
+
SMB mount point to access the network home directory. (*)
+
Central syslog server to send syslog messages to. (*)
+
Sitesummary collector URL to submit info to central server. (*)
+
+
+
(Hm, did I forget anything? Let me knew if I did.)
+
+
The points marked (*) are not required to be able to use the
+machine, but needed to provide central storage and allowing system
+administrators to track their machines. Since yesterday, everything
+but the sitesummary collector URL is dynamically discovered at boot
+and installation time in the svn version of Debian Edu.
+
+
The IP and DNS setup is fetched during boot using DHCP as usual.
+When a DHCP update arrives, the proxy setup is updated by looking for
+http://wpat/wpad.dat and using the content of this WPAD file to
+configure the http and ftp proxy in /etc/environment and
+/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP
+hook to ensure that the client stops using the Debian Edu proxy when
+it is moved outside the Debian Edu network, and instead uses any local
+proxy present on the new network when it moves around.
+
+
The DNS names of the LDAP, Kerberos and syslog server and related
+configuration are generated using DNS information at boot. First the
+installer looks for a host named ldap in the current DNS domain. If
+not found, it looks for _ldap._tcp SRV records in DNS instead. If an
+LDAP server is found, its root DSE entry is requested and the
+attributes namingContexts and defaultNamingContext are used to
+determine which LDAP base to use for NSS. If there are several
+namingContexts attibutes and the defaultNamingContext is present, that
+LDAP subtree is used as the base. If defaultNamingContext is missing,
+the subtrees listed as namingContexts are searched in sequence for any
+object with class posixAccount or posixGroup, and the first one with
+such an object is used as the LDAP base. For Kerberos, a similar
+search is done by first looking for a host named kerberos, and then
+for the _kerberos._tcp SRV record. I've been unable to find a way to
+look up the Kerberos realm, so for this the upper case string of the
+current DNS domain is used.
+
+
For the syslog server, the hosts syslog and loghost are searched
+for, and the _syslog._udp SRV record is consulted if no such host is
+found. This algorithm works for both Debian Edu and the University of
+Oslo. A similar strategy would work for locating the sitesummary
+server, but have not been implemented yet. I decided to fetch and
+save these settings during installation, to make sure moving to a
+different network does not change the set of users being allowed to
+log in nor the passwords required to log in. Usernames and passwords
+will be cached by sssd when the user logs in on the Debian Edu
+network, and will not change as the laptop move around. For a
+non-roaming machine, there is no caching, but given that it is
+supposed to stay in place it should not matter much. Perhaps we
+should switch those to use sssd too?
+
+
The user's SMB mount point for the network home directory is
+located when the user logs in for the first time. The LDAP server is
+consulted to look for the user's LDAP object and the sambaHomePath
+attribute is used if found. If it isn't found, the home directory
+path fetched from NSS is used instead. Assuming the path is of the
+form /site/server/directory/username, the second part is looked up in
+DNS and used to generate a SMB URL of the form
+smb://server.domain/username. This algorithm works for both Debian
+edu and the University of Oslo. Perhaps there are better attributes
+to use or a better algorithm that works for more sites, but this will
+do for now. :)
+
+
This work should make it easier to integrate the Debian Edu clients
+into any LDAP/Kerberos infrastructure, and make the current setup even
+more flexible than before. I suspect it will also work for thin
+client servers, allowing one to easily set up LTSP and hook it into a
+existing network infrastructure, but I have not had time to test this
+yet.
+
+
If you want to help out with implementing these things for Debian
+Edu, please contact us on debian-edu@lists.debian.org.
As reported earlier, the last few days I have looked at how Debian
+Edu clients are configured, and tried to get rid of all hardcoded
+configuration settings on the clients. I believe the work to be
+mostly done, and the clients seem to work just fine with dynamically
+generated configuration.
+
+
What is the point, you might ask? The point is to allow a Debian
+Edu desktop to integrate into an existing network infrastructure
+without any manual configuration.
+
+
This is what happens when installing a Debian Edu client here at
+the University of Oslo using PXE. With the PXE installation, I am
+asked for language (Norwegian Bokmål), locality (Norway) and keyboard
+layout (no-latin1), Debian Edu profile (Roaming Workstation), if I
+accept to reformat the hard drive (yes), if I want to submit info to
+popcon.debian.org (no) and root password (secret). After answering
+these questions, the installer goes ahead and does its thing, and
+after around 50 minutes it is done. I press enter to finish the
+installation, and the machine reboots into KDE. When the machine is
+ready and kdm asks for login information, I enter my university
+username and password, am told by kdm that a local home directory has
+been created and that I must log in again, and finally log in with the
+same username and password to the KDE 4.4 desktop. At no point during
+this process did it ask for university specific settings, and all the
+required configuration was dynamically detected using information
+fetched via DHCP and DNS. The roaming workstation is now ready for
+use.
+
+
How was this done, you might wonder? First of all, here is the
+list of things that need to be configured on the client to get it
+working properly out of the box:
+
+
+
IP address/netmask and DNS server.
+
Web proxy URL.
+
LDAP server for NSS directory information (user, group, etc).
+
Kerberos server for PAM password checking.
+
SMB mount point to access the network home directory. (*)
+
Central syslog server to send syslog messages to. (*)
+
Sitesummary collector URL to submit info to central server. (*)
+
+
+
(Hm, did I forget anything? Let me knew if I did.)
+
+
The points marked (*) are not required to be able to use the
+machine, but needed to provide central storage and allowing system
+administrators to track their machines. Since yesterday, everything
+but the sitesummary collector URL is dynamically discovered at boot
+and installation time in the svn version of Debian Edu.
+
+
The IP and DNS setup is fetched during boot using DHCP as usual.
+When a DHCP update arrives, the proxy setup is updated by looking for
+http://wpat/wpad.dat and using the content of this WPAD file to
+configure the http and ftp proxy in /etc/environment and
+/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP
+hook to ensure that the client stops using the Debian Edu proxy when
+it is moved outside the Debian Edu network, and instead uses any local
+proxy present on the new network when it moves around.
+
+
The DNS names of the LDAP, Kerberos and syslog server and related
+configuration are generated using DNS information at boot. First the
+installer looks for a host named ldap in the current DNS domain. If
+not found, it looks for _ldap._tcp SRV records in DNS instead. If an
+LDAP server is found, its root DSE entry is requested and the
+attributes namingContexts and defaultNamingContext are used to
+determine which LDAP base to use for NSS. If there are several
+namingContexts attibutes and the defaultNamingContext is present, that
+LDAP subtree is used as the base. If defaultNamingContext is missing,
+the subtrees listed as namingContexts are searched in sequence for any
+object with class posixAccount or posixGroup, and the first one with
+such an object is used as the LDAP base. For Kerberos, a similar
+search is done by first looking for a host named kerberos, and then
+for the _kerberos._tcp SRV record. I've been unable to find a way to
+look up the Kerberos realm, so for this the upper case string of the
+current DNS domain is used.
+
+
For the syslog server, the hosts syslog and loghost are searched
+for, and the _syslog._udp SRV record is consulted if no such host is
+found. This algorithm works for both Debian Edu and the University of
+Oslo. A similar strategy would work for locating the sitesummary
+server, but have not been implemented yet. I decided to fetch and
+save these settings during installation, to make sure moving to a
+different network does not change the set of users being allowed to
+log in nor the passwords required to log in. Usernames and passwords
+will be cached by sssd when the user logs in on the Debian Edu
+network, and will not change as the laptop move around. For a
+non-roaming machine, there is no caching, but given that it is
+supposed to stay in place it should not matter much. Perhaps we
+should switch those to use sssd too?
+
+
The user's SMB mount point for the network home directory is
+located when the user logs in for the first time. The LDAP server is
+consulted to look for the user's LDAP object and the sambaHomePath
+attribute is used if found. If it isn't found, the home directory
+path fetched from NSS is used instead. Assuming the path is of the
+form /site/server/directory/username, the second part is looked up in
+DNS and used to generate a SMB URL of the form
+smb://server.domain/username. This algorithm works for both Debian
+edu and the University of Oslo. Perhaps there are better attributes
+to use or a better algorithm that works for more sites, but this will
+do for now. :)
+
+
This work should make it easier to integrate the Debian Edu clients
+into any LDAP/Kerberos infrastructure, and make the current setup even
+more flexible than before. I suspect it will also work for thin
+client servers, allowing one to easily set up LTSP and hook it into a
+existing network infrastructure, but I have not had time to test this
+yet.
+
+
If you want to help out with implementing these things for Debian
+Edu, please contact us on debian-edu@lists.debian.org.
For a while now, I have wanted to find a way to change the DNS and
-DHCP services in Debian Edu to use the same LDAP objects for a given
-computer, to avoid the possibility of having a inconsistent state for
-a computer in LDAP (as in DHCP but no DNS entry or the other way
-around) and make it easier to add computers to LDAP.
-
-
I've looked at how powerdns and dhcpd is using LDAP, and using this
-information finally found a solution that seem to work.
-
-
The old setup required three LDAP objects for a given computer.
-One forward DNS entry, one reverse DNS entry and one DHCP entry. If
-we switch powerdns to use its strict LDAP method (ldap-method=strict
-in pdns-debian-edu.conf), the forward and reverse DNS entries are
-merged into one while making it impossible to transfer the reverse map
-to a slave DNS server.
-
-
If we also replace the object class used to get the DNS related
-attributes to one allowing these attributes to be combined with the
-dhcphost object class, we can merge the DNS and DHCP entries into one.
-I've written such object class in the dnsdomainaux.schema file (need
-proper OIDs, but that is a minor issue), and tested the setup. It
-seem to work.
-
-
With this test setup in place, we can get away with one LDAP object
-for both DNS and DHCP, and even the LTSP configuration I suggested in
-an earlier email. The combined LDAP object will look something like
-this:
The DNS server uses the associateddomain and arecord entries, while
-the DHCP server uses the dhcphwaddress and dhcpstatements entries
-before asking DNS to resolve the fixed-adddress. LTSP will use
-dhcphwaddress or associateddomain and the ldapconfig* attributes.
-
-
I am not yet sure if I can get the DHCP server to look for its
-dhcphost in a different location, to allow us to put the objects
-outside the "DHCP Config" subtree, but hope to figure out a way to do
-that. If I can't figure out a way to do that, we can still get rid of
-the hosts subtree and move all its content into the DHCP Config tree
-(which probably should be renamed to be more related to the new
-content. I suspect cn=dnsdhcp,ou=services or something like that
-might be a good place to put it.
-
-
If you want to help out with implementing this for Debian Edu,
-please contact us on debian-edu@lists.debian.org.
diff --git a/blog/index.rss b/blog/index.rss
index 38857dcdbd..8f2094baa9 100644
--- a/blog/index.rss
+++ b/blog/index.rss
@@ -6,6 +6,126 @@
http://people.skolelinux.org/pere/blog/
+
+ No hardcoded config on Debian Edu clients
+ http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html
+ http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html
+ Mon, 9 Aug 2010 20:15:00 +0200
+
+<p>As reported earlier, the last few days I have looked at how Debian
+Edu clients are configured, and tried to get rid of all hardcoded
+configuration settings on the clients. I believe the work to be
+mostly done, and the clients seem to work just fine with dynamically
+generated configuration.</p>
+
+<p>What is the point, you might ask? The point is to allow a Debian
+Edu desktop to integrate into an existing network infrastructure
+without any manual configuration.</p>
+
+<p>This is what happens when installing a Debian Edu client here at
+the University of Oslo using PXE. With the PXE installation, I am
+asked for language (Norwegian Bokmål), locality (Norway) and keyboard
+layout (no-latin1), Debian Edu profile (Roaming Workstation), if I
+accept to reformat the hard drive (yes), if I want to submit info to
+popcon.debian.org (no) and root password (secret). After answering
+these questions, the installer goes ahead and does its thing, and
+after around 50 minutes it is done. I press enter to finish the
+installation, and the machine reboots into KDE. When the machine is
+ready and kdm asks for login information, I enter my university
+username and password, am told by kdm that a local home directory has
+been created and that I must log in again, and finally log in with the
+same username and password to the KDE 4.4 desktop. At no point during
+this process did it ask for university specific settings, and all the
+required configuration was dynamically detected using information
+fetched via DHCP and DNS. The roaming workstation is now ready for
+use.</p>
+
+<p>How was this done, you might wonder? First of all, here is the
+list of things that need to be configured on the client to get it
+working properly out of the box:</p>
+
+<ul>
+<li>IP address/netmask and DNS server.</li>
+<li>Web proxy URL.</li>
+<li>LDAP server for NSS directory information (user, group, etc).</li>
+<li>Kerberos server for PAM password checking.</li>
+<li>SMB mount point to access the network home directory. (*)</li>
+<li>Central syslog server to send syslog messages to. (*)</li>
+<li>Sitesummary collector URL to submit info to central server. (*)</li>
+</ul>
+
+<p>(Hm, did I forget anything? Let me knew if I did.)</p>
+
+<p>The points marked (*) are not required to be able to use the
+machine, but needed to provide central storage and allowing system
+administrators to track their machines. Since yesterday, everything
+but the sitesummary collector URL is dynamically discovered at boot
+and installation time in the svn version of Debian Edu.</p>
+
+<p>The IP and DNS setup is fetched during boot using DHCP as usual.
+When a DHCP update arrives, the proxy setup is updated by looking for
+http://wpat/wpad.dat and using the content of this WPAD file to
+configure the http and ftp proxy in /etc/environment and
+/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP
+hook to ensure that the client stops using the Debian Edu proxy when
+it is moved outside the Debian Edu network, and instead uses any local
+proxy present on the new network when it moves around.</p>
+
+<p>The DNS names of the LDAP, Kerberos and syslog server and related
+configuration are generated using DNS information at boot. First the
+installer looks for a host named ldap in the current DNS domain. If
+not found, it looks for _ldap._tcp SRV records in DNS instead. If an
+LDAP server is found, its root DSE entry is requested and the
+attributes namingContexts and defaultNamingContext are used to
+determine which LDAP base to use for NSS. If there are several
+namingContexts attibutes and the defaultNamingContext is present, that
+LDAP subtree is used as the base. If defaultNamingContext is missing,
+the subtrees listed as namingContexts are searched in sequence for any
+object with class posixAccount or posixGroup, and the first one with
+such an object is used as the LDAP base. For Kerberos, a similar
+search is done by first looking for a host named kerberos, and then
+for the _kerberos._tcp SRV record. I've been unable to find a way to
+look up the Kerberos realm, so for this the upper case string of the
+current DNS domain is used.</p>
+
+<p>For the syslog server, the hosts syslog and loghost are searched
+for, and the _syslog._udp SRV record is consulted if no such host is
+found. This algorithm works for both Debian Edu and the University of
+Oslo. A similar strategy would work for locating the sitesummary
+server, but have not been implemented yet. I decided to fetch and
+save these settings during installation, to make sure moving to a
+different network does not change the set of users being allowed to
+log in nor the passwords required to log in. Usernames and passwords
+will be cached by sssd when the user logs in on the Debian Edu
+network, and will not change as the laptop move around. For a
+non-roaming machine, there is no caching, but given that it is
+supposed to stay in place it should not matter much. Perhaps we
+should switch those to use sssd too?</p>
+
+<p>The user's SMB mount point for the network home directory is
+located when the user logs in for the first time. The LDAP server is
+consulted to look for the user's LDAP object and the sambaHomePath
+attribute is used if found. If it isn't found, the home directory
+path fetched from NSS is used instead. Assuming the path is of the
+form /site/server/directory/username, the second part is looked up in
+DNS and used to generate a SMB URL of the form
+smb://server.domain/username. This algorithm works for both Debian
+edu and the University of Oslo. Perhaps there are better attributes
+to use or a better algorithm that works for more sites, but this will
+do for now. :)</p>
+
+<p>This work should make it easier to integrate the Debian Edu clients
+into any LDAP/Kerberos infrastructure, and make the current setup even
+more flexible than before. I suspect it will also work for thin
+client servers, allowing one to easily set up LTSP and hook it into a
+existing network infrastructure, but I have not had time to test this
+yet.</p>
+
+<p>If you want to help out with implementing these things for Debian
+Edu, please contact us on debian-edu@lists.debian.org.</p>
+
+
+
Testing if a file system can be used for home directories...
http://people.skolelinux.org/pere/blog/Testing_if_a_file_system_can_be_used_for_home_directories___.html
@@ -931,71 +1051,5 @@ auxiliary object class.</p>
-
- Combining PowerDNS and ISC DHCP LDAP objects
- http://people.skolelinux.org/pere/blog/Combining_PowerDNS_and_ISC_DHCP_LDAP_objects.html
- http://people.skolelinux.org/pere/blog/Combining_PowerDNS_and_ISC_DHCP_LDAP_objects.html
- Wed, 14 Jul 2010 23:45:00 +0200
-
-<p>For a while now, I have wanted to find a way to change the DNS and
-DHCP services in Debian Edu to use the same LDAP objects for a given
-computer, to avoid the possibility of having a inconsistent state for
-a computer in LDAP (as in DHCP but no DNS entry or the other way
-around) and make it easier to add computers to LDAP.</p>
-
-<p>I've looked at how powerdns and dhcpd is using LDAP, and using this
-information finally found a solution that seem to work.</p>
-
-<p>The old setup required three LDAP objects for a given computer.
-One forward DNS entry, one reverse DNS entry and one DHCP entry. If
-we switch powerdns to use its strict LDAP method (ldap-method=strict
-in pdns-debian-edu.conf), the forward and reverse DNS entries are
-merged into one while making it impossible to transfer the reverse map
-to a slave DNS server.</p>
-
-<p>If we also replace the object class used to get the DNS related
-attributes to one allowing these attributes to be combined with the
-dhcphost object class, we can merge the DNS and DHCP entries into one.
-I've written such object class in the dnsdomainaux.schema file (need
-proper OIDs, but that is a minor issue), and tested the setup. It
-seem to work.</p>
-
-<p>With this test setup in place, we can get away with one LDAP object
-for both DNS and DHCP, and even the LTSP configuration I suggested in
-an earlier email. The combined LDAP object will look something like
-this:</p>
-
-<blockquote><pre>
- dn: cn=hostname,cn=group1,cn=THINCLIENTS,cn=DHCP Config,dc=skole,dc=skolelinux,dc=no
- cn: hostname
- objectClass: dhcphost
- objectclass: domainrelatedobject
- objectclass: dnsdomainaux
- associateddomain: hostname.intern
- arecord: 10.11.12.13
- dhcphwaddress: ethernet 00:00:00:00:00:00
- dhcpstatements: fixed-address hostname
- ldapconfigsound: Y
-</pre></blockquote>
-
-<p>The DNS server uses the associateddomain and arecord entries, while
-the DHCP server uses the dhcphwaddress and dhcpstatements entries
-before asking DNS to resolve the fixed-adddress. LTSP will use
-dhcphwaddress or associateddomain and the ldapconfig* attributes.</p>
-
-<p>I am not yet sure if I can get the DHCP server to look for its
-dhcphost in a different location, to allow us to put the objects
-outside the "DHCP Config" subtree, but hope to figure out a way to do
-that. If I can't figure out a way to do that, we can still get rid of
-the hosts subtree and move all its content into the DHCP Config tree
-(which probably should be renamed to be more related to the new
-content. I suspect cn=dnsdhcp,ou=services or something like that
-might be a good place to put it.</p>
-
-<p>If you want to help out with implementing this for Debian Edu,
-please contact us on debian-edu@lists.debian.org.</p>
-
-
-
diff --git a/blog/jXplorer__a_very_nice_LDAP_GUI.html b/blog/jXplorer__a_very_nice_LDAP_GUI.html
index 2688a63483..7550a7e829 100644
--- a/blog/jXplorer__a_very_nice_LDAP_GUI.html
+++ b/blog/jXplorer__a_very_nice_LDAP_GUI.html
@@ -67,7 +67,7 @@ and remove the failing query. Nothing big, but very annoying.
diff --git a/blog/tags/debian edu/debian edu.rss b/blog/tags/debian edu/debian edu.rss
index d45bd075fa..2cabf4c534 100644
--- a/blog/tags/debian edu/debian edu.rss
+++ b/blog/tags/debian edu/debian edu.rss
@@ -2661,5 +2661,125 @@ it. :)</p>
+
+ No hardcoded config on Debian Edu clients
+ http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html
+ http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html
+ Mon, 9 Aug 2010 20:15:00 +0200
+
+<p>As reported earlier, the last few days I have looked at how Debian
+Edu clients are configured, and tried to get rid of all hardcoded
+configuration settings on the clients. I believe the work to be
+mostly done, and the clients seem to work just fine with dynamically
+generated configuration.</p>
+
+<p>What is the point, you might ask? The point is to allow a Debian
+Edu desktop to integrate into an existing network infrastructure
+without any manual configuration.</p>
+
+<p>This is what happens when installing a Debian Edu client here at
+the University of Oslo using PXE. With the PXE installation, I am
+asked for language (Norwegian Bokmål), locality (Norway) and keyboard
+layout (no-latin1), Debian Edu profile (Roaming Workstation), if I
+accept to reformat the hard drive (yes), if I want to submit info to
+popcon.debian.org (no) and root password (secret). After answering
+these questions, the installer goes ahead and does its thing, and
+after around 50 minutes it is done. I press enter to finish the
+installation, and the machine reboots into KDE. When the machine is
+ready and kdm asks for login information, I enter my university
+username and password, am told by kdm that a local home directory has
+been created and that I must log in again, and finally log in with the
+same username and password to the KDE 4.4 desktop. At no point during
+this process did it ask for university specific settings, and all the
+required configuration was dynamically detected using information
+fetched via DHCP and DNS. The roaming workstation is now ready for
+use.</p>
+
+<p>How was this done, you might wonder? First of all, here is the
+list of things that need to be configured on the client to get it
+working properly out of the box:</p>
+
+<ul>
+<li>IP address/netmask and DNS server.</li>
+<li>Web proxy URL.</li>
+<li>LDAP server for NSS directory information (user, group, etc).</li>
+<li>Kerberos server for PAM password checking.</li>
+<li>SMB mount point to access the network home directory. (*)</li>
+<li>Central syslog server to send syslog messages to. (*)</li>
+<li>Sitesummary collector URL to submit info to central server. (*)</li>
+</ul>
+
+<p>(Hm, did I forget anything? Let me knew if I did.)</p>
+
+<p>The points marked (*) are not required to be able to use the
+machine, but needed to provide central storage and allowing system
+administrators to track their machines. Since yesterday, everything
+but the sitesummary collector URL is dynamically discovered at boot
+and installation time in the svn version of Debian Edu.</p>
+
+<p>The IP and DNS setup is fetched during boot using DHCP as usual.
+When a DHCP update arrives, the proxy setup is updated by looking for
+http://wpat/wpad.dat and using the content of this WPAD file to
+configure the http and ftp proxy in /etc/environment and
+/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP
+hook to ensure that the client stops using the Debian Edu proxy when
+it is moved outside the Debian Edu network, and instead uses any local
+proxy present on the new network when it moves around.</p>
+
+<p>The DNS names of the LDAP, Kerberos and syslog server and related
+configuration are generated using DNS information at boot. First the
+installer looks for a host named ldap in the current DNS domain. If
+not found, it looks for _ldap._tcp SRV records in DNS instead. If an
+LDAP server is found, its root DSE entry is requested and the
+attributes namingContexts and defaultNamingContext are used to
+determine which LDAP base to use for NSS. If there are several
+namingContexts attibutes and the defaultNamingContext is present, that
+LDAP subtree is used as the base. If defaultNamingContext is missing,
+the subtrees listed as namingContexts are searched in sequence for any
+object with class posixAccount or posixGroup, and the first one with
+such an object is used as the LDAP base. For Kerberos, a similar
+search is done by first looking for a host named kerberos, and then
+for the _kerberos._tcp SRV record. I've been unable to find a way to
+look up the Kerberos realm, so for this the upper case string of the
+current DNS domain is used.</p>
+
+<p>For the syslog server, the hosts syslog and loghost are searched
+for, and the _syslog._udp SRV record is consulted if no such host is
+found. This algorithm works for both Debian Edu and the University of
+Oslo. A similar strategy would work for locating the sitesummary
+server, but have not been implemented yet. I decided to fetch and
+save these settings during installation, to make sure moving to a
+different network does not change the set of users being allowed to
+log in nor the passwords required to log in. Usernames and passwords
+will be cached by sssd when the user logs in on the Debian Edu
+network, and will not change as the laptop move around. For a
+non-roaming machine, there is no caching, but given that it is
+supposed to stay in place it should not matter much. Perhaps we
+should switch those to use sssd too?</p>
+
+<p>The user's SMB mount point for the network home directory is
+located when the user logs in for the first time. The LDAP server is
+consulted to look for the user's LDAP object and the sambaHomePath
+attribute is used if found. If it isn't found, the home directory
+path fetched from NSS is used instead. Assuming the path is of the
+form /site/server/directory/username, the second part is looked up in
+DNS and used to generate a SMB URL of the form
+smb://server.domain/username. This algorithm works for both Debian
+edu and the University of Oslo. Perhaps there are better attributes
+to use or a better algorithm that works for more sites, but this will
+do for now. :)</p>
+
+<p>This work should make it easier to integrate the Debian Edu clients
+into any LDAP/Kerberos infrastructure, and make the current setup even
+more flexible than before. I suspect it will also work for thin
+client servers, allowing one to easily set up LTSP and hook it into a
+existing network infrastructure, but I have not had time to test this
+yet.</p>
+
+<p>If you want to help out with implementing these things for Debian
+Edu, please contact us on debian-edu@lists.debian.org.</p>
+
+
+
diff --git a/blog/tags/debian edu/index.html b/blog/tags/debian edu/index.html
index f5851be916..cafec260ed 100644
--- a/blog/tags/debian edu/index.html
+++ b/blog/tags/debian edu/index.html
@@ -3177,6 +3177,139 @@ it. :)
+ Tags: debian edu, english, nuug.
+
+
As reported earlier, the last few days I have looked at how Debian
+Edu clients are configured, and tried to get rid of all hardcoded
+configuration settings on the clients. I believe the work to be
+mostly done, and the clients seem to work just fine with dynamically
+generated configuration.
+
+
What is the point, you might ask? The point is to allow a Debian
+Edu desktop to integrate into an existing network infrastructure
+without any manual configuration.
+
+
This is what happens when installing a Debian Edu client here at
+the University of Oslo using PXE. With the PXE installation, I am
+asked for language (Norwegian Bokmål), locality (Norway) and keyboard
+layout (no-latin1), Debian Edu profile (Roaming Workstation), if I
+accept to reformat the hard drive (yes), if I want to submit info to
+popcon.debian.org (no) and root password (secret). After answering
+these questions, the installer goes ahead and does its thing, and
+after around 50 minutes it is done. I press enter to finish the
+installation, and the machine reboots into KDE. When the machine is
+ready and kdm asks for login information, I enter my university
+username and password, am told by kdm that a local home directory has
+been created and that I must log in again, and finally log in with the
+same username and password to the KDE 4.4 desktop. At no point during
+this process did it ask for university specific settings, and all the
+required configuration was dynamically detected using information
+fetched via DHCP and DNS. The roaming workstation is now ready for
+use.
+
+
How was this done, you might wonder? First of all, here is the
+list of things that need to be configured on the client to get it
+working properly out of the box:
+
+
+
IP address/netmask and DNS server.
+
Web proxy URL.
+
LDAP server for NSS directory information (user, group, etc).
+
Kerberos server for PAM password checking.
+
SMB mount point to access the network home directory. (*)
+
Central syslog server to send syslog messages to. (*)
+
Sitesummary collector URL to submit info to central server. (*)
+
+
+
(Hm, did I forget anything? Let me knew if I did.)
+
+
The points marked (*) are not required to be able to use the
+machine, but needed to provide central storage and allowing system
+administrators to track their machines. Since yesterday, everything
+but the sitesummary collector URL is dynamically discovered at boot
+and installation time in the svn version of Debian Edu.
+
+
The IP and DNS setup is fetched during boot using DHCP as usual.
+When a DHCP update arrives, the proxy setup is updated by looking for
+http://wpat/wpad.dat and using the content of this WPAD file to
+configure the http and ftp proxy in /etc/environment and
+/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP
+hook to ensure that the client stops using the Debian Edu proxy when
+it is moved outside the Debian Edu network, and instead uses any local
+proxy present on the new network when it moves around.
+
+
The DNS names of the LDAP, Kerberos and syslog server and related
+configuration are generated using DNS information at boot. First the
+installer looks for a host named ldap in the current DNS domain. If
+not found, it looks for _ldap._tcp SRV records in DNS instead. If an
+LDAP server is found, its root DSE entry is requested and the
+attributes namingContexts and defaultNamingContext are used to
+determine which LDAP base to use for NSS. If there are several
+namingContexts attibutes and the defaultNamingContext is present, that
+LDAP subtree is used as the base. If defaultNamingContext is missing,
+the subtrees listed as namingContexts are searched in sequence for any
+object with class posixAccount or posixGroup, and the first one with
+such an object is used as the LDAP base. For Kerberos, a similar
+search is done by first looking for a host named kerberos, and then
+for the _kerberos._tcp SRV record. I've been unable to find a way to
+look up the Kerberos realm, so for this the upper case string of the
+current DNS domain is used.
+
+
For the syslog server, the hosts syslog and loghost are searched
+for, and the _syslog._udp SRV record is consulted if no such host is
+found. This algorithm works for both Debian Edu and the University of
+Oslo. A similar strategy would work for locating the sitesummary
+server, but have not been implemented yet. I decided to fetch and
+save these settings during installation, to make sure moving to a
+different network does not change the set of users being allowed to
+log in nor the passwords required to log in. Usernames and passwords
+will be cached by sssd when the user logs in on the Debian Edu
+network, and will not change as the laptop move around. For a
+non-roaming machine, there is no caching, but given that it is
+supposed to stay in place it should not matter much. Perhaps we
+should switch those to use sssd too?
+
+
The user's SMB mount point for the network home directory is
+located when the user logs in for the first time. The LDAP server is
+consulted to look for the user's LDAP object and the sambaHomePath
+attribute is used if found. If it isn't found, the home directory
+path fetched from NSS is used instead. Assuming the path is of the
+form /site/server/directory/username, the second part is looked up in
+DNS and used to generate a SMB URL of the form
+smb://server.domain/username. This algorithm works for both Debian
+edu and the University of Oslo. Perhaps there are better attributes
+to use or a better algorithm that works for more sites, but this will
+do for now. :)
+
+
This work should make it easier to integrate the Debian Edu clients
+into any LDAP/Kerberos infrastructure, and make the current setup even
+more flexible than before. I suspect it will also work for thin
+client servers, allowing one to easily set up LTSP and hook it into a
+existing network infrastructure, but I have not had time to test this
+yet.
+
+
If you want to help out with implementing these things for Debian
+Edu, please contact us on debian-edu@lists.debian.org.
diff --git a/blog/tags/english/english.rss b/blog/tags/english/english.rss
index b3c6bfae1c..ec282fde38 100644
--- a/blog/tags/english/english.rss
+++ b/blog/tags/english/english.rss
@@ -3375,5 +3375,125 @@ it. :)</p>
+
+ No hardcoded config on Debian Edu clients
+ http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html
+ http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html
+ Mon, 9 Aug 2010 20:15:00 +0200
+
+<p>As reported earlier, the last few days I have looked at how Debian
+Edu clients are configured, and tried to get rid of all hardcoded
+configuration settings on the clients. I believe the work to be
+mostly done, and the clients seem to work just fine with dynamically
+generated configuration.</p>
+
+<p>What is the point, you might ask? The point is to allow a Debian
+Edu desktop to integrate into an existing network infrastructure
+without any manual configuration.</p>
+
+<p>This is what happens when installing a Debian Edu client here at
+the University of Oslo using PXE. With the PXE installation, I am
+asked for language (Norwegian Bokmål), locality (Norway) and keyboard
+layout (no-latin1), Debian Edu profile (Roaming Workstation), if I
+accept to reformat the hard drive (yes), if I want to submit info to
+popcon.debian.org (no) and root password (secret). After answering
+these questions, the installer goes ahead and does its thing, and
+after around 50 minutes it is done. I press enter to finish the
+installation, and the machine reboots into KDE. When the machine is
+ready and kdm asks for login information, I enter my university
+username and password, am told by kdm that a local home directory has
+been created and that I must log in again, and finally log in with the
+same username and password to the KDE 4.4 desktop. At no point during
+this process did it ask for university specific settings, and all the
+required configuration was dynamically detected using information
+fetched via DHCP and DNS. The roaming workstation is now ready for
+use.</p>
+
+<p>How was this done, you might wonder? First of all, here is the
+list of things that need to be configured on the client to get it
+working properly out of the box:</p>
+
+<ul>
+<li>IP address/netmask and DNS server.</li>
+<li>Web proxy URL.</li>
+<li>LDAP server for NSS directory information (user, group, etc).</li>
+<li>Kerberos server for PAM password checking.</li>
+<li>SMB mount point to access the network home directory. (*)</li>
+<li>Central syslog server to send syslog messages to. (*)</li>
+<li>Sitesummary collector URL to submit info to central server. (*)</li>
+</ul>
+
+<p>(Hm, did I forget anything? Let me knew if I did.)</p>
+
+<p>The points marked (*) are not required to be able to use the
+machine, but needed to provide central storage and allowing system
+administrators to track their machines. Since yesterday, everything
+but the sitesummary collector URL is dynamically discovered at boot
+and installation time in the svn version of Debian Edu.</p>
+
+<p>The IP and DNS setup is fetched during boot using DHCP as usual.
+When a DHCP update arrives, the proxy setup is updated by looking for
+http://wpat/wpad.dat and using the content of this WPAD file to
+configure the http and ftp proxy in /etc/environment and
+/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP
+hook to ensure that the client stops using the Debian Edu proxy when
+it is moved outside the Debian Edu network, and instead uses any local
+proxy present on the new network when it moves around.</p>
+
+<p>The DNS names of the LDAP, Kerberos and syslog server and related
+configuration are generated using DNS information at boot. First the
+installer looks for a host named ldap in the current DNS domain. If
+not found, it looks for _ldap._tcp SRV records in DNS instead. If an
+LDAP server is found, its root DSE entry is requested and the
+attributes namingContexts and defaultNamingContext are used to
+determine which LDAP base to use for NSS. If there are several
+namingContexts attibutes and the defaultNamingContext is present, that
+LDAP subtree is used as the base. If defaultNamingContext is missing,
+the subtrees listed as namingContexts are searched in sequence for any
+object with class posixAccount or posixGroup, and the first one with
+such an object is used as the LDAP base. For Kerberos, a similar
+search is done by first looking for a host named kerberos, and then
+for the _kerberos._tcp SRV record. I've been unable to find a way to
+look up the Kerberos realm, so for this the upper case string of the
+current DNS domain is used.</p>
+
+<p>For the syslog server, the hosts syslog and loghost are searched
+for, and the _syslog._udp SRV record is consulted if no such host is
+found. This algorithm works for both Debian Edu and the University of
+Oslo. A similar strategy would work for locating the sitesummary
+server, but have not been implemented yet. I decided to fetch and
+save these settings during installation, to make sure moving to a
+different network does not change the set of users being allowed to
+log in nor the passwords required to log in. Usernames and passwords
+will be cached by sssd when the user logs in on the Debian Edu
+network, and will not change as the laptop move around. For a
+non-roaming machine, there is no caching, but given that it is
+supposed to stay in place it should not matter much. Perhaps we
+should switch those to use sssd too?</p>
+
+<p>The user's SMB mount point for the network home directory is
+located when the user logs in for the first time. The LDAP server is
+consulted to look for the user's LDAP object and the sambaHomePath
+attribute is used if found. If it isn't found, the home directory
+path fetched from NSS is used instead. Assuming the path is of the
+form /site/server/directory/username, the second part is looked up in
+DNS and used to generate a SMB URL of the form
+smb://server.domain/username. This algorithm works for both Debian
+edu and the University of Oslo. Perhaps there are better attributes
+to use or a better algorithm that works for more sites, but this will
+do for now. :)</p>
+
+<p>This work should make it easier to integrate the Debian Edu clients
+into any LDAP/Kerberos infrastructure, and make the current setup even
+more flexible than before. I suspect it will also work for thin
+client servers, allowing one to easily set up LTSP and hook it into a
+existing network infrastructure, but I have not had time to test this
+yet.</p>
+
+<p>If you want to help out with implementing these things for Debian
+Edu, please contact us on debian-edu@lists.debian.org.</p>
+
+
+
diff --git a/blog/tags/english/index.html b/blog/tags/english/index.html
index 07c67b4897..7ee079c10a 100644
--- a/blog/tags/english/index.html
+++ b/blog/tags/english/index.html
@@ -4086,6 +4086,139 @@ it. :)
+ Tags: debian edu, english, nuug.
+
+
As reported earlier, the last few days I have looked at how Debian
+Edu clients are configured, and tried to get rid of all hardcoded
+configuration settings on the clients. I believe the work to be
+mostly done, and the clients seem to work just fine with dynamically
+generated configuration.
+
+
What is the point, you might ask? The point is to allow a Debian
+Edu desktop to integrate into an existing network infrastructure
+without any manual configuration.
+
+
This is what happens when installing a Debian Edu client here at
+the University of Oslo using PXE. With the PXE installation, I am
+asked for language (Norwegian Bokmål), locality (Norway) and keyboard
+layout (no-latin1), Debian Edu profile (Roaming Workstation), if I
+accept to reformat the hard drive (yes), if I want to submit info to
+popcon.debian.org (no) and root password (secret). After answering
+these questions, the installer goes ahead and does its thing, and
+after around 50 minutes it is done. I press enter to finish the
+installation, and the machine reboots into KDE. When the machine is
+ready and kdm asks for login information, I enter my university
+username and password, am told by kdm that a local home directory has
+been created and that I must log in again, and finally log in with the
+same username and password to the KDE 4.4 desktop. At no point during
+this process did it ask for university specific settings, and all the
+required configuration was dynamically detected using information
+fetched via DHCP and DNS. The roaming workstation is now ready for
+use.
+
+
How was this done, you might wonder? First of all, here is the
+list of things that need to be configured on the client to get it
+working properly out of the box:
+
+
+
IP address/netmask and DNS server.
+
Web proxy URL.
+
LDAP server for NSS directory information (user, group, etc).
+
Kerberos server for PAM password checking.
+
SMB mount point to access the network home directory. (*)
+
Central syslog server to send syslog messages to. (*)
+
Sitesummary collector URL to submit info to central server. (*)
+
+
+
(Hm, did I forget anything? Let me knew if I did.)
+
+
The points marked (*) are not required to be able to use the
+machine, but needed to provide central storage and allowing system
+administrators to track their machines. Since yesterday, everything
+but the sitesummary collector URL is dynamically discovered at boot
+and installation time in the svn version of Debian Edu.
+
+
The IP and DNS setup is fetched during boot using DHCP as usual.
+When a DHCP update arrives, the proxy setup is updated by looking for
+http://wpat/wpad.dat and using the content of this WPAD file to
+configure the http and ftp proxy in /etc/environment and
+/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP
+hook to ensure that the client stops using the Debian Edu proxy when
+it is moved outside the Debian Edu network, and instead uses any local
+proxy present on the new network when it moves around.
+
+
The DNS names of the LDAP, Kerberos and syslog server and related
+configuration are generated using DNS information at boot. First the
+installer looks for a host named ldap in the current DNS domain. If
+not found, it looks for _ldap._tcp SRV records in DNS instead. If an
+LDAP server is found, its root DSE entry is requested and the
+attributes namingContexts and defaultNamingContext are used to
+determine which LDAP base to use for NSS. If there are several
+namingContexts attibutes and the defaultNamingContext is present, that
+LDAP subtree is used as the base. If defaultNamingContext is missing,
+the subtrees listed as namingContexts are searched in sequence for any
+object with class posixAccount or posixGroup, and the first one with
+such an object is used as the LDAP base. For Kerberos, a similar
+search is done by first looking for a host named kerberos, and then
+for the _kerberos._tcp SRV record. I've been unable to find a way to
+look up the Kerberos realm, so for this the upper case string of the
+current DNS domain is used.
+
+
For the syslog server, the hosts syslog and loghost are searched
+for, and the _syslog._udp SRV record is consulted if no such host is
+found. This algorithm works for both Debian Edu and the University of
+Oslo. A similar strategy would work for locating the sitesummary
+server, but have not been implemented yet. I decided to fetch and
+save these settings during installation, to make sure moving to a
+different network does not change the set of users being allowed to
+log in nor the passwords required to log in. Usernames and passwords
+will be cached by sssd when the user logs in on the Debian Edu
+network, and will not change as the laptop move around. For a
+non-roaming machine, there is no caching, but given that it is
+supposed to stay in place it should not matter much. Perhaps we
+should switch those to use sssd too?
+
+
The user's SMB mount point for the network home directory is
+located when the user logs in for the first time. The LDAP server is
+consulted to look for the user's LDAP object and the sambaHomePath
+attribute is used if found. If it isn't found, the home directory
+path fetched from NSS is used instead. Assuming the path is of the
+form /site/server/directory/username, the second part is looked up in
+DNS and used to generate a SMB URL of the form
+smb://server.domain/username. This algorithm works for both Debian
+edu and the University of Oslo. Perhaps there are better attributes
+to use or a better algorithm that works for more sites, but this will
+do for now. :)
+
+
This work should make it easier to integrate the Debian Edu clients
+into any LDAP/Kerberos infrastructure, and make the current setup even
+more flexible than before. I suspect it will also work for thin
+client servers, allowing one to easily set up LTSP and hook it into a
+existing network infrastructure, but I have not had time to test this
+yet.
+
+
If you want to help out with implementing these things for Debian
+Edu, please contact us on debian-edu@lists.debian.org.
diff --git a/blog/tags/fiksgatami/index.html b/blog/tags/fiksgatami/index.html
index 0d819db2bf..8088121201 100644
--- a/blog/tags/fiksgatami/index.html
+++ b/blog/tags/fiksgatami/index.html
@@ -88,7 +88,7 @@ med dem. Dette blir bra.
diff --git a/blog/tags/fildeling/index.html b/blog/tags/fildeling/index.html
index b3fcc44b50..df6528825d 100644
--- a/blog/tags/fildeling/index.html
+++ b/blog/tags/fildeling/index.html
@@ -397,7 +397,7 @@ Kommer neppe til å ta i bruk Blueray, og ei heller de nye DRM-greiene
diff --git a/blog/tags/norsk/index.html b/blog/tags/norsk/index.html
index 056a8de157..293dcd1793 100644
--- a/blog/tags/norsk/index.html
+++ b/blog/tags/norsk/index.html
@@ -3617,7 +3617,7 @@ Kommer neppe til å ta i bruk Blueray, og ei heller de nye DRM-greiene
As reported earlier, the last few days I have looked at how Debian
+Edu clients are configured, and tried to get rid of all hardcoded
+configuration settings on the clients. I believe the work to be
+mostly done, and the clients seem to work just fine with dynamically
+generated configuration.
+
+
What is the point, you might ask? The point is to allow a Debian
+Edu desktop to integrate into an existing network infrastructure
+without any manual configuration.
+
+
This is what happens when installing a Debian Edu client here at
+the University of Oslo using PXE. With the PXE installation, I am
+asked for language (Norwegian Bokmål), locality (Norway) and keyboard
+layout (no-latin1), Debian Edu profile (Roaming Workstation), if I
+accept to reformat the hard drive (yes), if I want to submit info to
+popcon.debian.org (no) and root password (secret). After answering
+these questions, the installer goes ahead and does its thing, and
+after around 50 minutes it is done. I press enter to finish the
+installation, and the machine reboots into KDE. When the machine is
+ready and kdm asks for login information, I enter my university
+username and password, am told by kdm that a local home directory has
+been created and that I must log in again, and finally log in with the
+same username and password to the KDE 4.4 desktop. At no point during
+this process did it ask for university specific settings, and all the
+required configuration was dynamically detected using information
+fetched via DHCP and DNS. The roaming workstation is now ready for
+use.
+
+
How was this done, you might wonder? First of all, here is the
+list of things that need to be configured on the client to get it
+working properly out of the box:
+
+
+
IP address/netmask and DNS server.
+
Web proxy URL.
+
LDAP server for NSS directory information (user, group, etc).
+
Kerberos server for PAM password checking.
+
SMB mount point to access the network home directory. (*)
+
Central syslog server to send syslog messages to. (*)
+
Sitesummary collector URL to submit info to central server. (*)
+
+
+
(Hm, did I forget anything? Let me knew if I did.)
+
+
The points marked (*) are not required to be able to use the
+machine, but needed to provide central storage and allowing system
+administrators to track their machines. Since yesterday, everything
+but the sitesummary collector URL is dynamically discovered at boot
+and installation time in the svn version of Debian Edu.
+
+
The IP and DNS setup is fetched during boot using DHCP as usual.
+When a DHCP update arrives, the proxy setup is updated by looking for
+http://wpat/wpad.dat and using the content of this WPAD file to
+configure the http and ftp proxy in /etc/environment and
+/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP
+hook to ensure that the client stops using the Debian Edu proxy when
+it is moved outside the Debian Edu network, and instead uses any local
+proxy present on the new network when it moves around.
+
+
The DNS names of the LDAP, Kerberos and syslog server and related
+configuration are generated using DNS information at boot. First the
+installer looks for a host named ldap in the current DNS domain. If
+not found, it looks for _ldap._tcp SRV records in DNS instead. If an
+LDAP server is found, its root DSE entry is requested and the
+attributes namingContexts and defaultNamingContext are used to
+determine which LDAP base to use for NSS. If there are several
+namingContexts attibutes and the defaultNamingContext is present, that
+LDAP subtree is used as the base. If defaultNamingContext is missing,
+the subtrees listed as namingContexts are searched in sequence for any
+object with class posixAccount or posixGroup, and the first one with
+such an object is used as the LDAP base. For Kerberos, a similar
+search is done by first looking for a host named kerberos, and then
+for the _kerberos._tcp SRV record. I've been unable to find a way to
+look up the Kerberos realm, so for this the upper case string of the
+current DNS domain is used.
+
+
For the syslog server, the hosts syslog and loghost are searched
+for, and the _syslog._udp SRV record is consulted if no such host is
+found. This algorithm works for both Debian Edu and the University of
+Oslo. A similar strategy would work for locating the sitesummary
+server, but have not been implemented yet. I decided to fetch and
+save these settings during installation, to make sure moving to a
+different network does not change the set of users being allowed to
+log in nor the passwords required to log in. Usernames and passwords
+will be cached by sssd when the user logs in on the Debian Edu
+network, and will not change as the laptop move around. For a
+non-roaming machine, there is no caching, but given that it is
+supposed to stay in place it should not matter much. Perhaps we
+should switch those to use sssd too?
+
+
The user's SMB mount point for the network home directory is
+located when the user logs in for the first time. The LDAP server is
+consulted to look for the user's LDAP object and the sambaHomePath
+attribute is used if found. If it isn't found, the home directory
+path fetched from NSS is used instead. Assuming the path is of the
+form /site/server/directory/username, the second part is looked up in
+DNS and used to generate a SMB URL of the form
+smb://server.domain/username. This algorithm works for both Debian
+edu and the University of Oslo. Perhaps there are better attributes
+to use or a better algorithm that works for more sites, but this will
+do for now. :)
+
+
This work should make it easier to integrate the Debian Edu clients
+into any LDAP/Kerberos infrastructure, and make the current setup even
+more flexible than before. I suspect it will also work for thin
+client servers, allowing one to easily set up LTSP and hook it into a
+existing network infrastructure, but I have not had time to test this
+yet.
+
+
If you want to help out with implementing these things for Debian
+Edu, please contact us on debian-edu@lists.debian.org.
diff --git a/blog/tags/nuug/nuug.rss b/blog/tags/nuug/nuug.rss
index 958f75dcfb..f9b21de10b 100644
--- a/blog/tags/nuug/nuug.rss
+++ b/blog/tags/nuug/nuug.rss
@@ -4517,5 +4517,125 @@ it. :)</p>
+
+ No hardcoded config on Debian Edu clients
+ http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html
+ http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html
+ Mon, 9 Aug 2010 20:15:00 +0200
+
+<p>As reported earlier, the last few days I have looked at how Debian
+Edu clients are configured, and tried to get rid of all hardcoded
+configuration settings on the clients. I believe the work to be
+mostly done, and the clients seem to work just fine with dynamically
+generated configuration.</p>
+
+<p>What is the point, you might ask? The point is to allow a Debian
+Edu desktop to integrate into an existing network infrastructure
+without any manual configuration.</p>
+
+<p>This is what happens when installing a Debian Edu client here at
+the University of Oslo using PXE. With the PXE installation, I am
+asked for language (Norwegian Bokmål), locality (Norway) and keyboard
+layout (no-latin1), Debian Edu profile (Roaming Workstation), if I
+accept to reformat the hard drive (yes), if I want to submit info to
+popcon.debian.org (no) and root password (secret). After answering
+these questions, the installer goes ahead and does its thing, and
+after around 50 minutes it is done. I press enter to finish the
+installation, and the machine reboots into KDE. When the machine is
+ready and kdm asks for login information, I enter my university
+username and password, am told by kdm that a local home directory has
+been created and that I must log in again, and finally log in with the
+same username and password to the KDE 4.4 desktop. At no point during
+this process did it ask for university specific settings, and all the
+required configuration was dynamically detected using information
+fetched via DHCP and DNS. The roaming workstation is now ready for
+use.</p>
+
+<p>How was this done, you might wonder? First of all, here is the
+list of things that need to be configured on the client to get it
+working properly out of the box:</p>
+
+<ul>
+<li>IP address/netmask and DNS server.</li>
+<li>Web proxy URL.</li>
+<li>LDAP server for NSS directory information (user, group, etc).</li>
+<li>Kerberos server for PAM password checking.</li>
+<li>SMB mount point to access the network home directory. (*)</li>
+<li>Central syslog server to send syslog messages to. (*)</li>
+<li>Sitesummary collector URL to submit info to central server. (*)</li>
+</ul>
+
+<p>(Hm, did I forget anything? Let me knew if I did.)</p>
+
+<p>The points marked (*) are not required to be able to use the
+machine, but needed to provide central storage and allowing system
+administrators to track their machines. Since yesterday, everything
+but the sitesummary collector URL is dynamically discovered at boot
+and installation time in the svn version of Debian Edu.</p>
+
+<p>The IP and DNS setup is fetched during boot using DHCP as usual.
+When a DHCP update arrives, the proxy setup is updated by looking for
+http://wpat/wpad.dat and using the content of this WPAD file to
+configure the http and ftp proxy in /etc/environment and
+/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP
+hook to ensure that the client stops using the Debian Edu proxy when
+it is moved outside the Debian Edu network, and instead uses any local
+proxy present on the new network when it moves around.</p>
+
+<p>The DNS names of the LDAP, Kerberos and syslog server and related
+configuration are generated using DNS information at boot. First the
+installer looks for a host named ldap in the current DNS domain. If
+not found, it looks for _ldap._tcp SRV records in DNS instead. If an
+LDAP server is found, its root DSE entry is requested and the
+attributes namingContexts and defaultNamingContext are used to
+determine which LDAP base to use for NSS. If there are several
+namingContexts attibutes and the defaultNamingContext is present, that
+LDAP subtree is used as the base. If defaultNamingContext is missing,
+the subtrees listed as namingContexts are searched in sequence for any
+object with class posixAccount or posixGroup, and the first one with
+such an object is used as the LDAP base. For Kerberos, a similar
+search is done by first looking for a host named kerberos, and then
+for the _kerberos._tcp SRV record. I've been unable to find a way to
+look up the Kerberos realm, so for this the upper case string of the
+current DNS domain is used.</p>
+
+<p>For the syslog server, the hosts syslog and loghost are searched
+for, and the _syslog._udp SRV record is consulted if no such host is
+found. This algorithm works for both Debian Edu and the University of
+Oslo. A similar strategy would work for locating the sitesummary
+server, but have not been implemented yet. I decided to fetch and
+save these settings during installation, to make sure moving to a
+different network does not change the set of users being allowed to
+log in nor the passwords required to log in. Usernames and passwords
+will be cached by sssd when the user logs in on the Debian Edu
+network, and will not change as the laptop move around. For a
+non-roaming machine, there is no caching, but given that it is
+supposed to stay in place it should not matter much. Perhaps we
+should switch those to use sssd too?</p>
+
+<p>The user's SMB mount point for the network home directory is
+located when the user logs in for the first time. The LDAP server is
+consulted to look for the user's LDAP object and the sambaHomePath
+attribute is used if found. If it isn't found, the home directory
+path fetched from NSS is used instead. Assuming the path is of the
+form /site/server/directory/username, the second part is looked up in
+DNS and used to generate a SMB URL of the form
+smb://server.domain/username. This algorithm works for both Debian
+edu and the University of Oslo. Perhaps there are better attributes
+to use or a better algorithm that works for more sites, but this will
+do for now. :)</p>
+
+<p>This work should make it easier to integrate the Debian Edu clients
+into any LDAP/Kerberos infrastructure, and make the current setup even
+more flexible than before. I suspect it will also work for thin
+client servers, allowing one to easily set up LTSP and hook it into a
+existing network infrastructure, but I have not had time to test this
+yet.</p>
+
+<p>If you want to help out with implementing these things for Debian
+Edu, please contact us on debian-edu@lists.debian.org.</p>
+
+
+
diff --git a/blog/tags/opphavsrett/index.html b/blog/tags/opphavsrett/index.html
index eda6e0330e..55cd6fb2ec 100644
--- a/blog/tags/opphavsrett/index.html
+++ b/blog/tags/opphavsrett/index.html
@@ -777,7 +777,7 @@ Kommer neppe til å ta i bruk Blueray, og ei heller de nye DRM-greiene
diff --git a/blog/tags/personvern/index.html b/blog/tags/personvern/index.html
index 67ec902a39..01911c688c 100644
--- a/blog/tags/personvern/index.html
+++ b/blog/tags/personvern/index.html
@@ -718,7 +718,7 @@ Kommer neppe til å ta i bruk Blueray, og ei heller de nye DRM-greiene
diff --git a/blog/tags/reprap/index.html b/blog/tags/reprap/index.html
index c535a07cfc..4ff5ddc93c 100644
--- a/blog/tags/reprap/index.html
+++ b/blog/tags/reprap/index.html
@@ -525,7 +525,7 @@ kommer til å bruke denne plasttypen som håndterer temperaturer mellom
diff --git a/blog/tags/video/index.html b/blog/tags/video/index.html
index dbce2eaa42..8eaefb6771 100644
--- a/blog/tags/video/index.html
+++ b/blog/tags/video/index.html
@@ -536,7 +536,7 @@ meg, Tollef og alle andre de som deltok på møtet på TV.
diff --git a/blog/tags/vitenskap/index.html b/blog/tags/vitenskap/index.html
index f5722d9aa6..a999180577 100644
--- a/blog/tags/vitenskap/index.html
+++ b/blog/tags/vitenskap/index.html
@@ -138,7 +138,7 @@ skyskrapere. Takke meg til en tur til månen.