#acl DvGroup:read,write,revert Known:read,write All:read <> == Overall Status == || automatic installation || works || || automatic maintenance || works || || ssh || using native ssh with gssapi and the time-honoured pam_krb5afs for tokens || || integration / features || mostly done || || user/group environment || mostly done || || application software || mostly done || || batch || works || || grid || UI partially works, no other work done yet || || Xsession environment || works, HEP``iX11 dropped || || desktop || works, including guest accounts || || special desktops || prepared (dual head, autologin for shift accounts,...) || || xdmcp || works, including font service for remote clients || == BUGS == === X Sessions accumulate ssh-agents === * see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134494 * try [[attachment:xinitrc-4.0.14-sshagent.patch|the fix in comment #37]] ? === USB Mouse stops working occasionally? === See RT#187492: Pointer stops working, it helps to start a new X session or replug the mouse. Model is ''ID 046d:c016 Logitech, Inc. M-UV69a Optical Wheel Mouse'' on a precision 370. This exact model works just fine on a test system with the same chipset (925X). Try setting the protocol explicitly again? This problem vanished after a while. The same colleague comlained about hanging X servers later. It may be related to his favorite window manager (windowmaker). === no truly automatic installation if untouched GPT disks are present === Found no way yet to get rid of the dialog asking whether to ignore or reinitalize the disks. Let's hope all systems with > 2 TB block devices have remote console. == TODO List == Besides some missing features and software packages, these are the most pressing items: === general === * set CF_no_root_passwd to true for appropriate defaults * Turn off irqbalance on non-SMP hosts (error during shutdown - no problem, just ugly) === Booting with init=/bin/sh does not work === * probably due to udev? * will it help to add /dev/tty0 to /etc/udev? * alternatively, devise a method for booting rescue systems over the net * PXE and/or GRUB entry === Add at least a few Xresources to make xssh to Sl3 and Solaris less painful === * how to do this best? xinitrc.d? - NO, that's ''after'' ~/.Xresources has been read * => have to modify /etc/X11/Xresources * this should be mostly ok now, but isn't quite perfect; maybe it's good enough. == 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 === * we'll provide the 32bit jpackage packages on both i386 and amd64 (done) * amd64 systems will get the 64bit 1.5 build in /opt/products in addition (done) * 1.4.2 will only be provided (in /opt/products) if there is a physics case for it === Browsers: 32bit Firefox is the only supported one === * on both i386 and amd64, system packages as they come with SL4 (done) * the version coming with SL4 (not necessarily the most recent) * 32bit even on amd64 is the only way to provide the most important plugins: * flash: using the "official" RPM (done, + DL_flash_plugin to avoid the license dialog) * java: using the plugin RPM from jpackage (see above) (done) === Mail Client: pine recommended, Thunderbird provided as is === * we provide the pine package coming with SL * + DL_pine and DL_sslcerts (done) * thunderbird is provided ''as is'' without support, '''''not''''' recommended === Openoffice: 2.0.x system packages from openoffice.org === * 1.1.2 coming with SL4 is just too old * only available as 32bit, who cares * redhat desktop integration ok * printing integration through printcap -> psprint.conf converter (student work) * done by Bernd, checks/rollout pending === /opt/products: General Points === SL4 is very young and not even mature, yet all of these have already been violated: * '''compat.def should ''not'' be used'''. It's empty now. Leave it that way. * When (re)building a package, * try building against the system libs * never ever rebuild against obsolete libs in /opt/products * When committing packages to the repository: * '''''please'' create a volume for your software''' * '''Only install what's needed.''' * If it's for a few hosts or a single server only, don't dump it into base.cf. * Think before installing -default packages. * If a default package is necessary, check for minimal content. * if it comes with dependencies on outdated libs in /opt/products, rebuild it * '''The internal dependency generator can ''not'' be used''' * use the '''fixed find-requires''' * should finally work well with buildroot, and without the need to set a link for it * then turn '''Auto``Prov off''' * For packages essentially bringing a complete Linux with them (oracle, maple, mathematica,..) turn both Auto``Req and Auto``Prov off. == Table of Missing Software == || intel compiler || || || pgi compiler || || || plan || SuSE only, holiday bug, ... => drop? || || 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 || || hwinfo || no longer necessary for csinfo || == open questions == === change /etc/mailcap ? === * ggv -> acroread for pdf? * ggv is much faster but printing does not work well? * ooo -> antiword for .doc? * not trivial since changes inserted by OOo packages themselves * /usr/bin/antiword in dag package has no x-bit === Do we have to provide backward compatible C++ Software ? === * applies to root, geant4, clhep, & probably more * we're not forcing anyone to migrate to SL4 anytime soon * but to be honest, we'll update the farm eventually * proposal: one common version for each package * one that is current at the time of SL4 being ready * to be provided as name-''version''_gcc3 * NB gcc 2.95.3 and root-3.05.07_gcc2 would still work * but don't roll out if not required... === SELinux and preserved Partitions: Relabel /usr1? === * /usr1/tmp (the directory and the link) get the right label in %post, but no files in there are touched * /usr1/scratch? === 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. * but is it completely stable? * is there a performance penalty (servers, farmnodes)? === 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 == === is DL_cron_sigpipe still needed? === Yes :-( === Really stay with UTF8? === It's a nuisance. Printing, xterm, pine, ... are all unsolved problems. On the other hand, SL4 works much better under LANG=C or en_US that SL3 did. Examples: * `man` will warn about 8-bit ascii characters, but no longer abort * no need to fiddle with man.config as on SL3 * `less` works with files containing 8-bit ascii * no need to replace it with the SuSE version as on SL3 ==== Decision: No ==== As decided in the [[UnixMinutes/Protokoll-2006-06-03|Unix meeting 2006-06-03]], we set the default to '''en_US''' and document for users how to change this. As of 2006-06-03, the linux feature changes `/etc/sysconfig/i18n` according to the setting of VAMOS variable `CF_LANG`, which is set to `en_US` on sl4-def. === support only bash as the login shell? === * zsh has UTF-8 issues * can we stop supporting tcsh as a login shell? * much effort especially since we have to change the profiles * not recommended anyway * mapping of users' shells in local /etc/passwd is implemented ==== Decision: No ==== It was ruled by the Unix Group that we shall support zsh and tcsh, and bash only for root. === 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. Update 2007-06-30: We're obviously not going to do it. === how to deal with shells hanging upon logout? === Both zsh and tcsh can cause problems when the AFS token is already gone before they try to write the history file. Possible solutions: 1. CERN has patches in SLC3 (not in SLC4). The zsh patch was tested successfully against the zsh from SL4, tcsh remains to be seen but most likely works. This just means we have to rebuild them whenever they're updated upstream. 2. Modifying pam so that the token is not destroyed upon logout, just the krb tickets. This is what we do on SL3. Update 2007-06-30: patched builds of zsh and tcsh were rolled out 2007-06-19. === PAM & Krb5 & AFS & SSH & Screen Locks === ==== The problem: ==== * The pam_krb5 coming with SL4 won't create AFS tokens from forwarded Kerberos5 tickets. * It also cannot handle refreshing credentials when unlocking the screen. * Our pam_krb5-1.3_rc7 from sourceforge hasn't seen any development in three years. And it segfaults on SL4. ==== 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 = sshd`<
> 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 login`<
> 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: Use our own build of pam_krb5afs, as in the past ==== 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. === replace NIS/LDAP with local files? === Why not finally rid ourselves of all NIS/LDAP/nsswicth(compat...) problems? Simply create /etc/passwd & /etc/group from a distributed master file (taking into account who gets a shell on the system). This was impemented by Waltraut and Felix, including mapping of shells (if wanted), and works very well. It's the default now. Using LDAP and/or NIS is still possible (CF_NSSWITCH). === if yes: how to handle nscd? === Since it makes lots of trouble, isn't needed for passwd and group anymore, all our local hosts are in /etc/hosts, we disable it completely for now. It could be enabled for DNS lookups if necessary (CF_nscd). == VAMOS features == || Feature || Priority || Remarks || || aaru || done || init script now does runcon -t unconfined_t yum ...|| || account || ok || cleaned up, only useful on wwwhera system (archive update still required)<
>remainders should probably moved to a different feature || || afs_client || 3 || || || afs_server || ok || nothing to do || || 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) ?!<
> - check_console operational (also on SL3?)|| || dhcp || 5 || ok, failover not tested but should work|| || 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 || || 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 (mostly 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? || || osm || 3 || dcache client ok, others unknown || || pam || done || uses pam_krb5afs.so from /opt/products || || passwd || 2 || done including support for local files || || passwd_prog || 3 || /opt/products/java/1.4.x wird zur Zeit gebraucht || || 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 but still bugs || || raid || 4 || mdadm ok, I2O no-go on SL4 || || removable_media || 5 || nothing to do, it just works || || scout || 4 || done || || security || 2 || done || || sge || 5 || actually nothing to do... || || 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 || packaged in SLZ_links-sue || || 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: * editfiles * copy * link 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: * `/etc/dhcpd.conf` should be ''dhcp_etc_t'', not ''etc_t'' * even if in this case dhcpd is still allowed to read the file, this may change eventually * and the file is not protected from other daemons allowed to read files of type ''etc_t'' but have no business with dhcp ===== 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: {{{ control: actionsequence = ( shellcommands.PASS1 copy editfiles shellcommands.PASS2 ) AddInstallable = ( RESTORECON ) }}} It will often be necessary to introduce several ''shellcomands'' passes, since restorecon should obviously run ''after'' the files are modified, but ''before'' any daemons that need them are (re)started. {{{ groups: HAS_SEL = ( FileExists(/usr/sbin/selinuxenabled) ) HAS_SEL:: SELINUX = ( ReturnsZero(/usr/sbin/selinuxenabled) ) }}} This should work silently and with minimal overhead on any system. If the SELINUX class is set, `restorecon` should work. {{{ editfiles: { /some/file.1 ... DefineClasses "RESTORECON" } copy: /repository/some/file.2 dest=/some/file.2 type=checksum define=RESTORECON links: CLASS1:: /some/file ->! ./some/file.1 type=relative define=RESTORECON CLASS2:: /some/file ->! ./some/file.2 type=relative define=RESTORECON }}} Here we make sure the RESTORECON class gets set if there is something to do for `restorecon`. At least in some cases, this only works if `RESTORECON` is declared `AddInstallable`, as shown above. {{{ shellcommands: PASS1:: "/some/other command ..." PASS2:: "/sbin/restorecon /some/file /some/file.1 /some/file.2" }}} One could do this more fine grained, but it's probably not worth it. === SELinux and httpd === * '''local files''' Must be of type `httpd_sys_content_t`. The sync-a.pl script now does this with chcon. To work on a whole tree: {{{ chcon -R -h -t httpd_sys_content_t /some/tree }}} The -h switch is important if symlinks should be usable through http. Notice the root directory of new filesystems is unlabelled, and chcon will refuse to apply a partial context to it. Hence, after mounting a new filesystem, run something like this: {{{ chcon system_u:object_r:file_t /new/mounted/filesystem }}} * '''AFS''' By default, httpd is not allowed to read files in AFS. It takes two steps to make this work (and, of course, appropriate httpd configuration in /etc/httpd/conf.d/): 1.#1 Enable the SELinux booleans ''httpd_enable_homedirs'' and ''use_nfs_home_dirs''. This allows httpd to read files of type nfs_t. The latest policy (requires selinux-policy-targeted-1.17.30-2.120 or later) applies a genfs context of nfs_t to anything below /afs. It is easiest to do this with system-config-securitylevel. 1.#2 Modify the policy. After step 1 and with an unmodified policy, it ''almost'' works. But access is really slow, and the logs fill with messages {{{ avc: denied { write } for pid=3980 comm="httpd" lport=7001 scontext=root:system_r:httpd_t tcontext=root:system_r:initrc_t tclass=udp_socket }}} Using the audit2allow utility, the following rule was generated: {{{ # allow AFS callbacks triggered by httpd: # This is much too generous, but I haven't found out yet how to limit this to # port 7001. Anyway, it's better than running httpd in unconfined_t. allow httpd_t initrc_t:udp_socket write; # needed if afs is ever restarted: allow httpd_t unconfined_t:udp_socket write; }}} To get this into a binary policy and load it: * install the `selinux-policy-targeted-sources` rpm * save the rule above in the file `/etc/selinux/targeted/src/policy/domains/local.te` * `make -C /etc/selinux/targeted/src/policy load` || Afterwards, updating the policy rpm will no longer load the new policy.<
><
> To get the new policy with our change, install the new selinux-policy-targeted-sources and rerun the ''make load'' step. This happens automatically during an update of selinux-policy-targeted-sources.<
><
>Do '''''not''''' play with the policy on production systems. Never install the policy sources on a production system unless you have to modify the binary policy on it ''and'' know what you're doing.|| == Bugs in the distribution we need to fix (currently none) == == Resolved Issues == * SL 4.2: `service dhcpd status` buggy, always returns 0 * bug is present in many other init scripts as well * should be fixed with ~TUTILS/chkservice changes as of 2006-05-25 * microcode_ctl fails, as the device is missing. * 2006-04-13 sw: fixed in SL 4.3