Petter Reinholdtsen

I Norge pågår en prosess for å innføre elektronisk stemmegiving ved kommune- og stortingsvalg. Dette skal introduseres i 2011. Det er all grunn til å tro at valg i Norge ikke vil være til å stole på hvis dette blir gjennomført. Da det hele var oppe til høring i 2006 forfattet jeg en høringsuttalelse fra NUUG (og EFN som hengte seg på) som skisserte hvilke punkter som må oppfylles for at en skal kunne stole på et valg, og elektronisk stemmegiving mangler flere av disse. Elektronisk stemmegiving er for alle praktiske formål å putte ens stemme i en sort boks under andres kontroll, og satse på at de som har kontroll med boksen er til å stole på - uten at en har mulighet til å verifisere dette selv. Det er ikke slik en gjennomfører demokratiske valg.

Da problemet er fundamentalt med hvordan elektronisk stemmegiving må fungere for at også ikke-krypografer skal kunne delta, har det vært mange rapporter om hvordan elektronisk stemmegiving har sviktet i land etter land. En liten samling referanser finnes på NUUGs wiki. Den siste er fra India, der valgkomisjonen har valgt å pusse politiet på en forsker som har dokumentert svakheter i valgsystemet.

Her i Norge har en valgt en annen tilnærming, der en forsøker seg med teknobabbel for å få befolkningen til å tro at dette skal bli sikkert. Husk, elektronisk stemmegiving underminerer de demokratiske valgene i Norge, og bør ikke innføres.

Den offentlige diskusjonen blir litt vanskelig av at media har valgt å kalle dette "evalg", som kan sies å både gjelde elektronisk opptelling av valget som Norge har gjort siden 60-tallet og som er en svært god ide, og elektronisk opptelling som er en svært dårlig ide. Diskusjonen gir ikke mening hvis en skal diskutere om en er for eller mot "evalg", og jeg forsøker derfor å være klar på at jeg snakker om elektronisk stemmegiving og unngå begrepet "evalg".

I dag fikk jeg endelig tittet litt på mine nyinnkjøpte roboter, og har brukt noen timer til å google etter interessante referanser og aktuell kildekode for bruk på Linux. Det mest lovende så langt er ispykee, som har en BSD-lisensiert linux-daemon som står som mellomledd mellom roboter på lokalnettet og en sentral tjeneste der en iPhone kan koble seg opp for å fjernstyre roboten. Linux-daemonen implementerer deler av protokollen som roboten forstår. Etter å ha knotet litt med å oppnå kontakt med roboten (den oppretter et eget ad-hoc wifi-nett, så jeg måtte gå av mitt vanlige nett for å få kontakt), og kommet frem til at den lytter på IP-port 9000 og 9001, gikk jeg i gang med å finne ut hvordan jeg kunne snakke med roboten vha. disse portene. Robotbiten av protokollen er publisert av produsenten med GPL-lisens, slik at det er mulig å se hvordan protokollen fungerer. Det finnes en java-klient for Android som så ganske snasen ut, men fant ingen kildekode for denne. Derimot hadde iphone-løsningen kildekode, så jeg tok utgangspunkt i den.

Daemonen ville i utgangspunktet forsøke å kontakte den sentrale tjenesten som iphone-programmet kobler seg til. Jeg skrev dette om til i stedet å sette opp en nettverkstjeneste på min lokale maskin, som jeg kan koble meg opp til med telnet og gi kommandoer til roboten (act, forward, right, left, etc). Det involverte i praksis å bytte ut socket()/connect() med socket()/bind()/listen()/accept() for å gjøre klienten om til en tjener.

Mens jeg har forsøkt å få roboten til å bevege seg har min samboer skrudd sammen resten av roboten for å få montert kamera og plastpynten (armer, plastfiber for lys). Nå er det hele montert, og roboten er klar til bruk. Må få flyttet den over til mitt vanlige trådløsnett før det blir praktisk, men de bitene av protokollen er ikke implementert i ispykee-daemonen, så der må jeg enten få tak i en mac eller en windows-maskin, eller implementere det selv.

