- <title>Fourth alpha release of Debian Edu/Skolelinux based on Debian Wheezy</title>
- <link>http://people.skolelinux.org/pere/blog/Fourth_alpha_release_of_Debian_Edu_Skolelinux_based_on_Debian_Wheezy.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Fourth_alpha_release_of_Debian_Edu_Skolelinux_based_on_Debian_Wheezy.html</guid>
- <pubDate>Wed, 3 Jul 2013 14:00:00 +0200</pubDate>
- <description><p>The fourth wheezy based alpha release of Debian Edu was wrapped up
-today. This is the release announcement:</p>
-
-<p><strong>New features for Debian Edu 7.1+edu0~alpha3 released
-2013-07-03</strong></p>
-
-<p>These are the release notes for for Debian Edu / Skolelinux
-7.1+edu0~alpha3, based on Debian with codename "Wheezy".</p>
-
-<p><strong>About Debian Edu and Skolelinux</strong></p>
-
-<p><a href="http://www.skolelinux.org/">Debian Edu, also known as
-Skolelinux</a>, is a Linux distribution based on Debian providing an
-out-of-the box environment of a completely configured school
-network. Immediately after installation a school server running all
-services needed for a school network is set up just waiting for users
-and machines being added via GOsa², a comfortable Web-UI. A netbooting
-environment is prepared using PXE, so after initial installation of
-the main server from CD, DVD or USB stick all other machines can be
-installed via the network. The provided school server provides LDAP
-database and Kerberos authentication service, centralized home
-directories, DHCP server, web proxy and many other services. The
-desktop contains
-<a href="http://people.skolelinux.org/pere/blog/Educational_applications_included_in_Debian_Edu___Skolelinux__the_screenshot_collection____.html">more
-than 60 educational software packages</a> and more are available from
-the Debian archive, and schools can choose between KDE, Gnome, LXDE
-and Xfce desktop environment.</p>
-
-<p>This is the fourth test release based on Debian Wheezy. Basically
-this is an updated and slightly improved version compared to the
-Squeeze release.</p>
-
-<p><strong>Software updates</strong></p>
-<ul>
- <li>Dropped ispell dictionaries from our default installation.</li>
- <li>Dropped menu-xdg from the KDE desktop option, to drop the Debian
- submenu. It was not included with Gnome, LXDE or Xfce, so this
- brings KDE in line with the others.</li>
- <li>Dropped xdrawchem, xjig and xsok from our default installation as
- they don't have a desktop menu entry and thus won't show up in the
- menu now that menu-xdg was removed.</li>
- <li>Removed the killer system to kill left behind processes on
- multi-user machines, as it was no longer able to understand when a
- X display was in use and killed the processes of the active users
- too.</li>
- <li>Dropped the golearn (from goplay) package as the debtags in wheezy
- are too few to make the package useful.</li>
-</ul>
-<p><strong>Other changes</strong></p>
-<ul>
- <li>Updated artwork matching http://wiki.debian.org/DebianArt/Themes/Joy
- <li>Multi-arch i386/amd64 USB stick ISO available.</li>
- <li>Got rid of ispell/wordlist related debconf questions that showed
- up for some language options.</li>
- <li>Switched to using http.debian.net as APT source by default.</li>
- <li>Fixed proxy configuration on Main Server installations.</li>
- <li>Changed LTSP setup to ask dpkg to use force-unsafe-io the same way
- d-i is doing it.</li>
- <li>Made sure root and user passwords were not left behind in the
- debconf database after installation on Main Server installations.</li>
- <li>Made Roaming Workstation dynamic setup more robust and added draft
- script setup-ad-client to hook a Roaming Workstation up to a
- Active Directory server instead of a Debian Edu Main Server.</li>
- <li>Update system to install needed firmware packages during
- installation, to work properly in Wheezy.</li>
- <li>Update system to handle hardware quirks (debian-edu-hwsetup).</li>
- <li>Corrected PXE installation setup to properly pass selected desktop
- and keymap settings to PXE installation clients.</li>
- <li>LTSP diskless workstations use sshfs by default, allowing them to
- work without adding them to DNS and NIS netgroups for NFS access.</li>
-</ul>
-<p><strong>Known issues</strong></p>
-<ul>
- <li>No mass import of user account data in GOsa (ldif or csv)
- available yet (698840).</li>
- <li>Artwork not enabled for all desktops.</li>
-</ul>
-<p><strong>Where to get it</strong></p>
+ <title>How to add extra storage servers in Debian Edu / Skolelinux</title>
+ <link>http://people.skolelinux.org/pere/blog/How_to_add_extra_storage_servers_in_Debian_Edu___Skolelinux.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/How_to_add_extra_storage_servers_in_Debian_Edu___Skolelinux.html</guid>
+ <pubDate>Wed, 12 Mar 2014 12:50:00 +0100</pubDate>
+ <description><p>On larger sites, it is useful to use a dedicated storage server for
+storing user home directories and data. The design for handling this
+in <a href="http://www.skolelinux.org/">Debian Edu / Skolelinux</a>, is
+to update the automount rules in LDAP and let the automount daemon on
+the clients take care of the rest. I was reminded about the need to
+document this better when one of the customers of
+<a href="http://www.slxdrift.no/">Skolelinux Drift AS</a>, where I am
+on the board of directors, asked about how to do this. The steps to
+get this working are the following:</p>
+
+<p><ol>
+
+<li>Add new storage server in DNS. I use nas-server.intern as the
+example host here.</li>
+
+<li>Add automoun LDAP information about this server in LDAP, to allow
+all clients to automatically mount it on reqeust.</li>
+
+<li>Add the relevant entries in tjener.intern:/etc/fstab, because
+tjener.intern do not use automount to avoid mounting loops.</li>
+
+</ol></p>
+
+<p>DNS entries are added in GOsa², and not described here. Follow the
+<a href="https://wiki.debian.org/DebianEdu/Documentation/Wheezy/GettingStarted">instructions
+in the manual</a> (Machine Management with GOsa² in section Getting
+started).</p>
+
+<p>Ensure that the NFS export points on the server are exported to the
+relevant subnets or machines:</p>
+
+<p><blockquote><pre>
+root@tjener:~# showmount -e nas-server
+Export list for nas-server:
+/storage 10.0.0.0/8
+root@tjener:~#
+</pre></blockquote></p>
+
+<p>Here everything on the backbone network is granted access to the
+/storage export. With NFSv3 it is slightly better to limit it to
+netgroup membership or single IP addresses to have some limits on the
+NFS access.</p>
+
+<p>The next step is to update LDAP. This can not be done using GOsa²,
+because it lack a module for automount. Instead, use ldapvi and add
+the required LDAP objects using an editor.</p>
+
+<p><blockquote><pre>
+ldapvi --ldap-conf -ZD '(cn=admin)' -b ou=automount,dc=skole,dc=skolelinux,dc=no
+</pre></blockquote></p>
+
+<p>When the editor show up, add the following LDAP objects at the
+bottom of the document. The "/&" part in the last LDAP object is a
+wild card matching everything the nas-server exports, removing the
+need to list individual mount points in LDAP.</p>
+
+<p><blockquote><pre>
+add cn=nas-server,ou=auto.skole,ou=automount,dc=skole,dc=skolelinux,dc=no
+objectClass: automount
+cn: nas-server
+automountInformation: -fstype=autofs --timeout=60 ldap:ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no
+
+add ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no
+objectClass: top
+objectClass: automountMap
+ou: auto.nas-server
+
+add cn=/,ou=auto.nas-server,ou=automount,dc=skole,dc=skolelinux,dc=no
+objectClass: automount
+cn: /
+automountInformation: -fstype=nfs,tcp,rsize=32768,wsize=32768,rw,intr,hard,nodev,nosuid,noatime nas-server.intern:/&
+</pre></blockquote></p>
+
+<p>The last step to remember is to mount the relevant mount points in
+tjener.intern by adding them to /etc/fstab, creating the mount
+directories using mkdir and running "mount -a" to mount them.</p>
+
+<p>When this is done, your users should be able to access the files on
+the storage server directly by just visiting the
+/tjener/nas-server/storage/ directory using any application on any
+workstation, LTSP client or LTSP server.</p>
+</description>
+ </item>
+
+ <item>
+ <title>Hvordan bør RFC 822-formattert epost lagres i en NOARK5-database?</title>
+ <link>http://people.skolelinux.org/pere/blog/Hvordan_b_r_RFC_822_formattert_epost_lagres_i_en_NOARK5_database_.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Hvordan_b_r_RFC_822_formattert_epost_lagres_i_en_NOARK5_database_.html</guid>
+ <pubDate>Fri, 7 Mar 2014 15:20:00 +0100</pubDate>
+ <description><p>For noen uker siden ble NXCs fri programvarelisenserte
+NOARK5-løsning
+<a href="http://www.nuug.no/aktiviteter/20140211-noark/">presentert hos
+NUUG</a> (video
+<a href="https://www.youtube.com/watch?v=JCb_dNS3MHQ">på youtube
+foreløbig</a>), og det fikk meg til å titte litt mer på NOARK5,
+standarden for arkivhåndtering i det offentlige Norge. Jeg lurer på
+om denne kjernen kan være nyttig i et par av mine prosjekter, og for ett
+av dem er det mest aktuelt å lagre epost. Jeg klarte ikke finne noen
+anbefaling om hvordan RFC 822-formattert epost (aka Internett-epost)
+burde lagres i NOARK5, selv om jeg vet at noen arkiver tar
+PDF-utskrift av eposten med sitt epostprogram og så arkiverer PDF-en
+(eller enda værre, tar papirutskrift og lagrer bildet av eposten som
+PDF i arkivet).</p>
+
+<p>Det er ikke så mange formater som er akseptert av riksarkivet til
+langtidsoppbevaring av offentlige arkiver, og PDF og XML er de mest
+aktuelle i så måte. Det slo meg at det måtte da finnes en eller annen
+egnet XML-representasjon og at det kanskje var enighet om hvilken som
+burde brukes, så jeg tok mot til meg og spurte
+<a href="http://samdok.com/">SAMDOK</a>, en gruppe tilknyttet
+arkivverket som ser ut til å jobbe med NOARK-samhandling, om de hadde
+noen anbefalinger:
+
+<p><blockquote>
+<p>Hei.</p>
+
+<p>Usikker på om dette er riktig forum å ta opp mitt spørsmål, men jeg
+lurer på om det er definert en anbefaling om hvordan RFC
+822-formatterte epost (aka vanlig Internet-epost) bør lages håndteres
+i NOARK5, slik at en bevarer all informasjon i eposten
+(f.eks. Received-linjer). Finnes det en anbefalt XML-mapping ala den
+som beskrives på
+&lt;URL: <a href="https://www.informit.com/articles/article.aspx?p=32074">https://www.informit.com/articles/article.aspx?p=32074</a> &gt;? Mitt
+mål er at det skal være mulig å lagre eposten i en NOARK5-kjerne og
+kunne få ut en identisk formattert kopi av opprinnelig epost ved
+behov.</p>
+</blockquote></p>
+
+<p>Postmottaker hos SAMDOK mente spørsmålet heller burde stilles
+direkte til riksarkivet, og jeg fikk i dag svar derfra formulert av
+seniorrådgiver Geir Ivar Tungesvik:</p>
+
+<p><blockquote>
+<p>Riksarkivet har ingen anbefalinger når det gjelder konvertering fra
+e-post til XML. Det står arkivskaper fritt å eventuelt definere/bruke
+eget format. Inklusive da - som det spørres om - et format der det er
+mulig å re-etablere e-post format ut fra XML-en. XML (e-post)
+dokumenter må være referert i arkivstrukturen, og det må vedlegges et
+gyldig XML skjema (.xsd) for XML-filene. Arkivskaper står altså fritt
+til å gjøre hva de vil, bare det dokumenteres og det kan dannes et
+utrekk ved avlevering til depot.</p>
+
+<p>De obligatoriske kravene i Noark 5 standarden må altså oppfylles -
+etter dialog med Riksarkivet i forbindelse med godkjenning. For
+offentlige arkiv er det særlig viktig med filene loependeJournal.xml
+og offentligJournal.xml. Private arkiv som vil forholde seg til Noark
+5 standarden er selvsagt frie til å bruke det som er relevant for dem
+av obligatoriske krav.</p>
+</blockquote></p>
+
+<p>Det ser dermed ut for meg som om det er et lite behov for å
+standardisere XML-lagring av RFC-822-formatterte meldinger. Noen som
+vet om god spesifikasjon i så måte? I tillegg til den omtalt over,
+har jeg kommet over flere aktuelle beskrivelser (søk på "rfc 822
+xml", så finner du aktuelle alternativer).</p>