Petter Reinholdtsen

Entries from November 2014.

How to stay with sysvinit in Debian Jessie
22nd November 2014

By now, it is well known that Debian Jessie will not be using sysvinit as its boot system by default. But how can one keep using sysvinit in Jessie? It is fairly easy, and here are a few recipes, courtesy of Erich Schubert and Simon McVittie.

If you already are using Wheezy and want to upgrade to Jessie and keep sysvinit as your boot system, create a file /etc/apt/preferences.d/use-sysvinit with this content before you upgrade:

Package: systemd-sysv
Pin: release o=Debian
Pin-Priority: -1

This file content will tell apt and aptitude to not consider installing systemd-sysv as part of any installation and upgrade solution when resolving dependencies, and thus tell it to avoid systemd as a default boot system. The end result should be that the upgraded system keep using sysvinit.

If you are installing Jessie for the first time, there is no way to get sysvinit installed by default (debootstrap used by debian-installer have no option for this), but one can tell the installer to switch to sysvinit before the first boot. Either by using a kernel argument to the installer, or by adding a line to the preseed file used. First, the kernel command line argument:

preseed/late_command="in-target apt-get install --purge -y sysvinit-core"

Next, the line to use in a preseed file:

d-i preseed/late_command string in-target apt-get install -y sysvinit-core

One can of course also do this after the first boot by installing the sysvinit-core package.

I recommend only using sysvinit if you really need it, as the sysvinit boot sequence in Debian have several hardware specific bugs on Linux caused by the fact that it is unpredictable when hardware devices show up during boot. But on the other hand, the new default boot system still have a few rough edges I hope will be fixed before Jessie is released.

Update 2014-11-26: Inspired by a blog post by Torsten Glaser, added --purge to the preseed line.

Tags: bootsystem, debian, english.
Hvordan vurderer regjeringen H.264-patentutfordringen?
16th November 2014

For en stund tilbake spurte jeg Fornyingsdepartementet om hvilke juridiske vurderinger rundt patentproblemstillingen som var gjort da H.264 ble tatt inn i statens referansekatalog over standarder. Stig Hornnes i FAD tipset meg om følgende som står i oppsumeringen til høringen om referansekatalogen versjon 2.0, som jeg siden ved hjelp av en innsynsforespørsel fikk tak i PDF-utgaven av datert 2009-06-03 (saksnummer 200803291, saksbehandler Henrik Linnestad).

Der står det følgende om problemstillingen:

4.4 Patentproblematikk

NUUG og Opera ser det som særlig viktig at forslagene knyttet til lyd og video baserer seg på de royalty-frie standardene Vorbis, Theora og FLAC.

Kommentarene relaterer seg til at enkelte standarder er åpne, men inneholder tekniske prosedyrer som det i USA (og noen andre land som Japan) er gitt patentrettigheter til. I vårt tilfelle berører dette spesielt standardene Mp3 og H.264, selv om Politidirektoratet peker på at det muligens kan være tilsvarende problematikk også for Theora og Vorbis. Dette medfører at det i USA kan kreves royalties for bruk av tekniske løsninger knyttet til standardene, et krav som også håndheves. Patenter kan imidlertid bare hevdes i de landene hvor patentet er gitt, så amerikanske patenter gjelder ikke andre steder enn USA.

Spesielt for utvikling av fri programvare er patenter problematisk. GPL, en "grunnleggende" lisens for distribusjon av fri programvare, avviser at programvare kan distribueres under denne lisensen hvis det inneholder referanser til patenterte rutiner som utløser krav om royalties. Det er imidlertid uproblematisk å distribuere fri programvareløsninger under GPL som benytter de aktuelle standardene innen eller mellom land som ikke anerkjenner patentene. Derfor finner vi også flere implementeringer av Mp3 og H.264 som er fri programvare, lisensiert under GPL.

