Revision 52 as of 2006-05-26 15:36:22

Clear message

TableOfContents

Overall Status

automatic installation

works

automatic maintenance

works

ssh

using native ssh with gssapi and the time-honoured pam_krb5afs for tokens

integration / features

the hard ones are done, but many missing

user/group environment

mostly done

application software

direction established

batch/grid

no work done yet

Xsession environment

works, HEPiX11 dropped

desktop

works, including guest accounts

special desktops

prepared (dual head, autologin for shift accounts,...)

xdmcp

works, including font service for remote clients

TODO List

Besides some missing features and software packages, these are the most pressing items:

=== Turn off irqbalance on SMP hosts ====

NSCD Behaviour & Handling is a Total Mess (TM)

=> first think about this, then design, then code, then document !

Booting with init=/bin/sh does not work

Terminal Settings

Application Software

As discussed in the [:UnixMinutes/Protokoll-2006-04-18:Unix meeting 2006-04-18]:

Java: 1.5 32-bit jpackage is default, 64bit build on amd64 in addition, nothing else without a case

Browsers: 32bit Firefox is the only supported one

Mail Client: pine recommended, Thunderbird provided as is

Openoffice: 2.0.x system packages from openoffice.org

Table of Missing Software

cernlib

2005 ok, we should roll out at least 2004 as well

root

to be done - how to provide backward compatibility?! (new C++ ABI)

form

sed by a single group only - drop ?

geant4

a Total Mess (TM) on all platforms

CLHEP

see comment for root above

hwinfo

used by csinfo; should be dropped in favour of dmidecode on SL3&4

plan

SuSE only, holiday bug, ...

prosper

there's a ticket for it nobody has time to work on

freemind

try to get a more recent version going

Table of Dropped Software

mgdiff

old, tkdiff should suffice

open questions

SELinux and preserved Partitions: Relabel /usr1?

Disable Sound except on desktops?

Sound is automatically configured during installation. Maybe we should diable it on all classes of machines except desktops? And is it sufficient to comment out the *snd* lines in /etc/modprobe.conf?

Leave cpufreq enabled?

This is the default, and it works fine on some recent hardware.

is DL_cron_sigpipe still needed?

Check whether this was fixed upstream.

roll out a development version of zsh with partial UTF8 support?

This was proposed in the [:UnixMinutes/Protokoll-2006-04-18:Unix meeting 2006-04-18] by at least two participants. At least two others think this is flirting with desaster.

replace NIS/LDAP with local files?

Why not finally rid ourselves of all NIS/LDAP/nsswicth(compat...) problems?

This is now available, and works very well. Make it the default?

if yes: how to handle nscd?

Any more s-bits to remove?

[em64t] /root # find /bin /etc /lib /misc /opt /sbin /selinux /srv /tftpboot /tmp.orig /usr /var -perm +6000 | xargs ls -ldF | awk '{print $1 "  " $3 "  " $4 "    \t" $9}'
-rwsr-xr-x  root  root          /bin/mount*
-rwsr-xr-x  root  root          /bin/ping*
-rwsr-xr-x  root  root          /bin/ping6*
-rwsr-xr-x  root  root          /bin/su*
-rwsr-xr-x  root  root          /bin/umount*
-rwsr-xr-x  root  root          /opt/products/krb5/1.4/bin/ksu*
-rwsr-xr-x  root  root          /opt/products/krb5/1.4/bin/v4rcp*
-rwxr-sr-x  root  root          /sbin/netreport*
-r-s--x--x  root  root          /sbin/pam_timestamp_check*
-r-sr-xr-x  root  root          /sbin/pwdb_chkpwd*
-r-sr-xr-x  root  root          /sbin/unix_chkpwd*
-rwsr-xr-x  root  root          /usr/bin/chage*
-rwsr-xr-x  root  root          /usr/bin/gpasswd*
-rwsr-xr-x  root  root          /usr/bin/kgrantpty*
-rwsr-xr-x  root  root          /usr/bin/kpac_dhcp_helper*
-rwxr-sr-x  root  mail          /usr/bin/lockfile*
-rwsr-xr-x  root  root          /usr/bin/lppasswd*
-rws--x--x  root  root          /usr/bin/newgrp*
-r-s--x--x  root  root          /usr/bin/passwd*
-rwsr-xr-x  root  root          /usr/bin/rcp*
-rwsr-xr-x  root  root          /usr/bin/rlogin*
-rwsr-xr-x  root  root          /usr/bin/rsh*
-rwsr-xr-x  root  root          /usr/bin/sg*
-rwxr-sr-x  root  slocate       /usr/bin/slocate*
-rwxr-sr-x  root  nobody        /usr/bin/ssh-agent*
-r-xr-sr-x  root  tty           /usr/bin/wall*
-rwxr-sr-x  root  tty           /usr/bin/write*
-rwsr-xr-x  root  root          /usr/kerberos/bin/ksu*
-rws--x--x  root  root          /usr/libexec/openssh/ssh-keysign*
-rwsr-xr-x  root  root          /usr/libexec/pt_chown*
-rws--x--x  vcsa  root          /usr/lib/mc/cons.saver*
-rwx--s--x  root  utmp          /usr/lib/vte/gnome-pty-helper*
-rwsr-xr-x  root  root          /usr/sbin/kppp*
-rwxr-sr-x  root  lock          /usr/sbin/lockdev*
-rwxr-sr-x  root  mail          /usr/sbin/mlock*
-rwxr-sr-x  root  postdrop      /usr/sbin/postdrop*
-rwxr-sr-x  root  postdrop      /usr/sbin/postqueue*
-rws--x--x  root  root          /usr/sbin/userhelper*
-rwsr-xr-x  root  root          /usr/sbin/userisdnctl*
-rwsr-xr-x  root  root          /usr/sbin/usernetctl*
-rwxr-sr-x  root  utmp          /usr/sbin/utempter*