Vi var tre som kjøpte slike roboter, og vi har blitt enige om å samle notater og referanser på NUUGs wiki. Ta en titt der hvis du er nysgjerrig.

Jeg kjøpte nettopp to Spykee-roboter, for test og leking. Kjøpte to da det var så billige, og gir meg mulighet til å eksperimentere uten å være veldig redd for å ødelegge alt ved å bytte ut firmware og slikt. Oppdaget at lekebutikken på Bryn senter hadde en liten stabel på lager som de ikke hadde klart å selge ut etter fjorårets juleinnkjøp, og var villig til å selge for en femtedel av vanlig pris. Jeg, Ronny og Jarle har skaffet oss restbeholdningen, og det blir morsomt å se hva vi får ut av dette.

Roboten har belter styrt av to motorer, kamera, høytaler, mikrofon og wifi-tilkobling. Det hele styrt av en GPL-lisensiert databoks som jeg mistenker kjører linux. Firmware-kildekoden ble visst publisert i mai. Eneste utfordringen er at kontroller-programvaren kun finnes til Windows, men det må en kunne jobbe seg rundt når vi har kildekoden til firmwaren. :)

• Wikipedia-oppføring
• Nedlasting av firmware-kilden
• prosjektwiki hos NUUG

I found the notes from Rob Weir on how to crush dissent matching my own thoughts on the matter quite well. Highly recommended for those wondering which road our society should go down. In my view we have been heading the wrong way for a long time.

As reported earlier, the last few days I have looked at how Debian Edu clients are configured, and tried to get rid of all hardcoded configuration settings on the clients. I believe the work to be mostly done, and the clients seem to work just fine with dynamically generated configuration.

What is the point, you might ask? The point is to allow a Debian Edu desktop to integrate into an existing network infrastructure without any manual configuration.

This is what happens when installing a Debian Edu client here at the University of Oslo using PXE. With the PXE installation, I am asked for language (Norwegian Bokmål), locality (Norway) and keyboard layout (no-latin1), Debian Edu profile (Roaming Workstation), if I accept to reformat the hard drive (yes), if I want to submit info to popcon.debian.org (no) and root password (secret). After answering these questions, the installer goes ahead and does its thing, and after around 50 minutes it is done. I press enter to finish the installation, and the machine reboots into KDE. When the machine is ready and kdm asks for login information, I enter my university username and password, am told by kdm that a local home directory has been created and that I must log in again, and finally log in with the same username and password to the KDE 4.4 desktop. At no point during this process did it ask for university specific settings, and all the required configuration was dynamically detected using information fetched via DHCP and DNS. The roaming workstation is now ready for use.

How was this done, you might wonder? First of all, here is the list of things that need to be configured on the client to get it working properly out of the box:

• IP address/netmask and DNS server.
• Web proxy URL.
• LDAP server for NSS directory information (user, group, etc).
• Kerberos server for PAM password checking.
• SMB mount point to access the network home directory. (*)
• Central syslog server to send syslog messages to. (*)
• Sitesummary collector URL to submit info to central server. (*)

(Hm, did I forget anything? Let me knew if I did.)

The points marked (*) are not required to be able to use the machine, but needed to provide central storage and allowing system administrators to track their machines. Since yesterday, everything but the sitesummary collector URL is dynamically discovered at boot and installation time in the svn version of Debian Edu.

The IP and DNS setup is fetched during boot using DHCP as usual. When a DHCP update arrives, the proxy setup is updated by looking for http://wpat/wpad.dat and using the content of this WPAD file to configure the http and ftp proxy in /etc/environment and /etc/apt/apt.conf. I decided to update the proxy setup using a DHCP hook to ensure that the client stops using the Debian Edu proxy when it is moved outside the Debian Edu network, and instead uses any local proxy present on the new network when it moves around.

