• RaQ

Computer Science have some Sun/Cobalt RaQ machines that are currently available for our use.

Hostnames

We're using Russian space project names. The first machine's soyuz; the other two will be salyut and mir. More names suggested for the future: cosmos, polynus, zenit, clipper, spiral.

Background

There are three Sun Cobalt RAQ 550's for us to use. These are 1Ghz Pentium III machines, but they are not PCs, crucially, part of the kernel for them is stored in a boot rom, much like an old world Macintosh. They are thus difficult to install a new OS on, or even keep updated. They are web appliances, but the hardware could be put to better use. The Sun Warranty has nearly run out either way.

Computer Science already has one in use with Debian on it, so we should be able to get the other three to work. There are many tutorials for older MIPS based RaQ web-appliances, but little or nothing for the RaQ 550s and XTRAs. This is because the latter is still supported, and not many people have installed Debian.

How we installed Debian on soyuz

We mostly followed the HOWTO at http://cobalt.iceblink.org/debian/debian-cobalt-howto.txt -- only a few things needed changing.

We didn't update the firmware, since it's already booting a Linux 2.4 kernel happily.

On the first netboot, it hung while starting syslogd (presumably because there was no network), so we edited /etc/init.d/syslogd on the server and commented out the line that actually starts it.

The next problem we ran into was that login wouldn't work because it couldn't write to the nfsroot. This turned out to be Ubuntu's nfs-user-server being broken -- the no_root_squash option wasn't doing anything (as verified with strace). We cheated by adding anonuid=0,anongid=0 to the exports options, making it "squash" to root.

Since we didn't have a Debian stable CD, we used debootstrap to install over the network, temporarily stealing compsoc2's IP address.

We kept the existing partitioning scheme, which had a 4GB root disk, 1.5GB /var, 512MB swap and the remainder of the disk as /home, using ext3 for everything. We changed the partition types initially all to 82/83 as appropriate, but then discovered an interesting problem with the RaQ's boot process -- its builtin kernel loads the real kernel from /boot/vmlinux.bz2 on /dev/md0, so you need at least one "Linux RAID autodetect" RAID device. In order to save reinstalling everything, soyuz's /home was set up as a single-disk RAID briefly and the kernel dropped on there -- so soyuz's kernel is in /home/boot/vmlinux.bz2. This should probably be done differently when we build future machines (have the root FS be the fake RAID device, so /boot ends up in a sensible place).

Once booted happily, we had to add natsemi to /etc/modules to get the network controller working.

BIOS/ROM Updates

We had some issues with soyuz (months after the install) which required us to patch the ROM. It'd make life much easier if the ROM update was applied before the machine dies, so I recommend making this part of the build process.

Computer Science Requirements

We have these machines to use for Compsoc, but we need to remember that:

• The machines should remain in their current location, although CS can let them come out for installation if needed
• CS might need them back if an academic need arises, but it's unlikely they'd need all three

Resources

• http://fallenknight.org/staticpages/index.php/rh9raq3 (Installing Red Hat on RaQ MIPS machines - not what we want)

• http://www.sun.com/hardware/serverappliances/pdfs/datasheets/datasheet.raq550.pdf (RaQ 550 Datasheet)

• http://cobalt-forum.sun.com/forum/index.php?t=index& (Cobalt Support Forums from Sun)

• http://www.cobaltfaqs.com/ (Community Cobalt Site)

• http://sunsolve.sun.com/handbook_pub/Systems/Cobalt/Cobalt.html (Cobalt Handbooks)

• http://www.cyrius.com/debian/cobalt/sarge.html (Debian Sarge Install HOWTO for RaQ 1,2)

• http://www.hockin.org/~thockin/cobalt-hack-faq.html (RaQ Hacking FAQ)

• http://lists.debian.org/debian-user/2002/06/msg00846.html (HOWTO Debian Sarge Install for RaQ 3 (x86))

• http://cobalt.iceblink.org/debian/debian-cobalt-howto.txt (HOWTO Debian Install x86 RaQ's)

• http://sourceforge.net/projects/cobalt-rom (ROM files and romutils package. The -flat ROM versions are for RaQ 550)

Interested people

• ojc4
• tdb
• drb8
• mpb3
• bcc
• aa79
• dcw5, innit
• wah3
• rn20
• jpw5
• nbg2
• anibal (anibal at debian dot org)
• ats1

Practical, current, ideas for use

• Game Server(s)
  • People: ojc4 (Have legal copy of UT2004)
  • This has been approved by Service now.
• Subversion/CVS/Arch/Darcs/... server for open-source joint development

  • We are currently discussing the possibility of hosting a Savannah or GForge site, with the aim of showing off Kent's open source development skills.

  • People: ojc4
• Tomcat/Apache server seperated from compsoc1 (since it's resource heavy, and compsoc1 is our workstation)
  • Yes PLEASE!!
  • Obviously external access is an issue here.
  • Tomcat being a pain in the arse to maintain for multiple users being an issue, too
  • People: ojc4 (Experience with tomcat... amusingly more so than Apache)
    • ojc4 says: I think the best option here is to issue people UNIX accounts, with a custom script that will install and configure a Tomcat binary for them. I could probably pull that off at some point.

    • ojc4 also says: We could also run an Apache on port 80, and run first-come first-served for subdirectories that proxy onto individual users' Tomcats. Hence http://raq1/helloworld could proxy http://raq1:8085/MyHelloServlet.

• General unix server

Back burner ideas that we may not be able to pull off

• Voice over IP server (Asterisk)
  • That'd be cool, particularly if we could get external access for it...
  • Yeah, would be able to do things like giving everyone external phone numbers (0870, if you want a free number - to buy that is, not phone), phoning from LAN to the university PBX (with a piece of hardware and a few spare phone lines), free online calls without having to open up the firewall to SBS PCs, telephone conferencing, ability to phone land lines - maybe even potential for compsoc to make money out of it.
  • VoIP sever probably isn't worth implementing unless it had external access, including UDP!
  • Can't interface it to the existing PBX without an FXO card
  • People: mpb3
• mosix clustering?
  • Assuming we get all three, I think we should cluster two, and see what we can do with them.
  • Probably worth looking at OpenSSI as well -- it seems a bit saner than MOSIX. -- ats1
  • People:

Things that aren't going to happen

• Incoming SSH Server for off-campus member access to Kent IRC
  • ... because we've got dodo now, which is an old Sun box