Petter Reinholdtsen

Elektronisk stemmegiving over Internet og datalagringsdirektivet
2011-08-07 10:00

I dag slo det meg hvordan Datalagringsdirektivet vil kunne gjøre det enklere å vite hvem som har stemt hva med elektronisk stemmegiving slik den planlegges gjennomført i Norge i høst.

Litt bakgrunnsinformasjon er kanskje nødvendig. Siden før 2006 har staten jobbet med å få på plass elektronisk stemmegiving i Norge, der borgerne kan stemme via en datamaskin i et stemmelokale eller via en nettleser over Internet. Slike valg er mindre demokratiske enn de valgene vi har hatt i Norge de siste årene. En kan anta at for hver stemme som blir registrert i et slikt system vil det notert tidspunktet stemmen ble registrert.

I mars i år vedtok stortinget å innføre elektronisk besøks og kommunikasjonskontroll av hele Norges befolkning, da en vedtok at EUs datalagringsdirektiv skulle innlemmes i det norske lovverket. Denne kommunikasjonskontrollen innebærer blant annet at oppkoblinger med nettleser blir registert. Det som ble vedtatt i mars innebærer ikke at det blir registrert hvilken nettside en besøkte, men det vil bli registrert en forbindelse mellom datamaskinene som er involvert. Dvs. når en besøker http://www.nuug.no/aktiviteter/20110809-forgerock/ fra sin maskin med adressen cm-84.208.83.178.getinternet.no (tilfeldig valgt adresse for Get-kunde), så vil tidspunktet, og adressene www.nuug.no og cm-84.208.83.178.getinternet.no bli registrert. En kan bruke adressen cm-*.getinternet.no kan brukes til å identifisere kunde/husstand.

Gitt at elektronisk stemmegiving via nettleser over Internet vil koble seg opp til datamaskinen som samler inn stemmer, så vil en altså ha et register over hver enkelt stemme knyttet mot tidspunkt, og et annet register som viser når kunder/husstander koblet seg opp mot datamaskinen som samler inn stemmer. Ved å koble disse registrene vil det ofte være mulig å finne ut hva kunder/husstander har stemt, uten å måtte knekke kryptering involvert i selve stemmesankingsystemet. Det vil være mindre treffsikkert hvis flere stemmer blir registrert på samme tidspunkt, hvis stemmene er gitt til forskjellige partier, men en vil ha en viss ide hvilke partier det må ha vært ved å se hvilke partier som fikk stemmer på det aktuelle tidspunktet.

Hvordan kan en vite at dette ikke blir gjort i dag? Det vil være umulig for en borger å kontrollere hva som skjer på datamaskinen som samler inn stemmer. De som står bak den norske elektroniske stemmegivingsløsningen har gitt ut kildekode som hevdes å være identisk med den som brukes til innsamling av stemmer, men det er ikke mulig for innbyggerne i Norge å kontrollere at den kildekoden er brukt til å lage programmene som brukes. Det vil f.eks. være trivielt for de som kontrollerer denne datamaskinen å legge inn ekstra kode som sender kopi av alle stemmer til en annen database utenfor valgstyrenes kontroll. Det påstås fra USA at det ble gjort med noen av de elektroniske stemmegivingsboksene der. Kanskje det påstås at stemmetellings-systemet ikke vil notere tidspunkt for hver enkelt stemme, men også dette vil det være umulig for oss innbyggerne å egenhendig kontrollere. Jeg vil ha valgsystemer som hver enkelt innbygger kan kontrollere, ikke et der vi må stole på påstander om systemet som ikke kan kontrolleres av hver enkelt innbygger.

Tags: norsk, personvern.
Et bilde på problemet med programvarepatenter
2011-08-06 21:45

Via en artikkel i Huffington Post om patentreform i USA fikk jeg et interessant bilde på problemet med programvarepatenter. Problemet er at staten deler ut usynlige "eiendommer" med uklare eiendomsgrenser, som gjør det umulig å vite om en er på annen manns grunn hvis en ikke har kjennskap til at "eiendommen" finnes, og selv når en vet om den usynlige "eiendommen" er det umulig å vite på hvilken side av grensen en befinner seg.

Hvis du er interessert i problemområdet programvarepatenter, så har NUUG en epostliste om temaet. Alle er hjertelig velkomne som abonnenter.

Tags: norsk, nuug.
How is booting into runlevel 1 different from single user boots?
2011-08-04 12:40

Wouter Verhelst have some interesting comments and opinions on my blog post on the need to clean up /etc/rcS.d/ in Debian and my blog post about the default KDE desktop in Debian. I only have time to address one small piece of his comment now, and though it best to address the misunderstanding he bring forward:

Currently, a system admin has four options: [...] boot to a single-user system (by adding 'single' to the kernel command line; this runs rcS and rc1 scripts)

This make me believe Wouter believe booting into single user mode and booting into runlevel 1 is the same. I am not surprised he believe this, because it would make sense and is a quite sensible thing to believe. But because the boot in Debian is slightly broken, runlevel 1 do not work properly and it isn't the same as single user mode. I'll try to explain what is actually happing, but it is a bit hard to explain.

Single user mode is defined like this in /etc/inittab: "~~:S:wait:/sbin/sulogin". This means the only thing that is executed in single user mode is sulogin. Single user mode is a boot state "between" the runlevels, and when booting into single user mode, only the scripts in /etc/rcS.d/ are executed before the init process enters the single user state. When switching to runlevel 1, the state is in fact not ending in runlevel 1, but it passes through runlevel 1 and end up in the single user mode (see /etc/rc1.d/S03single, which runs "init -t1 S" to switch to single user mode at the end of runlevel 1. It is confusing that the 'S' (single user) init mode is not the mode enabled by /etc/rcS.d/ (which is more like the initial boot mode).

This summary might make it clearer. When booting for the first time into single user mode, the following commands are executed: "/etc/init.d/rc S; /sbin/sulogin". When booting into runlevel 1, the following commands are executed: "/etc/init.d/rc S; /etc/init.d/rc 1; /sbin/sulogin". A problem show up when trying to continue after visiting single user mode. Not all services are started again as they should, causing the machine to end up in an unpredicatble state. This is why Debian admins recommend rebooting after visiting single user mode.

A similar problem with runlevel 1 is caused by the amount of scripts executed from /etc/rcS.d/. When switching from say runlevel 2 to runlevel 1, the services started from /etc/rcS.d/ are not properly stopped when passing through the scripts in /etc/rc1.d/, and not started again when switching away from runlevel 1 to the runlevels 2-5. I believe the problem is best fixed by moving all the scripts out of /etc/rcS.d/ that are not required to get a functioning single user mode during boot.

I have spent several years investigating the Debian boot system, and discovered this problem a few years ago. I suspect it originates from when sysvinit was introduced into Debian, a long time ago.

Tags: bootsystem, debian, english.
Fint at militæret ikke ble aktivisert 22. juli
2011-08-02 09:35

I gårdagens dagsavis gjøres det et poeng av at Forsvarets spesialkommando ikke ble tatt i bruk da en rykket ut under aksjonene 22. juli. Personlig må jeg innrømme at jeg et glad for at militæret ikke ble tatt i bruk, og ser ikke det som et problem slik journalisten legger opp til. Politi er trent opp til å forholde seg til sivile regler, mens militæret er trent opp til å forholde seg til militære regler. For å si det litt flåsete, så skal politiet spørre først og skyte etterpå, mens militæret skal skyte først og spørre etterpå. Jeg vil helst kun ha den første gjengen i aktiv operasjon blant sivile i Norge.

Ikke at jeg egentlig tror våre folk i militæret er mer skyteglade enn folk i politiet, men de er trent forskjellig og med forskjellig mål for treningen. Politiet er trent på å operere blant sin egen sivilbefolkning, mens militære er trent på å operere blant fiendtlige tropper. Jeg tror det er en vesentlig forskjell.

Tags: norsk, personvern.
Fin minnemarkering på Stortinget i dag
2011-08-01 16:40

Jeg hadde anledning, så jeg deltok på minnemarkeringen på Stortinget i dag. Det var en fin markering, og jeg likte talene. For meg er demokrati, åpenhet og humanitet fundert på frihet, som jeg håper vi alle vil bidra til å beskytte i tiden som kommer. Jeg registrerer at det i Danmark diskuteres å redusere friheten. Vi bør vite bedre her i Norge. Stoltenberg berørte retten til å feile, og den er nært knyttet til muligheten til å lykkes. Begge deler krever at en har friheten til å prøve, og den er viktig i et samfunn. Friheten til å prøve begrenses når kontroll innføres.

Det at noen av stolene i stortingssalen var tomme ga en litt uventet ramme til markeringen. Jeg hadde regnet med at stortingsrepresentanter, regjeringsmedlemmer og kongehus til sammen ville fylle alle setene. Vet ikke hvem som skulle sittet der det var ledige plasser, men antar noen var opptatt andre steder. Kanskje i begravelser, eller rett og slett var blitt drept (har ikke hørt at noen i Stortinget ble drept, men kan ha gått glipp av noe). Det at noen manglet synes jeg illustrerte minnestundens poeng godt. Vi mangler noen som skulle ha vært blant oss. Det kan aldri gjøres om, og bør aldri glemmes.

Tags: norsk, personvern.
What should start from /etc/rcS.d/ in Debian? - almost nothing
2011-07-30 14:00

In the Debian boot system, several packages include scripts that are started from /etc/rcS.d/. In fact, there is a bite more of them than make sense, and this causes a few problems. What kind of problems, you might ask. There are at least two problems. The first is that it is not possible to recover a machine after switching to runlevel 1. One need to actually reboot to get the machine back to the expected state. The other is that single user boot will sometimes run into problems because some of the subsystems are activated before the root login is presented, causing problems when trying to recover a machine from a problem in that subsystem. A minor additional point is that moving more scripts out of rcS.d/ and into the other rc#.d/ directories will increase the amount of scripts that can run in parallel during boot, and thus decrease the boot time.

So, which scripts should start from rcS.d/. In short, only the scripts that _have_ to execute before the root login prompt is presented during a single user boot should go there. Everything else should go into the numeric runlevels. This means things like lm-sensors, fuse and x11-common should not run from rcS.d, but from the numeric runlevels. Today in Debian, there are around 115 init.d scripts that are started from rcS.d/, and most of them should be moved out. Do your package have one of them? Please help us make single user and runlevel 1 better by moving it.

Scripts setting up the screen, keyboard, system partitions etc. should still be started from rcS.d/, but there is for example no need to have the network enabled before the single user login prompt is presented.

As always, things are not so easy to fix as they sound. To keep Debian systems working while scripts migrate and during upgrades, the scripts need to be moved from rcS.d/ to rc2.d/ in reverse dependency order, ie the scripts that nothing in rcS.d/ depend on can be moved, and the next ones can only be moved when their dependencies have been moved first. This migration must be done sequentially while we ensure that the package system upgrade packages in the right order to keep the system state correct. This will require some coordination when it comes to network related packages, but most of the packages with scripts that should migrate do not have anything in rcS.d/ depending on them. Some packages have already been updated, like the sudo package, while others are still left to do. I wish I had time to work on this myself, but real live constrains make it unlikely that I will find time to push this forward.

Tags: bootsystem, debian, english.
What is missing in the Debian desktop, or why my parents use Kubuntu
2011-07-29 08:10

While at Debconf11, I have several times during discussions mentioned the issues I believe should be improved in Debian for its desktop to be useful for more people. The use case for this is my parents, which are currently running Kubuntu which solve the issues.

I suspect these four missing features are not very hard to implement. After all, they are present in Ubuntu, so if we wanted to do this in Debian we would have a source.

  1. Simple GUI based upgrade of packages. When there are new packages available for upgrades, a icon in the KDE status bar indicate this, and clicking on it will activate the simple upgrade tool to handle it. I have no problem guiding both of my parents through the process over the phone. If a kernel reboot is required, this too is indicated by the status bars and the upgrade tool. Last time I checked, nothing with the same features was working in KDE in Debian.
  2. Simple handling of missing Firefox browser plugins. When the browser encounter a MIME type it do not currently have a handler for, it will ask the user if the system should search for a package that would add support for this MIME type, and if the user say yes, the APT sources will be searched for packages advertising the MIME type in their control file (visible in the Packages file in the APT archive). If one or more packages are found, it is a simple click of the mouse to add support for the missing mime type. If the package require the user to accept some non-free license, this is explained to the user. The entire process make it more clear to the user why something do not work in the browser, and make the chances higher for the user to blame the web page authors and not the browser for any missing features.
  3. Simple handling of missing multimedia codec/format handlers. When the media players encounter a format or codec it is not supporting, a dialog pop up asking the user if the system should search for a package that would add support for it. This happen with things like MP3, Windows Media or H.264. The selection and installation procedure is very similar to the Firefox browser plugin handling. This is as far as I know implemented using a gstreamer hook. The end result is that the user easily get access to the codecs that are present from the APT archives available, while explaining more on why a given format is unsupported by Ubuntu.
  4. Better browser handling of some MIME types. When displaying a text/plain file in my Debian browser, it will propose to start emacs to show it. If I remember correctly, when doing the same in Kunbutu it show the file as a text file in the browser. At least I know Opera will show text files within the browser. I much prefer the latter behaviour.

There are other nice features as well, like the simplified suite upgrader, but given that I am the one mostly doing the dist-upgrade, it do not matter much.

I really hope we could get these features in place for the next Debian release. It would require the coordinated effort of several maintainers, but would make the end user experience a lot better.

Tags: debian, english, multimedia, web.
Skolelinux-intervju: Frode Jemtland
2011-07-27 08:50

Neste mann ut i min serie med intervjuer av Skolelinux-relaterte personer er en tidligere styreleder i FRISK som var med fra starten av Skolelinux-prosjektet.

Hvem er du, og hva driver du med til daglig?

Mitt navn er Frode Jemtland, og jeg jobber i Hedmark IKT, som er et driftsselskap for Grue, Hamar, Kongsvinger, Løten, Nord-Odal og Stange kommuner. Her er jeg leder for avdelingen Løsninger og Arkitektur. Vi har i hovedansvar for servere, infrastruktur og løsninger som helhet.

Hvordan kom du i kontakt med Skolelinux-prosjektet?

Jobbet i IBM fra 2000, og da spesielt med Linux. Dette var da et av de mest tydelige linux prosjektene i Norge, og her ønsket jeg å bidra. Var aktivt med i prosjektet i 4-5 år.

Hva er fordelene med Skolelinux slik du ser det?

Fordelene slik jeg ser det er den sentraliserte driftmodellen, og alle de vel gjennomtenkte løsningene som er inkludert i denne løsningen. Samtidig er det basert på en stabil, og godt kjent plattform. Dette vil si at man har en løsning som skal være mye tilgjengelig, og hvor det er relativt enkelt å få tak i personer som kan mye om den grunnleggende plattformen.

Hva er ulempene med Skolelinux slik du ser det?

De største utfordringene med en løsningen er at den er intensiv på f.eks nettverk. I seg selv ikke et problem for en enkelt skole, men skal løsningen kjøres i større skala, med sentraliserte servere, så gir dette noen utfordringer.

Utifra hva jeg har sett på større installasjoner så er det ikke så enkelt å skjønne, hva som bør gjøres for at den skal skaleres opp, og da ta godt vare på alle sider av dette, ikke bare mer server å fordele last/trykk, men hvordan også beholde robustheten og fleksibiliteten i løsningen.

En annen utfordring er at stadig flere produkter som skal brukes i skoleløsningen ikke er laget til å kunne brukes i en skolelinuxløsning. Det blir derfor fort mye skreddersøm i de forskjellige installasjonene, for å få diverse pedagogiske programmer, webløsninger, smartboards, m.m. til å fungere. Man er også en for liten kundebase til at leverandørene ønsker å gjøre noe med utfordringen. Problemet overlates til oss.

Det er også en kontinuerlig utfordring rundt problemet med å holde programvare på stabile versjoner, kontra å få ny funksjonalitet. Dette er jo en konflikt mellom oss som ønsker å drifte en stabil, og kostnadseffektiv løsning, mot sluttbrukerne som ønsker seg funksjoner det er vant med fra andre løsninger, eller som de må ha for at et eller annet nytt produkt skal fungere i løsningen. Dette er en utfordring også for andre plattformer.

En siste utfordring som ikke har noe med løsningen å gjøre, men med det omkringliggende miljøet denne skal kjøre i, er at de enhetene som skal drifte dataløsninger for kommuner og fylkeskommuner begynner å profesjonaliseres, og er da avhengig av å ha standard løsninger for å drifte store brukermasser. MS er selvsagt klar over dette, og har jo nå flere områder de begynner å bli veldig dominerende på. Den største, og mest problematiske er katalogtjenesten. Man får snart ikke tak i større løsninger som ikke krever en AD. Når man da har store enheter som drifter både kommunalt ansatte og skoler, så vil det være et stordriftargument å standardisere på en katalog tjeneste, og da har man ikke noe valg. Her er alle slike driftsenheter for små til å få gjort om på dette. Her burde konkurransemyndighetene kommet på banen. Men konkurransetilsynet i USA griper sjeldent (og ikke før det har gått veldig lang tid) inn i monopolsituasjoner så lenge monopolisten er et amerikansk firma, så da har vel ikke andre myndigheter så mye de skulle ha sagt....

Hvilken fri programvare bruker du til daglig?

Privat kjører jeg Debian på alle mine datamaskiner. Det gjør jeg også på min jobbmaskin. Vi har også 15-20 linux servere av typene SuSE, Debian, Redhat, CentOS m.m. Jeg bruker derfor mye fri programvare. Av enkelt programmer kan sikkert masse nevnes. Hvis vi skal begrense oss til daglig, så må jeg si: OpenOffice, Firefox, Kontact, Kopete, Amarok, Gramps, Kate, ssh, bash, rsync, backuppc m.m.

Hvilken strategi tror du er den rette å bruke for å få skoler til å ta i bruk fri programvare?

Det er et godt spørsmål, som jeg har lurt på selv.

Argumentene som ofte har vært brukt om at ting koster mindre holder ikke mål når man ser på hva som faktisk koster penger. Det er de ansatte som er en kostnadsdriver. Det vil si at hvis man har et system som den ansatte kan, så vil en kostnad på dette systemet kunne forsvares ganske mye ved at den ansatte gjør dette raskere og effektivt. Også uten å måtte eventuelt leie inn folk.

Jeg syns det er viktigere å fokusere på prinsippet med å velge fri programvare, men det er også et felt hvor man fort møter lite forståelse blant de ansatte i skolen.

Her må nok strategien fortsette å være at de sentrale myndighetene må sende tydelige signaler for hva de ønsker at offentlige enheter skal gjøre. Det var mye positivt på gang ang. dette for et par år siden. Både med eNorge og eKommune planene, men dette syns jeg har stoppet opp. En del av dette kan jo kanskje være usikkerheten som etter hvert har blitt, når man har sett kompleksiteten i de prosjektene som har blitt igangsatt. Det har også blitt noe usikkerhet i markedet ref. Sun, Oracle, Novell, Microsoft m.m. Samtidig har jo også de proprietære programleverandørene sørget for å endre sine lisenser slik at man uansett ikke slipper unna kostnaden til deres produkter, selv om man skulle velge alternativer. Da er det økonomiske argumentet, som jeg nevnte tidligere, spilt ganske godt ut over sidelinjen.

Tags: debian edu, intervju, norsk.
Perl modules used by FixMyStreet which are missing in Debian/Squeeze
2011-07-26 12:25

The Norwegian FiksGataMi site is build on Debian/Squeeze, and this platform was chosen because I am most familiar with Debian (being a Debian Developer for around 10 years) because it is the latest stable Debian release which should get security support for a few years.

The web service is written in Perl, and depend on some perl modules that are missing in Debian at the moment. It would be great if these modules were added to the Debian archive, allowing anyone to set up their own FixMyStreet clone in their own country using only Debian packages. The list of modules missing in Debian/Squeeze isn't very long, and I hope the perl group will find time to package the 12 modules Catalyst::Plugin::SmartURI, Catalyst::Plugin::Unicode::Encoding, Catalyst::View::TT, Devel::Hide, Sort::Key, Statistics::Distributions, Template::Plugin::Comma, Template::Plugin::DateTime::Format, Term::Size::Any, Term::Size::Perl, URI::SmartURI and Web::Scraper to make the maintenance of FixMyStreet easier in the future.

Thanks to the great tools in Debian, getting the missing modules installed on my server was a simple call to 'cpan2deb Module::Name' and 'dpkg -i' to install the resulting package. But this leave me with the responsibility of tracking security problems, which I really do not have time for.

Tags: debian, english, fiksgatami.
Overvåkningslogikkens fallitt
2011-07-23 10:45

Det er vanskelig å få gjort noe fornuftig i dag, etter gårdagens tragiske hendelse. Tankene går til de som har mistet sine nærmeste. Jeg kan ikke forstille meg hvor tungt de har det nå, og jeg håper alle jeg kjenner har klart seg.

Jeg undres på hva motivasjonen til de som står bak kan være? Jeg tror en må være ganske desperat for å ty til slike midler, og oppleve at alle andre påvirkningsmuligheter er blokkert. Mon tro om Stortingets totalitære vedtak 4. april i år om å lovfeste massiv overvåkning av hele befolkningen bidro? Jeg undres også på om at gårdagens bombing og massedrap er resultat av de fremmedfiendtlige holdninger som har spredt seg i Norge i mange år, kombinert med Stortingets og regjeringens villighet til å forlate de verdier som vårt liberale demokrati er tuftet på (ved å legge opp til registrering og overvåkning av borgere som _ikke_ er mistenkt for noe kriminelt).

En ting er ganske klart, dog. Massiv kameraovervåkning bidrar ikke til å hindre slik grotesk kriminalitet. Regjeringskvartalet er et av de mest kameraovervåkede områdene i Oslo, og hindret ikke at sprengingen fant sted. Registrering av posisjonen til alle mobiltelefoner som politiet har hatt tilgang til i flere år nå ser ikke ut til å ha hjulpet det heller. De som tror at massiv kommunikasjonskontroll av hele befolkningen vil hindre ekstremister i å skade oss i Norge tror jeg tar feil. Til det tror jeg det må mer åpenhet, mindre kontroll og mer tillit til hver enkelt innbygger, da jeg tror bidrar til å holde ekstreme holdninger i sjakk.

Tags: norsk, personvern, surveillance.

RSS feed

Created by Chronicle v3.7