The DNS names of the LDAP, Kerberos and syslog server and related configuration are generated using DNS information at boot. First the installer looks for a host named ldap in the current DNS domain. If not found, it looks for _ldap._tcp SRV records in DNS instead. If an LDAP server is found, its root DSE entry is requested and the attributes namingContexts and defaultNamingContext are used to determine which LDAP base to use for NSS. If there are several namingContexts attibutes and the defaultNamingContext is present, that LDAP subtree is used as the base. If defaultNamingContext is missing, the subtrees listed as namingContexts are searched in sequence for any object with class posixAccount or posixGroup, and the first one with such an object is used as the LDAP base. For Kerberos, a similar search is done by first looking for a host named kerberos, and then for the _kerberos._tcp SRV record. I've been unable to find a way to look up the Kerberos realm, so for this the upper case string of the current DNS domain is used.

For the syslog server, the hosts syslog and loghost are searched for, and the _syslog._udp SRV record is consulted if no such host is found. This algorithm works for both Debian Edu and the University of Oslo. A similar strategy would work for locating the sitesummary server, but have not been implemented yet. I decided to fetch and save these settings during installation, to make sure moving to a different network does not change the set of users being allowed to log in nor the passwords required to log in. Usernames and passwords will be cached by sssd when the user logs in on the Debian Edu network, and will not change as the laptop move around. For a non-roaming machine, there is no caching, but given that it is supposed to stay in place it should not matter much. Perhaps we should switch those to use sssd too?

The user's SMB mount point for the network home directory is located when the user logs in for the first time. The LDAP server is consulted to look for the user's LDAP object and the sambaHomePath attribute is used if found. If it isn't found, the home directory path fetched from NSS is used instead. Assuming the path is of the form /site/server/directory/username, the second part is looked up in DNS and used to generate a SMB URL of the form smb://server.domain/username. This algorithm works for both Debian edu and the University of Oslo. Perhaps there are better attributes to use or a better algorithm that works for more sites, but this will do for now. :)

This work should make it easier to integrate the Debian Edu clients into any LDAP/Kerberos infrastructure, and make the current setup even more flexible than before. I suspect it will also work for thin client servers, allowing one to easily set up LTSP and hook it into a existing network infrastructure, but I have not had time to test this yet.

If you want to help out with implementing these things for Debian Edu, please contact us on debian-edu@lists.debian.org.

Update 2010-08-09: Simon Farnsworth gave me a heads-up on how to detect Kerberos realm from DNS, by looking for _kerberos TXT entries before falling back to the upper case DNS domain name. Will have to implement it for Debian Edu. :)

A few years ago, I was involved in a project planning to use Windows file servers as home directory servers for Debian Edu/Skolelinux machines. This was thought to be no problem, as the access would be through the SMB network file system protocol, and we knew other sites used SMB with unix and samba as the file server to mount home directories without any problems. But, after months of struggling, we had to conclude that our goal was impossible.

The reason is simply that while SMB can be used for home directories when the file server is Samba running on Unix, this only work because of Samba have some extensions and the fact that the underlying file system is a unix file system. When using a Windows file server, the underlying file system do not have POSIX semantics, and several programs will fail if the users home directory where they want to store their configuration lack POSIX semantics.

As part of this work, I wrote a small C program I want to share with you all, to replicate a few of the problematic applications (like OpenOffice.org and GCompris) and see if the file system was working as it should. If you find yourself in spooky file system land, it might help you find your way out again. This is the fs-test.c source:

/*
 * Some tests to check the file system sematics.  Used to verify that
 * CIFS from a windows server do not work properly as a linux home
 * directory.
 * License: GPL v2 or later
 * 
 * needs libsqlite3-dev and build-essential installed
 * compile with: gcc -Wall -lsqlite3 -DTEST_SQLITE fs-test.c -o fs-test
*/

