Petter Reinholdtsen

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 Debian Edu / Skolelinux, 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 Skolelinux Drift AS, where I am on the board of directors, asked about how to do this. The steps to get this working are the following:

1. Add new storage server in DNS. I use nas-server.intern as the example host here.
2. Add automoun LDAP information about this server in LDAP, to allow all clients to automatically mount it on reqeust.
3. Add the relevant entries in tjener.intern:/etc/fstab, because tjener.intern do not use automount to avoid mounting loops.

DNS entries are added in GOsa², and not described here. Follow the instructions in the manual (Machine Management with GOsa² in section Getting started).

Ensure that the NFS export points on the server are exported to the relevant subnets or machines:

root@tjener:~# showmount -e nas-server
Export list for nas-server:
/storage         10.0.0.0/8
root@tjener:~#

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.

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.

ldapvi --ldap-conf -ZD '(cn=admin)' -b ou=automount,dc=skole,dc=skolelinux,dc=no

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.

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:/&

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.

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.

For noen uker siden ble NXCs fri programvarelisenserte NOARK5-løsning presentert hos NUUG (video på youtube foreløbig), 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).

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 SAMDOK, en gruppe tilknyttet arkivverket som ser ut til å jobbe med NOARK-samhandling, om de hadde noen anbefalinger:

Hei.

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å <URL: https://www.informit.com/articles/article.aspx?p=32074 >? 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.

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:

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.

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.

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).

• XML MIME Transformation protocol (XMTP) fra OpenHealth, sist oppdatert 2001.
• An XML format for mail and other messages utkast fra IETF datert 2001.
• xMail: E-mail as XML en artikkel fra 2003 som beskriver python-modulen rfc822 som gir ut XML-representasjon av en RFC 822-formattert epost.

Finnes det andre og bedre spesifikasjoner for slik lagring? Send meg en epost hvis du har innspill.