Status and Availability

Improvements over SL3

SL5 users will benefit directly from these:

There are also many new features primarily of interest to administrators, like virtualization (Xen), configurable I/O schedulers, ionice(1), improved power management (really important for the farm these days), ...

General Points

AFS Sysname List

The AFS sysname list (the output of the fs sysname command) in Zeuthen is:

Platform

Sysname List

32bit (i686)

i586_rhel50

i386_linux26

i586_rhel30

i586_linux24

i386_linux24

64bit (x86_64)

amd64_rhel50

amd64_linux26

amd64_rhel30

i586_rhel50

i386_linux26

i586_rhel30

i586_linux24

i386_linux24

Login Shells

We made a serious effort to make bash a supported login shell, but it's impossible.

There is no way to reliably give bash users a working environment identical to that of zsh and tcsh users, due to bash's limited functionality w.r.t. startup files processing.

We recommend using zsh, zsh or zsh as the login shell. Tcsh is available for those who insist. Bash is not, sorry.

Notice this does not prevent users from writing or using bash scripts in any way.

Language Support, UTF8

It was initially planned to introduce use of UTF8 as the default with SL4. Alas, it was found that it's causing too much trouble, and makes things too incompatible to the rest of our environment. This hasn't changed with SL5. Also notice that a lot of software still has bugs when used under a UTF8 locale.

Hence the default for the LANG environment variable on SL5 systems is C, as on SL4, SL3 and DL5 before. Early SL4 systems had a default of en_US, because it makes certain GNOME applications behave more sensible (in particular gnome-terminal), but it was found to cause other problems (among them, changes in the date format and sorting order).

Any user may change the personal default by creating a file ~/.i18n:

# recommended and default:
#LANG=C

# alternative (but see the remarks concerning a2ps below):
#LANG=en_US

# I want to experiment with UTF-8
LANG=en_US.UTF-8
# But I really prefer A4 over Letter
LC_PAPER=de_DE

We do not install language support packages for other languages than US-english, with the sole exception of dictionaries for spellchecking. Languages other than english for the user interface are not supported.

But: Typing and displaying non ASCII characters should work very well under a UTF-8 locale in GNOME and KDE applications. Here's an example of how to achieve this even under the default environment:

export LANG=en_US.UTF-8 export LC_PAPER=de_DE exec gnome-terminal \

 . --hide-menubar --disable-factory --geometry=80x40 --window-with-profile=alpine \ -x alpine -i

This script will open a new gnome-terminal window and execute the alpine mail client in it. The alpine profile in your gnome-terminal should of course have suitable settings (no scroll bar, maybe a certain font,...).

For KDE users, something like this is probably more suitable:

export LANG=en_US.UTF-8 export LC_PAPER=de_DE exec konsole \

 . --nohist --nomenubar --notabbar --noscrollbar --vt_sz 80x40 \ -e alpine -i

It should be noted that both gnome-terminal and konsole do provide fairly good UTF-8 support, xterm will handle west european chars well, but does (by default?) not display russian, chinese etc. chars.

When switching to UTF-8 you might need further adjustments to the programs. We know that the following settings are needed:(please report more findings!)

There are two methods for typing: Compose Character (see below) should work in most applications, and for most "european" characters. In addition, the SCIM (smart common input method) is available in GNOME and KDE applications, and can be used to type other character sets, like Cyryllic, Chinese, Japanese and others. Some users have reported problems with SCIM like crashes and accidental input mode switches. If you don't use SCIM, you can disable it with the command im-chooser.

Removable Media and Hotplug Storage Devices

Backward Compatibility

Desktop/User Environment

Printing

Print Service has been changed from LPRng to Cups because LPRng is obsolete and Cups is better integrated in KDE, Gnome, OpenOffice and other tools.

Binaries

SL5 should be binary backward compatible with SL4. This means that executables built on and for SL4 should work on SL5. It does not mean that any executable that works on SL4 will work on SL5 as well: If it worked only due to legacy support before, it may no longer work on SL5.

In particular, binaries that depend on setting the environment variable $LD_ASSUME_KERNEL to a value lower than 2.6.9 won't work on SL5.

C++ ABI

