Generated.

[homepage.git] / blog / archive / 2014 / 03 / 03.rss

<?xml version="1.0" encoding="ISO-8859-1"?>
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/'>
        <channel>
                <title>Petter Reinholdtsen - Entries from March 2014</title>
                <description>Entries from March 2014</description>
                <link>http://people.skolelinux.org/pere/blog/</link>

        
        <item>
                <title>Freedombox on Dreamplug, Raspberry Pi and virtual x86 machine</title>
                <link>http://people.skolelinux.org/pere/blog/Freedombox_on_Dreamplug__Raspberry_Pi_and_virtual_x86_machine.html</link>        
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Freedombox_on_Dreamplug__Raspberry_Pi_and_virtual_x86_machine.html</guid>
                <pubDate>Fri, 14 Mar 2014 11:00:00 +0100</pubDate>
                <description>&lt;p&gt;The &lt;a href=&quot;https://wiki.debian.org/FreedomBox&quot;&gt;Freedombox
project&lt;/a&gt; is working on to providing the software and hardware for
making it easy for non-technical people to host their data and
communication at home, and being able to communicate with their
friends and family encrypted and away from prying eyes.  It has been
going on for a while, and is slowly progressing towards a new test
release (0.2).  And what day could be better than the Pi day to
announce that the new version will provide &quot;hard drive&quot;/SD card/USB
stick images for Dreamplug, Raspberry Pi and VirtualBox (or any other
virtualization system), and can also be installed using a Debian
installer preseed file.  The Debian based Freedombox is now based on
Debian Jessie, where most of the needed packages used are already
present.  Only one, the freedombox-setup package, is missing.  To try
to build your own boot image to test the current status, fetch the
freedom-maker scripts and build using
&lt;a href=&quot;http://packages.qa.debian.org/vmdebootstrap&quot;&gt;vmdebootstrap&lt;/a&gt;
with a user with sudo access to become root:

&lt;pre&gt;
git clone http://anonscm.debian.org/git/freedombox/freedom-maker.git \
  freedom-maker
sudo apt-get install git vmdebootstrap mercurial python-docutils \
  mktorrent extlinux virtualbox qemu-user-static binfmt-support \
  u-boot-tools
make -C freedom-maker dreamplug-image raspberry-image virtualbox-image
&lt;/pre&gt;

&lt;p&gt;Root access is needed to run debootstrap and mount loopback
devices.  See the README for more details on the build. If you do not
want all three images, trim the make line.  But note that thanks to &lt;a
href=&quot;https://bugs.debian.org/741407&quot;&gt;a race condition in
vmdebootstrap&lt;/a&gt;, the build might fail without the patch to the
kpartx call.&lt;/p&gt;

&lt;p&gt;If you instead want to install using a Debian CD and the preseed
method, boot a Debian Wheezy ISO and use this boot argument to load
the preseed values:&lt;/p&gt;

&lt;pre&gt;
url=&lt;a href=&quot;http://www.reinholdtsen.name/freedombox/preseed-jessie.dat&quot;&gt;http://www.reinholdtsen.name/freedombox/preseed-jessie.dat&lt;/a&gt;
&lt;/pre&gt;

&lt;p&gt;But note that due to &lt;a href=&quot;https://bugs.debian.org/740673&quot;&gt;a
recently introduced bug in apt in Jessie&lt;/a&gt;, the installer will
currently hang while setting up APT sources.  Killing the
&#39;&lt;tt&gt;apt-cdrom ident&lt;/tt&gt;&#39; process when it hang a few times during the
installation will get the installation going.  This affect all
installations in Jessie, and I expect it will be fixed soon.&lt;/p&gt;

Give it a go and let us know how it goes on the mailing list, and help
us get the new release published. :) Please join us on
&lt;a href=&quot;irc://irc.debian.org:6667/%23freedombox&quot;&gt;IRC (#freedombox on
irc.debian.org)&lt;/a&gt; and
&lt;a href=&quot;http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss&quot;&gt;the
mailing list&lt;/a&gt; if you want to help make this vision come true.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <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>&lt;p&gt;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 &lt;a href=&quot;http://www.skolelinux.org/&quot;&gt;Debian Edu / Skolelinux&lt;/a&gt;, 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
&lt;a href=&quot;http://www.slxdrift.no/&quot;&gt;Skolelinux Drift AS&lt;/a&gt;, where I am
on the board of directors, asked about how to do this.  The steps to
get this working are the following:&lt;/p&gt;