#define _FILE_OFFSET_BITS 64
#define _LARGEFILE_SOURCE 1
#define _LARGEFILE64_SOURCE 1

#define _GNU_SOURCE /* for asprintf() */

#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <sys/file.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>

#ifdef TEST_SQLITE
/*
 * Test sqlite open, as done by gcompris require the libsqlite3-dev
 * package and linking with -lsqlite3.  A more low level test is
 * below.
 * See also <URL: http://www.sqlite.org./faq.html#q5 >.
 */
#include <sqlite3.h>
#define CREATE_TABLE_USERS                                              \
  "CREATE TABLE users (user_id INT UNIQUE, login TEXT, lastname TEXT, firstname TEXT, birthdate TEXT, class_id INT ); "
int test_sqlite_open(void) {
  char *zErrMsg;
  char *name = "testsqlite.db";
  sqlite3 *db=NULL;
  unlink(name);
  int rc = sqlite3_open(name, &db);
  if( rc ){
    printf("error: sqlite open of %s failed: %s\n", name, sqlite3_errmsg(db));
    sqlite3_close(db);
    return -1;
  }

  /* create tables */
  rc = sqlite3_exec(db,CREATE_TABLE_USERS, NULL,  0, &zErrMsg);
  if( rc != SQLITE_OK ){
    printf("error: sqlite table create failed: %s\n", zErrMsg);
    sqlite3_close(db);
    return -1;
  }
  printf("info: sqlite worked\n");
  sqlite3_close(db);
  return 0;
}
#endif /* TEST_SQLITE */

/*
 * Demonstrate locking issue found in gcompris using sqlite3.  This
 * work with ext3, but not with cifs server on Windows 2003.  This is
 * done in the sqlite3 library.
 * See also
 * <URL:http://www.cygwin.com/ml/cygwin/2001-08/msg00854.html> and the
 * POSIX specification
 * <URL:http://www.opengroup.org/onlinepubs/009695399/functions/fcntl.html>.
 */
int test_gcompris_locking(void) {
  struct flock fl;
  char *name = "testsqlite.db";
  unlink(name);
  int fd = open(name, O_RDWR|O_CREAT|O_LARGEFILE, 0644);
  printf("info: testing fcntl locking\n");

  fl.l_whence = SEEK_SET;
  fl.l_pid    = getpid();
  printf("  Read-locking 1 byte from 1073741824");
  fl.l_start  = 1073741824;
  fl.l_len    = 1;
  fl.l_type   = F_RDLCK;
  if (0 != fcntl(fd, F_SETLK, &fl) ) printf(" - error!\n"); else printf("\n");

  printf("  Read-locking 510 byte from 1073741826");
  fl.l_start  = 1073741826;
  fl.l_len    = 510;
  fl.l_type   = F_RDLCK;
  if (0 != fcntl(fd, F_SETLK, &fl) ) printf(" - error!\n"); else printf("\n");

  printf("  Unlocking 1 byte from 1073741824");
  fl.l_start  = 1073741824;
  fl.l_len    = 1;
  fl.l_type   = F_UNLCK;
  if (0 != fcntl(fd, F_SETLK, &fl) ) printf(" - error!\n"); else printf("\n");

  printf("  Write-locking 1 byte from 1073741824");
  fl.l_start  = 1073741824;
  fl.l_len    = 1;
  fl.l_type   = F_WRLCK;
  if (0 != fcntl(fd, F_SETLK, &fl) ) printf(" - error!\n"); else printf("\n");

  printf("  Write-locking 510 byte from 1073741826");
  fl.l_start  = 1073741826;
  fl.l_len    = 510;
  if (0 != fcntl(fd, F_SETLK, &fl) ) printf(" - error!\n"); else printf("\n");

  printf("  Unlocking 2 byte from 1073741824");
  fl.l_start  = 1073741824;
  fl.l_len    = 2;
  fl.l_type   = F_UNLCK;
  if (0 != fcntl(fd, F_SETLK, &fl) ) printf(" - error!\n"); else printf("\n");

  close(fd);
  return 0;
}