There was no major change to the C++ ABI from the default compiler on SL3 to the one on SL5, only a few "ABI fixes". Most binaries built on SL3 should work fine with the shared libaries built on and for SL5. Example: Building the tests for ROOT-5.14 on SL4 and running them on SL5 works fine. One of the executables behaves slightly differently - but in this one, glibc detects a memory handling bug (see below).

In fact, it usually even works to build and run an executable on SL5 against libraries built on and for SL4, and sometimes even SL3.

Missing Shared Libraries

If your executable fails with an error message like this

error while loading shared libraries: libldap.so.2: cannot open shared object file: No such file or directory

this indicates a missing shared library. If such a a shared library is available on SL3/4, we'll try to make it available on SL5 as well, so please report these cases. To find out whether a libray is available on the older systems, log into an SL3/4 system and use rpm:

[sl3] ~ % rpm -q --whatprovides libldap.so.2
openldap-2.0.27-22.i386
[sl4] ~ % rpm -q --whatprovides libldap.so.2
compat-openldap-2.1.30-7.4E.i386

In this case, we created a compatibility package for SL5 from the SL4 one:

[sl5] ~ % rpm -q --whatprovides libldap.so.2
compat-sl3-openldap-2.1.30-7.4E.i386

This will be possible in almost all cases.

Using Shared Libraries from the SL3 AFS Installation

Many /opt/products packages are installed in AFS space, to make it possible to reference them with a symbolic link at least on systems with smaller disks. In many cases, this allows using this software on SL5 even if it's not installed into /opt/products on this platform. For example, to use the shared libraries from the root64-5.12.00 build from SL3, one can export LD_LIBRARY_PATH=/afs/ifh.de/amd64_rhel30/products/root64/5.12.00/lib64 . The corresponding path for the SL3/32bit installation is afs/ifh.de/i586_rhel30/products/.

Executables failing with *** glibc detected *** error messages

If your executable does not work, but instead fails like this

 ~ % voms-proxy-init
Cannot find file or dir: /afs/ifh.de/user/w/wiesand/.glite/vomses
Your identity: /O=GermanGrid/OU=DESY/CN=Stephan Wiesand
Enter GRID pass phrase:
Creating proxy ............................................................ Done
*** glibc detected *** voms-proxy-init: munmap_chunk(): invalid pointer: 0xbf97bd02 ***
======= Backtrace: =========
/lib/libc.so.6(cfree+0x1bb)[0x47c216db]

and so on, that's a bug in the application's memory management. Starting with SL3, glibc began detecting such bugs and warning about them. Since SL4, processes exhibiting such bugs are terminated by default. With SL5, glibc detects more of these problems, hence this may affect applications that worked on older releases.

As a workaround, you can set the environment variable MALLOC_CHECK_ to 1, to keep glibc from terminating such processes:

~ % MALLOC_CHECK_=1 voms-proxy-init malloc: using debugging hooks
Cannot find file or dir: /afs/ifh.de/user/w/wiesand/.glite/vomses
Your identity: /O=GermanGrid/OU=DESY/CN=Stephan Wiesan
 Enter GRID pass phrase:
Creating proxy ................................................................................. Done
*** glibc detected *** voms-proxy-init: free(): invalid pointer: 0xbf900d01 ***
Your proxy is valid until Wed May  9 03:49:39 2007

Notice the 'malloc: using debugging hooks' message before each command. Since this also costs performance, do not add this environment variable to your profile.

Executables failing with "cannot restore segment prot after reloc"

SL5 is the first SL release exposing end users to SELinux - which was present on SL4, but much more permissive by default, except for the targeted daemons. For example, processes normally have permission to either execute a memory location or write to it, but not both (wherever possible and practical, anyway).

This restriction makes life hard for attackers trying to exploit bugs like buffer overflows in the software. It also prevents a few existing applications from being executed. Here's an example for a certain release of GRID User Interface Software:

.../gui-2.3/lcg/bin/lcg-cp: error while loading shared libraries: .../gui-2.3/lcg/lib/libgfal_pthr.so: cannot restore segment prot after reloc: Permission denied

There is some information on SELinux memory protection available in http://people.redhat.com/~drepper/selinux-mem.html , and more about text relocations in http://people.redhat.com/~drepper/textrelocs.html . In short, the author of these documents explains that executables (including shared libraries) exhibiting this error are incorrectly built:

