- <title>s3ql, a locally mounted cloud file system - nice free software</title>
- <link>http://people.skolelinux.org/pere/blog/s3ql__a_locally_mounted_cloud_file_system___nice_free_software.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/s3ql__a_locally_mounted_cloud_file_system___nice_free_software.html</guid>
- <pubDate>Wed, 9 Apr 2014 11:30:00 +0200</pubDate>
- <description><p>For a while now, I have been looking for a sensible offsite backup
-solution for use at home. My requirements are simple, it must be
-cheap and locally encrypted (in other words, I keep the encryption
-keys, the storage provider do not have access to my private files).
-One idea me and my friends have had many years ago, before the cloud
-storage providers showed up, have been to use Google mail as storage,
-writing a Linux block device storing blocks as emails in the mail
-service provided by Google, and thus get heaps of free space. On top
-of this one can add encryption, RAID and volume management to have
-lots of (fairly slow, I admit that) cheap and encrypted storage. But
-I never found time to implement such system. But the last few weeks I
-have looked at a system called
-<a href="https://bitbucket.org/nikratio/s3ql/">S3QL</a>, a locally
-mounted network backed file system with the features I need.</p>
-
-<p>S3QL is a fuse file system with a local cache and cloud storage,
-handling several different storage providers, any with Amazon S3,
-Google Drive or OpenStack API. There are heaps of such storage
-providers. S3QL can also use a local directory as storage, which
-combined with sshfs allow for file storage on any ssh server. S3QL
-include support for encryption, compression, de-duplication, snapshots
-and immutable file systems, allowing me to mount the remote storage as
-a local mount point, look at and use the files as if they were local,
-while the content is stored in the cloud as well. This allow me to
-have a backup that should survive fire. The file system can not be
-shared between several machines at the same time, as only one can
-mount it at the time, but any machine with the encryption key and
-access to the storage service can mount it if it is unmounted.</p>
-
-<p>It is simple to use. I'm using it on Debian Wheezy, where the
-package is included already. So to get started, run <tt>apt-get
-install s3ql</tt>. Next, pick a storage provider. I ended up picking
-Greenqloud, after reading their nice recipe on
-<a href="https://greenqloud.zendesk.com/entries/44611757-How-To-Use-S3QL-to-mount-a-StorageQloud-bucket-on-Debian-Wheezy">how
-to use s3ql with their Amazon S3 service</a>, because I trust the laws
-in Iceland more than those in USA when it come to keeping my personal
-data safe and private, and thus would rather spend money on a company
-in Iceland. Another nice recipe is available from the article
-<a href="http://www.admin-magazine.com/HPC/Articles/HPC-Cloud-Storage">S3QL
-Filesystem for HPC Storage</a> by Jeff Layton in the HPC section of
-Admin magazine. When the provider is picked, figure out how to get
-the API key needed to connect to the storage API. With Greencloud,
-the key did not show up until I had added payment details to my
-account.</p>
-
-<p>Armed with the API access details, it is time to create the file
-system. First, create a new bucket in the cloud. This bucket is the
-file system storage area. I picked a bucket name reflecting the
-machine that was going to store data there, but any name will do.
-I'll refer to it as <tt>bucket-name</tt> below. In addition, one need
-the API login and password, and a locally created password. Store it
-all in ~root/.s3ql/authinfo2 like this:
-
-<p><blockquote><pre>
-[s3c]
-storage-url: s3c://s.greenqloud.com:443/bucket-name
-backend-login: API-login
-backend-password: API-password
-fs-passphrase: local-password
-</pre></blockquote></p>
-
-<p>I create my local passphrase using <tt>pwget 50</tt> or similar,
-but any sensible way to create a fairly random password should do it.
-Armed with these details, it is now time to run mkfs, entering the API
-details and password to create it:</p>
-
-<p><blockquote><pre>
-# mkdir -m 700 /var/lib/s3ql-cache
-# mkfs.s3ql --cachedir /var/lib/s3ql-cache --authfile /root/.s3ql/authinfo2 \
- --ssl s3c://s.greenqloud.com:443/bucket-name
-Enter backend login:
-Enter backend password:
-Before using S3QL, make sure to read the user's guide, especially
-the 'Important Rules to Avoid Loosing Data' section.
-Enter encryption password:
-Confirm encryption password:
-Generating random encryption key...
-Creating metadata tables...
-Dumping metadata...
-..objects..
-..blocks..
-..inodes..
-..inode_blocks..
-..symlink_targets..
-..names..
-..contents..
-..ext_attributes..
-Compressing and uploading metadata...
-Wrote 0.00 MB of compressed metadata.
-# </pre></blockquote></p>
-
-<p>The next step is mounting the file system to make the storage available.
-
-<p><blockquote><pre>
-# mount.s3ql --cachedir /var/lib/s3ql-cache --authfile /root/.s3ql/authinfo2 \
- --ssl --allow-root s3c://s.greenqloud.com:443/bucket-name /s3ql
-Using 4 upload threads.
-Downloading and decompressing metadata...
-Reading metadata...
-..objects..
-..blocks..
-..inodes..
-..inode_blocks..
-..symlink_targets..
-..names..
-..contents..
-..ext_attributes..
-Mounting filesystem...
-# df -h /mnt
-Filesystem Size Used Avail Use% Mounted on
-s3c://s.greenqloud.com:443/bucket-name 1.0T 0 1.0T 0% /s3ql
-#
-</pre></blockquote></p>
-
-<p>The file system is now ready for use. I use rsync to store my
-backups in it, and as the metadata used by rsync is downloaded at
-mount time, no network traffic (and storage cost) is triggered by
-running rsync. To unmount, one should not use the normal umount
-command, as this will not flush the cache to the cloud storage, but
-instead running the umount.s3ql command like this:
-
-<p><blockquote><pre>
-# umount.s3ql /s3ql
-#
-</pre></blockquote></p>
-
-<p>There is a fsck command available to check the file system and
-correct any problems detected. This can be used if the local server
-crashes while the file system is mounted, to reset the "already
-mounted" flag. This is what it look like when processing a working
-file system:</p>
+ <title>Hva henger under skibrua over E16 på Sollihøgda?</title>
+ <link>http://people.skolelinux.org/pere/blog/Hva_henger_under_skibrua_over_E16_p__Sollih_gda_.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Hva_henger_under_skibrua_over_E16_p__Sollih_gda_.html</guid>
+ <pubDate>Sun, 21 Sep 2014 09:50:00 +0200</pubDate>
+ <description><p>Rundt omkring i Oslo og Østlandsområdet henger det bokser over
+veiene som jeg har lurt på hva gjør. De har ut fra plassering og
+vinkling sett ut som bokser som sniffer ut et eller annet fra
+forbipasserende trafikk, men det har vært uklart for meg hva det er de
+leser av. Her om dagen tok jeg bilde av en slik boks som henger under
+<a href="http://www.openstreetmap.no/?zoom=19&mlat=59.96396&mlon=10.34443&layers=B00000">ei
+skibru på Sollihøgda</a>:</p>
+
+<p align="center"><img width="60%" src="http://people.skolelinux.org/pere/blog/images/2014-09-13-kapsch-sollihogda-crop.jpeg"></p>
+
+<p>Boksen er tydelig merket «Kapsch >>>», logoen til
+<a href="http://www.kapsch.net/">det sveitsiske selskapet Kapsch</a> som
+blant annet lager sensorsystemer for veitrafikk. Men de lager mye
+forskjellig, og jeg kjente ikke igjen boksen på utseendet etter en
+kjapp titt på produktlista til selskapet.</p>
+
+<p>I og med at boksen henger over veien E16, en riksvei vedlikeholdt
+av Statens Vegvesen, så antok jeg at det burde være mulig å bruke
+REST-API-et som gir tilgang til vegvesenets database over veier,
+skilter og annet veirelatert til å finne ut hva i alle dager dette
+kunne være. De har både
+<a href="https://www.vegvesen.no/nvdb/api/dokumentasjon/datakatalog">en
+datakatalog</a> og
+<a href="https://www.vegvesen.no/nvdb/api/dokumentasjon/sok">et
+søk</a>, der en kan søke etter ulike typer oppføringer innen for et
+gitt geografisk område. Jeg laget et enkelt shell-script for å hente
+ut antall av en gitt type innenfor området skibrua dekker, og listet
+opp navnet på typene som ble funnet. Orket ikke slå opp hvordan
+URL-koding av aktuelle strenger kunne gjøres mer generisk, og brukte
+en stygg sed-linje i stedet.</p>
+
+<blockquote><pre>
+#!/bin/sh
+urlmap() {
+ sed \
+ -e 's/ / /g' -e 's/{/%7B/g' \
+ -e 's/}/%7D/g' -e 's/\[/%5B/g' \
+ -e 's/\]/%5D/g' -e 's/ /%20/g' \
+ -e 's/,/%2C/g' -e 's/\"/%22/g' \
+ -e 's/:/%3A/g'
+}
+
+lookup() {
+ url="$1"
+ curl -s -H 'Accept: application/vnd.vegvesen.nvdb-v1+xml' \
+ "https://www.vegvesen.no/nvdb/api$url" | xmllint --format -
+}
+
+for id in $(seq 1 874) ; do
+ search="{
+ lokasjon: {
+ bbox: \"10.34425,59.96386,10.34458,59.96409\",
+ srid: \"WGS84\"
+ },
+ objektTyper: [{
+ id: $id, antall: 10
+ }]
+}"
+
+ query=/sok?kriterie=$(echo $search | urlmap)
+ if lookup "$query" |
+ grep -q '&lt;totaltAntallReturnert>0&lt;'
+ then
+ :
+ else
+ echo $id
+ lookup "/datakatalog/objekttyper/$id" |grep '^ &lt;navn>'
+ fi
+done
+
+exit 0
+</pre></blockquote>
+
+Aktuelt ID-område 1-874 var riktig i datakatalogen da jeg laget
+scriptet. Det vil endre seg over tid. Skriptet listet så opp
+aktuelle typer i og rundt skibrua:
+
+<blockquote><pre>
+5
+ &lt;navn>Rekkverk&lt;/navn>
+14
+ &lt;navn>Rekkverksende&lt;/navn>
+47
+ &lt;navn>Trafikklomme&lt;/navn>
+49
+ &lt;navn>Trafikkøy&lt;/navn>
+60
+ &lt;navn>Bru&lt;/navn>
+79
+ &lt;navn>Stikkrenne/Kulvert&lt;/navn>
+80
+ &lt;navn>Grøft, åpen&lt;/navn>
+86
+ &lt;navn>Belysningsstrekning&lt;/navn>
+95
+ &lt;navn>Skiltpunkt&lt;/navn>
+96
+ &lt;navn>Skiltplate&lt;/navn>
+98
+ &lt;navn>Referansestolpe&lt;/navn>
+99
+ &lt;navn>Vegoppmerking, langsgående&lt;/navn>
+105
+ &lt;navn>Fartsgrense&lt;/navn>
+106
+ &lt;navn>Vinterdriftsstrategi&lt;/navn>
+172
+ &lt;navn>Trafikkdeler&lt;/navn>
+241
+ &lt;navn>Vegdekke&lt;/navn>
+293
+ &lt;navn>Breddemåling&lt;/navn>
+301
+ &lt;navn>Kantklippareal&lt;/navn>
+318
+ &lt;navn>Snø-/isrydding&lt;/navn>
+445
+ &lt;navn>Skred&lt;/navn>
+446
+ &lt;navn>Dokumentasjon&lt;/navn>
+452
+ &lt;navn>Undergang&lt;/navn>
+528
+ &lt;navn>Tverrprofil&lt;/navn>
+532
+ &lt;navn>Vegreferanse&lt;/navn>
+534
+ &lt;navn>Region&lt;/navn>
+535
+ &lt;navn>Fylke&lt;/navn>
+536
+ &lt;navn>Kommune&lt;/navn>
+538
+ &lt;navn>Gate&lt;/navn>
+539
+ &lt;navn>Transportlenke&lt;/navn>
+540
+ &lt;navn>Trafikkmengde&lt;/navn>
+570
+ &lt;navn>Trafikkulykke&lt;/navn>
+571
+ &lt;navn>Ulykkesinvolvert enhet&lt;/navn>
+572
+ &lt;navn>Ulykkesinvolvert person&lt;/navn>
+579
+ &lt;navn>Politidistrikt&lt;/navn>
+583
+ &lt;navn>Vegbredde&lt;/navn>
+591
+ &lt;navn>Høydebegrensning&lt;/navn>
+592
+ &lt;navn>Nedbøyningsmåling&lt;/navn>
+597
+ &lt;navn>Støy-luft, Strekningsdata&lt;/navn>
+601
+ &lt;navn>Oppgravingsdata&lt;/navn>
+602
+ &lt;navn>Oppgravingslag&lt;/navn>
+603
+ &lt;navn>PMS-parsell&lt;/navn>
+604
+ &lt;navn>Vegnormalstrekning&lt;/navn>
+605
+ &lt;navn>Værrelatert strekning&lt;/navn>
+616
+ &lt;navn>Feltstrekning&lt;/navn>
+617
+ &lt;navn>Adressepunkt&lt;/navn>
+626
+ &lt;navn>Friksjonsmåleserie&lt;/navn>
+629
+ &lt;navn>Vegdekke, flatelapping&lt;/navn>
+639
+ &lt;navn>Kurvatur, horisontalelement&lt;/navn>
+640
+ &lt;navn>Kurvatur, vertikalelement&lt;/navn>
+642
+ &lt;navn>Kurvatur, vertikalpunkt&lt;/navn>
+643
+ &lt;navn>Statistikk, trafikkmengde&lt;/navn>
+647
+ &lt;navn>Statistikk, vegbredde&lt;/navn>
+774
+ &lt;navn>Nedbøyningsmåleserie&lt;/navn>
+775
+ &lt;navn>ATK, influensstrekning&lt;/navn>
+794
+ &lt;navn>Systemobjekt&lt;/navn>
+810
+ &lt;navn>Vinterdriftsklasse&lt;/navn>
+821
+ &lt;navn>Funksjonell vegklasse&lt;/navn>
+825
+ &lt;navn>Kurvatur, stigning&lt;/navn>
+838
+ &lt;navn>Vegbredde, beregnet&lt;/navn>
+862
+ &lt;navn>Reisetidsregistreringspunkt&lt;/navn>
+871
+ &lt;navn>Bruksklasse&lt;/navn>
+</pre></blockquote>
+
+<p>Av disse ser ID 775 og 862 mest relevant ut. ID 775 antar jeg
+refererer til fotoboksen som står like ved brua, mens
+«Reisetidsregistreringspunkt» kanskje kan være boksen som henger der.
+Hvordan finner jeg så ut hva dette kan være for noe. En titt på
+<a href="http://labs.vegdata.no/nvdb-datakatalog/862-Reisetidsregistreringspunkt/">datakatalogsiden
+for ID 862/Reisetidsregistreringspunkt</a> viser at det er finnes 53
+slike målere i Norge, og hvor de er plassert, men gir ellers få
+detaljer. Det er plassert 40 på østlandet og 13 i Trondheimsregionen.
+Men siden nevner «AutoPASS», og hvis en slår opp oppføringen på
+Sollihøgda nevner den «Ciber AS» som ID for eksternt system. (Kan det
+være snakk om
+<a href="http://www.proff.no/selskap/ciber-norge-as/oslo/internettdesign-og-programmering/Z0I3KMF4/">Ciber
+Norge AS</a>, et selskap eid av Ciber Europe Bv?) Et nettsøk på
+ «Ciber AS autopass» fører meg til en artikkel fra NRK Trøndelag i
+ 2013 med tittel
+«<a href="http://www.nrk.no/trondelag/sjekk-dette-hvis-du-vil-unnga-ko-1.11327947">Sjekk
+dette hvis du vil unngå kø</a>». Artikkelen henviser til vegvesenets
+nettside
+<a href="http://www.reisetider.no/reisetid/forside.html">reisetider.no</a>
+som har en
+<a href="http://www.reisetider.no/reisetid/omrade.html?omrade=5">kartside
+for Østlandet</a> som viser at det måles mellom Sandvika og Sollihøgda.
+Det kan dermed se ut til at jeg har funnet ut hva boksene gjør.</p>
+
+<p>Hvis det stemmer, så er dette bokser som leser av AutoPASS-ID-en
+til alle passerende biler med AutoPASS-brikke, og dermed gjør det mulig
+for de som kontrollerer boksene å holde rede på hvor en gitt bil er
+når den passerte et slikt målepunkt. NRK-artikkelen forteller at
+denne informasjonen i dag kun brukes til å koble to
+AutoPASS-brikkepasseringer passeringer sammen for å beregne
+reisetiden, og at bruken er godkjent av Datatilsynet. Det er desverre
+ikke mulig for en sjåfør som passerer under en slik boks å kontrollere
+at AutoPASS-ID-en kun brukes til dette i dag og i fremtiden.</p>
+
+<p>I tillegg til denne type AutoPASS-sniffere vet jeg at det også
+finnes mange automatiske stasjoner som tar betalt pr. passering (aka
+bomstasjoner), og der lagres informasjon om tid, sted og bilnummer i
+10 år. Finnes det andre slike sniffere plassert ut på veiene?</p>
+
+<p>Personlig har jeg valgt å ikke bruke AutoPASS-brikke, for å gjøre
+det vanskeligere og mer kostbart for de som vil invadere privatsfæren
+og holde rede på hvor bilen min beveger seg til enhver tid. Jeg håper
+flere vil gjøre det samme, selv om det gir litt høyere private
+utgifter (dyrere bompassering). Vern om privatsfæren koster i disse
+dager.</p>
+
+<p>Takk til Jan Kristian Jensen i Statens Vegvesen for tips om
+dokumentasjon på vegvesenets REST-API.</p>
+</description>
+ </item>
+
+ <item>
+ <title>Speeding up the Debian installer using eatmydata and dpkg-divert</title>
+ <link>http://people.skolelinux.org/pere/blog/Speeding_up_the_Debian_installer_using_eatmydata_and_dpkg_divert.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Speeding_up_the_Debian_installer_using_eatmydata_and_dpkg_divert.html</guid>
+ <pubDate>Tue, 16 Sep 2014 14:00:00 +0200</pubDate>
+ <description><p>The <a href="https://www.debian.org/">Debian</a> installer could be
+a lot quicker. When we install more than 2000 packages in
+<a href="http://www.skolelinux.org/">Skolelinux / Debian Edu</a> using
+tasksel in the installer, unpacking the binary packages take forever.
+A part of the slow I/O issue was discussed in
+<a href="https://bugs.debian.org/613428">bug #613428</a> about too
+much file system sync-ing done by dpkg, which is the package
+responsible for unpacking the binary packages. Other parts (like code
+executed by postinst scripts) might also sync to disk during
+installation. All this sync-ing to disk do not really make sense to
+me. If the machine crash half-way through, I start over, I do not try
+to salvage the half installed system. So the failure sync-ing is
+supposed to protect against, hardware or system crash, is not really
+relevant while the installer is running.</p>
+
+<p>A few days ago, I thought of a way to get rid of all the file
+system sync()-ing in a fairly non-intrusive way, without the need to
+change the code in several packages. The idea is not new, but I have
+not heard anyone propose the approach using dpkg-divert before. It
+depend on the small and clever package
+<a href="https://packages.qa.debian.org/eatmydata">eatmydata</a>, which
+uses LD_PRELOAD to replace the system functions for syncing data to
+disk with functions doing nothing, thus allowing programs to live
+dangerous while speeding up disk I/O significantly. Instead of
+modifying the implementation of dpkg, apt and tasksel (which are the
+packages responsible for selecting, fetching and installing packages),
+it occurred to me that we could just divert the programs away, replace
+them with a simple shell wrapper calling
+"eatmydata&nbsp;$program&nbsp;$@", to get the same effect.
+Two days ago I decided to test the idea, and wrapped up a simple
+implementation for the Debian Edu udeb.</p>
+
+<p>The effect was stunning. In my first test it reduced the running
+time of the pkgsel step (installing tasks) from 64 to less than 44
+minutes (20 minutes shaved off the installation) on an old Dell
+Latitude D505 machine. I am not quite sure what the optimised time
+would have been, as I messed up the testing a bit, causing the debconf
+priority to get low enough for two questions to pop up during
+installation. As soon as I saw the questions I moved the installation
+along, but do not know how long the question were holding up the
+installation. I did some more measurements using Debian Edu Jessie,
+and got these results. The time measured is the time stamp in
+/var/log/syslog between the "pkgsel: starting tasksel" and the
+"pkgsel: finishing up" lines, if you want to do the same measurement
+yourself. In Debian Edu, the tasksel dialog do not show up, and the
+timing thus do not depend on how quickly the user handle the tasksel
+dialog.</p>
+
+<p><table>
+
+<tr>
+<th>Machine/setup</th>
+<th>Original tasksel</th>
+<th>Optimised tasksel</th>
+<th>Reduction</th>
+</tr>
+
+<tr>
+<td>Latitude D505 Main+LTSP LXDE</td>
+<td>64 min (07:46-08:50)</td>
+<td><44 min (11:27-12:11)</td>
+<td>>20 min 18%</td>
+</tr>
+
+<tr>
+<td>Latitude D505 Roaming LXDE</td>
+<td>57 min (08:48-09:45)</td>
+<td>34 min (07:43-08:17)</td>
+<td>23 min 40%</td>
+</tr>
+
+<tr>
+<td>Latitude D505 Minimal</td>
+<td>22 min (10:37-10:59)</td>
+<td>11 min (11:16-11:27)</td>
+<td>11 min 50%</td>
+</tr>
+
+<tr>
+<td>Thinkpad X200 Minimal</td>
+<td>6 min (08:19-08:25)</td>
+<td>4 min (08:04-08:08)</td>
+<td>2 min 33%</td>
+</tr>
+
+<tr>
+<td>Thinkpad X200 Roaming KDE</td>
+<td>19 min (09:21-09:40)</td>
+<td>15 min (10:25-10:40)</td>
+<td>4 min 21%</td>
+</tr>
+
+</table></p>
+
+<p>The test is done using a netinst ISO on a USB stick, so some of the
+time is spent downloading packages. The connection to the Internet
+was 100Mbit/s during testing, so downloading should not be a
+significant factor in the measurement. Download typically took a few
+seconds to a few minutes, depending on the amount of packages being
+installed.</p>
+
+<p>The speedup is implemented by using two hooks in
+<a href="https://www.debian.org/devel/debian-installer/">Debian
+Installer</a>, the pre-pkgsel.d hook to set up the diverts, and the
+finish-install.d hook to remove the divert at the end of the
+installation. I picked the pre-pkgsel.d hook instead of the
+post-base-installer.d hook because I test using an ISO without the
+eatmydata package included, and the post-base-installer.d hook in
+Debian Edu can only operate on packages included in the ISO. The
+negative effect of this is that I am unable to activate this
+optimization for the kernel installation step in d-i. If the code is
+moved to the post-base-installer.d hook, the speedup would be larger
+for the entire installation.</p>
+
+<p>I've implemented this in the
+<a href="https://packages.qa.debian.org/debian-edu-install">debian-edu-install</a>
+git repository, and plan to provide the optimization as part of the
+Debian Edu installation. If you want to test this yourself, you can
+create two files in the installer (or in an udeb). One shell script
+need do go into /usr/lib/pre-pkgsel.d/, with content like this:</p>