Sun Ray Server Software 3 is what runs on the server and manages the communication which makes sure the Sun Rays can connect and get a login session (the session itself is just an ordinary session as provided by the underlying operating system). Sun provides this for Solaris and for Linux. We have been attempting to get it to run on Fedora Core 3.
Sun says the software is supported on "Java Desktop System, Release 2 or Red Hat Enterprise Server AS 3 (32-bit) or SuSE Enterprise Linux 8, service pack 3 (32-bit)." But Fedora is a Red Hat variant, so it ought to be possible to get it going, right?
The installation manual has a section on what software is required. Unfortunately, this just says "all packages are required" and instructs you, when installing Red Hat ES, to select the "Everything" option. This clearly isn't sensible. But perhaps the installation script will check that the environment is suitable?
The installation script is an opaque program which tries to figure out what to install, asks a couple of rudimentary questions, then installs it behind the scenes, and finally advises you to check the log for error messages. There was a message, as it happens, but given that everything happened in the background it was impossible to be entirely sure how serious the message was or even where it came from. Fortunately, though, it was possible to determine the root cause: a package which a bit of SRSS depends on (namely "linc") needed to be installed (from Fedora Core 2, since they have stopped supporting it under FC3).
Sun has at least been sensible enough to package the software for Linux in RPM format, which means there's a proper record of the installed files and who they belong to, and they can be managed in the same way as for Fedora's standard packages. However, they have completely ignored a useful feature, namely the dependencies. Normally when you try to install a package, if it needs a library that isn't present on your system then it will inform you that all the dependencies are not met and refuse to install the package — which is almost always sensible, because it won't work properly (or at all) until the dependencies are resolved. Modern package managers such as yum will even search for and (if possible) download a package which will solve the dependencies. However, Sun has chosen to install the packages with the "--nodeps" option, which means you don't even get so much as a warning. Therefore it wasn't until much later, when the configuration process started falling over, that I discovered that the "compat-openldap" package was needed for it to work properly. (I don't know why it is that commercial vendors don't seem to be able to package software to the same standards as open source authors. The free-for-noncommercial-use Intel compilers for Linux come with a script that suggests --force for the install arguments, which is completely unnecessary; Adobe Reader 7.0 for Linux and RealPlayer for Linux both come in packages that install by default into /usr/local, which misses the point, and IBM Object Rexx before they open sourced it came in a package with a trigger script which blindly removes the entire installation directory tree when you uninstall it, no matter whether you'd installed other things in there, which is stupid because the package manager already takes care of removing all the installed files. The previous version came in a package which needed LD_LIBRARY_PATH and other environment variables set at runtime as well as installing into /usr/local.)
Unfortunately there was also a genuine installation problem: SRSS comes with kernel modules which are written for 2.4.x and don't compile under 2.6.x (which has been out for, oh, a year and a half now) because they use module counters which got removed. Fortunately, it seems that removing the references to these and rehashing the Makefiles to conform to current build procedures results in a working module, though I'm sure that's not an ideal solution.
Unfortunately, once everything had been successfully installed, running the configuration scripts did not result in a working configuration. In fact it claimed to set up a DHCP server while leaving all the important things unspecified, so that I had to edit the DHCP configuration to even get it started. That wasn't sufficient, however, and looking at a screen with a small box in the middle containing a couple of pretty icons and the error code "22B" was somewhat reminiscent of trying to decode the error report issued by a ZX81 when your BASIC program went wrong. It turned out that, although the vendor-specific bit of DHCP looked like it had been configured, an essential line had been left out.
Now one of the things that the SRSS install script does is replace the system's "gdm" package with its own customised one. Sun's version has the same name but a different version number; but because it's based on an older version of Linux, the version number is lower than that of the same package in Fedora. Some time between installing SRSS and getting it to work, I had applied the current Fedora updates without realising that this would re-upgrade the "gdm" package. Discovering that this had happened was the final step in actually getting it to work, at long last.