StoWiki/ blog/ debian/ The LliureX classroom model

I started this blog to talk about things related to Free Software and Debian, but I haven't talked about what we are doing at work, so I'll start doing it today.

Last Friday we decided that our main problems with the classroom model were solved; we still need to do a lot of work and testing, but we have a sample installation working to work with.

Our project is going to be used in school's computer laboratories that have one server and about 16 clients. As there is not going to be a real system administrator on the schools, we've designed a model in which we only have one machine to care about; the server (all the clients use the same installation and no user data is stored on them, so they can be reinstalled at any time).

All the users' data is going to be in the server, starting with the authorization data (the client PCs will identify against the server) and ending with their home directories and files.

To simplify maintenance we've tried to store as much information as possible in an LDAP server. Currently we are using the LDAP server to store the configuration data for:

Right now we are using a mix of scripts to maintain the information in LDAP, but we plan to develop our own configuration system.

We looked at a lot of existing tools (CPU, Directory Administrator, GOsa, LDAP Account Manager, luma, smbldap-tools, webmin-ldap-user-simple) but haven't found one that adapts well to our needs. (anyway before starting to work on the new system I'll review those tools again).

Basically we want to use multiple front-ends (command line, GUI and web) and a modular system (we want to be able to support all our services, present and future).

If anybody knows a good free software tool that has this capabilities I'll be happy to test it. If I end up developing our tool it will probably be written in Python, is my language of choice lately and I'm almost sure that I'll be able to code the tool more or less quickly using a framework like Twisted.

The most problematic thing in for our model has been the use of Samba as the only network file system, we decided to use it because we wanted to be able to support Windows Systems (so we were going to install Samba anyway) and didn't like the idea of having to support various network file systems on the server (NFS and AFS where considered, but the first has always been problematic and the second requires Kerberos and complicates the management).

The good thing is that we found that the latest versions of Samba support the CIFS extensions for UNIX, so we were able to use it for mounting our users' home directories.

The problem was that we started to use pam-mount with smbfs and found problems with the handling of symlinks. We were using samba 3.0.4 and after a little bit of research we found that the problems seemed to be resolved in samba 3.0.5rc1, which I packaged (well, I'll have to repackage it, as now the samba 3.0.5 version is security release that does not contain the mentioned fixes).

When we tested with the new samba package we found that some of the symlink problems were solved, but not all, so I sent an email to the samba-technical mailing list with a small C program, only to find that we have to read more; we have to use the cifsfs, not the smbfs.

We tried and it worked, the only thing missing was the mount.cifs program; it is included in the samba source, but it is not compiled in the debian packages, so I modified our samba package to include the it in the smbfs package and sent a patch to the bug #227791.

With this changes everything worked fine when we mounted and umounted the home directories by hand, but we had problems with the pam-mount module. One of my co-workers solved them using custom scripts to mount and umount the shares, but it looked a hack to me, so I packaged the latest version of pam-mount applying patches similar to the ones included in the bug reports #259028 and #259032 and now everything works fine.