</description>
</item>
+ <item>
+ <title>MS Word krøller det til for politiet?</title>
+ <link>http://people.skolelinux.org/pere/blog/MS_Word_kr__ller_det_til_for_politiet_.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/MS_Word_kr__ller_det_til_for_politiet_.html</guid>
+ <pubDate>Thu, 8 Jul 2010 14:00:00 +0200</pubDate>
+ <description>
+<p>De siste dagene har Aftenposten
+<a href="http://www.aftenposten.no/nyheter/iriks/article3718597.ece">fortalt</a>
+<a href="http://www.aftenposten.no/nyheter/iriks/article3724249.ece">hvordan</a>
+politet har brukt skriveverktøy som ikke håndterer arabisk tekst og
+tekst som skal skrives fra høyre mot venstre når de har laget
+løpeseddel for å be om informasjon fra publikum. Resultatet har vært
+en uleselig arabisk-bit på løpeseddelen. Feilen har oppstått når
+teksten har blitt "kopiert inn i programvare som ikke har støtte for
+språk som skrives fra høyre mot venstre", og jeg er ganske sikker på
+at det er snakk om Microsoft Office i dette tilfellet. Er det slik at
+MS Office i norsk språkdrakt ikke har støtte for tekst som skal
+skrives fra høyre mot venstre? Jeg tror alle utgaver av
+OpenOffice.org har slik støtte, og det er jo ikke veldig vanskelig å
+la slik støtte finnes i alle utgaver av et program hvis støtten først
+er utviklet. Aftenpostens melding får meg til å undre om problemet
+ville vært unngått hvis politiet brukte OpenOffice.org i stedet for MS
+Office.</p>
+
+<p>Mon tro om det er flere eksempler på at MS Office har ødelagt for
+offentlig myndighet?</p>
+</description>
+ </item>
+
+ <item>
+ <title>jXplorer, a very nice LDAP GUI</title>
+ <link>http://people.skolelinux.org/pere/blog/jXplorer__a_very_nice_LDAP_GUI.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/jXplorer__a_very_nice_LDAP_GUI.html</guid>
+ <pubDate>Fri, 9 Jul 2010 12:55:00 +0200</pubDate>
+ <description>
+<p>Since
+<a href="http://people.skolelinux.org/pere/blog/LUMA__a_very_nice_LDAP_GUI.html">my
+last post</a> about available LDAP tools in Debian, I was told about a
+LDAP GUI that is even better than luma. The java application
+<a href="http://jxplorer.org/">jXplorer</a> is claimed to be capable of
+moving LDAP objects and subtrees using drag-and-drop, and can
+authenticate using Kerberos. I have only tested the Kerberos
+authentication, but do not have a LDAP setup allowing me to rewrite
+LDAP with my test user yet. It is
+<a href="http://packages.qa.debian.org/j/jxplorer.html">available in
+Debian</a> testing and unstable at the moment. The only problem I
+have with it is how it handle errors. If something go wrong, its
+non-intuitive behaviour require me to go through some query work list
+and remove the failing query. Nothing big, but very annoying.</p>
+</description>
+ </item>
+
+ <item>
+ <title>Idea for storing LTSP configuration in LDAP</title>
+ <link>http://people.skolelinux.org/pere/blog/Idea_for_storing_LTSP_configuration_in_LDAP.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Idea_for_storing_LTSP_configuration_in_LDAP.html</guid>
+ <pubDate>Sun, 11 Jul 2010 22:00:00 +0200</pubDate>
+ <description>
+<p>Vagrant mentioned on IRC today that ltsp_config now support
+sourcing files from /usr/share/ltsp/ltsp_config.d/ on the thin
+clients, and that this can be used to fetch configuration from LDAP if
+Debian Edu choose to store configuration there.</p>
+
+<p>Armed with this information, I got inspired and wrote a test module
+to get configuration from LDAP. The idea is to look up the MAC
+address of the client in LDAP, and look for attributes on the form
+ltspconfigsetting=value, and use this to export SETTING=value to the
+LTSP clients.</p>
+
+<p>The goal is to be able to store the LTSP configuration attributes
+in a "computer" LDAP object used by both DNS and DHCP, and thus
+allowing us to store all information about a computer in one place.</p>
+
+<p>This is a untested draft implementation, and I welcome feedback on
+this approach. A real LDAP schema for the ltspClientAux objectclass
+need to be written. Comments, suggestions, etc?</p>
+
+<blockquote><pre>
+# Store in /opt/ltsp/$arch/usr/share/ltsp/ltsp_config.d/ldap-config
+#
+# Fetch LTSP client settings from LDAP based on MAC address
+#
+# Uses ethernet address as stored in the dhcpHost objectclass using
+# the dhcpHWAddress attribute or ethernet address stored in the
+# ieee802Device objectclass with the macAddress attribute.
+#
+# This module is written to be schema agnostic, and only depend on the
+# existence of attribute names.
+#
+# The LTSP configuration variables are saved directly using a
+# ltspConfig prefix and uppercasing the rest of the attribute name.
+# To set the SERVER variable, set the ltspConfigServer attribute.
+#
+# Some LDAP schema should be created with all the relevant
+# configuration settings. Something like this should work:
+#
+# objectclass ( 1.1.2.2 NAME 'ltspClientAux'
+# SUP top
+# AUXILIARY
+# MAY ( ltspConfigServer $ ltsConfigSound $ ... )
+
+LDAPSERVER=$(debian-edu-ldapserver)
+if [ "$LDAPSERVER" ] ; then
+ LDAPBASE=$(debian-edu-ldapserver -b)
+ for MAC in $(LANG=C ifconfig |grep -i hwaddr| awk '{print $5}'|sort -u) ; do
+ filter="(|(dhcpHWAddress=ethernet $MAC)(macAddress=$MAC))"
+ ldapsearch -h "$LDAPSERVER" -b "$LDAPBASE" -v -x "$filter" | \
+ grep '^ltspConfig' | while read attr value ; do
+ # Remove prefix and convert to upper case
+ attr=$(echo $attr | sed 's/^ltspConfig//i' | tr a-z A-Z)
+ # bass value on to clients
+ eval "$attr=$value; export $attr"
+ done
+ done
+fi
+</pre></blockquote>
+
+<p>I'm not sure this shell construction will work, because I suspect
+the while block might end up in a subshell causing the variables set
+there to not show up in ltsp-config, but if that is the case I am sure
+the code can be restructured to make sure the variables are passed on.
+I expect that can be solved with some testing. :)</p>
+
+<p>If you want to help out with implementing this for Debian Edu,
+please contact us on debian-edu@lists.debian.org.</p>
+</description>
+ </item>
+
+ <item>
+ <title>Combining PowerDNS and ISC DHCP LDAP objects</title>
+ <link>http://people.skolelinux.org/pere/blog/Combining_PowerDNS_and_ISC_DHCP_LDAP_objects.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Combining_PowerDNS_and_ISC_DHCP_LDAP_objects.html</guid>
+ <pubDate>Wed, 14 Jul 2010 23:45:00 +0200</pubDate>
+ <description>
+<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>
+</description>
+ </item>
+
</channel>
</rss>
projects / homepage.git / blobdiff