The solution is usually to recompile the source with -fPIC .

If you can't do that, the workaround is to apply a security label to the binary which will allow it to perform text relocation:

[sl5] % chcon -t textrel_shlib_t .../gui-2.3/lcg/lib/libgfal_pthr.so 

<!> This only works on the local disk. Not in NFS/AFS/Lustre.

Executables failling with Fortran runtime error

fortran program fails on SL5 32-bit to read unformatted data written on SL3 32-bit with error message like this

Fortran runtime error: Invalid argument

recompile with gfortran runtime options

-fconvert=native -frecord-marker=4

Source Code

Building Software

In general, it is more strictly necessary than before to compile anything that will be used in a shared object with -fPIC. In particular, if one receives this error from the linker:

/usr/bin/ld: xyz.o: relocation R_X86_64_32 against `a local symbol' can not be used when  making a shared object; recompile with -fPIC

one should really do as told.

Applications

Software

Browser

Firefox ist the recommended web browser. We provide the java, flash and realplayer plugins.

Apline Mail Client

alpine, the successor of pine, is a recommended e-mail client.

Alpine consults /etc/mailcap to display attachments. Some users complained that ps and pdf files are displayed using evince. This can be changed to acroread and gv respectively by appending the two lines

application/pdf; acroread %s
application/postscript; gv %s

to your ~/.mailcap file.

To use alpine as default mail client in GNOME and Firefox 3.0, select it in the GNOME Control Center or run gnome-default-applications-properties directly:
Bildschirmfoto-Preferred-Applications.png

Compilers

GCC

Intel

Version 9.1, 10.1 and 2011 (12.0.3) of the C, C++, and FORTRAN compilers are available. The 32-bit runtime environment is installed on 64-bit Systems as well.

Portland Group

Version 7.0 (and/or later, newest: 2011(11.5) of the PGI compiler is installed. The 32-bit runtime system is available on 64-bit hosts.

Java

Version 1.7 is installed as 64-bit. Older versions had to be removed due to severe security problems and their end of support life.

ROOT

We provide version 5.14.00 (now patch release f) built with GCC4 as the default. A few more versions are installed in /opt/products and available through ini. As on SL3/4, the 64-bit build is installed in /opt/products/root64, the 32-bit one in /opt/products/root.

In 2011, DV/IT stopped providing new ROOT versions centrally and groups are expected to have their own installation tailored to their needs.

This being said, there seem to be ROOT versions installed in /afs/desy.de/products/root .

Matlab

Version R2012a is default with ini matlab. Some more versions are available too, see ini |grep matlab.

Known Problems

GNOME trash bin broken

This problem ist still with us. See GNOME_Trash_in_AFS_problem . Advice: Do not use the Gnome trashbin. If you do, clean out ~/.Trash regularly.

evo seems not to work

Error loading koala.jar . This seems to be a problem on the evo side. As a workaround, please start evo from http://evo.vrvs.org and not https://evo.vrvs.org

vi misbehaves in konsole & gnome-terminal if $TERM=vt100

If the environment variable TERM is set to vt100, some escape sequences produced by vi (or vim) are not processed correctly by konsole and gnome-terminal. Please do not set TERM in your dot files.

ps2pdf displacing graphics

There is one report of ps2pdf (from the gs package) shifting graphics in the document to the wrong posisiton on the page. Using epstopdf (from the tetex package) instead solved this problem.

firefox doesn't allow changing the helper application for postscript and PDF files

This is not specific to SL5. As of January 17, 2008, this procedure should help:

  1. stop firefox
  2. rm ~/.mozilla/firefox/*/mimeTypes.rdf

  3. restart firefox

Firefox should then get a working copy of this configuration file we now provide. You should be able to choose helper applications for the most relevant file types under Edit -> Preferences -> Downloads -> View & Edit Actions

Remark: this info may no longer be accurate with firefox 3

emacs is not using syntax highlighting by default

This is most probably due to an out of date ~/.emacs file. A good sample file can be copied from /etc/skel/.emacs

Software known not to work on SL5

Software we do not foresee to make available

Software removed from SL5

SL5_User_Information (last edited 2017-05-23 11:28:28 by StephanWiesand)