/*
 * Test if permissions of freshly created directories allow entries
 * below them.  This was a problem with OpenOffice.org and gcompris.
 * Mounting with option 'sync' seem to solve this problem while
 * slowing down file operations.
 */
int test_subdirectory_creation(void) {
#define LEVELS 5
  char *path = strdup("test");
  char *dirs[LEVELS];
  int level;
  printf("info: testing subdirectory creation\n");
  for (level = 0; level < LEVELS; level++) {
    char *newpath = NULL;
    if (-1 == mkdir(path, 0777)) {
      printf("  error: Unable to create directory '%s': %s\n",
	     path, strerror(errno));
      break;
    }
    asprintf(&newpath, "%s/%s", path, "test");
    free(path);
    path = newpath;
  }
  return 0;
}

/*
 * Test if symlinks can be created.  This was a problem detected with
 * KDE.
 */
int test_symlinks(void) {
  printf("info: testing symlink creation\n");
  unlink("symlink");
  if (-1 == symlink("file", "symlink"))
    printf("  error: Unable to create symlink\n");
  return 0;
}

int main(int argc, char **argv) {
  printf("Testing POSIX/Unix sematics on file system\n");
  test_symlinks();
  test_subdirectory_creation();
#ifdef TEST_SQLITE
  test_sqlite_open();
#endif /* TEST_SQLITE */
  test_gcompris_locking();
  return 0;
}

When everything is working, it should print something like this:

Testing POSIX/Unix sematics on file system
info: testing symlink creation
info: testing subdirectory creation
info: sqlite worked
info: testing fcntl locking
  Read-locking 1 byte from 1073741824
  Read-locking 510 byte from 1073741826
  Unlocking 1 byte from 1073741824
  Write-locking 1 byte from 1073741824
  Write-locking 510 byte from 1073741826
  Unlocking 2 byte from 1073741824

I do not remember the exact details of the problems we saw, but one of them was with locking, where if I remember correctly, POSIX allow a read-only lock to be upgraded to a read-write lock without unlocking the read-only lock (while Windows do not). Another was a bug in the CIFS/SMB client implementation in the Linux kernel where directory meta information would be wrong for a fraction of a second, making OpenOffice.org fail to create its deep directory tree because it was not allowed to create files in its freshly created directory.

Anyway, here is a nice tool for your tool box, might you never need it. :)

A few days ago, I tried to install a Roaming workation profile from Debian Edu/Squeeze while on the university network here at the University of Oslo, and noticed how much had to change to get it operational using the university infrastructure. It was fairly easy, but it occured to me that Debian Edu would improve a lot if I could get the client to connect without any changes at all, and thus let the client configure itself during installation and first boot to use the infrastructure around it. Now I am a huge step further along that road.

With our current squeeze-test packages, I can select the roaming workstation profile and get a working laptop connecting to the university LDAP server for user and group and our active directory servers for Kerberos authentication. All this without any configuration at all during installation. My users home directory got a bookmark in the KDE menu to mount it via SMB, with the correct URL. In short, openldap and sssd is correctly configured. In addition to this, the client look for http://wpad/wpad.dat to configure a web proxy, and when it fail to find it no proxy settings are stored in /etc/environment and /etc/apt/apt.conf. Iceweasel and KDE is configured to look for the same wpad configuration and also do not use a proxy when at the university network. If the machine is moved to a network with such wpad setup, it would automatically use it when DHCP gave it a IP address.

The LDAP server is located using DNS, by first looking for the DNS entry ldap.$domain. If this do not exist, it look for the _ldap._tcp.$domain SRV records and use the first one as the LDAP server. Next, it connects to the LDAP server and search all namingContexts entries for posixAccount or posixGroup objects, and pick the first one as the LDAP base. For Kerberos, a similar algorithm is used to locate the LDAP server, and the realm is the uppercase version of $domain.