Answered Questions

support only bash as the login shell?

Decision

It was ruled by the Unix Group that we shall support bash in addition to zsh and tcsh.

PAM & Krb5 & AFS & SSH & Screen Locks

The problem:

Possible solutions:

  1. Get our old pam_krb5 going, and build everything (including kerberos and ssh) ourselves, like on SL3. A lot of work, and not the direction we want to take generally.

  2. Use Doug Engert's pam_afs2 module. This is currently implemented. It is a minimally invasive solution since it allows using the pam_krb5 and openssh coming with SL4. Alas, it doesn't solve the screen lock problem.
  3. Try staying close to SL4 and the direction RHEL is taking:

    According to [https://lists.openafs.org/pipermail/openafs-info/2006-April/022127.html this] posting to the OpenAFS mailing list, there was some hope that Red Hats pam_krb5 module should do the job. This turned out to be true, alas only for more recent versions of the module than what comes with SL4. But the latest one from FC5 (2.2.6-2.2) works on SL4 and is easy to rebuild (nothing required except rpmbuild --rebuild ...src.rpm). It comes with new options, to be set in the appdefaults/pam part of krb5.conf:

    • external = sshdBR This enables getting a PAG and an AFS token upon gssapi authentication.

    If called correctly by the application, the module will refresh the credentials, which solves the screen lock problem. To make this work for AFS tokens as well, the following option is required:
    • tokens = sshd loginBR This will limit creation of a new PAG to the listed services. In addition, the tokens flag must not be used in /etc/pam.d/system_auth.

    The pam configuration for xscreensaver can now simply stack system_auth! The only caveat is that the xscreensaver coming with SL4 will use krb5 and not pam. Hence this requires

    rebuilding the package, with a trivial change: replace configure --with-pam with configure --with-pam --without-kerberos in the spec. And in order not to pick up a dependency on /opt/products/bin/perl5 :-( add export PATH=/usr/bin:/usr/X11R6/bin:/bin to the beginning of the %build and %install sections.

    Now unlocking the screen works, but only with xscreensaver. The KDE desktop lock does not call pam the right way. Since it also works different than in the past (when we could patch the string identifying the pam servicename in the executable), this probably will not be supported any longer. We recommend using GNOME anyway. The last remaining problem is then that sshd cannot be used in privsep mode. While the new pam module supports an option

    • use_shmem = sshd

    it only works with recent openssh releases. Rebuilding 4.3p2-4 from FC5 on SL4 requires a few minor changes only. From the spec's changelog:
    -  replaced openssh-selinux.patch by openssh-selinux-sl4 .patch 
       (the one from 3.9p1-8.RHEL4.12) to match lower libselinux version on SL4
    -  downgraded libselinux requirements to >= 1.17.9
    -  disabled AUDIT (requires the new selinux patch - although the differences
       are trivial, saved the effort since we don;t need audit support)
    -  changed build requirement from libX11-devel to xorg-x11-devel 
    -  disabled patch26 (pam-no-stack.patch)
    SELinux support in ssh is probably not needed, hence this could even be done much simpler.

Solution 3 is nearly perfect, moderately expensive to support in the long run, and what things will be like on SL5 anyway. It is also more or less what CERN is doing.

Decision

In the [:UnixMinutes/Protokoll-2006-04-18:Unix meeting 2006-04-18], it was ruled by the majority of participants that solution 1 is the way to go. Andreas will carry out the work since he was the only volunteer. Providing a public preview will have to wait until this is done.

Update

The dignified pam_krb5afs module (build statically against heimdal) works. /etc/pam.d/system-auth is using it. xscreensaver and kdesktop_lock work with adapted pam configuration. The SL_fix_kdesktop_lock rpm was reanimated to make kdesktop_lock use a pam configuration file different to /etc/pam.d/kde (named kde-kss). The pam_afs2 pam module is no longer needed.

roadmap

  1. other priority1 features (sue) (?profiles?)
  2. Milestone: Regular test systems
  3. priority2 features
  4. Milestone: Ready for special purposes
  5. priority3 features
  6. Milestone: public preview

little todos

VAMOS features

Feature

Priority

Remarks

aaru

done

init script should probably runcon -t unconfined_t yum ...

account

ok

cleaned up, only useful on wwwhera system (archive update still required)BRremainders should probably moved to a different feature

afs_client

3

arcd

won't

should not be needed naymore

arcx

5

this is for servers only - client works

automount

done

cfengine

done

conmgr

done

- gpm not turned off (also on SL3) ?!BR - check_console operational (also on SL3?)

dhcp

5

basically ok, but restorecon missing, bug in init script (status)

doocsadm

5

PITZ HOSTS ONLY!!! Keep this off my sane systems. Please.

emacs

won't

trivial package DL_emacs - done

exports

2

done (&trivial) for V3, but V4 ?

group

2

done including support for local files; nscd and vamos variables are messy

hepixdm

4

replaced by gdm

hosts

done

inetd

3

kerberos

done

kernel

done

klogin

ok

nothing to do

ldap (client)

2

ldap (server)

5

links

won't

links should be packaged (partially done)

linux

3

done

localdisks

ok

nothing to do

mail

won't

DL_postfix_nullclient.rpm - done

motd

3

probably trivial

nagios

done

nscd stuff is done

name_srv

5

netgroup

2

nfs

2

NFS3 ok, NFS4 to be done

nsswitch

2

nsswitch.files ok as is?

pam

done

uses pam_krb5afs.so from /opt/products

passwd

2

use local files for everything ?BR - passwd implemented, but needs more test and refinementBR - need nscd restart if it runsBR - group?

passwd_prog

3

/opt/products/bin/java wird gebraucht, dann trivialBRProblem: es wird i.a. kein opt/products/bin/java geben

printing

done

keep opt-products lprng :-(, but let cups installed without configuration

products

done

profiles

won't

most of this should go into profiles and other packages - done

raid

4

mdadm ok, I2O to be done

removable_media

5

nothing to do, it just works

scout

4

security

2

done

sge

5

sound

won't

nothing to do, it just works (maybe turn off except desktops)

ssh

done

sudo

3

sue

done

sue_boot now runs sue.update in the unconfined_t domain on SELinux-enabled systems, this should alleviate most file context problems

sue_links

won't

should be packaged

syslog

done

done for client

tcp_wrapper

2

testcfe

won't

WN: only for testing new stuff or bug verification

tidy_up

done

trusted

ok

trivial

vamos

done

trivial for client

xf86

won't

replaced by kvm

xntp

done

ypclient

ok

no changes needed

zzz

done

needed for sue.run-sched

Traps & Pitfalls

Files in /etc/cron.d

These must have mode 644. Crond does not accept 755.

SELinux and cfengine

the problem

Any files read by daemons covered by the targeted policy must have the correct type. The file /etc/passwd, for example, is read by nscd:

[root@satyr2 ~]# ls -Z /etc/passwd
-rw-r--r--  root     root     system_u:object_r:etc_t          /etc/passwd

Unfortuantely, cfengine is not aware of security contexts. Hence files it modifies may end up with the wrong context, and daemons may no longer be able to access them:

[root@satyr2 ~]# ls -Z /etc/passwd
-rw-r--r--  root     root     system_u:object_r:etc_runtime_t  /etc/passwd

These actions are known to have this problem:

Even more unfortunately, many files (but not all) will still have the right context if a feature is run interactively, or even by cron, since in this case they run in the unconfined_t domain. This may change in the future, but so far the problem only affects features run from /etc/init.d/sue_boot The reason is that then processes run in domain initrc_t, with the result that newly created files may get a different context.

Hence to test the effect of a feature, run sue.update like this:

[root@satyr2 ~]# runcon -t initrc_t /products/sue/etc/sue.update ...

the solution(s)

modify the sue_boot init script

One step is obviously to run sue_boot in a different context, by adding this to /etc/init.d/sue_boot

RUNCON=""
if [ -x /usr/sbin/selinuxenabled ]; then
    /usr/sbin/selinuxenabled && RUNCON="/usr/bin/runcon -t unconfined_t --"
fi

and then changing the sue.update command to this:

$RUNCON /products/sue/etc/sue.update -v 2>&1 | cat

This seems to work the way it does normally (which is less than perfect since all output ends up in the sue update logs even if nothing was done), and it indeed solves most problems. Hence this should probably be implemented.

However, if the default type created in a directory is not the desired one, action must be taken in the features. Example:

use restorecon in features where appropriate

The restorecon command looks up the right file context(s) in /etc/selinux/targeted/contexts/files/file_contexts and sets the context accordingly for all files passed as arguments. It only works if SELinux is available in the kernel and enabled. If it is available but disabled, the command will complete successfully but the contexts will not be changed, hence no point in running it.

These are the ingredients for (cfengine2 only) feature to correct the filetypes:

SELinux and httpd

Bugs in the distribution we need to fix