&lt;p&gt;&lt;ol&gt;

&lt;li&gt;Add new storage server in DNS.  I use nas-server.intern as the
example host here.&lt;/li&gt;

&lt;li&gt;Add automoun LDAP information about this server in LDAP, to allow
all clients to automatically mount it on reqeust.&lt;/li&gt;

&lt;li&gt;Add the relevant entries in tjener.intern:/etc/fstab, because
tjener.intern do not use automount to avoid mounting loops.&lt;/li&gt;

&lt;/ol&gt;&lt;/p&gt;

&lt;p&gt;DNS entries are added in GOsa², and not described here.  Follow the
&lt;a href=&quot;https://wiki.debian.org/DebianEdu/Documentation/Wheezy/GettingStarted&quot;&gt;instructions
in the manual&lt;/a&gt; (Machine Management with GOsa² in section Getting
started).&lt;/p&gt;

&lt;p&gt;Ensure that the NFS export points on the server are exported to the
relevant subnets or machines:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
root@tjener:~# showmount -e nas-server
Export list for nas-server:
/storage         10.0.0.0/8
root@tjener:~#
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
ldapvi --ldap-conf -ZD &#39;(cn=admin)&#39; -b ou=automount,dc=skole,dc=skolelinux,dc=no
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;When the editor show up, add the following LDAP objects at the
bottom of the document.  The &quot;/&amp;&quot; 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.&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
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:/&amp;
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;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 &quot;mount -a&quot; to mount them.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;
</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>&lt;p&gt;For noen uker siden ble NXCs fri programvarelisenserte
NOARK5-løsning
&lt;a href=&quot;http://www.nuug.no/aktiviteter/20140211-noark/&quot;&gt;presentert hos
NUUG&lt;/a&gt; (video
&lt;a href=&quot;https://www.youtube.com/watch?v=JCb_dNS3MHQ&quot;&gt;på youtube
foreløbig&lt;/a&gt;), 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).&lt;/p&gt;

&lt;p&gt;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
&lt;a href=&quot;http://samdok.com/&quot;&gt;SAMDOK&lt;/a&gt;, en gruppe tilknyttet
arkivverket som ser ut til å jobbe med NOARK-samhandling, om de hadde
noen anbefalinger:

&lt;p&gt;&lt;blockquote&gt;
&lt;p&gt;Hei.&lt;/p&gt;

&lt;p&gt;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å
&amp;lt;URL: &lt;a href=&quot;https://www.informit.com/articles/article.aspx?p=32074&quot;&gt;https://www.informit.com/articles/article.aspx?p=32074&lt;/a&gt; &amp;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.&lt;/p&gt;
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;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:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;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å &quot;rfc 822
xml&quot;, så finner du aktuelle alternativer).&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;&lt;a href=&quot;http://www.openhealth.org/xmtp/&quot;&gt;XML MIME Transformation
protocol (XMTP)&lt;/a&gt; fra OpenHealth, sist oppdatert 2001.&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;https://tools.ietf.org/html/draft-klyne-message-rfc822-xml-03&quot;&gt;An
XML format for mail and other messages&lt;/a&gt; utkast fra IETF datert
2001.&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;http://www.informit.com/articles/article.aspx?p=32074&quot;&gt;xMail:
E-mail as XML&lt;/a&gt; en artikkel fra 2003 som beskriver python-modulen
rfc822 som gir ut XML-representasjon av en RFC 822-formattert epost.&lt;/li&gt;

&lt;/ul&gt;

&lt;p&gt;Finnes det andre og bedre spesifikasjoner for slik lagring?  Send
meg en epost hvis du har innspill.&lt;/p&gt;
</description>
        </item>
        
        </channel>
</rss>