So, what is not working, you might ask. SMB mounting my home directory do not work. No idea why, but suspected the incorrect Kerberos settings in /etc/krb5.conf and /etc/samba/smb.conf might be the cause. These are not properly configured during installation, and had to be hand-edited to get the correct Kerberos realm and server, but SMB mounting still do not work. :(

With this automatic configuration in place, I expect a Debian Edu roaming profile installation would be able to automatically detect and connect to any site using LDAP and Kerberos for NSS directory and PAM authentication. It should also work out of the box in a Active Directory environment providing posixAccount and posixGroup objects with UID and GID values.

If you want to help out with implementing these things for Debian Edu, please contact us on debian-edu@lists.debian.org.

The new roaming workstation profile in Debian Edu/Squeeze is fairly similar to the laptop setup am I working on using Ubuntu for the University of Oslo, and just for the heck of it, I tested today how hard it would be to integrate that profile into the university infrastructure. In this case, it is the university LDAP server, Active Directory Kerberos server and SMB mounting from the Netapp file servers.

I was pleasantly surprised that the only three files needed to be changed (/etc/sssd/sssd.conf, /etc/ldap.conf and /etc/mklocaluser.d/20-debian-edu-config) and one file had to be added (/usr/share/perl5/Debian/Edu_Local.pm), to get the client working. Most of the changes were to get the client to use the university LDAP for NSS and Kerberos server for PAM, but one was to change a hard coded DNS domain name in the mklocaluser hook from .intern to .uio.no.

This testing was so encouraging, that I went ahead and adjusted the Debian Edu scripts and setup in subversion to centralise the roaming workstation setup a bit more and avoid the hardcoded DNS domain name, so that when I test this tomorrow, I expect to get away with modifying only /etc/sssd/sssd.conf and /etc/ldap.conf to get it to use the university servers.

My goal is to get the clients to have no hardcoded settings and fetch all their initial setup during installation and first boot, to allow them to be inserted also into environments where the default setup in Debian Edu has been changed or as with the university, where the environment is different but provides the protocols Debian Edu uses.

I discovered this while doing automated testing of upgrades from Debian Lenny to Squeeze. A few packages in Debian still got circular dependencies, and it is often claimed that apt and aptitude should be able to handle this just fine, but some times these dependency loops causes apt to fail.

An example is from todays upgrade of KDE using aptitude. In it, a bug in kdebase-workspace-data causes perl-modules to fail to upgrade. The cause is simple. If a package fail to unpack, then only part of packages with the circular dependency might end up being unpacked when unpacking aborts, and the ones already unpacked will fail to configure in the recovery phase because its dependencies are unavailable.

In this log, the problem manifest itself with this error:

dpkg: dependency problems prevent configuration of perl-modules:
 perl-modules depends on perl (>= 5.10.1-1); however:
  Version of perl on system is 5.10.0-19lenny2.
dpkg: error processing perl-modules (--configure):
 dependency problems - leaving unconfigured

The perl/perl-modules circular dependency is already reported as a bug, and will hopefully be solved as soon as possible, but it is not the only one, and each one of these loops in the dependency tree can cause similar failures. Of course, they only occur when there are bugs in other packages causing the unpacking to fail, but it is rather nasty when the failure of one package causes the problem to become worse because of dependency loops.

Thanks to the tireless effort by Bill Allombert, the number of circular dependencies left in Debian is dropping, and perhaps it will reach zero one day. :)

Todays testing also exposed a bug in update-notifier and different behaviour between apt-get and aptitude, the latter possibly caused by some circular dependency. Reported both to BTS to try to get someone to look at it.

I just posted this announcement culminating several months of work with the next Debian Edu release. Not nearly done, but one major step completed.

This is the first test release based on Squeeze. The focus of this release is to test the user application selection. To have a look, install the standalone profile and let the developers know if the set of installed packages i.e. applications should be modified. If some user application is missing, or if there are some applications that no longer make sense to be included in Debian Edu, please let us know. Also, if a useful application is missing the translation for your language of choice, please let us know too.

