Scientific Linux DESY 3 at Zeuthen
SL3 is available in a 64bit version for AMD64/EM64T systems as well.
The major difference with respect to DL5 is its much longer lifetime and enhanced compatibility with most other HEP sites because it's based on Scientific Linux, an effort started and kindly made available by our colleagues from FNAL and meanwhile joined by those from CERN. It has been and still is being adopted by many labs and university departments, although some chose to purchase subscriptions for RedHat Enterprise Linux (which should not make any difference from the users' point of view).
Presentations about Scientific Linux at DESY were given in the DESY Linux User
Meeting
April 21st, 2004 and
August 25th, 2004.
There also was a presentation to the CUC on August 2nd, 2004.
A
presentation introducing Scientific Linux (DESY)
in more detail was given in the Zeuthen Technical Seminar September 14th, 2004.
Knut Woller presented the
Scientific Linux Roadmap for DESY in the computing seminar November 1st, 2004.
The introduction of SL3 at Zeuthen in Spring 2005 was accompanied by a
presentation in the Zeuthen Technical Seminar April 19, 2005.
See also the
SLD pages by -IT- in Hamburg .
It is in use on
As of October 2005, SL3 has essentially replaced DL5. Migration is complete except for very few servers, typically fileservers with uptimes of many months.
A public login 64bit system sl3-64.ifh.de is available as well.
SL3 had been available to early adopters since January 7, 2005, and a public preview system (sl3.ifh.de) had been provided since July 30, 2004. Any serious problems reported by users have been sorted out. As of June 8, 2005, the public preview was no longer available since it's no longer needed.
The last DL5 system accessible to users vanished December 29, 2005.
ini ooo_de)gv package was added to the selection
The AFS sysname of SL3 is , for the first time, a list.
The value is i586_rhel30, i586_linux24, i386_linux24.
This should provide full backward compatibility with DL5 and
even DL4 for AFS paths containing a component /@sys/,
but the value returned by livesys is different.
The 64bit version will have amd64_rhel30, amd64_linux24 prepended to that list.
The default compiler is gcc 3.2.3 as it comes with RedHat linux (notice that from the size of the diff, this bears more similarity with a 3.3.3 release than 3.2.3 as it comes from gcc.org). The default C++ runtime library is the one matching this compiler. While we haven't found any problems with this yet (for example, all ROOT version built on DL5 work fine), some applications built on DL5 may have to be provided with an LD_LIBRARY_PATH pointing to the C++ runtime lib for the compiler they have been built with. These applications will refuse to start with an error message indicating a missing shared library.
The full set of compilers available on DL5 is available in /opt/products on SL3 as well. It's just that none of them is in a user's PATH by default. Use ini gcc333 to build with the DL5 default compiler, or run applications with the DL5 runtime libraries. On 32-bit systems, even ini gcc2 works. To run such executables on 64-bit SL3, use LD_LIBRARY_PATH=/opt/products/gcc/2.95.3/lib .
The decision not to replace the default compiler and runtime library should provide better cross site compatibility and is now considered final.
Many applications built on SL3 will work on DL5. But some won't: If they depend on NPTL, or glibc ABI 2.3.3 (which is provided by the glibc 2.3.2 coming with RedHat Linux today...), it may be impossible to run them on any linux system not providing those.
As of June 10, 2005, gcc version 3.4.3, as it comes
with SL4, is made available (execute ini gcc343 to use it).
The Native POSIX Thread Library is the major technical difference under the hood. This affects programming multithreaded applications since there are significant differences in the way signals are dispatched and single threads are identified (there is no more manager thread, and all threads now have the same PID).
For more information about NPTL, see the NPTL whitepaper and this article about porting threaded applications to linux 2.6 that does apply to the kernel/glibc combo on SL3 even though the kernel version there is 2.4.
The implementation is supposed to be backward binary compatible, unless an application relies on the deviations of LinuxThreads from the POSIX standard. One known class of such applications are older implementations of the Java Virtual Machine (both from SUN and IBM) and hence any software coming with its own old JVM (like Matlab and older versions of Maple).
As a workaround to allow using such applications, SL3 ships with two older,
non-NPTL implementations of the thread libraries.
If you have trouble using the default one, you can set the environment
variable LD_ASSUME_KERNEL to either 2.4.19 or
2.4.0 for broken applications.Do NOT do this generally,
like in ~/.profile. Instead, wrap those applications into some script like this:
#!/bin/sh
export LD_ASSUME_KERNEL=2.4.19
/some/path/my/broken/app "$@"
Make this executable with chmod +x and place it in ~/bin.
For more information about the LD_ASSUME_KERNEL mechanism, see
here.
This affects old software dynamically linked against pre-glibc versions
of the system library. There should not be much software like this around.
So far we only found that we had to remove the cmesvr and
cmspawn utilities from the CMZ package, hence asynchronous
editing in CMZ is impossible. It hasn't been investigated whether or not
it's feasible to add a libc5 to SL3, and we'd much rather not spend time on
this issue.
Starting with RHL9 (the base of RHEL3), Red Hat deliberately introduced an incompatibility in character handling to accommodate a new locale model (see here for details). This breaks static objects and static libraries built on previous glibc versions (RHL <=8, RHEL <2.1, SuSE at least <=9.0, ...) and affects various 3rd party products, in particular compilers like PGI (but the recently installed PGI version 5.2 of course fixes this).
The symptom is an error message from the linker
"undefined reference to __ctype_b" or some other symbol starting
with __ctype.
As a workaround for the compiler problem, compiling the file ctype.c and adding it to the object list for the linker should help.
The better way to resolve these issues is of course to update our installation of these 3rd party products, so please let us know if you find this to be necessary for anything not already listed in the known problems section of this document
A similar class of problems is applications that access the internal glibc symbol __libc_wait that was never meant to be used anywhere else and is now no longer exported. As a workaround, it helps to create a shared object from the file libcwait.c and either link this with your application or use it with LD_PRELOAD=.../libcwait.so for applications you only have the binary executables of. This is how we got matlab6 going.
The default behaviour of the hostname command on any Red Hat
Linux is to always return the fully qualified domain name (host.ifh.de),
no matter whether or not the -f switch is used. This may be
wrong, but some software out there relies on this behaviour. SLD will therefore
behave like this as well.
The central font server is no longer used by default. Instead, every login host has its own local font server with its own local fonts. While this makes things faster and more reliable, some fonts may still be missing, and some may even be impossible to make available this way.
Systems that have to cater for Windoze clients make the font server available to those. As a result, there should not be problems with missing font in remote X Sessions anymore. Our default Xsession will set the right font path (loginserver:7100).
XDMCP is still possible on central login servers but highly deprecated and may be turned off soon (it is effectively a clear text protocol). With XWin32 on Windows XP, it is easy to configure a session via ssh. The command that should be executed through on the server is then
/usr/sue/lib/xdm/hepix/Xsession session
where session is on e of the supported session types, currently kde, fvwm2, windowmaker, icewm, gnome, and failsafe. This way, the full functionality of the kdm chooser is retained.
The X Server on SL3 desktops does not listen on the TCP port. Hence the xhost command (which is extremely insecure and has been deprecated for years) has no effect. Use ssh tunnels to run remote X applications instead. In the future, all linux systems at DESY Zeuthen may even drop outgoing traffic on this port.
The KDE version coming with SL3 is almost, but not quite, the same as the one on DL5. There seem to be no problems when moving from DL5 to SL3, but some personal settings may no longer be correct when logging in under DL5 afterwards (found to to happen for automatic screen lock, for example). As a workaround, you can separate your kde configurations for DL5 and SL3 like this:
cd
mkdir .i586_rhel30
cp -a .kde Desktop .i586_rhel30
mv .kde Desktop .i586_linux24
ln -s .@sys/.kde .@sys/Desktop .
mkdir .amd64_rhel30
ln -s ~/.@sys/.kde .@sys/Desktop .amd64_rhel30
Whenever you log in through kdm (locally on your desktop PC, or remotely via xdmcp),
it will store your last choice in the file ~/.wmrc and make this
the default the next time you type in your user name - if it can read
the file. Since kdm has no access to your home directory, to make this effective
you have to replace this file by a link to a file in a location readable
by kdm:
mv ~/.wmrc ~/public/.wmrc
ln -s public/.wmrc ~/.wmrc
Firefox is available on SL3 and has replaced mozilla. Notice that some configuration options are locked down and cannot be changed by users:
As of version 1.0.7 (September 24, 2005), saving passwords is no longer forcibly disabled.
It's still disabled by default, but can now be turned on.
As of April 28, 2005, a configuration problem is fixed. Options like
"startup.homepage" or "tabs.loadInBackground" are no longer locked.
For the users who have started firefox before April 28, 2005:
To have an effect of these changes you have to remove your
.mozilla/firefox/salt.default/user.js
acroread or acroread7.
As of January 7, 2006, the asian fonts are available on all interactive systems. Documents using tese can also be printed properly.
If you'd like to use the firefox plugin, create the following symlink:
ln -s /usr/local/Adobe/Acrobat7.0/Browser/intellinux/nppdf.so ~/.mozilla/pluginsYou may have to create the plugins directory before. We don't make this the default (as we do for the Java, Flash and other plugins) because it would be much harder to get rid of for users who prefer the standalone application than it is to create this link.
soffice, swriter, simpress, scalc .
To run the new version 2.1.0 use soffice2.1.0, swriter2.1.0, simpress2.1.0, scalc2.1.0 .
[x]maple, [x]maple9.5, [x]maple10.s. The s in the maple10
command is due due to a change in maple licensing that forced us to add this
letter to the package version. A native 64-bit version for the amd64 platform
became available with version 10, and this is what we provide on those systems.
ini matlab before you can use it. Version 6
comes with an ancient jvm and relies on glibc internals that were never guaranteed.
We now implemented a hack to make it possible to run it on SL3 anyway. ini matlab6
does this for you (available on 32-bit systems only).
Note that matlab licenses are scarce and extremely expensive. You should not assume that a license is available for you unless your group purchased one.
ini svn13x. This will
change eventually.
/mnt/floppy/mnt/cdrom, /mnt/cdrom1, .../mnt/hotplugfdisk /dev/sda
to create a single partition 1 on it (make sure the kernel successfully read the
new partition table! re-plug the stick if necessary), then run /sbin/mkfs.vfat
/dev/sda1 to create the filesystem.
These devices seem to make more problems under SL3 than they did under DL5, although they do work flawlessly on a fairly extensive matrix of testsystems and devices if partitioned according to the rule above:
400 MHz PII i440BX 850 MHz PIII i440BX 64 MB TwinMos USB 1 1.7 GHz P4 i850 (ASUS) 128 MB Transcend USB2 (x) 2.4 GHz P4 i850 (Dell) 1 GB Silverpearl USB2 2.8 GHz P4 i875 3.2 GHz P4 i925 2.8 GHz Pentium D i955If the partition on your stick is not recognized (in this case, /dev/hotplug will point to /dev/sda instead of /dev/sda1), try re-plugging it: unplug, count to 10, then plug it in again - smoothly and firmly, in a single move, without hesitating at the first contact.
A few sticks owned by users don't work at all. We can't help that, since we don't have such hardware available for testing.
For the same reason, please don't use any defective Floppies, CDs, Memory Sticks etc. on any of our systems.
If you use the screen program (which is not encouraged anyway!), you have
to export the SCREENDIR variable. The recommended value is
/tmp/uscreens-$USER .
are meant to be used as X-Terminal-like login devices only, because there's no group admin responsible for them. They have to be handled as true thin clients, and hence
The content of /usr1 will be preserved except for hosts with very small disks:
uco-zn@desy.de by e-mail, requesting the upgrade
to SL3 and providing the following data:
For the curious: This involves changing the host entry in our configuration database, creating an installation profile (using live information from the system about it's partitioning if necessary), and running a script on the system to install to create an additional, default entry for the boot loader which will then start the installation process.
Even after the preparation, it is possible to reboot into the old operating system in an emergency (say, if your desktop PC crashes during the afternoon, and you really just want to boot and not wait for the installation to finish before you can continue your work): Simply choose the second entry instead of "SL3-Upgrade" when booting. This will however undo the preparation, so please let us know.
While for TFT screen there's one and just one correct mode, CRTs allow for some variation. The automatic procedure aims for a reasonable compromise between a high refresh rate, a high total number of pixels, and a dpi resolution that's no too high to make it necessary to change all font sizes from their default (typically: 1152x864 on 17 inch CRTs, 1280x1024 on 19 inch, and 1400x1050 on 21 inch screens - at either 75 or 85 Hz depending on the monitor's capabilities). It generally yields a result that's at least acceptable - and won't damage the hardware - but users may have different preferences.