I Norge og EU er patentlovgivningen langt mer restriktiv enn i USA, men det er også her mulig å få patentert metoder for løsning av et problem som relaterer seg til databehandling. Det er AIF bekjent ikke relevante patenter i EU eller Norge hva gjelder H.264 og Mp3, men muligheten for at det finnes patenter uten at det er gjort krav om royalties eller at det senere vil gis slike patenter kan ikke helt avvises.

AIF mener det er et behov for å gi offentlige virksomheter mulighet til å benytte antatt royaltyfrie åpne standarder som et likeverdig alternativ eller i tillegg til de markedsledende åpne standardene.

Det ser dermed ikke ut til at de har vurdert patentspørsmålet i sammenheng med opphavsrettsvilkår slik de er formulert for f.eks. Apple Final Cut Pro, Adobe Premiere Pro, Avid og Sorenson-verktøyene, der det kreves brukstillatelse for patenter som ikke er gyldige i Norge for å bruke disse verktøyene til annet en personlig og ikke kommersiell aktivitet når det gjelder H.264-video. Jeg må nok lete videre etter svar på det spørsmålet.

Tags: h264, multimedia, norsk, opphavsrett, standard, video, web.
A Debian package for SMTP via Tor (aka SMTorP) using exim4
10th November 2014

The right to communicate with your friends and family in private, without anyone snooping, is a right every citicen have in a liberal democracy. But this right is under serious attack these days.

A while back it occurred to me that one way to make the dragnet surveillance conducted by NSA, GCHQ, FRA and others (and confirmed by the whisleblower Snowden) more expensive for Internet email, is to deliver all email using SMTP via Tor. Such SMTP option would be a nice addition to the FreedomBox project if we could send email between FreedomBox machines without leaking metadata about the emails to the people peeking on the wire. I proposed this on the FreedomBox project mailing list in October and got a lot of useful feedback and suggestions. It also became obvious to me that this was not a novel idea, as the same idea was tested and documented by Johannes Berg as early as 2006, and both the Mailpile and the Cables systems propose a similar method / protocol to pass emails between users.

To implement such system one need to set up a Tor hidden service providing the SMTP protocol on port 25, and use email addresses looking like username@hidden-service-name.onion. With such addresses the connections to port 25 on hidden-service-name.onion using Tor will go to the correct SMTP server. To do this, one need to configure the Tor daemon to provide the hidden service and the mail server to accept emails for this .onion domain. To learn more about Exim configuration in Debian and test the design provided by Johannes Berg in his FAQ, I set out yesterday to create a Debian package for making it trivial to set up such SMTP over Tor service based on Debian. Getting it to work were fairly easy, and the source code for the Debian package is available from github. I plan to move it into Debian if further testing prove this to be a useful approach.

If you want to test this, set up a blank Debian machine without any mail system installed (or run apt-get purge exim4-config to get rid of exim4). Install tor, clone the git repository mentioned above, build the deb and install it on the machine. Next, run /usr/lib/exim4-smtorp/setup-exim-hidden-service and follow the instructions to get the service up and running. Restart tor and exim when it is done, and test mail delivery using swaks like this:

torsocks swaks --server dutlqrrmjhtfa3vp.onion \
  --to fbx@dutlqrrmjhtfa3vp.onion

This will test the SMTP delivery using tor. Replace the email address with your own address to test your server. :)

The setup procedure is still to complex, and I hope it can be made easier and more automatic. Especially the tor setup need more work. Also, the package include a tor-smtp tool written in C, but its task should probably be rewritten in some script language to make the deb architecture independent. It would probably also make the code easier to review. The tor-smtp tool currently need to listen on a socket for exim to talk to it and is started using xinetd. It would be better if no daemon and no socket is needed. I suspect it is possible to get exim to run a command line tool for delivery instead of talking to a socket, and hope to figure out how in a future version of this system.

Until I wipe my test machine, I can be reached using the fbx@dutlqrrmjhtfa3vp.onion mail address, deliverable over SMTorP. :)

Tags: debian, english, freedombox, personvern, surveillance.

RSS Feed

Created by Chronicle v4.6