In addition, feedback and help to polish the desktop (menus, artwork, starters, etc.) is appreciated. We would like to ship a nice and handy KDE4 desktop targeted for schools out of the box.

The other profiles should be installable, but there is a lot more work left to be done before they are ready, so do not expect to much.

Changes compared to the lenny based version

• Everything from Debian Squeeze
  • Desktop environment KDE 4.4 => the new KDE desktop in combination with some new artwork
  • Web browser Iceweasel 3.5
  • OpenOffice.org 3.2
  • Educational toolbox GCompris 9.3
  • Music creator Rosegarden 10.04.2
  • Image editor Gimp 2.6.10
  • Virtual universe Celestia 1.6.0
  • Virtual stargazer Stellarium 0.10.4
  • 3D modeler Blender 2.49.2 (new application)
  • Video editor Kdenlive 0.7.7 (new application)
• Now using Kerberos for password checking (migration not finished). Enabled for:
  • PAM
  • LDAP
  • IMAP
  • SMTP (sender verification)
• New experimental roaming workstation profile for laptops.
• Show welcome page to users when they first log in. The URL is fetched from LDAP.
• New LXDE desktop option, in addition to KDE (default) and Gnome.
• General cleanup (not finished)

The following features are not working as they should

• No web based administration tool for creating users and groups. The scripts ldap-createuser-krb and ldap-add-user-to-group can be used for testing.
• DVD installs are missing debian-installer images for the PXE boot, and do not set up the PXE menu on eth0 because of this. LTSP clients should still boot from eth1 on thin client servers.
• The restructured KDE menu is not implemented.
• The LDAP server setup need to be reviewed for security.
• The LDAP directory structure need to be reworked.
• Different sets of packages are installed when using the DVD and the netinst CD. More packages are installed using the netinst CD.
• The jackd package fail to install. This is believed to be caused by some ongoing transition, and hopefully should be solved soon. The jackd1 package can be installed manually for those that need it.
• Some packages lack translations. See http://wiki.debian.org/DebianEdu/Status/Squeeze for updated status, and help out with translations.

To download this multiarch netinstall release you can use

• ftp://ftp.skolelinux.org/skolelinux-cd/squeeze-alpha/debian-edu-6.0.0+edua0-CD.iso
• http://ftp.skolelinux.org/skolelinux-cd/squeeze-alpha/debian-edu-6.0.0+edua0-CD.iso
• rsync -avzP ftp.skolelinux.org::skolelinux-cd/squeeze-alpha/debian-edu-6.0.0+edua0-CD.iso

To download this multiarch dvd release you can use

• ftp://ftp.skolelinux.org/skolelinux-cd/squeeze-alpha/debian-edu-6.0.0+edua0-DVD.iso
• http://ftp.skolelinux.org/skolelinux-cd/squeeze-alpha/debian-edu-6.0.0+edua0-DVD.iso
• rsync -avzP ftp.skolelinux.org::skolelinux-cd/squeeze-alpha/debian-edu-6.0.0+edua0-DVD.iso

There is no source DVD available yet. It will be prepared when we get closer to the final release.

The MD5SUM of these images are

• 3dbf45d59f42a53518b6e3c9ec3b5eb6 debian-edu-6.0.0+edua0-CD.iso
• 22f2cbfce281d1c6e478be452638675d debian-edu-6.0.0+edua0-DVD.iso

The SHA1SUM of these images are

• c53d1b69b40cf37cd27aefaf33f6f6a3821bedf0 debian-edu-6.0.0+edua0-CD.iso
• 2ec29d7db676d59d32197b05c277ffe16348376c debian-edu-6.0.0+edua0-DVD.iso

How to report bugs: http://wiki.debian.org/DebianEdu/HowTo/ReportBugsInBugzilla

Please direct replies to debian-edu@lists.debian.org