Xen domains working
Yesterday, I managed to move our GForge server into the DMZ as a Xen domain. The CoObRA Repositories are also hosted in a Xen domain, although they might consume way more RAM than the currently assigned 256 MB …
I have to admit that the firewall of the university is still blocking SMTP for the GForge .. so he does not receive any mails from outside the university.
The people from KDE (not the desktop environment) are having problems copying large files between Xen domains running on different cpus of a dual core machine. The machine does not respond and eventually crashes, if I remember correctly.
Diskless Gentoo Nodes
The gigabit port in the student pool works and a week ago we borrowed a VF45<->SC cable to start working on Diskless nodes…
Meanwhile, it seems we managed to create a working net-bootable Gentoo image for our student pool. It consists of a shareable part (
/bin, /sbin, /lib, ...) and an individual part (a few files in
/etc, /var/run, /tmp ...). Many solutions for diskless nodes mount the root filesystem and the individual parts on the client. The drawback is, that you have to take care of the mount timings, so that /bin (which is a shared mount) and /etc (which contains individual settings like the nfs mount points in fstab) are availiable early in the boot process.
The problem is that the kernel only mounts one NFS share at boot time. That is why we decided to create each clients root filesystem on the server using
mount --bind.The shared files are mounted into each individual filesystem. With exports
nohide option it is possible to mount only one filesystem on the client and have everything there. 😀
Now I just have to find out how to prevent Gentoo from unmounting its root filesystem too early on shutdown …
In order to document our work we are planning to write a HowTo in the Gentoo-Wiki