forked from Controls/gitea-pages
remove long outdated legacy documentation
This commit is contained in:
@@ -23,4 +23,3 @@ Contents:
|
||||
third-party
|
||||
troubleshooting
|
||||
more
|
||||
legacy
|
||||
|
||||
@@ -1,20 +0,0 @@
|
||||
================
|
||||
Legacy Systems
|
||||
================
|
||||
|
||||
This section describes the PSI legacy Linux environment, ie. those systems
|
||||
running Scientific Linux 6 and earlier. Unlike the rest of the admin guide, this
|
||||
section is mostly a plain import of existing snippets of documentation, which
|
||||
were created in a variety of formats.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
legacy/communication
|
||||
legacy/installation
|
||||
legacy/misc
|
||||
legacy/monitoring
|
||||
legacy/puppet
|
||||
legacy/services
|
||||
legacy/software
|
||||
legacy/storage
|
||||
@@ -1,37 +0,0 @@
|
||||
Miscellaneous
|
||||
=============
|
||||
|
||||
This section contains (potentially out-of-date or obsolete) documents
|
||||
from the wiki, various places on AFS, etc. Most of them should be
|
||||
integrated in the other sections properly, the rest removed.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
misc/afstowindowsloginchangeinsl4andsl5
|
||||
misc/configureldaponpsipuppet3
|
||||
misc/createanewkickstartinstallationforfedora10
|
||||
misc/disklessclientsl60
|
||||
misc/dkmsbasics
|
||||
misc/firefoxpreferenceshowto
|
||||
misc/howtoeditinstallimg
|
||||
misc/howto-start-vncserver
|
||||
misc/kernelmodulee1000eupdateforsl5.1
|
||||
misc/linuxhowtolookupforpcidevicesandcorrespondingmodulesinsl5
|
||||
misc/linuxhowto-rpm-updatepsi-desktoppackageonsl5
|
||||
misc/linuxhowto-sl5-nvidiadriverinstallationupdate
|
||||
misc/linuxloginclusters
|
||||
misc/loadbalancerllclb1
|
||||
misc/nxserverclientinstallation
|
||||
misc/prepareanewslrelease
|
||||
misc/projectpsi-puppet1
|
||||
misc/psi-puppet2_installation
|
||||
misc/puppetmanifestsforsl53
|
||||
misc/puppetmasteratpsi
|
||||
misc/puppet-trouble-shooting-in-twiki
|
||||
misc/release_snapshotssl53
|
||||
misc/repairrpmdb
|
||||
misc/sap_client_for_linux_howto
|
||||
misc/updatesl57
|
||||
misc/updateslmaindoc
|
||||
misc/vpnclientlinux
|
||||
@@ -1,199 +0,0 @@
|
||||
AFS to Windows-Login Change
|
||||
===========================
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
http://ait.web.psi.ch/services/linux/news/unified_login1.html
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
In the night from August 2 to 3 2009 the AFS authentication service
|
||||
will be changed to the Windows authentication service on Green SL4 and
|
||||
SL5 PCs.
|
||||
|
||||
This document describes the changes that have to be made in our
|
||||
cfengine and puppet environments to facilitate the PSI wide automatic
|
||||
reconfiguration of the Kerberos 5 authentication service on Green SL4
|
||||
and SL5 systems.
|
||||
|
||||
This automatic reconfiguration requires cfengine running on SL4 and
|
||||
puppet running on SL5 hosts respectively.
|
||||
|
||||
Note: For technical reasons SL3 systems can not use the Windows
|
||||
authentication service.
|
||||
|
||||
Basically, the following two steps have to be performed:
|
||||
|
||||
- Replace the current `krb5.conf` for the AFS authentication service by
|
||||
the new `krb5.conf` for the Windows authentication service.
|
||||
|
||||
- Distribute the `krenew.sh` script, which periodically renews an
|
||||
existing renewable ticket. It starts running when the user logs in
|
||||
to its graphical desktop.
|
||||
|
||||
|
||||
For additional information see the reference.
|
||||
|
||||
Files
|
||||
-----
|
||||
|
||||
`/etc/krb5.conf` for the Windows authentication server for SL4 and
|
||||
SL5::
|
||||
|
||||
[libdefaults]
|
||||
default_realm = D.PSI.CH
|
||||
ticket_lifetime = 25h
|
||||
dns_lookup_realm = false
|
||||
dns_lookup_kdc = false
|
||||
udp_preference_limit = 10
|
||||
renew_lifetime = 30d
|
||||
forwardable = true
|
||||
|
||||
[realms]
|
||||
PSI.CH = {
|
||||
kdc = afs00.psi.ch:88 afs01.psi.ch:88 afs02.psi.ch:88
|
||||
admin_server = afs00.psi.ch:749
|
||||
kpasswd_server = afs00.psi.ch:464
|
||||
default_domain = psi.ch
|
||||
}
|
||||
D.PSI.CH = {
|
||||
kdc = d.psi.ch.
|
||||
kpasswd_server = d.psi.ch.
|
||||
default_domain = psi.ch
|
||||
}
|
||||
[domain_realm]
|
||||
.psi.ch = D.PSI.CH
|
||||
|
||||
|
||||
To automatically renew a Kerberos v5 ticket during an X session the
|
||||
krenew command will be started when logging in to X. It is executed by
|
||||
the script `krenew.sh`, which is placed into
|
||||
`/etc/X11/xinit/xinitrc.d/`.
|
||||
|
||||
`/etc/X11/xinit/xinitrc.d/krenew.sh` for SL4 and SL5::
|
||||
|
||||
#!/bin/bash
|
||||
|
||||
/usr/bin/krenew -b -K 60 -t
|
||||
|
||||
|
||||
Procedure
|
||||
---------
|
||||
|
||||
SL4
|
||||
~~~
|
||||
|
||||
Replace `krb5.conf` File by Cfengine
|
||||
....................................
|
||||
|
||||
The replacement of the `krb5.conf` is done by cfengine
|
||||
on Green SL4 systems.
|
||||
|
||||
The current `krb5.conf` source files::
|
||||
|
||||
/afs/psi.ch/service/linux/cfengine/masterfiles/distTesting/scientific/46/etc/krb5.conf
|
||||
|
||||
and::
|
||||
|
||||
/afs/psi.ch/service/linux/cfengine/masterfiles/dist/scientific/46/etc/krb5.conf
|
||||
|
||||
have to be replaced by the `krb5.conf` file for the Windows
|
||||
authentication server.
|
||||
|
||||
|
||||
Distribute `krenew.sh` By Cfengine
|
||||
..................................
|
||||
|
||||
Copy `krenew.sh` to::
|
||||
|
||||
/afs/psi.ch/service/linux/cfengine/masterfiles/distTesting/scientific/46/etc/
|
||||
|
||||
and::
|
||||
|
||||
/afs/psi.ch/service/linux/cfengine/masterfiles/dist/scientific/46/etc/
|
||||
|
||||
|
||||
Configure cfengine to distribute them by adding the following entry to::
|
||||
|
||||
/afs/psi.ch/service/linux/cfengine/masterfiles/inputsTesting/scientific/46/cf.linux.AFS
|
||||
|
||||
and::
|
||||
|
||||
/afs/psi.ch/service/linux/cfengine/masterfiles/inputs/scientific/46/cf.linux.AFS
|
||||
|
||||
|
||||
The entry::
|
||||
|
||||
linux.scientific::
|
||||
$(MASTERDIR)/$(DISTDIR)/$(DIST)/$(RELEASE)/etc/krenew.sh
|
||||
owner=root group=root
|
||||
mode=0755
|
||||
dest=/etc/X11/xinit/xinitrc.d/krenew.sh
|
||||
type=sum # makes a MD5 checksum
|
||||
server=$(MASTERHOST)
|
||||
backup=true
|
||||
syslog=true
|
||||
|
||||
|
||||
SL5
|
||||
---
|
||||
|
||||
Replace `krb5.conf` File by Puppet
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The replacement of the `krb5.conf` is done by puppet on Green SL5
|
||||
systems.
|
||||
|
||||
The corresponding `krb5.conf` source file::
|
||||
|
||||
/afs/psi.ch/software/linux/dist/scientific/51/puppet/files/afs/etc/krb5.conf
|
||||
|
||||
has to be replaced by the `krb5.conf` file for the Windows
|
||||
authentication server.
|
||||
|
||||
Distribute `krenew.sh` By Puppet
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Copy `krenew.sh` to the following puppet directory::
|
||||
|
||||
/afs/psi.ch/software/linux/dist/scientific/51/puppet/files/afs/etc/
|
||||
|
||||
Now edit the puppet manifest `psi_afs.pp` in both environments,
|
||||
production development. Add `krenew.sh` to the file resource type as
|
||||
shown below.
|
||||
|
||||
`/afs/psi.ch/service/linux/puppet/etc/puppet/development/manifests/psi_defaults/psi_afs.pp`,
|
||||
|
||||
`/afs/psi.ch/service/linux/puppet/etc/puppet/production/manifests/psi_defaults/psi_afs.pp`::
|
||||
|
||||
# psi_afs.pp
|
||||
#
|
||||
# Link to PSI pam files
|
||||
# Default PAM configuration for PSI systems
|
||||
#
|
||||
|
||||
|
||||
class psi_afs {
|
||||
|
||||
file {
|
||||
"/etc/krb5.conf":
|
||||
owner => "root",
|
||||
group => "root",
|
||||
source => [
|
||||
"puppet://$servername/$psi_release/afs/etc/krb5.conf.$hostname",
|
||||
"puppet://$servername/$psi_release/afs/etc/krb5.conf"
|
||||
];
|
||||
|
||||
"/etc/X11/xinit/xinitrc.d/krenew.sh":
|
||||
owner => "root",
|
||||
group => "root",
|
||||
mode => "755",
|
||||
source => [
|
||||
"puppet:///$psi_release/afs/etc/krenew.sh.$hostname",
|
||||
"puppet:///$psi_release/afs/etc/krenew.sh"
|
||||
];
|
||||
}
|
||||
|
||||
}
|
||||
@@ -1,110 +0,0 @@
|
||||
Configure LDAP on `psi-puppet3`
|
||||
===============================
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
- https://intranet.psi.ch/AIT/LdapActiveDirectoryIntegrationPSI
|
||||
|
||||
- http://linux.web.cern.ch/linux/docs/account-mgmt.shtml
|
||||
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
This document describes the configuration of LDAP to access user account
|
||||
information on an SL6 system.
|
||||
|
||||
Requirements
|
||||
------------
|
||||
|
||||
RPMS:
|
||||
|
||||
- nss-pam-ldapd
|
||||
|
||||
Procedure
|
||||
---------
|
||||
|
||||
Configure `/etc/nsswitch.conf`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The `/etc/nsswitch.conf` configuration file describes the order in
|
||||
which password-file lookups are performed. To make sure that local
|
||||
accounts take precedence over LDAP accounts, it should have these
|
||||
entries::
|
||||
|
||||
passwd: files ldap
|
||||
shadow: files
|
||||
group: files ldap
|
||||
|
||||
|
||||
Configuring `/etc/nslcd.conf`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The `/etc/nslcd.conf` configuration file is used to set system-wide
|
||||
defaults to be applied when running ldap clients. This mechanism is
|
||||
available on SLP6.
|
||||
|
||||
This section describes the options that are relevant to configure
|
||||
account lookups in the d.psi.ch LDAP service. An example configure
|
||||
file containing the options described below is shown here. Please edit
|
||||
it to suit your needs - in particular the `filter passwd` entry!::
|
||||
|
||||
|
||||
# the ldaps uri enforces SSL
|
||||
uri ldaps://d.psi.ch:636
|
||||
base ou=PSI,dc=d,dc=psi,dc=ch
|
||||
binddn CN=linux_ldap,OU=Services,OU=IT,DC=d,DC=psi,DC=ch
|
||||
bindpw *NOT SHOWN*
|
||||
|
||||
# ldap base definitions for each nameservice
|
||||
base passwd ou=Users,ou=PSI,dc=d,dc=psi,dc=ch
|
||||
base group ou=Groups,ou=PSI,dc=d,dc=psi,dc=ch
|
||||
|
||||
|
||||
filter passwd (&(objectClass=user)(!(objectClass=computer))(msSFU30UidNumber=*)(msSFU30HomeDirectory=*))
|
||||
map passwd uid cn
|
||||
map passwd uidNumber msSFU30UidNumber
|
||||
map passwd gidNumber msSFU30GidNumber
|
||||
map passwd loginShell msSFU30LoginShell
|
||||
map passwd gecos displayName
|
||||
# do not resolve the unneeded userPassword
|
||||
#map passwd userPassword msSFU30Password
|
||||
|
||||
map passwd homeDirectory msSFU30HomeDirectory
|
||||
# for our clusters' special environments we may want to use an expression
|
||||
# #map passwd homeDirectory "/home/${sAMAccountName}"
|
||||
|
||||
filter group (&(objectClass=Group)(msSFU30Name=*))
|
||||
map group uniqueMember member
|
||||
map group gidNumber msSFU30GidNumber
|
||||
|
||||
timelimit 30
|
||||
|
||||
# we may want to use this to reduce standing connections to the LDAP server
|
||||
idle_timelimit 300
|
||||
|
||||
# require that server's certificate is tested. The standard installed CA bundle includes
|
||||
# the necessary Root CA cert from QuoVadis
|
||||
tls_reqcert hard
|
||||
tls_cacertfile /etc/ssl/certs/ca-bundle.crt
|
||||
|
||||
# request paged results from the LDAP server
|
||||
pagesize 1000
|
||||
|
||||
referrals off
|
||||
|
||||
|
||||
Please make sure that the `nss-pam-ldapd` RPM is installed on your
|
||||
client machine. Run `yum install nss-pam-ldapd` if this RPM is not
|
||||
installed.
|
||||
|
||||
Then, make sure that the `nslcd` runs, and gets started at boot time::
|
||||
|
||||
/sbin/service nslcd restart
|
||||
/sbin/chkconfig --level 345 nslcd on
|
||||
|
||||
|
||||
Note: the `nslcd` service must be restarted after changes to the
|
||||
`/etc/nslcd.conf` have been made! For more information, run `man
|
||||
nslcd.conf` and/or `man nslcd`.
|
||||
@@ -1,119 +0,0 @@
|
||||
Create a new Kickstart Installation (for Fedora 10)
|
||||
===================================================
|
||||
|
||||
This document describes the setup of a new kickstart installation at
|
||||
PSI taking Fedora10 as an example.
|
||||
|
||||
|
||||
Introduction
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Some NICs include the ability to boot using a Pre-Execution
|
||||
Environment (PXE). It works by sending out a broadcast request for a
|
||||
DHCP server on the network. If the DHCP server is configured to send
|
||||
the client the IP address or hostname of a tftp server and the
|
||||
location on that tftp server of the files needed to start the Linux
|
||||
installation, the client can start a network installation without
|
||||
having to boot from local media such as a CD.
|
||||
|
||||
This method can also be used with kickstart to perform an automated
|
||||
network installation.
|
||||
|
||||
To perform a network installation using PXE boot, use the following
|
||||
steps:
|
||||
|
||||
- Create an installation tree for the network install and make it
|
||||
available to the systems being installed.
|
||||
|
||||
- Configure the tftp server.
|
||||
|
||||
- Configure the DHCP server.
|
||||
|
||||
- Boot the system to start the installation.
|
||||
|
||||
|
||||
Procedure
|
||||
~~~~~~~~~
|
||||
|
||||
Preparation of the PXE Boot Installation
|
||||
........................................
|
||||
|
||||
Go to the `tftp` top directory::
|
||||
|
||||
# cd /afs/psi.ch/service/linux/tftpboot/
|
||||
# cd pxelinux.cfg/
|
||||
# cp -a default.testing{,-20081211}
|
||||
|
||||
Now edit the file `default.testing`. Add a new entry for Fedora10.
|
||||
|
||||
# vi default.testing
|
||||
|
||||
# cd ..
|
||||
# mkdir -p fedora/10
|
||||
# cd fedora/10
|
||||
# mkdir i386 x86_64
|
||||
# cd i386/
|
||||
# pwd
|
||||
/afs/psi.ch/service/linux/tftpboot/fedora/10/i386/
|
||||
# wget ftp://sunsite.cnlab-switch.ch/mirror/fedora/linux/releases/10/Fedora/i386/os/isolinux/vmlinuz
|
||||
# wget ftp://sunsite.cnlab-switch.ch/mirror/fedora/linux/releases/10/Fedora/i386/os/isolinux/initrd.img
|
||||
|
||||
|
||||
After having performed a first test installation, the kickstart file
|
||||
`testhost:/root/anaconda-ks.cfg` based on that installation was
|
||||
written. This kickstart file was copied to
|
||||
`/afs/psi.ch/software/linux/kickstart/configs/fedora10-ks.cfg`. Then
|
||||
`fedora10-ks.cfg` was edited.
|
||||
|
||||
`File: fedora10-ks.cfg Version 1`
|
||||
|
||||
- Note:
|
||||
|
||||
For testing the kickstart installations the root password is given,
|
||||
see line starting with `rootpw`. In the final version it will be
|
||||
removed::
|
||||
|
||||
|
||||
##################################
|
||||
# fedora10-ks.cfg 32-bit
|
||||
##################################
|
||||
|
||||
install
|
||||
url --url=ftp://sunsite.cnlab-switch.ch/mirror/fedora/linux/releases/10/Fedora/i386/os
|
||||
lang en_US.UTF-8
|
||||
|
||||
network --device eth0 --bootproto dhcp
|
||||
rootpw --iscrypted $6$dzHkd6Tb5OuEd92w$1mFgHdoRA9JnIeTz7lq8tvh8Gu1DJPWQyV7LyLGGTEE27ORgF6rYLPDc5nRZRMzoX8Zpasg5UFy4T7jOYyWa50
|
||||
authconfig --enableshadow --passalgo=sha512
|
||||
selinux --disabled
|
||||
timezone --utc Europe/Zurich
|
||||
bootloader --location=mbr
|
||||
|
||||
### PARTITION
|
||||
# The following is the partition information you requested
|
||||
# Note that any partitions you deleted are not expressed
|
||||
# here so unless you clear all partitions first, this is
|
||||
# not guaranteed to work
|
||||
#part /boot --fstype ext3 --size=100 --asprimary
|
||||
#part swap --size=500 --asprimary
|
||||
#part / --fstype ext3 --size=200 --grow --asprimary
|
||||
|
||||
%packages
|
||||
@admin-tools
|
||||
@base
|
||||
@core
|
||||
@editors
|
||||
@hardware-support
|
||||
@text-internet
|
||||
|
||||
%end
|
||||
|
||||
|
||||
Kickstart Pre Installation Scripts:
|
||||
|
||||
- /afs/psi.ch/software/linux/dist/scientific/5/kickstart/pre
|
||||
- /afs/psi.ch/software/linux/dist/scientific/5/kickstart/pre/set_partition
|
||||
- /afs/psi.ch/software/linux/dist/scientific/5/kickstart/pre/pre_custom
|
||||
- /afs/psi.ch/software/linux/dist/scientific/5/kickstart/pre/ask_ip
|
||||
- /afs/psi.ch/software/linux/dist/scientific/5/kickstart/pre/pre_custom
|
||||
- /afs/psi.ch/software/linux/dist/scientific/5/kickstart/pre/ask_ipaddr
|
||||
@@ -1,54 +0,0 @@
|
||||
Diskless Client SL60
|
||||
====================
|
||||
|
||||
Procedure
|
||||
---------
|
||||
|
||||
Select the kernel that diskless clients should use
|
||||
(vmlinuz-kernel-version) and copy it to the tftp boot directory::
|
||||
|
||||
# cp /boot/vmlinuz-2.6.32-220.4.1.el6.i686 /afs/psi.ch/service/linux/tftpboot/dl/sl60/i386/
|
||||
|
||||
|
||||
Create the initrd (i.e. initramfs-kernel-version.img) with network support::
|
||||
|
||||
# yum install dracut-network
|
||||
# dracut initramfs-dl-2.6.32-220.4.1.el6.i686.img 2.6.32-220.4.1.el6.i686
|
||||
|
||||
|
||||
Copy the resulting initramfs-kernel-version.img into the tftp boot directory as well::
|
||||
|
||||
# cp /tmp/initramfs-dl-2.6.32-220.4.1.el6.i686.img /afs/psi.ch/service/linux/tftpboot/dl/sl60/i386/
|
||||
|
||||
Edit the default boot configuration to use the initrd and kernel
|
||||
inside `/var/lib/tftpboot`. This configuration should instruct the
|
||||
diskless client's root to mount the exported file system
|
||||
(`/exported/root/directory`) as read-write. To do this, configure
|
||||
`/var/lib/tftpboot/pxelinux.cfg/default` with the following::
|
||||
|
||||
label sl6dl
|
||||
kernel dl/sl60/i386/vmlinuz-2.6.32-220.4.1.el6.i686
|
||||
append initrd=dl/sl60/i386/initramfs-dl-2.6.32-220.4.1.el6.i686.img root=nfs4:129.129.190.91:/dl/sl60/i386/base rw
|
||||
|
||||
|
||||
Replace server-ip with the IP address of the host machine on which the
|
||||
tftp and DHCP services reside. The NFS share is now ready for
|
||||
exporting to diskless clients. These clients can boot over the network
|
||||
via PXE.
|
||||
|
||||
From the manual::
|
||||
|
||||
22.3. Configuring an Exported File System for Diskless Clients
|
||||
The root directory of the exported file system (used by diskless clients in the network) is shared via NFS. Configure the NFS service to export the root directory by adding it to /etc/exports. For instructions on how to do so, refer to Section 12.7.1, “ The /etc/exports Configuration File”.
|
||||
To accommodate completely diskless clients, the root directory should contain a complete Red Hat Enterprise Linux installation. You can synchronize this with a running system via rsync, as in:
|
||||
# rsync -a -e ssh --exclude='/proc/*' --exclude='/sys/*' hostname.com:/ /exported/root/directory
|
||||
Replace hostname.com with the hostname of the running system with which to synchronize via rsync. The /exported/root/directory is the path to the exported file system.
|
||||
Alternatively, you can also use yum with the --installroot option to install Red Hat Enterprise Linux to a specific location. For example:
|
||||
yum groupinstall Base --installroot=/exported/root/directory
|
||||
The file system to be exported still needs to be configured further before it can be used by diskless clients. To do this, perform the following procedure:
|
||||
Procedure 22.2. Configure file system
|
||||
Configure the exported file system's /etc/fstab to contain (at least) the following configuration:
|
||||
none /tmp tmpfs defaults 0 0
|
||||
tmpfs /dev/shm tmpfs defaults 0 0
|
||||
sysfs /sys sysfs defaults 0 0
|
||||
proc /proc proc defaults 0 0
|
||||
@@ -1,396 +0,0 @@
|
||||
Dynamic Kernel Module Support (DKMS) Basics
|
||||
===========================================
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
G. Lerhaupt, Linuxjournal (www.linuxjournal.com/), September 1st, 2003.
|
||||
|
||||
|
||||
Introduction To DKMS
|
||||
--------------------
|
||||
|
||||
Source is a wonderful thing. Merged module source in the kernel tree
|
||||
is even better. Most of all, support for that source is what really
|
||||
counts. In today's explosion of Linux in the enterprise, the ability
|
||||
to pick up the phone and find help is critical. More than ever,
|
||||
corporations are driving Linux development and requirements. Often,
|
||||
this meets with skepticism and a bit of anxiety by the community, but
|
||||
if done correctly, the benefits are seen and felt by everyone.
|
||||
|
||||
The dynamic kernel module support (DKMS) framework should be viewed as
|
||||
a prime example of this. DKMS, a system designed to help Dell Computer
|
||||
Corporation distribute fixes to its customers in a controlled fashion,
|
||||
also speeds driver development, testing and validation for the entire
|
||||
community.
|
||||
|
||||
The DKMS framework is basically a duplicate tree outside of the kernel
|
||||
tree that holds module source and compiled module binaries. This
|
||||
duplication allows for a decoupling of modules from the kernel, which,
|
||||
for Linux solution and deployment providers, is a powerful tool. The
|
||||
power comes from permitting driver drops onto existing kernels in an
|
||||
orderly and supportable manner. In turn, this frees both providers and
|
||||
their customers from being bound by kernel drops to fix their issues.
|
||||
Instead, when a driver fix has been released, DKMS serves as a stopgap
|
||||
to distribute the fix until the code can be merged back into the
|
||||
kernel.
|
||||
|
||||
Staying with the customer angle for a bit longer, DKMS offers other
|
||||
advantages. The business of compiling from source, installing or
|
||||
fidgeting with rebuildable source RPMs has never been for the
|
||||
faint-of-heart. The reality is that more Linux users are coming in
|
||||
with less experience, necessitating simpler solutions. DKMS bridges
|
||||
these issues by creating one executable that can be called to build,
|
||||
install or uninstall modules. Further, using its match feature,
|
||||
configuring modules on new kernels could not be easier, as the modules
|
||||
to install can be based solely on the configuration of some kernel
|
||||
previously running. In production environments, this is an immense
|
||||
step forward as IT managers no longer have to choose between some
|
||||
predefined solution stack or the security enhancements of a newer
|
||||
kernel.
|
||||
|
||||
DKMS also has much to offer developers and veteran Linux users. The
|
||||
aforementioned idea of the decoupling of modules from the kernel
|
||||
through duplication (not complete separation) creates a viable test
|
||||
bed for driver development. Rather than having to push fixes into
|
||||
successive kernels, these fixes can be distributed and tested on the
|
||||
spot and on a large scale. This speedup in testing translates to an
|
||||
overall improvement in the speed of general development. By removing
|
||||
kernel releases as a blocking mechanism to widespread module code
|
||||
distribution, the result is better tested code that later can be
|
||||
pushed back into the kernel at a more rapid pace—a win for both
|
||||
developers and users.
|
||||
|
||||
DKMS also makes developers' lives easier by simplifying the delivery
|
||||
process associated with kernel-dependent software. In the past, for
|
||||
example, Dell's main method for delivering modules was RPMs containing
|
||||
kernel-specific precompiled modules. As kernel errata emerged, we
|
||||
often were taken through the monotonous and unending process of
|
||||
recompiling binaries for these new kernels—a situation that no
|
||||
developer wants to be in. However, Dell still favored this delivery
|
||||
mechanism because it minimized the amount of work and/or knowledge
|
||||
customers needed to have to install modules. With DKMS, we can meet
|
||||
these usability requirements and significantly decrease our workload
|
||||
from the development standpoint. DKMS requires module source code to
|
||||
be located only on the user's system. The DKMS executable takes care
|
||||
of building and installing the module for any kernel users may have on
|
||||
their systems, eliminating the kernel catch-up game.
|
||||
|
||||
|
||||
Using DKMS
|
||||
----------
|
||||
|
||||
With all of this up-front hype about DKMS, perhaps it might be best to
|
||||
settle into the particulars of actually how the software is used.
|
||||
|
||||
- Using DKMS for a module requires that the module source be located
|
||||
on the user's system and that it be located in the directory
|
||||
`/usr/src/(module))-((module-version))/`.
|
||||
|
||||
- A `dkms.conf` file must exist with the appropriately formatted
|
||||
directives within this configuration file to tell DKMS such things
|
||||
as where to install the module and how to build it.
|
||||
|
||||
More information on the format of the `dkms.conf` file can be found
|
||||
later in this article. Once these two requirements have been met and
|
||||
DKMS has been installed on the system, the user can begin using DKMS
|
||||
by adding a `module/module-version` to the DKMS tree. The example add
|
||||
command::
|
||||
|
||||
# dkms add -m qla2x00 -v v6.04.00
|
||||
|
||||
would add `qla2x00/v6.04.00` to the extant `/var/dkms` tree. This
|
||||
command includes creating the directory `/var/dkms/qla2x00/v6.04.00/`,
|
||||
creating a symlink from `/var/dkms/qla2x00/v6.04.00/source` to
|
||||
`/usr/src/qla2x00-v6.04.00/` and copying the `dkms.conf` file from its
|
||||
original location to `/var/dkms/qla2x00/v6.04.00/dkms.conf`.
|
||||
|
||||
Once this add is complete, the module is ready to be built. The `dkms
|
||||
build` command requires that the proper kernel sources are located on
|
||||
the system from the `/lib/module/kernel-version/build` symlink. The
|
||||
make command used to compile the module is specified in the
|
||||
`dkms.conf` configuration file. Continuing with the `qla2x00/v6.04.00`
|
||||
example::
|
||||
|
||||
# dkms build -m qla2x00 -v v6.04.00 -k 2.4.20-8smp
|
||||
|
||||
compiles the module but stops short of installing it. Although build
|
||||
expects a kernel-version parameter, if this kernel name is left out,
|
||||
it assumes the currently running kernel. However, building modules
|
||||
for kernels not currently running also is a viable option. This
|
||||
functionality is assured through the use of a kernel preparation
|
||||
subroutine that runs before any module build is performed. This
|
||||
paranoid kernel preparation involves running a make mrproper, copying
|
||||
the proper kernel .config file to the kernel source directory, running
|
||||
a make oldconfig and, finally, running a make dep. These steps ensure
|
||||
that the module being built is built against the proper kernel
|
||||
symbols. By default, DKMS looks for the kernel `.config` file in the
|
||||
`/lib/modules/kernel-version/build/configs/` directory, utilizing Red
|
||||
Hat's naming structure for those config files. If the kernel `.config`
|
||||
file is not located in this directory, you must specify a `--config`
|
||||
option with your build command and tell DKMS where the `.config` file
|
||||
can be found.
|
||||
|
||||
Successful completion of a build creates, for this example, the
|
||||
`/var/dkms/qla2x00/v6.04.00/2.4.20-8smp/` directory as well as the log
|
||||
and module subdirectories within this directory. The log directory
|
||||
holds a log file of the module make, and the module directory holds
|
||||
copies of the compiled `.o` binaries.
|
||||
|
||||
With the completion of a build, the module now can be installed on the
|
||||
kernel for which it was built. Installation copies the compiled module
|
||||
binary to the correct location in the `/lib/modules/` tree, as
|
||||
specified in the dkms.conf file. If a module by that name is already
|
||||
found in that location, DKMS saves it in its tree as an original
|
||||
module, so it can be put back into place at a later time if the newer
|
||||
module is uninstalled. The example install command::
|
||||
|
||||
# dkms install -m qla2x00 -v v6.04.00 -k 2.4.20-8smp
|
||||
|
||||
creates the following symlink::
|
||||
|
||||
/var/dkms/qla2x00/v6.04.00/kernel-2.4.20-8smp → /var/dkms/qla2x00/v6.04.00/2.4.20-8smp
|
||||
|
||||
This symlink is how DKMS keeps tabs on which driver version is
|
||||
installed on which kernel. As stated earlier, if a module by the same
|
||||
name is installed already, DKMS saves a copy in its tree in the
|
||||
`/var/dkms/module-name/original_module/` directory. In this case, it
|
||||
would be saved to `/var/dkms/qla2x00/original_module/2.4.20-8smp/`.
|
||||
|
||||
To complete the DKMS cycle, you also can uninstall or remove your
|
||||
module from the tree. Uninstall removes the module you installed and,
|
||||
if applicable, replaces it with its original module. In scenarios
|
||||
where multiple versions of a module are located within the DKMS tree,
|
||||
when one version is uninstalled, DKMS does not try to understand or
|
||||
assume which of these other versions should be put in its
|
||||
place. Instead, if a true original_module was saved from the original
|
||||
DKMS installation, it is put back into the kernel. All of the other
|
||||
module versions for that module are left in the built state. An
|
||||
example uninstall would be::
|
||||
|
||||
# dkms uninstall -m qla2x00 -v v6.04.00 -k 2.4.20-8smp
|
||||
|
||||
If the kernel version parameter is unset, the currently running kernel
|
||||
is assumed, but the same behavior does not occur with the remove
|
||||
command. Remove and uninstall are similar in that a remove command
|
||||
completes all of the same steps as does an uninstall. However, if the
|
||||
module-version being removed is the last instance of that
|
||||
module-version for all kernels on your system, after the uninstall
|
||||
portion of the remove completes, remove physically removes all traces
|
||||
of that module from the DKMS tree. In other words, when an uninstall
|
||||
command completes, your modules are left in the **built**
|
||||
state. However, when a remove completes, you have to start over from
|
||||
the add command before you can use this module again with DKMS. Here
|
||||
are two sample remove commands::
|
||||
|
||||
# dkms remove -m qla2x00 -v v6.04.00 -k 2.4.20-8smp
|
||||
|
||||
# dkms remove -m qla2x00 -v v6.04.00 --all
|
||||
|
||||
With the first remove command, the module would be uninstalled. If
|
||||
this `module/module-version` were not installed on any other kernel,
|
||||
all traces of it would be removed from the DKMS tree. If, say,
|
||||
`qla2x00/v6.04.00` also was installed on the `2.4.20-8bigmem` kernel,
|
||||
the first remove command would leave it alone—it would remain intact
|
||||
in the DKMS tree. That would not be the case in the second example. It
|
||||
would uninstall all versions of the `qla2x00/v6.04.00` module from all
|
||||
kernels and then completely expunge all references of
|
||||
`qla2x00/v6.04.00` from the DKMS tree. Thus, remove is what cleans
|
||||
your DKMS tree.
|
||||
|
||||
|
||||
Miscellaneous DKMS Commands
|
||||
---------------------------
|
||||
|
||||
DKMS also comes with a fully functional status command that returns
|
||||
information about what is currently located in your tree. If no
|
||||
parameters are set, it returns all information found. Logically, the
|
||||
specificity of information returned depends on which parameters are
|
||||
passed to your status command. Each status entry returned is of the
|
||||
state added, built or installed. If an original module has been saved,
|
||||
this information also is displayed. Some example status commands
|
||||
include::
|
||||
|
||||
# dkms status
|
||||
|
||||
# dkms status -m qla2x00
|
||||
|
||||
# dkms status -m qla2x00 -v v6.04.00
|
||||
|
||||
# dkms status -k 2.4.20-8smp
|
||||
|
||||
# dkms status -m qla2x00 -v v6.04.00 -k 2.4.20-8smp
|
||||
|
||||
|
||||
Another major feature of DKMS is the match command. The match command
|
||||
takes the configuration of DKMS-installed modules for one kernel and
|
||||
applies it to some other kernel. When the match completes, the same
|
||||
`module/module-versions` installed for one kernel are then installed
|
||||
on the other kernel. This is helpful when you are upgrading from one
|
||||
kernel to the next but want to keep the same DKMS modules in place for
|
||||
the new kernel. In the example::
|
||||
|
||||
# dkms match --templatekernel 2.4.20-8smp -k 2.4.20-9smp
|
||||
|
||||
`--templatekernel` is the match-er kernel from which the configuration
|
||||
is based. The `-k` kernel is the match-ee upon which the
|
||||
configuration is instated.
|
||||
|
||||
For systems management purposes, the commands mktarball and ldtarball
|
||||
also have been added to DKMS. These commands allow the user to make
|
||||
and load tarball archives, respectively, into the DKMS tree to
|
||||
facilitate using DKMS in deployments where many similar systems
|
||||
exist. This allows the system administrator to build modules on only
|
||||
one system. Rather than build the same module on every other system,
|
||||
the built binary can be applied directly to the other systems' DKMS
|
||||
tree. Specifically, mktarball creates a tarball of the source for a
|
||||
given `module/module-version`. It then archives the DKMS tree of every
|
||||
kernel version that has a module built for that
|
||||
`module/module-version`. Consider the example::
|
||||
|
||||
# dkms mktarball -m qla2x00 -v v6.04.00 -k 2.4.20-8smp,2.4.20-8
|
||||
|
||||
Depending on the `-k` kernel parameter, `mktarball` archives only
|
||||
certain binaries compiled for those kernels specified. If no kernel
|
||||
parameter is given, it archives all built module binaries for that
|
||||
`module/module-version`.
|
||||
|
||||
With `ldtarball`, DKMS simply parses the archive created with
|
||||
mktarball and applies whatever is found to that system's DKMS
|
||||
tree. This leaves all modules in the built state; the `dkms install`
|
||||
command then can be used to place the module binaries into the
|
||||
`/lib/modules` tree. Under normal operation, ldtarball does not
|
||||
overwrite any files that already exist in the system's DKMS
|
||||
tree. However, the archive can be forced over what is in the tree with
|
||||
the `--force` option. An example `ldtarball`::
|
||||
|
||||
# dkms ldtarball --config qla2x00-v6.04.00-kernel2.4.20-8smp.tar.gz
|
||||
|
||||
The last miscellaneous DKMS command is `mkdriverdisk`. As can be
|
||||
inferred from its name, `mkdriverdisk` takes the proper sources in
|
||||
your DKMS tree and creates a driver disk image that can provide
|
||||
updated drivers to Linux distribution installations. A sample
|
||||
`mkdriverdisk` might look like::
|
||||
|
||||
# dkms mkdriverdisk -d redhat -m qla2x00 -v v6.04.00 -k 2.4.20-8BOOT
|
||||
|
||||
Currently, the only supported distribution driver disk format is Red
|
||||
Hat, but this easily could expand with some help from the community in
|
||||
understanding driver disk requirements and formats on a
|
||||
per-distribution basis. For more information on the extra necessary
|
||||
files and their formats for DKMS to create Red Hat driver disks, see
|
||||
`people.redhat.com/dledford`. These files should be placed in your
|
||||
module source directory.
|
||||
|
||||
The dkms.conf Configuration File Format
|
||||
---------------------------------------
|
||||
|
||||
For maintainers of DKMS packages, the `dkms.conf` configuration file
|
||||
is the only auxiliary piece necessary to make your source tarball
|
||||
DKMS-ready. The format of the conf file is a successive list of shell
|
||||
variables sourced by DKMS when working with your package. For
|
||||
example, an excerpt from the `qla2x00/v6.04.00 dkms.conf` file::
|
||||
|
||||
MAKE="make all INCLUDEDIR=/lib/modules/$kernelver/build/include"
|
||||
MAKE_smp="make SMP=1 all INCLUDEDIR=/lib/modules/$kernelver/build/include"
|
||||
LOCATION="/kernel/drivers/addon/qla2200"
|
||||
REMAKE_INITRD="yes"
|
||||
MODULE_NAME="qla2200.o:qla2200_6x.o qla2300.o:qla2300_6x.o"
|
||||
CLEAN="make clean"
|
||||
MODULES_CONF_ALIAS_TYPE="scsi_hostadapter"
|
||||
MODULES_CONF0="options scsi_mod scsi_allow_ghost_devices=1"
|
||||
|
||||
shows that each of the shell variable directives should be coded in
|
||||
all capital letters. One of the current exceptions to this rule is the
|
||||
`MAKE_` directive. DKMS uses the generic `MAKE=` command to build your
|
||||
module. But, if a `MAKE_kernel-regexp-text` command exists and the
|
||||
text after the `MAKE_ matches` (as a substring) the kernel for which
|
||||
it is being built, then this alternate make command is used. In the
|
||||
above example, you can see how DKMS would use the `MAKE_smp` directive
|
||||
on any smp kernel for which it was building this module. Similar
|
||||
`PATCH_` commands also exist. When the text after the underscore
|
||||
matches the kernel for which a module is being built, that patch first
|
||||
is applied to the module source. This allows developers to distribute
|
||||
one source tarball, with one `dkms.conf` and multiple patches. Yet,
|
||||
different patches can be applied as necessary to the source to ensure
|
||||
all modules function correctly on all kernels.
|
||||
|
||||
Also notice that dkms.conf accepts the `$kernelver` variable, which,
|
||||
at build time, is replaced with the kernel version for which the
|
||||
module is being built. This is especially important so the correct
|
||||
include directories are referenced when compiling a module for a
|
||||
kernel that is not currently running.
|
||||
|
||||
Using DKMS in Conjunction with RPM
|
||||
----------------------------------
|
||||
|
||||
DKMS and RPM actually work quite well together. The only twist is that
|
||||
to make it function properly, you have to create an RPM that installs
|
||||
source. Although normal practice is to install source only with source
|
||||
RPMs, a source RPM does not necessarily work with DKMS; it will not
|
||||
let you do much besides install the source. Instead, your source
|
||||
tarball needs to be included with your RPM, so your source can be
|
||||
placed in `/usr/src/module-module-version/` and the proper DMKS
|
||||
commands can be called. The `%post` and `%preun` basically are DKMS
|
||||
commands.
|
||||
|
||||
Here is a sample `.spec` file::
|
||||
|
||||
%define module qla2x00
|
||||
|
||||
Summary: Qlogic HBA module
|
||||
Name: %module_dkms
|
||||
Version: v6.04.00
|
||||
Release: 1
|
||||
Vendor: Qlogic Corporation
|
||||
Copyright: GPL
|
||||
Packager: Gary Lerhaupt <gary_lerhaupt@dell.com>
|
||||
Group: System Environment/Base
|
||||
BuildArch: noarch
|
||||
Requires: dkms gcc bash sed
|
||||
Source0: qla2x00src-%version.tgz
|
||||
Source1: dkms.conf
|
||||
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root/
|
||||
|
||||
%description
|
||||
This package contains Qlogic's qla2x00 HBA module meant
|
||||
for the DKMS framework.
|
||||
|
||||
%prep
|
||||
rm -rf qla2x00src-%version
|
||||
mkdir qla2x00src-%version
|
||||
cd qla2x00src-%version
|
||||
tar xvzf $RPM_SOURCE_DIR/qla2x00src-%version.tgz
|
||||
|
||||
%install
|
||||
if [ "$RPM_BUILD_ROOT" != "/" ]; then
|
||||
|
||||
rm -rf $RPM_BUILD_ROOT
|
||||
fi
|
||||
mkdir -p $RPM_BUILD_ROOT/usr/src/%module-%version/
|
||||
install -m 644 $RPM_SOURCE_DIR/dkms.conf
|
||||
$RPM_BUILD_ROOT/usr/src/%module-%version
|
||||
install -m 644 qla2x00src-%version/*
|
||||
$RPM_BUILD_ROOT/usr/src/%module-%version
|
||||
|
||||
%clean
|
||||
if [ "$RPM_BUILD_ROOT" != "/" ]; then
|
||||
|
||||
rm -rf $RPM_BUILD_ROOT
|
||||
fi
|
||||
|
||||
%files
|
||||
%defattr(0644,root,root)
|
||||
%attr(0755,root,root) /usr/src/%module-%version/
|
||||
|
||||
%pre
|
||||
|
||||
%post
|
||||
/sbin/dkms add -m %module -v %version
|
||||
/sbin/dkms build -m %module -v %version
|
||||
/sbin/dkms install -m %module -v %version
|
||||
exit 0
|
||||
|
||||
%preun
|
||||
/sbin/dkms remove -m %module -v %version --all
|
||||
exit 0
|
||||
@@ -1,4 +0,0 @@
|
||||
Firefox Preferences
|
||||
===================
|
||||
|
||||
`/usr/lib64/firefox/browser/defaults/preferences/all-psi.js`
|
||||
@@ -1,18 +0,0 @@
|
||||
How To Start Vncserver
|
||||
======================
|
||||
|
||||
Login to the remote host::
|
||||
|
||||
# ssh root@<hostname>
|
||||
# ls -l /tmp/krb*
|
||||
|
||||
Login as <user> you want to get the Desktop from::
|
||||
|
||||
# su - <user>
|
||||
# export KRB5CCNAME=/tmp/krb5cc_3651_bxD3lb
|
||||
# aklog
|
||||
# x0vncserver -SecurityTypes=None -display=:0.0
|
||||
|
||||
Start vnc client on local host::
|
||||
|
||||
# vncviewer
|
||||
@@ -1,20 +0,0 @@
|
||||
How to edit `install.img`
|
||||
=========================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
This HowTo describes how to extract, edit and rebuild the install.img
|
||||
file of an SL6 release. This file is found in the distribution
|
||||
toplevel `$basearch` directory e.g. in
|
||||
`/afs/psi.ch/software/linux/dist/scientific/62/x86_64/images/` at our
|
||||
site. It is loaded during the installation and brings up the
|
||||
installation process.
|
||||
|
||||
The reason to edit the `install.img` in this example is the file
|
||||
`/etc/anaconda.repos.d/sl.repo`, which references the original SL repos,
|
||||
i.e. the anaconda installer will try to get RPMS from these external
|
||||
repos during the installation even if we declare our local repos in
|
||||
the kickstart config file. We want now that anaconda takes RPMS from
|
||||
our local copies of the SL repos, because first the installation is
|
||||
faster, second we do not depend on down times of the SL site.
|
||||
@@ -1,864 +0,0 @@
|
||||
Kernel Module E1000E Update For SL5.1
|
||||
=====================================
|
||||
|
||||
This document is almost certainly obsolete, hence I just include the
|
||||
unformatted POD source of the original::
|
||||
|
||||
=head2 References
|
||||
|
||||
=over 4
|
||||
|
||||
=item *
|
||||
|
||||
http://support.intel.com/support/
|
||||
|
||||
=back
|
||||
|
||||
=head2 Introduction
|
||||
|
||||
The Intel Gigabit ethernet card F<82567LM>, which comes with the
|
||||
new Fujitsu Siemens computers F<Celsius W370>, F<Esprimo p7935 e80>,
|
||||
F<Esprimo e7935 e80> and F<Lifebook e8420>, contemporary does not work
|
||||
out of the box in SL51 (and for sure others) because the updated version
|
||||
of the e1000e driver is not available yet in Scientific Linux.
|
||||
|
||||
As a consequence of this the network installation is not working for this
|
||||
kind of hardware, because
|
||||
the SL5.1 installation kernel, too, is not coming with the proper driver.
|
||||
|
||||
This documents describes a quick workaround, Solution 1, and a more profound
|
||||
procedure, Solution 2, to solve this issue. A third alternative, Solution 3,
|
||||
is shortly mentioned, but could not be finalized.
|
||||
|
||||
=head3 Solution 1
|
||||
|
||||
For the network installation
|
||||
via PXE boot a second SL5 compatible network card has to be plugged in. When the
|
||||
installation has finished, an updated version of the
|
||||
e1000e driver, that supports the mentioned hardware can be downloaded
|
||||
from the Intel website (see References) and installed on the system.
|
||||
|
||||
=head3 Solution 2
|
||||
|
||||
Use the SL5.3 kernel, the e1000e driver of which does support the F<82567LM> hardware,
|
||||
to install the SL5.1.
|
||||
|
||||
First, the PXE boot environment has to be setup with the SL5.3 kernel and the related
|
||||
initial ramdisk.
|
||||
|
||||
Second, the F<.buildstamp> in the initial ramdisk of SL5.3 has to be replaced by the
|
||||
F<.buildstamp> of SL5.1. This facilitates the SL5.3 installer to use the SL5.1 installation
|
||||
tree. Therefore the ramdisk has to be unpacked, modified and
|
||||
repacked (it is a gzipped cpio archive).
|
||||
|
||||
Third, build a kernel module e1000e RPM for SL5.1 which will be installed during the SL5.1
|
||||
installation by means of a custom key F<e1000e>.
|
||||
|
||||
Fourth, setup the F<e1000e> custom key.
|
||||
|
||||
=head3 Solution 3
|
||||
|
||||
Note: This was tried but does not work yet.
|
||||
|
||||
For the network installation compile the new e1000e driver for the installation kernel and put it into
|
||||
the corresponding initial ramdisk.
|
||||
|
||||
For the running system build the e1000e RPMS for the current kernel/architecture combinations
|
||||
and install the RPMS during the kickstart process.
|
||||
|
||||
When the kernel is updated the corresponding e1000e RPMS have to be rebuilt and put into
|
||||
the update repository.
|
||||
|
||||
=head2 Procedure for Solution 1
|
||||
|
||||
Get the tarball, extract it and build the driver following
|
||||
the instructions in the README of the tarball.
|
||||
|
||||
Get the tarball and extract it.
|
||||
|
||||
# [root@pc7637]
|
||||
# uname -a
|
||||
Linux pc7637 2.6.18-92.1.22.el5PAE #1 SMP Tue Dec 16 07:10:07 EST 2008 i686 i686 i386 GNU/Linux
|
||||
# cd /tmp/
|
||||
# wget http://downloadmirror.intel.com/17069/eng/e1000e-0.4.1.7.tar.gz
|
||||
# tar xfz e1000e-0.4.1.7.tar.gz
|
||||
|
||||
Install the corresponding kernel source RPM.
|
||||
|
||||
# rpm -ivh /afs/psi.ch/software/mirror/scientific/5x/SRPMS/vendor/kernel-2.6.18-92.1.22.el5.src.rpm
|
||||
|
||||
Build the RPM for the running kernel.
|
||||
|
||||
# rpmbuild -tb e1000e-0.4.1.7.tar.gz
|
||||
...
|
||||
Wrote: /usr/src/redhat/RPMS/i386/e1000e-0.4.1.7-1.i386.rpm
|
||||
...
|
||||
|
||||
Install the driver RPM.
|
||||
|
||||
# rpm -ivh /usr/src/redhat/RPMS/i386/e1000e-0.4.1.7-1.i386.rpm
|
||||
|
||||
Becaus this is a newly installed host, disable older kernels in grub,
|
||||
because the kernel module e1000e is only valid for the running kernel.
|
||||
However the older kernels should be removed later, if there are no needs to run
|
||||
them.
|
||||
|
||||
# vi /boot/grub/grub.conf
|
||||
|
||||
The resulting RPM e1000e-0.4.1.7-1.i386.rpm was built on a FS Celsius W370
|
||||
after Network installation via an old plugged in 3COM network card
|
||||
as 2nd network device. After installation of this RPM the 3COM
|
||||
card was removed and the on board Intel Gigabit network card
|
||||
was running with the new e1000e kernel module.
|
||||
|
||||
=over 4
|
||||
|
||||
=item Note:
|
||||
|
||||
This RPM contains only the module for an SL51 PAE kernel.
|
||||
|
||||
/lib/modules/2.6.18-92.1.22.el5PAE/kernel/drivers/net/e1000e/e1000e.ko.new
|
||||
|
||||
=back
|
||||
|
||||
=for comment
|
||||
##################################################################################3
|
||||
|
||||
=head2 Procedure for Solution 2
|
||||
|
||||
=head3 Setup the PXE Boot Environment for the New Kickstart Installation
|
||||
|
||||
Add the following labels to
|
||||
F</afs/psi.ch/service/linux/tftpboot/pxelinux.cfg/default.testing>.
|
||||
At the time of writing they are used for testing, their names will probably
|
||||
be changed later on.
|
||||
|
||||
Note: You can take the same kickstart configuration files as for the default
|
||||
SL51 installation, under the labels sl5 and sl564.
|
||||
|
||||
label sl53t32
|
||||
kernel scientific/53for51install/i386/vmlinuz
|
||||
append initrd=scientific/53for51install/i386/initrd.img ksdevice=eth0 \
|
||||
ks=nfs:129.129.190.59:/master/linux/kickstart/configs/sl51-a-ks.cfg noipv6
|
||||
|
||||
label sl53t64
|
||||
kernel scientific/53for51install/x86_64/vmlinuz
|
||||
append initrd=scientific/53for51install/x86_64/initrd.img ksdevice=eth0 \
|
||||
ks=nfs:129.129.190.59:/master/linux/kickstart/configs/sl51-64-a-ks.cfg noipv6
|
||||
|
||||
Copy the installation kernel and the initial ramdisk to the tftpboot
|
||||
location given in the respective labels above.
|
||||
|
||||
# cd /afs/psi.ch/service/linux/tftpboot/scientific/
|
||||
# mkdir -p 53for51install/i386 53for51install/x86_64
|
||||
|
||||
# cd 53for51install/i386/
|
||||
# wget http://ftp.scientificlinux.org/linux/scientific/5rolling/i386/images/pxeboot/vmlinuz
|
||||
# wget http://ftp.scientificlinux.org/linux/scientific/5rolling/i386/images/pxeboot/initrd.img
|
||||
|
||||
# cd ../x86_64/
|
||||
# wget http://ftp.scientificlinux.org/linux/scientific/5rolling/x86_64/images/pxeboot/vmlinuz
|
||||
# wget http://ftp.scientificlinux.org/linux/scientific/5rolling/x86_64/images/pxeboot/initrd.img
|
||||
|
||||
Before proceeding with the next section test whether the basic setup is working.
|
||||
Therefore boot F<sl53t32> and F<sl53t64> on a test machine.
|
||||
|
||||
This should setup the network connections, start the kickstart
|
||||
till to the point when it runs the pre installation scripts.
|
||||
|
||||
=head3 Modify the Initial Ramdisk, Example for x86_64
|
||||
|
||||
Unpack the initial ramdisk image of SL5.3.
|
||||
|
||||
# cd /afs/psi.ch/service/linux/tftpboot/scientific/53for51install/x86_64/
|
||||
# mkdir tmp
|
||||
# cd tmp
|
||||
# zcat ../initrd.img | cpio -ivd
|
||||
|
||||
The content of the F<.buildstamp> will be something alike.
|
||||
|
||||
# cat .buildstamp
|
||||
200902111740.x86_64
|
||||
Scientific Linux
|
||||
53
|
||||
SL
|
||||
your distribution provided bug reporting tool.
|
||||
|
||||
Now replace this F<.buildstamp> file with the one
|
||||
of the SL5.1 installation tree. Therefore you also have to
|
||||
unpack the ramdisk.
|
||||
|
||||
# cd /afs/psi.ch/software/linux/dist/scientific/51/x86_64/images/pxeboot/
|
||||
# mkdir tmp
|
||||
# cd tmp
|
||||
# zcat ../initrd.img | cpio -ivd
|
||||
|
||||
Here we have the following F<.buildstamp>.
|
||||
|
||||
# cat .buildstamp
|
||||
200801141434.x86_64
|
||||
Scientific Linux
|
||||
51
|
||||
SL
|
||||
your distribution provided bug reporting tool.
|
||||
|
||||
# cp -i .buildstamp \
|
||||
# /afs/psi.ch/service/linux/tftpboot/scientific/53for51install/x86_64/tmp/
|
||||
|
||||
Clean up.
|
||||
|
||||
# cd ..
|
||||
# rm -rf tmp
|
||||
|
||||
Repack the initial ramdisk of SL5.3 x86_64.
|
||||
For this part the commands were taken from F</sbin/mkinitrd> of
|
||||
the SL5.1 RPM F<mkinitrd-5.1.19.6-19> and put into a script,
|
||||
because repacking the ramdisk without the same command options
|
||||
as from the F</sbin/mkinitrd> script fails.
|
||||
|
||||
=opentwisty
|
||||
|
||||
# # Function from /sbin/mkinitrd
|
||||
# findall() {
|
||||
# echo nash-find "$@" | /sbin/nash --force --quiet
|
||||
# }
|
||||
#
|
||||
# # Architecture
|
||||
# ARCH="x86_64"
|
||||
#
|
||||
# # Set file locations:
|
||||
# # The temporary directory in the tftpboot directory
|
||||
# # where the initial ramdisk is extracted to.
|
||||
# MNTIMAGE="/afs/psi.ch/service/linux/tftpboot/scientific/53for51install/$ARCH/tmp"
|
||||
#
|
||||
# # The name of the new ramdisk, not to overwrite the original one
|
||||
# target="initrd.img_new"
|
||||
#
|
||||
# # Start processing
|
||||
# if test ! -d $MNTIMAGE
|
||||
# then
|
||||
# echo "Error: $MNTIMAGE does not exist."
|
||||
# exit
|
||||
# fi
|
||||
#
|
||||
# if test -e ${MNTIMAGE}/../initrd.img_new.cpio
|
||||
# then
|
||||
# echo -n "${MNTIMAGE}/../initrd.img_new.cpio exists. Shall I remove it (y/N)?"
|
||||
# read a
|
||||
# if test "$a" = "y"
|
||||
# then
|
||||
# rm -f ${MNTIMAGE}/../initrd.img_new.cpio
|
||||
# fi
|
||||
# fi
|
||||
#
|
||||
# # Create the empty ramdisk file (from /sbin/mkinitrd)
|
||||
# IMAGE=`mktemp ${MNTIMAGE}/../initrd.img_new.cpio`
|
||||
#
|
||||
# # Fill it as cpio archive (from /sbin/mkinitrd)
|
||||
# (cd $MNTIMAGE; findall . | cpio --quiet -c -o) >| $IMAGE || exit 1
|
||||
#
|
||||
# # Compress the cpio archive (from /sbin/mkinitrd)
|
||||
# gzip -9 < $IMAGE >| ${MNTIMAGE}/../$target
|
||||
#
|
||||
# echo "Check the new initial ramdisk at"
|
||||
# echo "/afs/psi.ch/service/linux/tftpboot/scientific/53for51install/$ARCH/"
|
||||
# echo
|
||||
|
||||
=closetwisty
|
||||
|
||||
Go to the tftpboot direcory and setup the new initial ramdisk.
|
||||
Make also a backup of the original one.
|
||||
|
||||
# cd /afs/psi.ch/service/linux/tftpboot/scientific/53for51install/x86_64/
|
||||
# mv initrd.img initrd.img_orig
|
||||
# ln -s initrd.img_new initrd.img
|
||||
|
||||
Now test the PXE boot kickstart installation using the
|
||||
label F<sl53t64>.
|
||||
|
||||
If everything looks fine clean up and go to the next section
|
||||
or repeat this part for the i386 architecture.
|
||||
|
||||
# rm -rf tmp/ initrd.img_new.cpio
|
||||
|
||||
=head3 Build the e1000e Kernel Module RPM, Example for x86_64
|
||||
|
||||
Go to the build system tux50-64 and download the e1000e sources
|
||||
and get the spec file.
|
||||
|
||||
# [gasser_m@tux50-64]
|
||||
# cd /scratch/gasser_m/rpm_topdir/SOURCES/
|
||||
# wget http://downloadmirror.intel.com/17069/eng/e1000e-0.4.1.7.tar.gz
|
||||
# tar xfz e1000e-0.4.1.7.tar.gz
|
||||
# cp e1000e-0.4.1.7/e1000e.spec ../SPECS/
|
||||
# rm -rf e1000e-0.4.1.7
|
||||
# cd ../SPECS/
|
||||
# cp e1000e e1000e_orig
|
||||
|
||||
Note, you can build the RPM directly from this tarball, but here we want to
|
||||
change the name of the built RPM to apply our PSI naming convention for kernel
|
||||
modules, thus we need to edit the spec file before building.
|
||||
|
||||
# vi e1000e.spec
|
||||
|
||||
=opentwisty
|
||||
|
||||
#### begin e1000e.spec
|
||||
|
||||
%define driver_name e1000e
|
||||
%define kernel 2.6.18-92.1.22.el5
|
||||
|
||||
%define pkg_name kernel-module-%{driver_name}-%{kernel}
|
||||
|
||||
Name: %{pkg_name}
|
||||
Summary: Intel(R) Gigabit Ethernet Connection
|
||||
Version: 0.4.1.7
|
||||
Release: 1
|
||||
Source: %{driver_name}-%{version}.tar.gz
|
||||
Vendor: Intel Corporation
|
||||
Packager: Marc Gasser <marc.gasser@psi.ch>
|
||||
License: GPL
|
||||
ExclusiveOS: linux
|
||||
Group: System Environment/Kernel
|
||||
Provides: %{driver_name}
|
||||
URL: http://support.intel.com/support/go/linux/e1000e.htm
|
||||
BuildRoot: %{_tmppath}/%{driver_name}-%{version}-root
|
||||
# do not generate debugging packages by default - newer versions of rpmbuild
|
||||
# may instead need:
|
||||
#%define debug_package %{nil}
|
||||
%debug_package %{nil}
|
||||
# macros for finding system files to update at install time (pci.ids, pcitable)
|
||||
%define find() %(for f in %*; do if [ -e $f ]; then echo $f; break; fi; done)
|
||||
%define _pciids /usr/share/pci.ids /usr/share/hwdata/pci.ids
|
||||
%define _pcitable /usr/share/kudzu/pcitable /usr/share/hwdata/pcitable /dev/null
|
||||
%define pciids %find %{_pciids}
|
||||
%define pcitable %find %{_pcitable}
|
||||
Requires: kernel, fileutils, findutils, gawk, bash
|
||||
|
||||
%description
|
||||
This package contains the Linux driver for the Intel(R) Gigabit Family of Server Adapters.
|
||||
|
||||
########################### begin RPM build section
|
||||
|
||||
%prep
|
||||
%setup -n %{driver_name}-%{version}
|
||||
|
||||
%build
|
||||
mkdir -p %{buildroot}
|
||||
|
||||
KV=%{kernel}
|
||||
KA=%{_arch}
|
||||
KV_BASE=$(echo $KV | sed '{ s/hugemem//g; s/smp//g; s/enterprise//g; }' )
|
||||
|
||||
if [ -e /usr/src/kernels ] && [ $(echo $KV_BASE | grep "^2.6") ]; then
|
||||
if [ -e /etc/redhat-release ]; then
|
||||
KSP=$(ls /lib/modules | grep $KV_BASE)
|
||||
for K in $KSP ; do
|
||||
if [ $KA == "x86_64" ] && \
|
||||
[ $(echo $K | grep hugemem) ]; then
|
||||
# Include path for x86_64 hugemem is broken
|
||||
# on RHEL4
|
||||
continue
|
||||
fi
|
||||
make -C src clean
|
||||
make -C src KSP=/lib/modules/$K/build \
|
||||
INSTALL_MOD_PATH=%{buildroot} \
|
||||
KVERSION=$k \
|
||||
MANDIR=%{_mandir} \
|
||||
CFLAGS_EXTRA="$CFLAGS_EXTRA" install
|
||||
done
|
||||
else
|
||||
make -C src clean
|
||||
make -C src INSTALL_MOD_PATH=%{buildroot} \
|
||||
MANDIR=%{_mandir} install
|
||||
fi
|
||||
else
|
||||
SwitchRHKernel () {
|
||||
CFLAGS_EXTRA=""
|
||||
for K in $2 ; do
|
||||
if [ $K == $1 ] ; then
|
||||
CFLAGS_EXTRA="$CFLAGS_EXTRA -D__BOOT_KERNEL_$K=1"
|
||||
else
|
||||
CFLAGS_EXTRA="$CFLAGS_EXTRA -D__BOOT_KERNEL_$K=0"
|
||||
fi
|
||||
done
|
||||
}
|
||||
|
||||
KSP="/lib/modules/$KV/build
|
||||
/usr/src/linux-$KV
|
||||
/usr/src/linux-$(echo $KV | sed 's/-.*//')
|
||||
/usr/src/kernel-headers-$KV
|
||||
/usr/src/kernel-source-$KV
|
||||
/usr/src/linux-$(echo $KV | sed 's/\([0-9]*\.[0-9]*\)\..*/\1/')
|
||||
/usr/src/linux"
|
||||
|
||||
KSRC=$(for d in $KSP ; do [ -e $d/include/linux ] && echo $d; echo; done)
|
||||
KSRC=$(echo $KSRC | awk '{ print $1 }')
|
||||
|
||||
if [ -e $KSRC/include/linux/rhconfig.h ] ; then
|
||||
RHKL=$(grep 'BOOT_KERNEL_.* [01]' /boot/kernel.h |
|
||||
sed 's/.*BOOT_KERNEL_\(.*\) [01]/\1/')
|
||||
if echo $RHKL | grep BIGMEM
|
||||
then
|
||||
RHKL=$(echo $RHKL | sed 's/ENTERPRISE//')
|
||||
fi
|
||||
if echo $RHKL | grep HUGEMEM
|
||||
then
|
||||
RHKL=$(echo $RHKL | sed 's/BIGMEM//')
|
||||
fi
|
||||
for K in $RHKL ; do
|
||||
SwitchRHKernel $K "$RHKL"
|
||||
make -C src clean
|
||||
if [ $KA == "x86_64" ] ; then
|
||||
CFLAGS_EXTRA="$CFLAGS_EXTRA -D__MODULE_KERNEL_x86_64=0 -D__MODULE_KERNEL_ia32e=1"
|
||||
fi
|
||||
make -C src INSTALL_MOD_PATH=%{buildroot} \
|
||||
MANDIR=%{_mandir} CFLAGS_EXTRA="$CFLAGS_EXTRA" install
|
||||
done
|
||||
else
|
||||
make -C src clean
|
||||
make -C src INSTALL_MOD_PATH=%{buildroot} MANDIR=%{_mandir} install
|
||||
fi
|
||||
fi
|
||||
|
||||
%install
|
||||
# Append .new to driver name to avoid conflict with kernel RPM
|
||||
echo "# Going to " %{buildroot}
|
||||
cd %{buildroot}
|
||||
find lib -name "e1000e.*o" -exec mv {} {}.new \; \
|
||||
-fprintf %{_builddir}/%{driver_name}-%{version}/file.list "/%p.new\n"
|
||||
|
||||
|
||||
%clean
|
||||
rm -rf %{buildroot}
|
||||
|
||||
%files -f %{_builddir}/%{driver_name}-%{version}/file.list
|
||||
%defattr(-,root,root)
|
||||
%{_mandir}/man7/e1000e.7.gz
|
||||
%doc COPYING
|
||||
%doc README
|
||||
%doc file.list
|
||||
%doc pci.updates
|
||||
|
||||
########################### end RPM build section
|
||||
|
||||
########################### begin RPM installation section
|
||||
|
||||
%post
|
||||
FL="%{_docdir}/%{name}-%{version}/file.list
|
||||
%{_docdir}/%{name}/file.list"
|
||||
FL=$(for d in $FL ; do if [ -e $d ]; then echo $d; break; fi; done)
|
||||
|
||||
if [ -d /usr/local/lib/%{name} ]; then
|
||||
rm -rf /usr/local/lib/%{name}
|
||||
fi
|
||||
if [ -d /usr/local/share/%{name} ]; then
|
||||
rm -rf /usr/local/share/%{name}
|
||||
fi
|
||||
|
||||
echo "original pci.ids saved in /usr/local/share/%{name}";
|
||||
if [ "%{pcitable}" != "/dev/null" ]; then
|
||||
echo "original pcitable saved in /usr/local/share/%{name}";
|
||||
fi
|
||||
|
||||
#### Save old drivers (aka .o and .o.gz) in $d_usr
|
||||
# k is(are) the kernel version(s) extracted with sed from the full qualified
|
||||
# kernel module name(s) in file.list
|
||||
echo "Original drivers saved in /usr/local/share/%{name}";
|
||||
for k in $(sed 's/\/lib\/modules\/\([0-9a-zA-Z_\.\-]*\).*/\1/' $FL) ;
|
||||
do
|
||||
d_drivers=/lib/modules/$k
|
||||
d_usr=/usr/local/share/%{name}/$k
|
||||
mkdir -p $d_usr
|
||||
cd $d_drivers; find . -name %{driver_name}.*o -exec cp --parents {} $d_usr \; -exec rm -f {} \;
|
||||
cd $d_drivers; find . -name %{driver_name}_*.*o -exec cp --parents {} $d_usr \; -exec rm -f {} \;
|
||||
cd $d_drivers; find . -name %{driver_name}.*o.gz -exec cp --parents {} $d_usr \; -exec rm -f {} \;
|
||||
cd $d_drivers; find . -name %{driver_name}_*.*o.gz -exec cp --parents {} $d_usr \; -exec rm -f {} \;
|
||||
cp --parents %{pciids} /usr/local/share/%{name}/
|
||||
if [ "%{pcitable}" != "/dev/null" ]; then
|
||||
cp --parents %{pcitable} /usr/local/share/%{name}/
|
||||
fi
|
||||
done
|
||||
|
||||
# Add driver link
|
||||
for f in $(sed 's/\.new$//' $FL) ; do
|
||||
ln -f $f.new $f
|
||||
done
|
||||
|
||||
# Check if kernel version rpm was built on IS the same as running kernel
|
||||
BK_LIST=$(sed 's/\/lib\/modules\/\([0-9a-zA-Z_\.\-]*\).*/\1/' $FL)
|
||||
MATCH=no
|
||||
for i in $BK_LIST
|
||||
do
|
||||
if [ $(uname -r) == $i ] ; then
|
||||
MATCH=yes
|
||||
break
|
||||
fi
|
||||
done
|
||||
if [ $MATCH == no ] ; then
|
||||
echo -n "WARNING: Running kernel is $(uname -r). "
|
||||
echo -n "RPM supports kernels ( "
|
||||
for i in $BK_LIST
|
||||
do
|
||||
echo -n "$i "
|
||||
done
|
||||
echo ")"
|
||||
fi
|
||||
|
||||
LD="%{_docdir}/%{name}";
|
||||
if [ -d %{_docdir}/%{name}-%{version} ]; then
|
||||
LD="%{_docdir}/%{name}-%{version}";
|
||||
fi
|
||||
|
||||
#Yes, this really needs bash
|
||||
bash -s %{pciids} \
|
||||
%{pcitable} \
|
||||
$LD/pci.updates \
|
||||
$LD/pci.ids.new \
|
||||
$LD/pcitable.new \
|
||||
%{name} \
|
||||
<<"END"
|
||||
#! /bin/bash
|
||||
# $1 = system pci.ids file to update
|
||||
# $2 = system pcitable file to update
|
||||
# $3 = file with new entries in pci.ids file format
|
||||
# $4 = pci.ids output file
|
||||
# $5 = pcitable output file
|
||||
# $6 = driver name for use in pcitable file
|
||||
|
||||
exec 3<$1
|
||||
exec 4<$2
|
||||
exec 5<$3
|
||||
exec 6>$4
|
||||
exec 7>$5
|
||||
driver=$6
|
||||
IFS=
|
||||
|
||||
# pattern matching strings
|
||||
ID="[[:xdigit:]][[:xdigit:]][[:xdigit:]][[:xdigit:]]"
|
||||
VEN="${ID}*"
|
||||
DEV=" ${ID}*"
|
||||
SUB=" ${ID}*"
|
||||
TABLE_DEV="0x${ID} 0x${ID} \"*"
|
||||
TABLE_SUB="0x${ID} 0x${ID} 0x${ID} 0x${ID} \"*"
|
||||
|
||||
line=
|
||||
table_line=
|
||||
ids_in=
|
||||
table_in=
|
||||
vendor=
|
||||
device=
|
||||
ids_device=
|
||||
table_device=
|
||||
subven=
|
||||
ids_subven=
|
||||
table_subven=
|
||||
subdev=
|
||||
ids_subdev=
|
||||
table_subdev=
|
||||
ven_str=
|
||||
dev_str=
|
||||
sub_str=
|
||||
|
||||
# force a sub-shell to fork with a new stdin
|
||||
# this is needed if the shell is reading these instructions from stdin
|
||||
while true
|
||||
do
|
||||
# get the first line of each data file to jump start things
|
||||
exec 0<&3
|
||||
read -r ids_in
|
||||
if [ "$2" != "/dev/null" ];then
|
||||
exec 0<&4
|
||||
read -r table_in
|
||||
fi
|
||||
|
||||
# outer loop reads lines from the updates file
|
||||
exec 0<&5
|
||||
while read -r line
|
||||
do
|
||||
# vendor entry
|
||||
if [[ $line == $VEN ]]
|
||||
then
|
||||
vendor=0x${line:0:4}
|
||||
ven_str=${line#${line:0:6}}
|
||||
# add entry to pci.ids
|
||||
exec 0<&3
|
||||
exec 1>&6
|
||||
while [[ $ids_in != $VEN ||
|
||||
0x${ids_in:0:4} < $vendor ]]
|
||||
do
|
||||
echo "$ids_in"
|
||||
read -r ids_in
|
||||
done
|
||||
echo "$line"
|
||||
if [[ 0x${ids_in:0:4} == $vendor ]]
|
||||
then
|
||||
read -r ids_in
|
||||
fi
|
||||
|
||||
# device entry
|
||||
elif [[ $line == $DEV ]]
|
||||
then
|
||||
device=`echo ${line:1:4} | tr [:upper:] [:lower:]`
|
||||
table_device=0x${line:1:4}
|
||||
dev_str=${line#${line:0:7}}
|
||||
ids_device=`echo ${ids_in:1:4} | tr [:upper:] [:lower:]`
|
||||
table_line="$vendor $table_device \"$driver\" \"$ven_str|$dev_str\""
|
||||
# add entry to pci.ids
|
||||
exec 0<&3
|
||||
exec 1>&6
|
||||
while [[ $ids_in != $DEV ||
|
||||
$ids_device < $device ]]
|
||||
do
|
||||
if [[ $ids_in == $VEN ]]
|
||||
then
|
||||
break
|
||||
fi
|
||||
if [[ $ids_device != ${ids_in:1:4} ]]
|
||||
then
|
||||
echo "${ids_in:0:1}$ids_device${ids_in#${ids_in:0:5}}"
|
||||
else
|
||||
echo "$ids_in"
|
||||
fi
|
||||
read -r ids_in
|
||||
ids_device=`echo ${ids_in:1:4} | tr [:upper:] [:lower:]`
|
||||
done
|
||||
if [[ $device != ${line:1:4} ]]
|
||||
then
|
||||
echo "${line:0:1}$device${line#${line:0:5}}"
|
||||
else
|
||||
echo "$line"
|
||||
fi
|
||||
if [[ $ids_device == $device ]]
|
||||
then
|
||||
read -r ids_in
|
||||
fi
|
||||
# add entry to pcitable
|
||||
if [ "$2" != "/dev/null" ];then
|
||||
exec 0<&4
|
||||
exec 1>&7
|
||||
while [[ $table_in != $TABLE_DEV ||
|
||||
${table_in:0:6} < $vendor ||
|
||||
( ${table_in:0:6} == $vendor &&
|
||||
${table_in:7:6} < $table_device ) ]]
|
||||
do
|
||||
echo "$table_in"
|
||||
read -r table_in
|
||||
done
|
||||
echo "$table_line"
|
||||
if [[ ${table_in:0:6} == $vendor &&
|
||||
${table_in:7:6} == $table_device ]]
|
||||
then
|
||||
read -r table_in
|
||||
fi
|
||||
fi
|
||||
# subsystem entry
|
||||
elif [[ $line == $SUB ]]
|
||||
then
|
||||
subven=`echo ${line:2:4} | tr [:upper:] [:lower:]`
|
||||
subdev=`echo ${line:7:4} | tr [:upper:] [:lower:]`
|
||||
table_subven=0x${line:2:4}
|
||||
table_subdev=0x${line:7:4}
|
||||
sub_str=${line#${line:0:13}}
|
||||
ids_subven=`echo ${ids_in:2:4} | tr [:upper:] [:lower:]`
|
||||
ids_subdev=`echo ${ids_in:7:4} | tr [:upper:] [:lower:]`
|
||||
table_line="$vendor $table_device $table_subven $table_subdev \"$driver\" \"$ven_str|$sub_str\""
|
||||
# add entry to pci.ids
|
||||
exec 0<&3
|
||||
exec 1>&6
|
||||
while [[ $ids_in != $SUB ||
|
||||
$ids_subven < $subven ||
|
||||
( $ids_subven == $subven &&
|
||||
$ids_subdev < $subdev ) ]]
|
||||
do
|
||||
if [[ $ids_in == $VEN ||
|
||||
$ids_in == $DEV ]]
|
||||
then
|
||||
break
|
||||
fi
|
||||
if [[ ! (${ids_in:2:4} == "1014" &&
|
||||
${ids_in:7:4} == "052C") ]]
|
||||
then
|
||||
if [[ $ids_subven != ${ids_in:2:4} || $ids_subdev != ${ids_in:7:4} ]]
|
||||
then
|
||||
echo "${ids_in:0:2}$ids_subven $ids_subdev${ids_in#${ids_in:0:11}}"
|
||||
else
|
||||
echo "$ids_in"
|
||||
fi
|
||||
fi
|
||||
read -r ids_in
|
||||
ids_subven=`echo ${ids_in:2:4} | tr [:upper:] [:lower:]`
|
||||
ids_subdev=`echo ${ids_in:7:4} | tr [:upper:] [:lower:]`
|
||||
done
|
||||
if [[ $subven != ${line:2:4} || $subdev != ${line:7:4} ]]
|
||||
then
|
||||
echo "${line:0:2}$subven $subdev${line#${line:0:11}}"
|
||||
else
|
||||
echo "$line"
|
||||
fi
|
||||
if [[ $ids_subven == $subven &&
|
||||
$ids_subdev == $subdev ]]
|
||||
then
|
||||
read -r ids_in
|
||||
fi
|
||||
# add entry to pcitable
|
||||
if [ "$2" != "/dev/null" ];then
|
||||
exec 0<&4
|
||||
exec 1>&7
|
||||
while [[ $table_in != $TABLE_SUB ||
|
||||
${table_in:14:6} < $table_subven ||
|
||||
( ${table_in:14:6} == $table_subven &&
|
||||
${table_in:21:6} < $table_subdev ) ]]
|
||||
do
|
||||
if [[ $table_in == $TABLE_DEV ]]
|
||||
then
|
||||
break
|
||||
fi
|
||||
if [[ ! (${table_in:14:6} == "0x1014" &&
|
||||
${table_in:21:6} == "0x052C") ]]
|
||||
then
|
||||
echo "$table_in"
|
||||
fi
|
||||
read -r table_in
|
||||
done
|
||||
echo "$table_line"
|
||||
if [[ ${table_in:14:6} == $table_subven &&
|
||||
${table_in:21:6} == $table_subdev ]]
|
||||
then
|
||||
read -r table_in
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
|
||||
exec 0<&5
|
||||
done
|
||||
|
||||
# print the remainder of the original files
|
||||
exec 0<&3
|
||||
exec 1>&6
|
||||
echo "$ids_in"
|
||||
while read -r ids_in
|
||||
do
|
||||
echo "$ids_in"
|
||||
done
|
||||
|
||||
if [ "$2" != "/dev/null" ];then
|
||||
exec 0>&4
|
||||
exec 1>&7
|
||||
echo "$table_in"
|
||||
while read -r table_in
|
||||
do
|
||||
echo "$table_in"
|
||||
done
|
||||
fi
|
||||
|
||||
break
|
||||
done <&5
|
||||
|
||||
exec 3<&-
|
||||
exec 4<&-
|
||||
exec 5<&-
|
||||
exec 6>&-
|
||||
exec 7>&-
|
||||
|
||||
END
|
||||
|
||||
mv -f $LD/pci.ids.new %{pciids}
|
||||
if [ "%{pcitable}" != "/dev/null" ]; then
|
||||
mv -f $LD/pcitable.new %{pcitable}
|
||||
fi
|
||||
|
||||
uname -r | grep BOOT || /sbin/depmod -a > /dev/null 2>&1 || true
|
||||
|
||||
########################### end RPM installation section
|
||||
|
||||
########################### begin RPM deinstallation section
|
||||
%preun
|
||||
# If doing RPM un-install
|
||||
if [ $1 -eq 0 ] ; then
|
||||
FL="%{_docdir}/%{name}-%{version}/file.list
|
||||
%{_docdir}/%{name}/file.list"
|
||||
FL=$(for d in $FL ; do if [ -e $d ]; then echo $d; break; fi; done)
|
||||
|
||||
# Remove driver link
|
||||
for f in $(sed 's/\.new$//' $FL) ; do
|
||||
rm -f $f
|
||||
done
|
||||
|
||||
# Restore old drivers
|
||||
if [ -d /usr/local/share/%{name} ]; then
|
||||
cd /usr/local/share/%{name}; find . -name '%{driver_name}.*o*' -exec cp --parents {} /lib/modules/ \;
|
||||
cd /usr/local/share/%{name}; find . -name '%{driver_name}_*.*o*' -exec cp --parents {} /lib/modules/ \;
|
||||
rm -rf /usr/local/share/%{name}
|
||||
fi
|
||||
fi
|
||||
|
||||
%postun
|
||||
uname -r | grep BOOT || /sbin/depmod -a > /dev/null 2>&1 || true
|
||||
|
||||
########################### end RPM deinstallation section
|
||||
|
||||
#### end e1000e.spec
|
||||
|
||||
=closetwisty
|
||||
|
||||
=head3 Create the Customization Key for the e1000e Driver, Example for x86_64
|
||||
|
||||
Go to the customization key directory for SL5.1 and create the basic
|
||||
files.
|
||||
|
||||
# cd /afs/psi.ch/software/linux/dist/scientific/51/kickstart/custom/
|
||||
# mkdir e1000e
|
||||
# cd e1000e
|
||||
# touch custom.sh
|
||||
# vi custom.sh
|
||||
|
||||
=opentwisty
|
||||
|
||||
#!/bin/bash
|
||||
#
|
||||
# KS Customization for e1000e driver
|
||||
#
|
||||
# marc.gasser@psi.ch
|
||||
# 2009-02-24
|
||||
#
|
||||
# KSII scriplet rules apply
|
||||
#
|
||||
# This customization was added for the Intel Gigabit ethernet
|
||||
# card 82567LM, which comes with the new Fujitsu Siemens computers
|
||||
# Celsius W370, Esprimo p7935 e80, Esprimo e7935 e80 and Lifebook e8420,
|
||||
# because the e1000e.ko version 0.2.0 coming with SL kernels <= 2.6.18-92.1.22.el5
|
||||
# does not support this kind of hardware.
|
||||
#
|
||||
##############################################################
|
||||
# Changelog:
|
||||
# ---------
|
||||
#
|
||||
##############################################################
|
||||
|
||||
ARCH=$(uname -m)
|
||||
DIR_E1000E=/mnt/master/linux/dist/scientific/51/psi/all
|
||||
|
||||
# Install the kernel-module-e1000e containing the e1000e driver
|
||||
if test "$ARCH" = "x86_64"
|
||||
then
|
||||
echo "Install kernel-module-e1000e for $ARCH" >> $POSTLOG 2>&1
|
||||
rpm -ivh $DIR_E1000E/kernel-module-e1000e-2.6.18-92.1.22.el5-0.4.1.7-1.x86_64.rpm || \
|
||||
echo error installing kernel-module-e1000e \
|
||||
>> $POSTLOG 2>&1
|
||||
else
|
||||
echo "Install kernel-module-e1000e for $ARCH" >> $POSTLOG 2>&1
|
||||
rpm -ivh $DIR_E1000E/kernel-module-e1000e-2.6.18-92.1.22.el5-0.4.1.7-1.i386.rpm || \
|
||||
echo error installing kernel-module-e1000e \
|
||||
>> $POSTLOG 2>&1
|
||||
fi
|
||||
|
||||
=closetwisty
|
||||
|
||||
Copy the kernel-module-e1000e RPMS to F</mnt/master/linux/dist/scientific/51/psi/all/>
|
||||
and F</mnt/master/linux/dist/scientific/51/kernel/all/>, create the symbolic links
|
||||
in the corresponding F<current> and/or F<testing> repositories, and run C<createrepo>
|
||||
within F<current> and/or F<testing>.
|
||||
|
||||
That's it. Now you can test the installation using the custom key
|
||||
F<e1000e>.
|
||||
@@ -1,236 +0,0 @@
|
||||
Linux How To - RPM - Update psi-desktop Package on SL5
|
||||
======================================================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
Contemporary there are many PSI related cron jobs which are executed
|
||||
at the same time on all linux clients. As a consequence too many AFS
|
||||
requests coming from these clients are sent simultaneously to the AFS
|
||||
servers causing AFS performance problems. Thus, these cron jobs should
|
||||
be spread over time. In order to have time to fix things if anything
|
||||
goes wrong, the respective jobs are scheduled within a certain time
|
||||
window instead of using the whole time range, e.g. the hourly executed
|
||||
job window ranges from 20-40 minutes of an hour and not from 0-59
|
||||
minutes.
|
||||
|
||||
At the time of writing only `/usr/sbin/psi-puppet` is configured to
|
||||
run within such a window, the time is set randomly in
|
||||
`/etc/cron.d/psi-cronjobs` during installation of the RPM psi-desktop
|
||||
to which the file belongs to, 27 in the example below::
|
||||
|
||||
#
|
||||
# /etc/cron.d/psi-cronjobs
|
||||
#
|
||||
# PSI related cronjobs
|
||||
#
|
||||
# Urs Beyerle, PSI
|
||||
#
|
||||
|
||||
# Run puppet every hour at xx:27
|
||||
27 * * * * root /usr/sbin/psi-puppet >/dev/null 2>&1
|
||||
|
||||
# Send info back to master daily at 10:00
|
||||
00 10 * * * root /usr/sbin/psi-sendinfo >/dev/null 2>&1
|
||||
|
||||
# Run psi-auto-udpate daily at 00:30, 01:30, 02:30, 04:30
|
||||
30 00 * * * root /usr/sbin/psi-auto-update >> /var/log/update/psi-update.log 2>&1
|
||||
30 02 * * * root /usr/sbin/psi-auto-update >> /var/log/update/psi-update.log 2>&1
|
||||
30 03 * * * root /usr/sbin/psi-auto-update >> /var/log/update/psi-update.log 2>&1
|
||||
30 04 * * * root /usr/sbin/psi-auto-update >> /var/log/update/psi-update.log 2>&1
|
||||
|
||||
|
||||
- /usr/sbin/psi-puppet: Runs puppetd, but only if AUTO_UPDATE_CONFIG=yes
|
||||
- /usr/sbin/psi-auto-update: Runs the psi-update script if AUTO_UPDATE_RPMS=yes
|
||||
- /usr/sbin/psi-update: Runs the yum_update script
|
||||
(Will get the script yum_update from our master.
|
||||
The script yum_update will be saved as psi-yum_update.
|
||||
Afterwards psi-yum_update will be executed locally.)
|
||||
|
||||
Now the following jobs should be scheduled analogously.#???
|
||||
|
||||
- `/etc/cron.hourly/update_afs_users`
|
||||
|
||||
- `/etc/cron.hourly/update_environment_modules`
|
||||
|
||||
Maybe the time window for `/usr/sbin/psi-puppet` has to be expanded.
|
||||
|
||||
- Are there GFA related things which should be scheduled in a new manner?#???
|
||||
|
||||
Procedure Description
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Go to the relevant build system (e.g. tux50). Get the sources for
|
||||
building the psi-desktop RPM, unpack them and apply your modifications
|
||||
in the unpacked files. When finished tar and gzip again, build the new
|
||||
RPM, and, eventually, test it on a test machine.
|
||||
|
||||
|
||||
Procedure Step by Step
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Get The Source RPM
|
||||
....................
|
||||
|
||||
Run::
|
||||
|
||||
# [gasser_m@tux50]
|
||||
# cd /scratch/gasser_m/rpm_topdir/SRPMS/
|
||||
# ll /scratch/redhat/SRPMS/
|
||||
total 11M
|
||||
-rw-r--r-- 1 beyerle ait 4.9M Jun 30 08:09 psi-desktop-1.3.3-16.slp5.src.rpm
|
||||
-rw-r--r-- 1 beyerle ait 4.9M Jun 30 08:11 psi-desktop-1.3.3-17.slp5.src.rpm
|
||||
-rw-r--r-- 1 beyerle ait 5.3K Jun 30 10:32 nxcleanup-0.3-1.slp5.src.rpm
|
||||
-rw-r--r-- 1 beyerle ait 6.0K Jul 9 10:40 nxcleanup-0.4-1.slp5.src.rpm
|
||||
-rw-r--r-- 1 beyerle ait 418K Jul 16 10:48 aufs-0.20080605.cvs-5.slp5.src.rpm
|
||||
-rw-r--r-- 1 beyerle ait 642K Jul 29 12:57 ntfs-3g-1.2712-4.slp5.src.rpm
|
||||
|
||||
# cp /scratch/redhat/SRPMS/psi-desktop-1.3.3-17.slp5.src.rpm .
|
||||
# rpm -ivh psi-desktop-1.3.3-17.slp5.src.rpm
|
||||
|
||||
This will install the files
|
||||
`/scratch/gasser_m/rpm_topdir/SOURCES/psi-desktop-1.3.3.tar.gz` and
|
||||
`/scratch/gasser_m/rpm_topdir/SPECS/psi-desktop.spec`::
|
||||
|
||||
# cd /scratch/gasser_m/rpm_topdir/SOURCES/
|
||||
# tar xfz psi-desktop-1.3.3.tar.gz
|
||||
|
||||
Apply Your Modifications
|
||||
........................
|
||||
|
||||
Edit `/scratch/gasser_m/rpm_topdir/SPECS/psi-desktop.spec`::
|
||||
|
||||
Modified Parts in "psi-desktop.spec"
|
||||
------------------------------------
|
||||
Note: Some lines are cut at the end.
|
||||
|
||||
NEW VERSION | OLD VERSION
|
||||
---------------------------------------------------------------------------------------------------------------------
|
||||
...
|
||||
Release: 18%{?dist} | Release: 17%{?dist}
|
||||
...
|
||||
Packager: Marc Gasser <marc.gasser@psi.ch> | Packager: Urs Beyerle <urs.beyerle@psi.ch>
|
||||
...
|
||||
#### begin psi-cronjobs ############################ | # randomly runs puppet in psi-cronjobs
|
||||
# | # create a random number between 0-9
|
||||
# Randomly run commands in "/etc/cron.d/psi-cronjobs" | random=${RANDOM:1:1}
|
||||
# | [ ! $random ] && random=0
|
||||
# /usr/sbin/psi-puppet: hourly at random1 | sed -i "s/random/$random/" /etc/cron.d/psi-cronjobs
|
||||
random1=$[ ( $RANDOM % 20 ) + 21 ] # create a random n|
|
||||
[ ! $random1 ] && random1=33 |
|
||||
sed -i "s/random1/$random1/g" /etc/cron.d/psi-cronjobs |
|
||||
|
|
||||
# /usr/sbin/psi-sendinfo: daily at 10:1random2 |
|
||||
# /usr/sbin/update_environment_modules: daily at 06:0random|
|
||||
# /usr/sbin/update_afs_users: hourly at XX:1random2 |
|
||||
random2=$[ ( $RANDOM % 10 ) ] # create a random number be|
|
||||
[ ! $random2 ] && random2=3 |
|
||||
sed -i "s/random2/$random2/g" /etc/cron.d/psi-cronjobs |
|
||||
|
|
||||
#### end psi-cronjobs ############################ |
|
||||
...
|
||||
---------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
|
||||
Edit `/etc/cron.d/psi-cronjobs`. The modified `psi-cronjobs` which
|
||||
will be packed into the new `psi-desktop` RPM::
|
||||
|
||||
# cd /scratch/gasser_m/rpm_topdir/SOURCES/psi-desktop-1.3.3/slp5/etc/cron.d
|
||||
# vi psi-cronjobs
|
||||
|
||||
#
|
||||
# /etc/cron.d/psi-cronjobs
|
||||
#
|
||||
# PSI related cronjobs
|
||||
#
|
||||
# Marc Gasser, PSI
|
||||
#
|
||||
# Note: The time settings for these cron jobs are
|
||||
# set in "psi-desktop.spec". They are
|
||||
# randomized within a specific time window.
|
||||
# The randomization takes place when the RPM is
|
||||
# installed, thus it is client specific.
|
||||
|
||||
|
||||
# Run psi-puppet every hour at XX:random1
|
||||
random1 * * * * root /usr/sbin/psi-puppet >/dev/null 2>&1
|
||||
|
||||
# Send info back to master daily at 10:1random2
|
||||
1random2 10 * * * root /usr/sbin/psi-sendinfo >/dev/null 2>&1
|
||||
|
||||
# Run psi-auto-udpate daily at 00:4random2, 01:4random2, 02:4random2, 04:4random2
|
||||
4random2 00 * * * root /usr/sbin/psi-auto-update >> /var/log/update/psi-update.log 2>&1
|
||||
4random2 02 * * * root /usr/sbin/psi-auto-update >> /var/log/update/psi-update.log 2>&1
|
||||
4random2 03 * * * root /usr/sbin/psi-auto-update >> /var/log/update/psi-update.log 2>&1
|
||||
4random2 04 * * * root /usr/sbin/psi-auto-update >> /var/log/update/psi-update.log 2>&1
|
||||
|
||||
# Run update_environment_modules daily at 06:0random2, 13:0random2, 18:0random2
|
||||
0random2 06 * * * root /usr/sbin/update_environment_modules >/dev/null 2>&1
|
||||
0random2 13 * * * root /usr/sbin/update_environment_modules >/dev/null 2>&1
|
||||
0random2 18 * * * root /usr/sbin/update_environment_modules >/dev/null 2>&1
|
||||
|
||||
# Run update_afs_users every hour at XX:1random2
|
||||
1random2 * * * * root /usr/sbin/update_afs_users >/dev/null 2>&1
|
||||
|
||||
|
||||
Move commands which are controlled by `/etc/cron.d/psi-cronjobs` to
|
||||
`/usr/sbin/` if not done yet::
|
||||
|
||||
# cd /scratch/gasser_m/rpm_topdir/SOURCES/psi-desktop-1.3.3/slp5/
|
||||
# mv etc/cron.d/update_environment_modules usr/sbin/
|
||||
# mv etc/cron.d/update_afs_users usr/sbin/
|
||||
|
||||
Cronjob Schedule in `psi-cronjobs`
|
||||
..................................
|
||||
|
||||
Applying this `psi-desktop.spec` to the file `psi-cronjobs` will
|
||||
randomly distribute the respective cronjobs whithin the time windows
|
||||
given below. The randomization takes place when the RPM is installed
|
||||
or updated on the client.
|
||||
|
||||
- `/usr/sbin/psi-puppet`: hourly from HH:21 to HH:40.
|
||||
|
||||
- `/usr/sbin/psi-sendinfo`: daily from 10:10 to 10:19.
|
||||
|
||||
- `/usr/sbin/update_environment_modules`: daily from 06:00 to 06:09,
|
||||
from 13:00 to 13:09 and from 18:00 to 18:09.
|
||||
|
||||
- `/usr/sbin/update_afs_users`: hourly from HH:10 to HH:19.
|
||||
|
||||
|
||||
Build the new `psi-desktop` RPM
|
||||
...............................
|
||||
|
||||
Build both, the new RPM and the new SRPM applying the spec file::
|
||||
|
||||
# cd /scratch/gasser_m/rpm_topdir/SOURCES/
|
||||
# tar cfz psi-desktop-1.3.3.tar.gz psi-desktop-1.3.3
|
||||
# rm -rf psi-desktop-1.3.3/
|
||||
# cd /scratch/gasser_m/rpm_topdir/SPECS/
|
||||
# rpmbuild -ba psi-desktop.spec
|
||||
|
||||
Test the New `psi-desktop` RPM
|
||||
..............................
|
||||
|
||||
The file
|
||||
`tux50:/scratch/gasser_m/rpm_topdir/RPMS/noarch/psi-desktop-1.3.3-18.slp5.noarch.rpm`
|
||||
was copied to `pc7377:/tmp/` and updated using yum::
|
||||
|
||||
# [root@pc7377 etc]
|
||||
# yum update /tmp/psi-desktop-1.3.3-18.slp5.noarch.rpm
|
||||
|
||||
|
||||
Add the New `psi-desktop` RPM to Psi-All Repository
|
||||
...................................................
|
||||
|
||||
Copy the new RPM to the respective SL5 repository. Update the
|
||||
`repodata` and the symbolic links in `.../RPMSall/...` if necessary::
|
||||
|
||||
# [gasser_m@tux50 ~]
|
||||
# cd /scratch/gasser_m/rpm_topdir/RPMS/noarch/
|
||||
# cp psi-desktop-1.3.3-18.slp5.noarch.rpm /afs/psi.ch/software/linux/dist/scientific/51/psi/all/
|
||||
|
||||
# cd /afs/psi.ch/software/linux/dist/scientific/51/psi/all/
|
||||
# createrepo .
|
||||
# cd /afs/psi.ch/software/linux/dist/scientific/51/scripts
|
||||
# make rpms_all
|
||||
@@ -1,452 +0,0 @@
|
||||
Linux How To - SL5 - Nvidia Driver Installation/Update On SL51 i386
|
||||
===================================================================
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
- https://wiki.intranet.psi.ch/AIT/Linux/HowToDKMS?skin=clean.nat%2cpsiskin%2cpattern #Update_nvidia_x11_drv_driver_to
|
||||
|
||||
- [[DynamicKernelModuleSupportBasics][Dynamic Kernel Module Support (DKMS) Basics]]
|
||||
|
||||
|
||||
Requirements
|
||||
~~~~~~~~~~~~
|
||||
|
||||
DKMS (Dynamic Kernel Module Support) framework has to be installed
|
||||
before the nvidia RPM installation, because the RPM scripts use it for
|
||||
proper setup::
|
||||
|
||||
# yum install dkms.noarch
|
||||
|
||||
|
||||
Procedure
|
||||
~~~~~~~~~
|
||||
|
||||
Check what graphic card is in your computer and what driver is
|
||||
installed::
|
||||
|
||||
# lspci
|
||||
...
|
||||
01:00.0 VGA compatible controller: nVidia Corporation G72 [GeForce 7300 LE] (rev a1)
|
||||
|
||||
# less /etc/X11/xorg.conf
|
||||
(See the output below at "before nvidia installation".)
|
||||
|
||||
# rpm -qa | grep nvid
|
||||
(nothing found)
|
||||
|
||||
Before beginning with the installation of the new graphics driver,
|
||||
make a backup of your current `xorg.conf`::
|
||||
|
||||
# cd /etc/X11/
|
||||
# cp xorg.conf xorg.conf_bak
|
||||
|
||||
Check whether some nvidia driver is available::
|
||||
|
||||
# [root@pc7377 X11]# yum list | grep nvidia
|
||||
nvidia-x11-drv.i386 100.14.19-3.9.slp5 sl51psi
|
||||
|
||||
# [root@pc7377 X11]# yum install nvidia-x11-drv.i386
|
||||
|
||||
|
||||
### begin output
|
||||
Loading "kernel-module" plugin
|
||||
Setting up Install Process
|
||||
Setting up repositories
|
||||
Reading repository metadata in from local files
|
||||
Parsing package install arguments
|
||||
Resolving Dependencies
|
||||
--> Populating transaction set with selected packages. Please wait.
|
||||
---> Downloading header for nvidia-x11-drv to pack into transaction set.
|
||||
nvidia-x11-drv-100.14.19- 100% |=========================| 24 kB 00:00
|
||||
---> Package nvidia-x11-drv.i386 0:100.14.19-3.9.slp5 set to be updated
|
||||
--> Running transaction check
|
||||
--> Processing Dependency: dkms for package: nvidia-x11-drv
|
||||
--> Restarting Dependency Resolution with new changes.
|
||||
--> Populating transaction set with selected packages. Please wait.
|
||||
---> Downloading header for dkms to pack into transaction set.
|
||||
dkms-2.0.17.4-1.9.slp5.no 100% |=========================| 36 kB 00:00
|
||||
---> Package dkms.noarch 0:2.0.17.4-1.9.slp5 set to be updated
|
||||
--> Running transaction check
|
||||
Beginning Kernel Module Plugin
|
||||
Finished Kernel Module Plugin
|
||||
|
||||
Dependencies Resolved
|
||||
|
||||
=============================================================================
|
||||
Package Arch Version Repository Size
|
||||
=============================================================================
|
||||
Installing:
|
||||
nvidia-x11-drv i386 100.14.19-3.9.slp5 sl51psi 7.1 M
|
||||
Installing for dependencies:
|
||||
dkms noarch 2.0.17.4-1.9.slp5 sl51psi 89 k
|
||||
|
||||
Transaction Summary
|
||||
=============================================================================
|
||||
Install 2 Package(s)
|
||||
Update 0 Package(s)
|
||||
Remove 0 Package(s)
|
||||
|
||||
Total download size: 7.2 M
|
||||
Is this ok [y/N]: y
|
||||
Downloading Packages:
|
||||
(1/2): nvidia-x11-drv-100 100% |=========================| 7.1 MB 00:00
|
||||
(2/2): dkms-2.0.17.4-1.9. 100% |=========================| 89 kB 00:00
|
||||
Running Transaction Test
|
||||
Finished Transaction Test
|
||||
Transaction Test Succeeded
|
||||
Running Transaction
|
||||
Installing: dkms ######################### [1/2]
|
||||
Installing: nvidia-x11-drv ######################### [2/2]
|
||||
|
||||
Installed: nvidia-x11-drv.i386 0:100.14.19-3.9.slp5
|
||||
Dependency Installed: dkms.noarch 0:2.0.17.4-1.9.slp5
|
||||
Complete!
|
||||
[root@pc7377 X11]# dkms status -m nvidia
|
||||
nvidia, 100.14.19-3.9.slp5, 2.6.18-92.1.10.el5, i686: installed
|
||||
nvidia, 100.14.19-3.9.slp5, 2.6.18-53.1.4.el5, i686: installed-weak from 2.6.18-92.1.10.el5
|
||||
nvidia, 100.14.19-3.9.slp5, 2.6.18-53.1.21.el5, i686: installed-weak from 2.6.18-92.1.10.el5
|
||||
[root@pc7377 X11]# rpm -q --scripts nvidia-x11-drv-100
|
||||
package nvidia-x11-drv-100 is not installed
|
||||
[root@pc7377 X11]# rpm -q --scripts nvidia-x11-drv
|
||||
postinstall scriptlet (using /bin/sh):
|
||||
/sbin/ldconfig
|
||||
# Make sure we have a Files section in xorg.conf, otherwise create an empty one
|
||||
XORGCONF=/etc/X11/xorg.conf
|
||||
[ -w ${XORGCONF} ] && ! grep -q 'Section "Files"' ${XORGCONF} && \
|
||||
echo -e 'Section "Files"\nEndSection' >> ${XORGCONF}
|
||||
# Enable the proprietary driver
|
||||
/usr/sbin/nvidia-config-display enable || :
|
||||
# Add to DKMS registry
|
||||
dkms add -m nvidia -v 100.14.19-3.9.slp5 -q || :
|
||||
# Rebuild and make available for the currenty running kernel
|
||||
dkms build -m nvidia -v 100.14.19-3.9.slp5 -q || :
|
||||
dkms install -m nvidia -v 100.14.19-3.9.slp5 -q --force || :
|
||||
/sbin/MAKEDEV nvidia
|
||||
preuninstall scriptlet (using /bin/sh):
|
||||
# Remove all versions from DKMS registry
|
||||
dkms remove -m nvidia -v 100.14.19-3.9.slp5 -q --all || :
|
||||
# Last removal, disable the proprietary driver
|
||||
if [ $1 -eq 0 ]; then
|
||||
/usr/sbin/nvidia-config-display disable || :
|
||||
fi
|
||||
postuninstall program: /sbin/ldconfig
|
||||
### end output
|
||||
|
||||
Check the status of the nvidia kernel module. (From the dkms manpage:
|
||||
`dkms status` returns the current status of modules, versions and
|
||||
kernels within the tree as well as whether they have been added, built
|
||||
or installed.)::
|
||||
|
||||
# dkms status -m nvidia
|
||||
nvidia, 100.14.19-3.9.slp5, 2.6.18-92.1.10.el5, i686: installed
|
||||
nvidia, 100.14.19-3.9.slp5, 2.6.18-53.1.4.el5, i686: installed-weak from 2.6.18-92.1.10.el5
|
||||
nvidia, 100.14.19-3.9.slp5, 2.6.18-53.1.21.el5, i686: installed-weak from 2.6.18-92.1.10.el5
|
||||
|
||||
List the package specific scriptlet(s) that are used as part of the
|
||||
installation and uninstallation processes::
|
||||
|
||||
# rpm -q --scripts nvidia-x11-drv
|
||||
|
||||
### begin output
|
||||
postinstall scriptlet (using /bin/sh):
|
||||
/sbin/ldconfig
|
||||
# Make sure we have a Files section in xorg.conf, otherwise create an empty one
|
||||
XORGCONF=/etc/X11/xorg.conf
|
||||
[ -w ${XORGCONF} ] && ! grep -q 'Section "Files"' ${XORGCONF} && \
|
||||
echo -e 'Section "Files"\nEndSection' >> ${XORGCONF}
|
||||
# Enable the proprietary driver
|
||||
/usr/sbin/nvidia-config-display enable || :
|
||||
# Add to DKMS registry
|
||||
dkms add -m nvidia -v 100.14.19-3.9.slp5 -q || :
|
||||
# Rebuild and make available for the currenty running kernel
|
||||
dkms build -m nvidia -v 100.14.19-3.9.slp5 -q || :
|
||||
dkms install -m nvidia -v 100.14.19-3.9.slp5 -q --force || :
|
||||
/sbin/MAKEDEV nvidia
|
||||
preuninstall scriptlet (using /bin/sh):
|
||||
# Remove all versions from DKMS registry
|
||||
dkms remove -m nvidia -v 100.14.19-3.9.slp5 -q --all || :
|
||||
# Last removal, disable the proprietary driver
|
||||
if [ $1 -eq 0 ]; then
|
||||
/usr/sbin/nvidia-config-display disable || :
|
||||
fi
|
||||
postuninstall program: /sbin/ldconfig
|
||||
### end output
|
||||
|
||||
|
||||
Check whether your xorg.conf was modified to use the nvidia driver::
|
||||
|
||||
# less /etc/X11/xorg.conf
|
||||
|
||||
### begin output
|
||||
(after nvidia installation) # (before nvidia installation)
|
||||
# Xorg configuration created by pyxf86config # # Xorg configuration created by pyxf86config
|
||||
#
|
||||
Section "ServerLayout" # Section "ServerLayout"
|
||||
Identifier "Default Layout" # Identifier "Default Layout"
|
||||
Screen 0 "Screen0" 0 0 # Screen 0 "Screen0" 0 0
|
||||
InputDevice "Keyboard0" "CoreKeyboard" # InputDevice "Keyboard0" "CoreKeyboard"
|
||||
EndSection # EndSection
|
||||
#
|
||||
Section "Files" #
|
||||
ModulePath "/usr/lib/xorg/modules/extensions/nvidia" #
|
||||
ModulePath "/usr/lib/xorg/modules" #
|
||||
EndSection #
|
||||
#
|
||||
Section "InputDevice" # Section "InputDevice"
|
||||
Identifier "Keyboard0" # Identifier "Keyboard0"
|
||||
Driver "kbd" # Driver "kbd"
|
||||
Option "XkbModel" "pc105" # Option "XkbModel" "pc105"
|
||||
Option "XkbLayout" "ch" # Option "XkbLayout" "ch"
|
||||
Option "XkbVariant" "de_nodeadkeys" # Option "XkbVariant" "de_nodeadkeys"
|
||||
EndSection # EndSection
|
||||
#
|
||||
Section "Device" # Section "Device"
|
||||
Identifier "Videocard0" # Identifier "Videocard0"
|
||||
Driver "nvidia" # Driver "nv"
|
||||
EndSection # EndSection
|
||||
#
|
||||
Section "Screen" # Section "Screen"
|
||||
Identifier "Screen0" # Identifier "Screen0"
|
||||
Device "Videocard0" # Device "Videocard0"
|
||||
DefaultDepth 24 # DefaultDepth 24
|
||||
SubSection "Display" # SubSection "Display"
|
||||
Viewport 0 0 # Viewport 0 0
|
||||
Depth 24 # Depth 24
|
||||
EndSubSection # EndSubSection
|
||||
EndSection # EndSection
|
||||
### end output #
|
||||
|
||||
|
||||
Test the module with glxgears for instance::
|
||||
|
||||
[root@pc7377 ~]# glxgears
|
||||
|
||||
11424 frames in 5.0 seconds = 2284.662 FPS
|
||||
11291 frames in 5.0 seconds = 2258.003 FPS
|
||||
11244 frames in 5.0 seconds = 2248.682 FPS
|
||||
11290 frames in 5.0 seconds = 2257.974 FPS
|
||||
12626 frames in 5.0 seconds = 2525.121 FPS
|
||||
3439 frames in 5.0 seconds = 687.363 FPS
|
||||
964 frames in 5.0 seconds = 192.629 FPS
|
||||
964 frames in 5.0 seconds = 192.620 FPS
|
||||
1395 frames in 5.0 seconds = 278.978 FPS
|
||||
12080 frames in 5.0 seconds = 2415.854 FPS
|
||||
11252 frames in 5.0 seconds = 2250.348 FPS
|
||||
|
||||
|
||||
Problem With Automatic Nvidia Driver Update On SL51 i386
|
||||
--------------------------------------------------------
|
||||
|
||||
Problem Description
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
On some systems the automatic nvidia driver update by dkms fails.
|
||||
Somehow when the new RPM `nvidia-x11-drv-169.12-4.9.slp5` is installed
|
||||
by yum or rpm, the old nvidia version `100.14.19-3.9.slp5` remains in
|
||||
dkms status `added`, i.e. the respective directory remains in the dkms
|
||||
tree, while the original driver sources are removed from `/usr/src/`,
|
||||
i.e. the RPM `nvidia-x11-drv-100.14.19-3.9.slp5` was removed.
|
||||
|
||||
During reboot the service `dkms_autoinstaller` (see `chkconfig
|
||||
--list`) obviously tries to build the old `100.14.19-3.9.slp5` as well
|
||||
because it tries to get the file
|
||||
`/var/lib/dkms/nvidia/100.14.19-3.9.slp5/source/dkms.conf`. This,
|
||||
however, fails because the `.../scource` is a symbolic link pointing
|
||||
to the source directory that was removed during the nvidia RPM update
|
||||
as mentioned before::
|
||||
|
||||
"source -> /usr/src/nvidia-100.14.19-3.9.slp5"
|
||||
|
||||
Though, this basically would not be a problem if dkms was not confused
|
||||
by the occurences of several nvidia versions in its tree under
|
||||
`/var/lib/dkms/nvidia/`.
|
||||
|
||||
The main questions are:
|
||||
|
||||
- Why does the update procedure only partially clean the installation
|
||||
environment (under `/usr/src/` it is clean, under
|
||||
`/var/lib/dkms/nvidia/` it is not)?
|
||||
|
||||
- Why does dkms not properly recognize the new nvidia version only but
|
||||
also tries to build modules out of the sources of the older version?
|
||||
|
||||
|
||||
Solution
|
||||
~~~~~~~~
|
||||
|
||||
The problem appears if the nvidia driver RPM is installed or updated
|
||||
before the dkms framework is ready on the system, because the RPM
|
||||
scripts invoke a variety of `dkms` commands to install the new driver
|
||||
into the dkms tree and to remove the old driver version from it. Thus,
|
||||
one has to install the dkms RPM first, before doing any driver
|
||||
installation or updates.
|
||||
|
||||
Manual Update Using DKMS
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Perform the following steps::
|
||||
|
||||
[root@pc7377 ~]# dkms status -m nvidia
|
||||
nvidia, 100.14.19-3.9.slp5, 2.6.18-92.1.10.el5, i686: installed
|
||||
nvidia, 100.14.19-3.9.slp5, 2.6.18-92.1.13.el5, i686: installed
|
||||
nvidia, 100.14.19-3.9.slp5, 2.6.18-53.1.4.el5, i686: installed-weak from 2.6.18-92.1.10.el5
|
||||
nvidia, 100.14.19-3.9.slp5, 2.6.18-53.1.4.el5, i686: installed-weak from 2.6.18-92.1.13.el5
|
||||
nvidia, 100.14.19-3.9.slp5, 2.6.18-53.1.21.el5, i686: installed-weak from 2.6.18-92.1.10.el5
|
||||
nvidia, 100.14.19-3.9.slp5, 2.6.18-53.1.21.el5, i686: installed-weak from 2.6.18-92.1.13.el5
|
||||
nvidia, 100.14.19-3.9.slp5, 2.6.18-92.1.10.el5, i686: installed-weak from 2.6.18-92.1.13.el5
|
||||
|
||||
[root@pc7377 ~]# uname -a
|
||||
Linux pc7377 2.6.18-92.1.13.el5 #1 SMP Wed Sep 24 16:44:34 EDT 2008 i686 i686 i386 GNU/Linux
|
||||
|
||||
[root@pc7377 ~]# locate nvidia.ko
|
||||
/lib/modules/2.6.18-53.1.21.el5/weak-updates/lib/modules/2.6.18-92.1.10.el5/kernel/drivers/video/nvidia/nvidia.ko
|
||||
/lib/modules/2.6.18-53.1.21.el5/weak-updates/lib/modules/2.6.18-92.1.13.el5/kernel/drivers/video/nvidia/nvidia.ko
|
||||
/lib/modules/2.6.18-53.1.4.el5/weak-updates/lib/modules/2.6.18-92.1.10.el5/kernel/drivers/video/nvidia/nvidia.ko
|
||||
/lib/modules/2.6.18-53.1.4.el5/weak-updates/lib/modules/2.6.18-92.1.13.el5/kernel/drivers/video/nvidia/nvidia.ko
|
||||
/lib/modules/2.6.18-92.1.10.el5/kernel/drivers/video/nvidia/nvidia.ko
|
||||
/lib/modules/2.6.18-92.1.10.el5/weak-updates/lib/modules/2.6.18-92.1.13.el5/kernel/drivers/video/nvidia/nvidia.ko
|
||||
/lib/modules/2.6.18-92.1.13.el5/kernel/drivers/video/nvidia/nvidia.ko
|
||||
/var/lib/dkms/nvidia/100.14.19-3.9.slp5/2.6.18-92.1.10.el5/i686/module/nvidia.ko
|
||||
/var/lib/dkms/nvidia/100.14.19-3.9.slp5/2.6.18-92.1.13.el5/i686/module/nvidia.ko
|
||||
|
||||
[root@pc7377 ~]# rpm -q nvidia-x11-drv
|
||||
nvidia-x11-drv-100.14.19-3.9.slp5
|
||||
|
||||
[root@pc7377 ~]# cp -i /etc/X11/xorg.conf /etc/X11/xorg.conf_orig
|
||||
|
||||
[root@pc7377 ~]# yum --enablerepo=psi-beta update nvidia-x11-drv
|
||||
...
|
||||
=============================================================================
|
||||
Package Arch Version Repository Size
|
||||
=============================================================================
|
||||
Updating:
|
||||
nvidia-x11-drv i386 169.12-4.9.slp5 psi-beta 9.7 M
|
||||
|
||||
Transaction Summary
|
||||
=============================================================================
|
||||
Install 0 Package(s)
|
||||
Update 1 Package(s)
|
||||
Remove 0 Package(s)
|
||||
|
||||
Total download size: 9.7 M
|
||||
Is this ok [y/N]: y
|
||||
Downloading Packages:
|
||||
(1/1): nvidia-x11-drv-169 100% |=========================| 9.7 MB 00:00
|
||||
Running Transaction Test
|
||||
Finished Transaction Test
|
||||
Transaction Test Succeeded
|
||||
Running Transaction
|
||||
Updating : nvidia-x11-drv ######################### [1/2]
|
||||
|
||||
Cleanup : nvidia-x11-drv ######################### [2/2]
|
||||
|
||||
Updated: nvidia-x11-drv.i386 0:169.12-4.9.slp5
|
||||
|
||||
|
||||
- Note
|
||||
|
||||
`yum update` takes some time because it invokes dkms, which builds
|
||||
the required module(s) on the fly and does the cleaning up, see
|
||||
`nvidia.spec` or the output of `rpm -q --scripts RPM`::
|
||||
|
||||
|
||||
[root@pc7377 nvidia]# rpm -q --scripts nvidia-x11-drv-169.12-4.9.slp5
|
||||
postinstall scriptlet (using /bin/sh):
|
||||
/sbin/ldconfig
|
||||
# Make sure we have a Files section in xorg.conf, otherwise create an empty one
|
||||
XORGCONF=/etc/X11/xorg.conf
|
||||
[ -w ${XORGCONF} ] && ! grep -q 'Section "Files"' ${XORGCONF} && \
|
||||
echo -e 'Section "Files"\nEndSection' >> ${XORGCONF}
|
||||
# Enable the proprietary driver
|
||||
/usr/sbin/nvidia-config-display enable || :
|
||||
# Add to DKMS registry
|
||||
dkms add -m nvidia -v 169.12-4.9.slp5 -q || :
|
||||
# Rebuild and make available for the currenty running kernel
|
||||
dkms build -m nvidia -v 169.12-4.9.slp5 -q || :
|
||||
dkms install -m nvidia -v 169.12-4.9.slp5 -q --force || :
|
||||
/sbin/MAKEDEV nvidia
|
||||
preuninstall scriptlet (using /bin/sh):
|
||||
# Remove all versions from DKMS registry
|
||||
dkms remove -m nvidia -v 169.12-4.9.slp5 -q --all || :
|
||||
# Last removal, disable the proprietary driver
|
||||
if [ $1 -eq 0 ]; then
|
||||
/usr/sbin/nvidia-config-display disable || :
|
||||
fi
|
||||
postuninstall program: /sbin/ldconfig
|
||||
|
||||
|
||||
Snapshot of output of `ps auxwf` during `yum update`::
|
||||
|
||||
...
|
||||
\_ /bin/bash
|
||||
root 16677 0.0 0.0 5968 1668 pts/1 S 17:25 0:00 | \_ su -
|
||||
root 16681 0.0 0.0 4804 1440 pts/1 S 17:25 0:00 | \_ -bash
|
||||
root 17409 1.6 2.1 55980 44440 pts/1 S+ 17:43 0:04 | \_ /usr/bin/python /usr/bin/yum --enablerepo=psi-beta
|
||||
root 17413 0.0 0.0 4452 1028 pts/1 S+ 17:44 0:00 | \_ /bin/sh /var/tmp/rpm-tmp.62532 2
|
||||
root 18088 0.0 0.0 5112 1764 pts/1 S+ 17:45 0:00 | \_ /bin/bash /usr/sbin/dkms install -m nvidia
|
||||
root 18188 0.0 0.0 4456 1200 pts/1 S+ 17:45 0:00 | \_ /bin/bash /sbin/weak-modules --add-modu
|
||||
root 19238 0.0 0.0 4460 692 pts/1 S+ 17:47 0:00 | \_ /bin/bash /sbin/weak-modules --add-
|
||||
root 19243 5.5 0.0 2004 452 pts/1 D+ 17:47 0:00 | \_ zcat /boot/initrd-2.6.18-53.1.4
|
||||
root 19244 2.5 0.0 1816 496 pts/1 S+ 17:47 0:00 | \_ cpio -i
|
||||
...
|
||||
|
||||
|
||||
When the new nvidia RPM was installed the old stuff was not cleaned up
|
||||
properly, the old module sources remained in the dkms tree under
|
||||
`/var/lib/dkms/nvidia/` and has to be removed manually::
|
||||
|
||||
[root@pc7377 etc]# dkms status -m nvidia
|
||||
nvidia, 100.14.19-3.9.slp5: added
|
||||
nvidia, 169.12-4.9.slp5, 2.6.18-92.1.13.el5, i686: installed
|
||||
nvidia, 169.12-4.9.slp5, 2.6.18-53.1.4.el5, i686: installed-weak from 2.6.18-92.1.13.el5
|
||||
nvidia, 169.12-4.9.slp5, 2.6.18-53.1.21.el5, i686: installed-weak from 2.6.18-92.1.13.el5
|
||||
nvidia, 169.12-4.9.slp5, 2.6.18-92.1.10.el5, i686: installed-weak from 2.6.18-92.1.13.el5
|
||||
|
||||
# rm -rf /var/lib/dkms/nvidia/100.14.19-3.9.slp5/
|
||||
# dkms status -m nvidia
|
||||
nvidia, 169.12-4.9.slp5, 2.6.18-92.1.13.el5, i686: installed
|
||||
nvidia, 169.12-4.9.slp5, 2.6.18-53.1.4.el5, i686: installed-weak from 2.6.18-92.1.13.el5
|
||||
nvidia, 169.12-4.9.slp5, 2.6.18-53.1.21.el5, i686: installed-weak from 2.6.18-92.1.13.el5
|
||||
nvidia, 169.12-4.9.slp5, 2.6.18-92.1.10.el5, i686: installed-weak from 2.6.18-92.1.13.el5
|
||||
|
||||
The `.../weak-updates/...` nvidia modules below are symbolic links to
|
||||
`/lib/modules/2.6.18-92.1.13.el5/kernel/drivers/video/nvidia/nvidia.ko`,
|
||||
which is identical with
|
||||
`/var/lib/dkms/nvidia/169.12-4.9.slp5/2.6.18-92.1.13.el5/i686/module/nvidia.ko`::
|
||||
|
||||
[root@pc7377 etc]# updatedb
|
||||
[root@pc7377 etc]# locate nvidia.ko
|
||||
/lib/modules/2.6.18-53.1.21.el5/weak-updates/lib/modules/2.6.18-92.1.13.el5/kernel/drivers/video/nvidia/nvidia.ko
|
||||
/lib/modules/2.6.18-53.1.4.el5/weak-updates/lib/modules/2.6.18-92.1.13.el5/kernel/drivers/video/nvidia/nvidia.ko
|
||||
/lib/modules/2.6.18-92.1.10.el5/weak-updates/lib/modules/2.6.18-92.1.13.el5/kernel/drivers/video/nvidia/nvidia.ko
|
||||
/lib/modules/2.6.18-92.1.13.el5/kernel/drivers/video/nvidia/nvidia.ko
|
||||
/var/lib/dkms/nvidia/169.12-4.9.slp5/2.6.18-92.1.13.el5/i686/module/nvidia.ko
|
||||
|
||||
|
||||
Nvidia related lines in `/var/log/messages`::
|
||||
|
||||
...
|
||||
Oct 23 17:48:12 pc7377 Updated: nvidia-x11-drv.i386 169.12-4.9.slp5
|
||||
...
|
||||
Oct 24 11:16:04 pc7377 kernel: NVRM: API mismatch: the client has the version 169.12, but
|
||||
Oct 24 11:16:04 pc7377 kernel: NVRM: this kernel module has the version 100.14.19. Please
|
||||
Oct 24 11:16:04 pc7377 kernel: NVRM: make sure that this kernel module and all NVIDIA driver
|
||||
Oct 24 11:16:04 pc7377 kernel: NVRM: components have the same version.
|
||||
Oct 24 11:16:05 pc7377 gdm[6706]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0
|
||||
Oct 24 11:16:09 pc7377 kernel: NVRM: API mismatch: the client has the version 169.12, but
|
||||
Oct 24 11:16:09 pc7377 kernel: NVRM: this kernel module has the version 100.14.19. Please
|
||||
Oct 24 11:16:09 pc7377 kernel: NVRM: make sure that this kernel module and all NVIDIA driver
|
||||
Oct 24 11:16:09 pc7377 kernel: NVRM: components have the same version.
|
||||
Oct 24 11:16:10 pc7377 gdm[3734]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0
|
||||
Oct 24 11:16:13 pc7377 kernel: NVRM: API mismatch: the client has the version 169.12, but
|
||||
Oct 24 11:16:13 pc7377 kernel: NVRM: this kernel module has the version 100.14.19. Please
|
||||
Oct 24 11:16:13 pc7377 kernel: NVRM: make sure that this kernel module and all NVIDIA driver
|
||||
Oct 24 11:16:13 pc7377 kernel: NVRM: components have the same version.
|
||||
Oct 24 11:16:14 pc7377 gdm[3752]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0
|
||||
Oct 24 11:16:14 pc7377 gdm[6489]: deal_with_x_crashes: Running the XKeepsCrashing script
|
||||
...
|
||||
Oct 24 11:27:45 pc7377 kernel: nvidia: module license 'NVIDIA' taints kernel.
|
||||
Oct 24 11:27:45 pc7377 kernel: ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 169
|
||||
Oct 24 11:27:45 pc7377 kernel: NVRM: loading NVIDIA UNIX x86 Kernel Module 169.12 Thu Feb 14 17:53:07 PST 2008
|
||||
...
|
||||
-131
@@ -1,131 +0,0 @@
|
||||
How To Look Up For PCI Devices And Corresponding Modules in SL5
|
||||
===============================================================
|
||||
|
||||
Weblinks
|
||||
--------
|
||||
|
||||
- Intel Driver Download Center: http://downloadcenter.intel.com/
|
||||
|
||||
- Intel Support Site: http://support.intel.com/support/index.htm
|
||||
|
||||
- Intel Network Connectivity: http://support.intel.com/support/network/sb/cs-008441.htm
|
||||
|
||||
|
||||
Procedure Description
|
||||
---------------------
|
||||
|
||||
List your PCI devices, look up for the vendor and hardware ID numbers
|
||||
and search the corresponding entry in the table which maps hardware
|
||||
IDs to module names.
|
||||
|
||||
|
||||
This might be helpful if one has a new hardware device such as a new
|
||||
network card, which is not recognized by the system because of a
|
||||
missing entry in the file
|
||||
`/lib/modules/<kernelversion>/modules.pcimap`, which maps devices to
|
||||
modules. Assumption: the required driver (module) is present.
|
||||
|
||||
|
||||
Step by Step Procedure: Example For a Working Network Card
|
||||
----------------------------------------------------------
|
||||
|
||||
List your PCI devices using `lscpi`::
|
||||
|
||||
# lspci
|
||||
...
|
||||
00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)
|
||||
...
|
||||
|
||||
Listing with `lspci -n` will show identification numbers instead of names::
|
||||
|
||||
# lspci -n
|
||||
...
|
||||
00:19.0 0200: 8086:10bd (rev 02)
|
||||
...
|
||||
|
||||
- a)
|
||||
|
||||
`19.0 PCI device number`
|
||||
|
||||
- b)
|
||||
|
||||
`0200 Hardware Type "Ethernet controller"`
|
||||
|
||||
- c)
|
||||
|
||||
`8086 Vendor ID "Intel Corporation"`
|
||||
|
||||
- d)
|
||||
|
||||
`10bd Hardware ID "82566DM-2 Gigabit Network Connection"`
|
||||
|
||||
|
||||
For a very verbose output use `lspci -vv`::
|
||||
|
||||
# lspci -vv | grep 00:19 -A 15
|
||||
00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)
|
||||
Subsystem: Fujitsu Siemens Computer GmbH Unknown device 10fd
|
||||
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
|
||||
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
|
||||
Latency: 0
|
||||
Interrupt: pin A routed to IRQ 74
|
||||
Region 0: Memory at f2200000 (32-bit, non-prefetchable) [size=128K]
|
||||
Region 1: Memory at f2225000 (32-bit, non-prefetchable) [size=4K]
|
||||
Region 2: I/O ports at 1820 [size=32]
|
||||
Capabilities: [c8] Power Management version 2
|
||||
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
|
||||
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
|
||||
Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+
|
||||
Address: 00000000fee00000 Data: 404a
|
||||
Capabilities: [e0] #13 [0306]
|
||||
|
||||
|
||||
Hovewer, take the device ID `10bd` and look for it in the `modules.pcimap`::
|
||||
|
||||
# grep 10bd /lib/modules/2.6.18-92.1.13.el5/modules.pcimap
|
||||
e1000e 0x00008086 0x000010bd 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
|
||||
|
||||
In this output one can see that the kernel module e1000e is selected
|
||||
for this network device. You can see this by "lsmod" if your network
|
||||
is up::
|
||||
|
||||
# lsmod | grep e1000e
|
||||
e1000e 92801 0
|
||||
|
||||
|
||||
Step by Step Procedure: Example For a Not Working Network Card
|
||||
--------------------------------------------------------------
|
||||
|
||||
Basically the steps from the previous section are repeated to get the
|
||||
required hardware infos.
|
||||
|
||||
Eventually the missing entry is added to `modules.pcimap`. Here we
|
||||
assume that the "e1000e" module works as well for the new network
|
||||
card::
|
||||
|
||||
# lscpi
|
||||
00:19.0 Ethernet controller: Intel Corporation Unknown device 10de (rev 02)
|
||||
|
||||
The device ID is `10de`::
|
||||
|
||||
# grep 10de /lib/modules/2.6.18-53.1.4.el5/modules.pcimap
|
||||
...
|
||||
|
||||
Only vendor IDs match the number `10de`. The following line will be
|
||||
added to `modules.pcimap`::
|
||||
|
||||
# vi /lib/modules/2.6.18-53.1.4.el5/modules.pcimap
|
||||
... adding the line
|
||||
e1000e 0x00008086 0x000010de 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
|
||||
|
||||
`ethtool`
|
||||
---------
|
||||
|
||||
Use `ethtool` to get network device specific information, e.g. query
|
||||
the specified ethernet device for associated driver information::
|
||||
|
||||
[root@pc7377 ~]# ethtool -i eth0
|
||||
driver: e1000e
|
||||
version: 0.4.1.7-NAPI
|
||||
firmware-version: 1.3-0
|
||||
bus-info: 0000:00:19.0
|
||||
@@ -1,26 +0,0 @@
|
||||
Linux Login Clusters
|
||||
====================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The following list shows the hosts of linux login clusters.
|
||||
|
||||
- SL4 32bit
|
||||
|
||||
llc5, llc6 (Schrank 3.7)
|
||||
|
||||
- SL4 64 bit
|
||||
|
||||
lcsl4a, lcsl4b (Schrank 6.9)
|
||||
|
||||
- SL5 32bit
|
||||
|
||||
lcsl5a (Schrank 6.9)
|
||||
|
||||
- SL5 64 bit
|
||||
|
||||
llcsl5a (Schrank 6.9)
|
||||
|
||||
|
||||
To watch the hosts go to the ganglia web interface: http://129.129.190.27/ganglia/
|
||||
@@ -1,533 +0,0 @@
|
||||
Load Balancer `llclb1`
|
||||
======================
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
- http://www.austintek.com/LVS/LVS-HOWTO/mini-HOWTO/LVS-mini-HOWTO.html
|
||||
|
||||
- http://www.linuxvirtualserver.org/
|
||||
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
This document describes the setup of `llclb1.psi.ch`, the Linux Login
|
||||
Cluster LoadBalancer for the ssh service on llc5 and llc6.
|
||||
|
||||
The load balancing is implemented by means of the ipvsadm utility.
|
||||
|
||||
The forwarding method is LVS_DR, direct routing (see below).
|
||||
|
||||
Terms and Abbreviations
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- LVS (Linux Virtual Server)
|
||||
|
||||
The Linux Virtual Server is a scalable server built on a cluster of
|
||||
real servers, with the load balancer (director) running on the Linux
|
||||
operating system (LVS = director + realservers). The architecture
|
||||
of the server cluster is fully transparent to end users, and the
|
||||
users interact as if it were a single server.
|
||||
|
||||
- IPVS, ip_vs
|
||||
|
||||
The code that patches the linux kernel on the director.
|
||||
|
||||
- Director (Load Balancer)
|
||||
|
||||
The node that runs the ipvs code. Clients connect to the
|
||||
director. The director forwards packets to the realservers. The
|
||||
director is nothing but an IP router with special rules that make
|
||||
the LVS work.
|
||||
|
||||
- Realservers (Servers)
|
||||
|
||||
The hosts that have the services. The realservers handle the
|
||||
requests from the clients.
|
||||
|
||||
- Client
|
||||
|
||||
The host or user level process that connects to the VIP on the
|
||||
director.
|
||||
|
||||
- Forwarding method
|
||||
|
||||
Currently LVS-NAT, LVS-DR, LVS-Tun. The director is a router with
|
||||
somewhat different rules for forwarding packets than a normal
|
||||
router. The forwarding method determines how the director sends
|
||||
packets from the client to the realservers.
|
||||
|
||||
- Scheduling
|
||||
|
||||
The algorithm the director uses to select a realserver to service a
|
||||
new connection request from a client (ipvsadm and schedulers).
|
||||
|
||||
- VIP
|
||||
|
||||
Virtual IP, the IP on the director that the client connects to.
|
||||
|
||||
- DIP
|
||||
|
||||
Director IP, the IP on the director in the network.
|
||||
|
||||
- RIP
|
||||
|
||||
Realserver IP, the IP on the realserver.
|
||||
|
||||
|
||||
General setup of an LVS
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The following figure illustrates a general layout of a network with an
|
||||
LVS::
|
||||
|
||||
_________ _________ _________
|
||||
| | | | | |
|
||||
| CLIENT 1| | CLIENT 2| | CLIENT N|
|
||||
|_________| |_________| |_________|
|
||||
| | |
|
||||
--------------------------------
|
||||
|
|
||||
___|_____
|
||||
| |
|
||||
| GATEWAY |
|
||||
|_________|
|
||||
|
|
||||
Linux Virtual Server |
|
||||
...............................................................
|
||||
. | .
|
||||
. ___VIP____ .
|
||||
. | | .
|
||||
. | DIRECTOR | .
|
||||
. |__________| .
|
||||
. DIP .
|
||||
. | .
|
||||
. ------------------------------------------ .
|
||||
. | | | .
|
||||
. | | | .
|
||||
. _____RIP1_____ ____RIP2______ _____RIPN_____ .
|
||||
. | | | | | | .
|
||||
. | REALSERVER 1 | | REALSERVER 2 | | REALSERVER N | .
|
||||
. | | | | | | .
|
||||
. |______________| |______________| |______________| .
|
||||
. .
|
||||
...............................................................
|
||||
|
||||
|
||||
|
||||
One or Two NICs on the Director
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you have one NIC on the director, the VIP and the RIP are on the
|
||||
same physical network interface, where at least one virtual NIC was
|
||||
added, to hold one of the IP addresses.
|
||||
|
||||
If you have two NICs you can assign one to the VIP network and the
|
||||
second to the RIP network.
|
||||
|
||||
Here we have one NIC on the director.
|
||||
|
||||
|
||||
Requirements For LVS-DR
|
||||
-----------------------
|
||||
|
||||
For a reasonable LVS-DR setup the following is required:
|
||||
|
||||
- One or more clients which are on networks different from the VIP and
|
||||
DIP network.
|
||||
|
||||
- The realservers must be on the same network as the director (the
|
||||
realservers and director can arp each other).
|
||||
|
||||
- One director host with at least one network interface.
|
||||
|
||||
- One, better two static IPs for the director (one for the VIP, and
|
||||
one for the DIP).
|
||||
|
||||
- Two realservers.
|
||||
|
||||
- One static IP for each realserver.
|
||||
|
||||
|
||||
**Note to the Number of IPs on the director**:
|
||||
|
||||
Depending on the service that is routed through the director, it might
|
||||
be useful to have two different IPs for the VIP and the DIP.
|
||||
|
||||
E.g.: If you load balance an ssh service and you assign one IP to your
|
||||
NIC, which acts as VIP and DIP at the same time you can not reach your
|
||||
director anymore via ssh, because all ssh requests are routed through
|
||||
to one of the realservers.
|
||||
|
||||
Installation Procedure
|
||||
----------------------
|
||||
|
||||
Director Installation
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
An SL54 server installation was performed on llclb1.
|
||||
|
||||
The director configuration shown below is implemented by means of
|
||||
puppet modules on puppet server psi-puppet1.
|
||||
|
||||
|
||||
Realserver Installation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Contemporary, the realservers llc5 and llc6 are SL46 Desktop Enhanced
|
||||
systems.
|
||||
|
||||
|
||||
One NIC LVS-DR Configuration
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The director processes only the client-to-server half of a connection
|
||||
in the virtual server via direct routing, and the response packets can
|
||||
follow separate network routes to the clients. This can greatly
|
||||
increase the scalability of virtual server.
|
||||
|
||||
Compared to the virtual server via IP tunneling approach, this
|
||||
approach doesn't have tunneling overhead (In fact, this overhead is
|
||||
minimal in most situations), but requires that one of the load
|
||||
balancer's interfaces and the real server's interfaces must be in the
|
||||
same physical segment.
|
||||
|
||||
The following figure illustrates the setup of the LVS-DR with llclb1
|
||||
(director) having one NIC. The whole LVS is on the same network::
|
||||
|
||||
|
||||
_________ _________ _________
|
||||
| | | | | |
|
||||
| CLIENT 1| | CLIENT 2| | CLIENT N|
|
||||
|_________| |_________| |_________|
|
||||
| | |
|
||||
--------------------------------
|
||||
|
|
||||
___|_____
|
||||
| |
|
||||
| GATEWAY | IP=129.129.190.1
|
||||
|_________|
|
||||
|
|
||||
LVS (for service ssh) |
|
||||
.....................................................................
|
||||
. | .
|
||||
. __________ | .
|
||||
. | llc | | VIP=129.129.190.54 (eth0:1) .
|
||||
. | | | .
|
||||
. | DIRECTOR |---| .
|
||||
. | | | .
|
||||
. | llclb1 | | DIP=129.129.190.53 (eth0) .
|
||||
. |__________| | .
|
||||
. | .
|
||||
. | .
|
||||
. ------------------------------------ .
|
||||
. | | .
|
||||
. | | .
|
||||
. RIP1=129.129.193.175 RIP2=129.129.193.176 .
|
||||
. ______________ ______________ .
|
||||
. | | | | .
|
||||
. | REALSERVER 1 | | REALSERVER 2 | .
|
||||
. | llc5 | | llc6 | .
|
||||
. |______________| |______________| .
|
||||
. .
|
||||
.....................................................................
|
||||
|
||||
|
||||
Network Configuration
|
||||
.....................
|
||||
|
||||
Configure the LVS network according the scheme shown above. Static
|
||||
IPs for llclb1, llc, llc5 and llc6 have to be assigned.
|
||||
|
||||
|
||||
Director Configuration
|
||||
......................
|
||||
|
||||
Configure the static device eth0 and restart the network.
|
||||
|
||||
`/etc/sysconfig/network-scripts/ifcfg-eth0`::
|
||||
|
||||
DEVICE=eth0
|
||||
BOOTPROTO=none
|
||||
HWADDR=00:14:5E:6B:13:3E
|
||||
ONBOOT=yes
|
||||
IPADDR=129.129.190.53
|
||||
NETMASK=255.255.255.0
|
||||
GATEWAY=129.129.193.1
|
||||
TYPE=Ethernet
|
||||
USERCTL=no
|
||||
IPV6INIT=no
|
||||
PEERDNS=yes
|
||||
|
||||
|
||||
`/etc/sysconfig/network`::
|
||||
|
||||
NETWORKING=yes
|
||||
NETWORKING_IPV6=no
|
||||
HOSTNAME=llclb1
|
||||
|
||||
|
||||
|
||||
Install the package ipvsadm::
|
||||
|
||||
# yum install ipvsadm
|
||||
|
||||
Setup the LVS for ssh on the director using the following script:
|
||||
Note: It might be better to add it to the init scripts.
|
||||
|
||||
`/etc/setup-LVS-DR-director.conf`::
|
||||
|
||||
#!/bin/bash
|
||||
#---------------mini-rc.lvs_dr-director------------------------
|
||||
|
||||
###
|
||||
### Network configuration
|
||||
###
|
||||
|
||||
VIP1=129.129.190.54
|
||||
|
||||
RIP1=129.129.190.175
|
||||
RIP2=129.129.190.176
|
||||
|
||||
|
||||
# Set ip_forward OFF for lvs-dr director (1 on, 0 off)
|
||||
# (there is no forwarding in the conventional sense for LVS-DR)
|
||||
cat /proc/sys/net/ipv4/ip_forward
|
||||
echo "0" >/proc/sys/net/ipv4/ip_forward
|
||||
|
||||
# Director is not gw for realservers: leave icmp redirects on
|
||||
echo 'setting icmp redirects (1 on, 0 off) '
|
||||
echo "1" >/proc/sys/net/ipv4/conf/all/send_redirects
|
||||
cat /proc/sys/net/ipv4/conf/all/send_redirects
|
||||
echo "1" >/proc/sys/net/ipv4/conf/default/send_redirects
|
||||
cat /proc/sys/net/ipv4/conf/default/send_redirects
|
||||
echo "1" >/proc/sys/net/ipv4/conf/eth0/send_redirects
|
||||
cat /proc/sys/net/ipv4/conf/eth0/send_redirects
|
||||
|
||||
# Add ethernet device and routing for VIP $VIP1
|
||||
/sbin/ifconfig eth0:1 $VIP1 broadcast $VIP1 netmask 255.255.255.255
|
||||
/sbin/route add -host $VIP1 dev eth0:1
|
||||
# Listing ifconfig info for VIP $VIP1
|
||||
/sbin/ifconfig eth0:1
|
||||
|
||||
# Check VIP $VIP1 is reachable from self (director)
|
||||
/bin/ping -c 1 $VIP1
|
||||
# Listing routing info for VIP $VIP1
|
||||
/bin/netstat -rn
|
||||
|
||||
###
|
||||
### Setup_ipvsadm_table
|
||||
###
|
||||
|
||||
# Clear ipvsadm table
|
||||
/sbin/ipvsadm -C
|
||||
|
||||
# Installing LVS services with ipvsadm
|
||||
# Add ssh to VIP with round robin scheduling
|
||||
/sbin/ipvsadm -A -t ${VIP1}:ssh -s rr
|
||||
|
||||
# Forward ssh to realserver using direct routing with weight 1
|
||||
/sbin/ipvsadm -a -t ${VIP1}:ssh -r $RIP1 -g -w 1
|
||||
# Check realserver reachable from director
|
||||
ping -c 1 $RIP1
|
||||
|
||||
# Forward ssh to realserver using direct routing with weight 1
|
||||
/sbin/ipvsadm -a -t ${VIP1}:ssh -r $RIP2 -g -w 1
|
||||
# Check realserver reachable from director
|
||||
ping -c 1 $RIP2
|
||||
|
||||
# Set tcp timeout to 72 hours while leaving
|
||||
# tcpfin and udp timeouts unchanged.
|
||||
/sbin/ipvsadm --set 259200 0 0
|
||||
|
||||
# List timeout values
|
||||
/sbin/ipvsadm -L --timeout
|
||||
|
||||
# Displaying ipvsadm settings
|
||||
/sbin/ipvsadm
|
||||
|
||||
# Not installing a default gw for LVS_TYPE vs-dr
|
||||
|
||||
###
|
||||
### Delete an LVS entry
|
||||
###
|
||||
#
|
||||
# Example: remove/delete ssh forwarding to RIP2
|
||||
#
|
||||
# /sbin/ipvsadm -d -t ${VIP1}:ssh -r RIP2
|
||||
#
|
||||
#
|
||||
|
||||
#---------------mini-rc.lvs_dr-director------------------------
|
||||
|
||||
|
||||
Realserver Configuration
|
||||
........................
|
||||
|
||||
The realserver shall send responses not to the VIP of the load
|
||||
balancer, rather to the client directly. This requires the iptables
|
||||
rule below.
|
||||
|
||||
Settings of realserver 2 for instance:
|
||||
|
||||
`/etc/sysconfig/network-scripts/ifcfg-eth0`::
|
||||
|
||||
DEVICE=eth0
|
||||
BOOTPROTO=none
|
||||
HWADDR=00:06:5B:8C:3C:8E
|
||||
ONBOOT=yes
|
||||
TYPE=Ethernet
|
||||
DHCP_HOSTNAME=llc6
|
||||
PEERDNS=yes
|
||||
IPADDR=129.129.190.176
|
||||
NETMASK=255.255.255.0
|
||||
GATEWAY=129.129.190.1
|
||||
USERCTL=no
|
||||
IPV6INIT=no
|
||||
|
||||
|
||||
`/etc/sysconfig/network`::
|
||||
|
||||
NETWORKING=yes
|
||||
HOSTNAME=llc6
|
||||
|
||||
|
||||
`/etc/sysconfig/lvs`::
|
||||
|
||||
# LVS configuration file for LLC and LLCX
|
||||
VIP=129.129.190.54
|
||||
|
||||
|
||||
`/etc/init.d/lvs`::
|
||||
|
||||
#! /bin/sh
|
||||
#
|
||||
# chkconfig: 345 90 10
|
||||
# description: Startscript to initialize this machine as an lvs real server.
|
||||
|
||||
# Get network configuration
|
||||
. /etc/sysconfig/network
|
||||
# Get functions
|
||||
. /etc/rc.d/init.d/functions
|
||||
# Get VIP from the LVS configuration file
|
||||
. /etc/sysconfig/lvs
|
||||
|
||||
# Check that networking is up
|
||||
if [ ${NETWORKING} = "no" ] ; then
|
||||
exit 0
|
||||
fi
|
||||
|
||||
RETVAL=0
|
||||
|
||||
# See how we were called.
|
||||
case "$1" in
|
||||
start)
|
||||
# Add rule
|
||||
echo "Starting load balancing mechanism with NAT iptables "
|
||||
/sbin/iptables -t nat -A PREROUTING -d $VIP -j REDIRECT
|
||||
;;
|
||||
stop)
|
||||
# Delete rule
|
||||
echo "Stopping load balancing mechanism with NAT iptables "
|
||||
/sbin/iptables -t nat -D PREROUTING -d $VIP -j REDIRECT
|
||||
;;
|
||||
*)
|
||||
echo "Usage: $0 {start|stop}"
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
exit $RETVAL
|
||||
|
||||
|
||||
Update Procedure
|
||||
----------------
|
||||
|
||||
Director Update
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Login to llclb1 as root and run yum update::
|
||||
|
||||
# yum clean all
|
||||
# yum update
|
||||
|
||||
Then reboot the director::
|
||||
|
||||
# reboot
|
||||
|
||||
After rebooting no lvs rules are set by default::
|
||||
|
||||
[root@llclb1 ~]# ipvsadm -L
|
||||
IP Virtual Server version 1.2.1 (size=4096)
|
||||
Prot LocalAddress:Port Scheduler Flags
|
||||
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
|
||||
|
||||
As soon as the realservers are updated and rebooted, too (see next
|
||||
section), run the lvs setup script to initialize the lvs rules for the
|
||||
ssh loadbalancing::
|
||||
|
||||
# sh /etc/setup-LVS-DR-director.conf
|
||||
|
||||
|
||||
0
|
||||
setting icmp redirects (1 on, 0 off)
|
||||
1
|
||||
1
|
||||
1
|
||||
SIOCADDRT: File exists
|
||||
eth0:1 Link encap:Ethernet HWaddr 00:14:5E:6B:13:3E
|
||||
inet addr:129.129.190.54 Bcast:129.129.190.54 Mask:255.255.255.255
|
||||
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
||||
Interrupt:169 Memory:d8300000-d8310000
|
||||
|
||||
PING 129.129.190.54 (129.129.190.54) 56(84) bytes of data.
|
||||
64 bytes from 129.129.190.54: icmp_seq=1 ttl=64 time=0.053 ms
|
||||
|
||||
--- 129.129.190.54 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 0.053/0.053/0.053/0.000 ms
|
||||
Kernel IP routing table
|
||||
Destination Gateway Genmask Flags MSS Window irtt Iface
|
||||
129.129.190.54 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
|
||||
129.129.190.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
|
||||
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
|
||||
0.0.0.0 129.129.190.1 0.0.0.0 UG 0 0 0 eth0
|
||||
PING 129.129.190.175 (129.129.190.175) 56(84) bytes of data.
|
||||
64 bytes from 129.129.190.175: icmp_seq=1 ttl=64 time=2.13 ms
|
||||
|
||||
--- 129.129.190.175 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 2.139/2.139/2.139/0.000 ms
|
||||
PING 129.129.190.176 (129.129.190.176) 56(84) bytes of data.
|
||||
64 bytes from 129.129.190.176: icmp_seq=1 ttl=64 time=0.172 ms
|
||||
|
||||
--- 129.129.190.176 ping statistics ---
|
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms
|
||||
rtt min/avg/max/mdev = 0.172/0.172/0.172/0.000 ms
|
||||
Timeout (tcp tcpfin udp): 259200 120 300
|
||||
IP Virtual Server version 1.2.1 (size=4096)
|
||||
Prot LocalAddress:Port Scheduler Flags
|
||||
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
|
||||
TCP llc.psi.ch:ssh rr
|
||||
-> llc6.psi.ch:ssh Route 1 1 1
|
||||
-> llc5.psi.ch:ssh Route 1 0 0
|
||||
|
||||
|
||||
Realserver Update
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
The realservers should be updated automatically as they are standard
|
||||
SL desktop hosts. Login as root to the corresponding realserver,
|
||||
e.g. llc5, and verify that the update was performed correctly, if not
|
||||
fix it first.
|
||||
|
||||
Then reboot the realserver. The iptables rule for the direct routing
|
||||
are initialized automatically by the init script /etc/init.d/lvs::
|
||||
|
||||
# reboot
|
||||
|
||||
Eventually, test the ssh connection from any client to llc::
|
||||
|
||||
# [anyuser@anyhost] ssh llc
|
||||
|
||||
@@ -1,164 +0,0 @@
|
||||
NX Server/Client Installation
|
||||
=============================
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
- http://freenx.berlios.de/
|
||||
|
||||
- http://nomachine.com/
|
||||
|
||||
- http://wiki.centos.org/HowTos/FreeNX/
|
||||
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
This document describes the setup of an NX server/client
|
||||
infrastructure on SL54.
|
||||
|
||||
First, a more generic installation procedure is illustrated, second,
|
||||
the PSI default nx server/client setup is shown.
|
||||
|
||||
Generic Installation
|
||||
--------------------
|
||||
|
||||
NX Server
|
||||
~~~~~~~~~
|
||||
|
||||
Required Packages
|
||||
.................
|
||||
|
||||
- nx
|
||||
- freenx
|
||||
|
||||
The packages were found in the centos-extras repository. One can use
|
||||
the following yum repo file, for instance.
|
||||
|
||||
File `/etc/yum.repos.d/centos-extras.repo`::
|
||||
|
||||
[centos-extras]
|
||||
name=Centos Extras for SL5.5
|
||||
baseurl=ftp://mirror.switch.ch/mirror/centos/5.5/extras/$basearch/
|
||||
enabled=0
|
||||
|
||||
Procedure
|
||||
.........
|
||||
|
||||
Install the required packages on your platform, i386 or x86_64::
|
||||
|
||||
# yum --enablerepo centos-extras install freenx
|
||||
|
||||
Now, generate the ssh keys::
|
||||
|
||||
# nxkeygen
|
||||
|
||||
The keys are stored in `/etc/nxserver` and in the home directory of
|
||||
the nx user account::
|
||||
|
||||
# cd /var/lib/nxserver/home/
|
||||
# ls -l .ssh/
|
||||
-rw------- 1 nx root 672 Oct 22 16:28 authorized_keys2
|
||||
-rw------- 1 nx root 672 Oct 22 16:28 client.id_dsa.key
|
||||
-rwx------ 1 nx root 392 Oct 22 16:14 known_hosts
|
||||
-rw------- 1 nx root 605 Oct 22 16:28 server.id_dsa.pub.key
|
||||
|
||||
The private key `client.id_dsa.key` has to be copied to the nx client
|
||||
(see next section).
|
||||
|
||||
NX Client
|
||||
~~~~~~~~~
|
||||
|
||||
Required Packages
|
||||
.................
|
||||
|
||||
- nxclient
|
||||
|
||||
|
||||
Procedure
|
||||
.........
|
||||
|
||||
NoMachine does not allow the distribution of their client, so it must
|
||||
be downloaded from their website at http://nomachine.com/.
|
||||
|
||||
After downloading install it::
|
||||
|
||||
# rpm -ivh nxclient-3.4.0-7.i386.rpm
|
||||
|
||||
Get the private ssh key of user nx from the server and copy it to the
|
||||
client::
|
||||
|
||||
# [root@server]
|
||||
# scp /var/lib/nxserver/home/.ssh/client.id_dsa.key client:/usr/NX/share/keys/
|
||||
|
||||
Create the following symbolic link to the key on the client::
|
||||
|
||||
# [root@client]
|
||||
# cd /usr/NX/share/keys/
|
||||
# ln -s client.id_dsa.key server.id_dsa.key
|
||||
|
||||
Now, you can login to the nx server::
|
||||
|
||||
# nxclient
|
||||
|
||||
|
||||
PSI Installation
|
||||
----------------
|
||||
|
||||
The difference between the generic and the PSI installation is, that
|
||||
the NX packages can be installed from our local repository. Further,
|
||||
the PSI default keys are part of this installation, i.e. installing
|
||||
the RPMS sets up a working NX server/client environment.
|
||||
|
||||
|
||||
NX Server
|
||||
~~~~~~~~~
|
||||
|
||||
Required Packages
|
||||
.................
|
||||
|
||||
- nx
|
||||
- freenx
|
||||
- freenx-psi
|
||||
|
||||
|
||||
Currently the server packages are available from the SL54 psi-beta
|
||||
repository, while the client packages are located in the PSI nonfree
|
||||
repo.
|
||||
|
||||
Procedure
|
||||
.........
|
||||
|
||||
File `/etc/yum.repos.d/psi-beta.repo`::
|
||||
|
||||
[psi-beta]
|
||||
name=54 psi beta
|
||||
baseurl=http://linux.web.psi.ch/dist/scientific/54/beta/
|
||||
enabled=0
|
||||
|
||||
Install freenx, nx and freenx-psi on the server::
|
||||
|
||||
# yum --enablerepo psi-beta install freenx nx freenx-psi
|
||||
|
||||
NX Client
|
||||
~~~~~~~~~
|
||||
|
||||
Required Packages
|
||||
.................
|
||||
|
||||
- nxclient
|
||||
- nxclient-psi
|
||||
|
||||
|
||||
Procedure
|
||||
.........
|
||||
|
||||
Install nxclient and nxclient-psi on the client host::
|
||||
|
||||
# yum install nxclient nxclient-psi
|
||||
|
||||
|
||||
Now, you can login to the nx server::
|
||||
|
||||
# nxclient
|
||||
|
||||
@@ -1,98 +0,0 @@
|
||||
Puppet Manifests for SL 5.3
|
||||
===========================
|
||||
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
As we are planning to upgrade from SL 5.1 to SL 5.3, we decided to
|
||||
reorganize and reimplement all the client configuration manifests.
|
||||
|
||||
|
||||
Procedure
|
||||
---------
|
||||
|
||||
**Note**: Here we are still in the development state, thus filenames
|
||||
and everything probably will be changed for the productive setup.
|
||||
|
||||
|
||||
Puppet SVN
|
||||
~~~~~~~~~~
|
||||
|
||||
To manage the changes to manifests and client configuration files we
|
||||
use `subversion (svn)` as a revision control::
|
||||
|
||||
# ENV=CnodeSL5
|
||||
# mkdir /var/puppet/environments/$ENV
|
||||
# cd /var/puppet/environments/$ENV
|
||||
|
||||
|
||||
Check out all manifests::
|
||||
|
||||
# svn co svn+ssh://svn.psi.ch/repos/linux/kickstart/trunk/puppet/manifests
|
||||
|
||||
|
||||
Check out modules individually::
|
||||
|
||||
# mkdir /var/puppet/environments/$ENV/modules
|
||||
# cd /var/puppet/environments/$ENV/modules
|
||||
# svn co svn+ssh://svn.psi.ch/repos/linux/kickstart/trunk/puppet/Modules/facts
|
||||
# svn co svn+ssh://svn.psi.ch/repos/linux/kickstart/trunk/puppet/Modules/cnode
|
||||
# svn co svn+ssh://svn.psi.ch/repos/linux/kickstart/trunk/puppet/Modules/psibasic
|
||||
# svn co svn+ssh://svn.psi.ch/repos/linux/kickstart/trunk/puppet/Modules/ssh
|
||||
# svn co svn+ssh://svn.psi.ch/repos/linux/kickstart/trunk/puppet/Modules/ntp
|
||||
# svn co svn+ssh://svn.psi.ch/repos/linux/kickstart/trunk/puppet/Modules/scratch
|
||||
|
||||
|
||||
On the Puppet Server Side
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Restart the puppet server. For testing use some increased verbosity
|
||||
(-v), debug mode (-d) and log to a file (-l). Set these options in
|
||||
`/etc/init.d/puppetmaster` using variable `PUPPETMASTER_OPTS`::
|
||||
|
||||
# vi /etc/init.d/puppetmaster
|
||||
...
|
||||
PUPPETMASTER_OPTS="-v -d -l /var/log/puppet/puppetmaster.log"
|
||||
...
|
||||
|
||||
# /etc/init.d/puppetmaster restart
|
||||
|
||||
|
||||
On the Puppet Client Side
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To specify which environment the Puppet client uses you can specify a
|
||||
value for the environment configuration variable in the client's
|
||||
`puppet.conf` file. Here the environment `developmentSL53` is set.
|
||||
|
||||
Additionally the name of the puppet server `psi-puppet1.psi.ch` is
|
||||
assigned::
|
||||
|
||||
# vi /etc/puppet/puppet.conf
|
||||
[main]
|
||||
vardir = /var/puppet
|
||||
logdir = /var/log/puppet
|
||||
rundir = /var/run/puppet
|
||||
ssldir = $vardir/ssl
|
||||
environment = developmentSL53
|
||||
|
||||
[puppetd]
|
||||
classfile = $vardir/classes.txt
|
||||
localconfig = $vardir/localconfig
|
||||
factsync = true
|
||||
server = psi-puppet1.psi.ch
|
||||
|
||||
In the Kickstart
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
In the SL 5.3 Installation Tree
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Create the base directories, its subdirectories and some first test
|
||||
file for the `Basic` class as declared above in the manifest
|
||||
`basic.pp` on the server::
|
||||
|
||||
# cd /afs/psi.ch/software/linux/dist/scientific/53/
|
||||
# mkdir -p puppet/files/Basic/etc
|
||||
# touch puppet/files/Basic/etc/puppet-test-file
|
||||
@@ -1,188 +0,0 @@
|
||||
Update SL53 i386 and x86_64
|
||||
===========================
|
||||
|
||||
Get Native Scientific Linux Updates
|
||||
-----------------------------------
|
||||
|
||||
This section describes how the particular linux repositories are
|
||||
updated by looking for new RPMS in our mirror and copying them from
|
||||
there to the repositories.
|
||||
|
||||
|
||||
Get the Latest Security Update RPMS
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Get the latest security update RPMS from the local SL53 mirror for
|
||||
both architectures, i386 and x86_64, by invoking
|
||||
`update_repo_all_directories.sh` on tux50. They will be copied to the
|
||||
corresponding `.../update.${ARCH}/all/` directories. This will take
|
||||
some time::
|
||||
|
||||
# cd /afs/psi.ch/software/linux/dist/scientific/53/scripts/
|
||||
# ./update_repo_all_directories.sh > ~/tmp/20090930-update_repo_all_directories.sl53.output 2>&1
|
||||
|
||||
Then, check for errors in the log file::
|
||||
|
||||
# grep -i error ~/tmp/20090930-update_repo_all_directories.sl53.output
|
||||
...
|
||||
|
||||
Finally, run `update_symlinks_in_rpms_all.sh` to keep all symlinks in
|
||||
the directory
|
||||
`/afs/psi.ch/software/linux/dist/scientific/53/RPMS_all/` up to date.
|
||||
|
||||
The script removes dead links and creates new links to the new RPMS.
|
||||
It is basically not necessary for running PSI updates, rather it's
|
||||
just convenient to have a directory with the list of all RPMS of a
|
||||
distribution::
|
||||
|
||||
# ./update_symlinks_in_rpms_all.sh
|
||||
|
||||
|
||||
Create A New PSI Version And Release The SLP Snapshots
|
||||
------------------------------------------------------
|
||||
|
||||
Keep the following order:
|
||||
|
||||
- Update the "all" repositories. (Described in section texttext)
|
||||
|
||||
- Create new snapshots. (Described in section texttext)
|
||||
|
||||
- Release "unstable" from new snapshots.
|
||||
|
||||
- Create a new PSI version.
|
||||
|
||||
- Release "testing".
|
||||
|
||||
- Release "stable".
|
||||
|
||||
|
||||
Release Unstable
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The "unstable" distribution is where active development of SLP occurs.
|
||||
Generally, this distribution is run by developers and those who like
|
||||
to live on the edge.
|
||||
|
||||
The command `release_unstable.sh` will update the respective symlinks
|
||||
`.../unstable` to the latest snapshots.
|
||||
|
||||
Because `release_unstable.sh` is interactive, you should not redirect
|
||||
the output to a file, as you won't be able to see the questions asked.
|
||||
|
||||
Before `release_unstable.sh`::
|
||||
|
||||
# [gasser_m@tux50]
|
||||
# cd /afs/psi.ch/software/linux/dist/scientific/53/
|
||||
# ls -l */unstable
|
||||
|
||||
# ./release_unstable.sh
|
||||
|
||||
After `release_unstable.sh`::
|
||||
|
||||
# ls -l */unstable
|
||||
|
||||
As soon as an unstable distribution has become testing a new unstable
|
||||
can be generated that again points to the new latest snapshots.
|
||||
|
||||
|
||||
Create A New PSI Version
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As soon as the new PSI version is created, i.e. the symbolic links
|
||||
which point to the same target snapshots as the latest unstable
|
||||
snapshots, the PSI auto-update process is active again for the hosts
|
||||
which are set to unstable::
|
||||
|
||||
# cd /afs/psi.ch/software/linux/dist/scientific/53/scripts
|
||||
# ./create_new_psi_version.sh
|
||||
|
||||
|
||||
Release Testing
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
The "testing" distribution contains packages that haven't been
|
||||
accepted into a "stable" release yet, but they are in the queue for
|
||||
that. The main advantage of using this distribution is that it has
|
||||
more recent versions of software.
|
||||
|
||||
The command `release_testing.sh` will update the respective symlinks
|
||||
`.../testing` to the latest unstable snapshots.
|
||||
|
||||
Because `release_testing.sh` is interactive, you should not redirect
|
||||
the output to a file, as you won't be able to see the questions asked.
|
||||
|
||||
Before `release_testing.sh`::
|
||||
|
||||
# [gasser_m@tux50]
|
||||
# cd /afs/psi.ch/software/linux/dist/scientific/53/
|
||||
# ls -l */testing
|
||||
|
||||
# ./release_testing.sh
|
||||
|
||||
After `release_testing.sh`::
|
||||
|
||||
# ls -l */testing
|
||||
|
||||
|
||||
Release Stable
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
The "stable" distribution, formerly known as "current", contains the
|
||||
latest officially released distribution of SLP.
|
||||
|
||||
This is the production release of SLP, the one which we primarily
|
||||
recommend using.
|
||||
|
||||
The command `release_stable.sh` will update the respective symlinks
|
||||
`.../stable` to the latest unstable snapshots.
|
||||
|
||||
Because `release_stable.sh` is interactive, you should not redirect
|
||||
the output to a file, as you won't be able to see the questions asked.
|
||||
|
||||
Before `release_stable.sh`::
|
||||
|
||||
# [gasser_m@tux50]
|
||||
# cd /afs/psi.ch/software/linux/dist/scientific/53/
|
||||
# ls -l */stable
|
||||
|
||||
lrwxr-xr-x 1 gasser_m ait 8 Sep 18 11:25 cluster/stable -> 20090316
|
||||
lrwxr-xr-x 1 gasser_m ait 8 Sep 18 11:23 enhanced/stable -> 20090316
|
||||
lrwxr-xr-x 1 gasser_m ait 18 Sep 18 11:24 kernel/stable -> 2.6.18-128.1.1.el5
|
||||
lrwxr-xr-x 1 gasser_m ait 8 Sep 18 11:24 nonfree/stable -> 20090316
|
||||
lrwxr-xr-x 1 gasser_m ait 8 Sep 18 11:22 others/stable -> 20090316
|
||||
lrwxr-xr-x 1 gasser_m ait 8 Sep 18 11:21 psi/stable -> 20090821
|
||||
lrwxr-xr-x 1 gasser_m ait 8 Sep 18 11:22 update.i386/stable -> 20090820
|
||||
lrwxr-xr-x 1 gasser_m ait 8 Sep 18 11:21 update.x86_64/stable -> 20090820
|
||||
|
||||
# ./release_stable.sh
|
||||
|
||||
### begin ./release_stable.sh ###
|
||||
Sourcing configuration file ./dist-config
|
||||
|
||||
TOP_DIR is /afs/psi.ch/software/linux/dist/scientific/53
|
||||
|
||||
Running ./release_stable.sh ...
|
||||
|
||||
Latest snapshot in psi:
|
||||
/afs/psi.ch/software/linux/dist/scientific/53/psi/testing -> 20090916
|
||||
Latest snapshot in others:
|
||||
/afs/psi.ch/software/linux/dist/scientific/53/others/testing -> 20090916
|
||||
Latest snapshot in update.i386:
|
||||
/afs/psi.ch/software/linux/dist/scientific/53/update.i386/testing -> 20090916
|
||||
Latest snapshot in update.x86_64:
|
||||
/afs/psi.ch/software/linux/dist/scientific/53/update.x86_64/testing -> 20090916
|
||||
Latest snapshot in enhanced:
|
||||
/afs/psi.ch/software/linux/dist/scientific/53/enhanced/testing -> 20090916
|
||||
Latest snapshot in kernel:
|
||||
/afs/psi.ch/software/linux/dist/scientific/53/kernel/testing -> 2.6.18-128.7.1.el5
|
||||
Latest snapshot in nonfree:
|
||||
/afs/psi.ch/software/linux/dist/scientific/53/nonfree/testing -> 20090916
|
||||
Latest snapshot in cluster:
|
||||
/afs/psi.ch/software/linux/dist/scientific/53/cluster/testing -> 20090916
|
||||
|
||||
Relink stable to the latest snapshots (y/n)?
|
||||
|
||||
|
||||
After `release_stable.sh`::
|
||||
|
||||
# ls -l */stable
|
||||
@@ -1,21 +0,0 @@
|
||||
Repair the RPM DB
|
||||
=================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
Sometimes the rpm database gets broken and any command of manipulating
|
||||
or questioning RPMS might fail.
|
||||
|
||||
So, it can be necessary to remove the corrupted RPM database and to
|
||||
reinitialize it.
|
||||
|
||||
Procedure
|
||||
---------
|
||||
|
||||
Run::
|
||||
|
||||
# cd /var/lib/rpm
|
||||
# rm -f __db.*
|
||||
# rpmdb --initdb
|
||||
# rpmdb --rebuilddb
|
||||
@@ -1,120 +0,0 @@
|
||||
Installation of SAP Citrix Client and Prerequisites
|
||||
===================================================
|
||||
|
||||
SL6 32 bit
|
||||
----------
|
||||
|
||||
First tests with rebuild of SRPMS of pcsc-lite and pcsc-lite-libs
|
||||
version 1.5.2-7 without hal support.
|
||||
|
||||
Install pcsl-lite 1.5.2 (SmartCard daemon)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Run::
|
||||
|
||||
# yum install pcsc-lite
|
||||
# yum install pcsc-lite-libs
|
||||
|
||||
|
||||
Install Omnikey SmartCard driver
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Run::
|
||||
|
||||
# yum --enablerepo beta install omnikey-usb-3121-driver # todo: move the driver to the stable repo
|
||||
# /etc/init.d/pcscd restart
|
||||
|
||||
or for debug mode::
|
||||
|
||||
# /usr/sbin/pcscd -df
|
||||
|
||||
|
||||
Install Citrix ICA Client
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Run::
|
||||
|
||||
# yum install openmotif libXp
|
||||
# yum install ICAClient
|
||||
|
||||
|
||||
SL6 64 bit
|
||||
----------
|
||||
|
||||
Install pcsc-lite-1.5.3
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The following packages have to be present/installed.
|
||||
|
||||
- alsa-lib, alsa-lib.i686, gtk2-devel, gtk2-devel.i386, glibc, glibc.i686, glibc-devel, glibc-devel.i686
|
||||
- libgcc, libgcc.i686, libusb, libusb.i686, libusb-devel, libusb-devel.i686
|
||||
- libXpm, libXpm.i686, libXaw, libXaw.i686, nspluginwrapper, nspluginwrapper.i686
|
||||
- openmotif, openmotif.i686, openmotif-devel, openmotif-devel.i686
|
||||
- libusb1, libusb1.i686, libusb1-devel, libusb1-devel.i686
|
||||
|
||||
Remove the preinstalled pcsc-lite packages::
|
||||
|
||||
# rpm -e --nodeps pcsc-lite pcsc-lite-libs pcsc-lite-openct
|
||||
|
||||
|
||||
Download, unpack pcsc-lite-1.5.3 sources, run configure and build the
|
||||
daemon::
|
||||
|
||||
# wget --no-check-certificate https://alioth.debian.org/frs/download.php/3017/pcsc-lite-1.5.3.tar.bz2
|
||||
# tar xvf pcsc-lite-1.5.3.tar
|
||||
# cd pcsc-lite-1.5.3.tar
|
||||
|
||||
# ./configure --enable-usbdropdir=/usr/lib/pcsc/drivers --disable-libhal --prefix=/usr CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
|
||||
|
||||
# make
|
||||
# make check
|
||||
# make install
|
||||
|
||||
|
||||
Install Omnikey SmartCard driver
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Run::
|
||||
|
||||
# yum --enablerepo beta install omnikey-usb-3121-driver # todo: move the driver to the stable repo
|
||||
#todo: dependency pcsc-lite-libs???
|
||||
# /etc/init.d/pcscd restart
|
||||
|
||||
or for debug mode::
|
||||
|
||||
# /usr/sbin/pcscd -df
|
||||
|
||||
|
||||
Install Citrix ICA Client
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Run::
|
||||
|
||||
# yum install openmotif libXp
|
||||
# yum install ICAClient
|
||||
|
||||
|
||||
Start SAP Session
|
||||
-----------------
|
||||
|
||||
Plug in the Omnikey 3121 USB SmartCard reader, and plug in the
|
||||
SmartCard.
|
||||
|
||||
Start the Citrix Receiver (E.g. in KDE: Applications --> Internet -->
|
||||
Citrix Receiver) and login to the terminal server tsadlm01, use your
|
||||
Windows login and password.
|
||||
|
||||
Then run the APPGATE_Start application by clicking the icon.
|
||||
|
||||
Open the connection to the server acc1.caz.admin.ch using the method
|
||||
certificate and keep the autoselected certificate, read from the
|
||||
SmartCard reader. Click ok.
|
||||
|
||||
Enter your password for the SmartCard token and click ok.
|
||||
|
||||
Internet Explorer starts and pops up to websites, HP something and one
|
||||
from the BIT. Close them or leave them, as you like.
|
||||
|
||||
Switch to the cmd.exe console of the terminal server and press any
|
||||
key. UltraLogon will start and open the SAP main window, where you
|
||||
select your session.
|
||||
@@ -1,46 +0,0 @@
|
||||
VPN Client on Linux
|
||||
===================
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
- vpnc manpage
|
||||
|
||||
Requirements
|
||||
------------
|
||||
|
||||
- VPN Client Package
|
||||
|
||||
|
||||
Procedure
|
||||
---------
|
||||
|
||||
Installation
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Login as localadmin (Green PC) or root (Red PC) and install the VPN
|
||||
related packages::
|
||||
|
||||
# yum install vpnclient-psi
|
||||
# yum install vpnc
|
||||
|
||||
Configuration
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
For Users
|
||||
.........
|
||||
|
||||
You don't have to configure anything manually, the configuration was
|
||||
done by installing the `vpnclient-psi` package.
|
||||
|
||||
For Packager
|
||||
............
|
||||
|
||||
The default configuration files are `/etc/vpnc/default.conf` and
|
||||
`/etc/vpnc.conf`.
|
||||
|
||||
The Cisco VPN client config file `vpn-psi.pcf` for PSI is provided by
|
||||
Tobias Marx. The command `/usr/share/doc/vpnc-0.5.3/pcf2vpnc` is used
|
||||
to convert the `.pcf` to `.conf`::
|
||||
|
||||
# perl /usr/share/doc/vpnc-0.5.3/pcf2vpnc vpn-psi.pcf vpn-psi.conf
|
||||
@@ -1,19 +0,0 @@
|
||||
Services
|
||||
========
|
||||
|
||||
Login cluster
|
||||
-------------
|
||||
|
||||
The login cluster allows users to run interactive programs. The
|
||||
cluster consists of several nodes `llcN.psi.ch`, where N is 1, 2,
|
||||
or 3. There is also a load-balancer, `llclb1.psi.ch`, which uses IPVS
|
||||
with a round robin policy to distribute incoming connections.
|
||||
|
||||
|
||||
Jump hosts
|
||||
----------
|
||||
|
||||
Many servers can only be accessed via SSH through one of the two jump
|
||||
hosts, `wmgt01.psi.ch` and `wmgt02.psi.ch`. These two systems require
|
||||
two-factor authentication (currently using a Cryptocard dongle) and
|
||||
offer a very restricted environment.
|
||||
@@ -1,10 +0,0 @@
|
||||
Software
|
||||
========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
software/repositories
|
||||
software/packaging
|
||||
software/modules
|
||||
|
||||
@@ -1,26 +0,0 @@
|
||||
Modules
|
||||
=======
|
||||
|
||||
The Scientific Computing team provides a number of programs using Modules. The
|
||||
Modules configuration files and the corresponding software are stored on AFS.
|
||||
|
||||
To use Modules it is necessary to create a symlink::
|
||||
|
||||
ln -snf /afs/psi.ch/sys/psi.x86_64.slp6/ /opt/psi
|
||||
|
||||
where ``x86_64.slp6`` describes the architecture and OS of the system the
|
||||
modules should be used on. It is the output of ``fs sysname``. Every session
|
||||
needs to ``source /opt/psi/config/profile.bash`` as well.
|
||||
|
||||
The available modules can be listed by running::
|
||||
|
||||
module avail
|
||||
|
||||
Note that the modules are hierarchical, i.e. only the modules that can actually
|
||||
be loaded are listed. Some modules require that other modules are loaded first,
|
||||
e.g. a certain version of gcc, and are listed only after that has been done.
|
||||
|
||||
Modules are loaded by running::
|
||||
|
||||
module load gcc/4.7.3
|
||||
|
||||
@@ -1,35 +0,0 @@
|
||||
Packaging
|
||||
=========
|
||||
|
||||
Currently, the two most important custom packages are OpenAFS and GPFS
|
||||
(see below), but there are many others. The sources and spec files
|
||||
for RPMs are stored on AFS in
|
||||
`/afs/psi.ch/project/linux/src/scientific/RPMS/` and
|
||||
`/afs/psi.ch/project/linux/src/RPMS/`. They should be - and partially
|
||||
have been - moved to Gitlab, group `linux-packages`.
|
||||
|
||||
|
||||
Build hosts
|
||||
-----------
|
||||
|
||||
|
||||
OpenAFS
|
||||
-------
|
||||
|
||||
|
||||
GPFS
|
||||
----
|
||||
|
||||
The source files for GPFS as well as certain tools for building the
|
||||
packages are stored in
|
||||
`/afs/psi.ch/project/linux/src/scientific/RPMS/gpfs/`. The
|
||||
`README.build` file in that directory contains instructions on how to
|
||||
build GPFS for a given combination of GPFS version and kernel version.
|
||||
|
||||
The files `default-version.${release}.${architecture}` contain the
|
||||
GPFS Release and supported versions for the specific `${release}` and
|
||||
`${architecture}`, e.g.::
|
||||
|
||||
GPFSVERSION="3.5.0-24 4.1.1-4"
|
||||
GPFSRELEASE=7
|
||||
|
||||
@@ -1,245 +0,0 @@
|
||||
Repositories
|
||||
============
|
||||
|
||||
A number of repositories are currently mirrored on AFS under
|
||||
``/afs/psi.ch/software/mirror`` (``$MIRROR``), in particular the following
|
||||
versions of Scientific Linux, both 32 and 64 bit: 5.7, 6.0, 6.4, and 6.x.
|
||||
|
||||
The repositories are accessible via HTTP at http://linux.web.psi.ch/.
|
||||
|
||||
They are stored in ``$MIRROR/scientific``, each subdirectory of which
|
||||
is a mount point for a separate AFS volume. This is done because
|
||||
smaller AFS volumes are easier to handle (e.g. when moving them
|
||||
between fileservers).
|
||||
|
||||
Each mirror, e.g. ``$MIRROR/scientific/60/epelp/`` contains a
|
||||
subdirectory ``all``, which contains the packages that we actually
|
||||
want in our YUM repositories.
|
||||
|
||||
Repository management as well as package building can be done on the
|
||||
various ``tux*.psi.ch`` servers.
|
||||
|
||||
Further documentation on repository management can be found in
|
||||
``/afs/psi.ch/project/linux/doc``. This documentation will eventually
|
||||
be included in this document.
|
||||
|
||||
The directory ``$MIRROR/scientific/scripts`` contains scripts for
|
||||
various tasks related to managing the Scientific Linux repositories.
|
||||
It is a working copy of a [git
|
||||
repository](http://git.psi.ch/linux-dist/sl-scripts).
|
||||
|
||||
|
||||
Tools
|
||||
-----
|
||||
|
||||
There are several scripts that are used to maintain/update the various
|
||||
repositories.
|
||||
|
||||
|
||||
``sync_updates.sh``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This script copies new packages from the SL mirror to the PSI distribution
|
||||
directories, and runs ``createrepo --update`` to update the repository metadata.
|
||||
|
||||
Information on the directories is read from a file ``dist-config`` in the
|
||||
current working directory.
|
||||
|
||||
|
||||
``update_symlinks``
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Updates
|
||||
-------
|
||||
|
||||
To release updates to the existing repositories, the steps below have to be
|
||||
performed. The value of ``DIST_DIR`` is the base directory of the distribution
|
||||
to be updated, i.e. ``/afs/psi.ch/software/linux/dist/scientific/xx/``, where
|
||||
``xx`` is one of ``57``, ``60``, or ``64``.
|
||||
|
||||
1. Update add-on repositories
|
||||
2. cd "${DIST_DIR}/scripts"
|
||||
3. ./sync_updates.sh
|
||||
4. ./update_symlinks.sh
|
||||
5. ./create_snapshots.sh alldirs
|
||||
6. ./release_unstable.sh
|
||||
7. ./incr_version.sh
|
||||
8. ./update_version_info.sh
|
||||
9. test new unstable release
|
||||
10. ./release.sh testing
|
||||
11. ./update_version-info.sh
|
||||
12. test testing release
|
||||
13. ./release.sh stable
|
||||
14. ./update_version-info.sh
|
||||
|
||||
The sections below describe each step in detail. The value of ``PRJ_DIR`` is
|
||||
``/afs/psi.ch/project/linux/``.
|
||||
|
||||
|
||||
Kernel updates
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
If there is a new kernel, some of the modules need to be rebuilt. For SL 5.7
|
||||
there is a script in the ``scripts`` subdirectory taking care of this:
|
||||
``build_kernel_modules.sh``.
|
||||
|
||||
|
||||
Update add-on repositories
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
GPFS
|
||||
,,,,
|
||||
|
||||
rsync --archive --verbose ${PRJ_DIR}/dist/slp6/RPMS/*/kmod-gpfs* "${DIST_DIR}/psi/all"
|
||||
rsync --archive --verbose ${PRJ_DIR}/dist/slp6/RPMS/*/gpfs* "${DIST_DIR}/nonfree/all"
|
||||
|
||||
Notes:
|
||||
|
||||
- Don't know why the kernel modules for GPFS are in 'psi' but the GPFS user-land
|
||||
software is in 'nonfree'.
|
||||
- Hans-Christian is responsible for building RPMs
|
||||
|
||||
|
||||
OpenAFS
|
||||
,,,,,,,
|
||||
|
||||
Note: OpenAFS version on tux50 and tux50-64 is 1.4.x. On all other systems it is 1.6.x.
|
||||
|
||||
Build OpenAFS
|
||||
+++++++++++++
|
||||
|
||||
On tux50, tux50-64, tux60-tux60-64, tux70.
|
||||
|
||||
Either::
|
||||
|
||||
rsync --verbose ${PRJ_DIR}/dist/slp6/RPMS/*/kernel-module-openafs-* "${DIST_DIR}/psi/all"
|
||||
|
||||
or: copy decicated versions
|
||||
|
||||
Notes: Achim is responsible for building OpenAFS RPMs.
|
||||
|
||||
Checklist
|
||||
+++++++++
|
||||
|
||||
New version available? If yes, build binaries:
|
||||
|
||||
========= ===== ========= ========
|
||||
OS New? Compiled Copied?
|
||||
--------- ----- --------- --------
|
||||
tux50 no
|
||||
tux50-64 no
|
||||
tux60 yes yes yes
|
||||
tux60-64 yes yes yes
|
||||
tux70-64 yes yes yes
|
||||
========= ===== ========= ========
|
||||
|
||||
New kernel or version available? If yes, install kernel, build module:
|
||||
========= ===== ========= ========
|
||||
OS New? Compiled Copied?
|
||||
--------- ----- --------- --------
|
||||
tux50 no - -
|
||||
tux50-64 no - -
|
||||
tux60 yes yes yes
|
||||
tux60-64 yes yes yes
|
||||
tux70-64 yes yes yes
|
||||
========= ===== ========= ========
|
||||
|
||||
ZFS
|
||||
,,,
|
||||
|
||||
ZFS kernel modules are available for EL7 only!
|
||||
|
||||
Sync from master repository
|
||||
+++++++++++++++++++++++++++
|
||||
|
||||
Run on tux70-64 as normal user::
|
||||
|
||||
reposync --repoid=zfs --norepopath --download_path /afs/psi.ch/software/mirror/zfsonlinux/7/x86_64
|
||||
|
||||
Build kmod
|
||||
++++++++++
|
||||
|
||||
Build on tux70-64 as root.
|
||||
|
||||
Boot into the right (newest) kernel! This is the kernel we are going to build
|
||||
the modules for. Run::
|
||||
|
||||
# set some variables
|
||||
$ ZFS_VERS='x.y.z'
|
||||
$ ZFS_REL='r'
|
||||
$ ZFS_REPO_DIR='/afs/psi.ch/software/linux/dist/scientificlinux/7x/x86_64/zfs/'
|
||||
$ DIST='el7'
|
||||
$ ARCH='x86_64'
|
||||
|
||||
$ cd /usr/src/spl-$ZFS_VERS
|
||||
$ ./configure
|
||||
$ make rpm-utils rpm-kmod
|
||||
|
||||
# Install the spl packages, they are required to build zfs.
|
||||
$ yum localinstall \
|
||||
kmod-spl-devel-$ZFS_VERS-$ZFS_REL.$DIST.$ARCH.rpm \
|
||||
kmod-spl-devel-kernel-$ZFS_VERS-$ZFS_REL.$DIST.$ARCH.rpm \
|
||||
kmod-spl-kernel-$ZFS_VERS-$ZFS_REL.$DIST.$ARCH.rpm \
|
||||
spl-$ZFS_VERS-$ZFS_REL.$DIST.$ARCH.rpm
|
||||
|
||||
$ cd ../zfs-x.y.z
|
||||
$ ./configure
|
||||
$ make rpm-utils rpm-kmod
|
||||
|
||||
# you need an AFS-token to copy the files!
|
||||
$ klog.openafs USERNAME
|
||||
|
||||
# for a new ZFS version do
|
||||
$ cp -v spl-$ZFS_VERS/*.x86_64.rpm "$ZFS_REPO_DIR"
|
||||
$ cp -v zfs-$ZFS_VERS/*.x86_64.rpm "$ZFS_REPO_DIR"
|
||||
|
||||
# to copy kernel modules only, do
|
||||
$ cp -v spl-$ZFS_VERS/kmod-*-$(uname -r)*.x86_64.rpm "$ZFS_REPO_DIR"
|
||||
$ cp -v zfs-$ZFS_VERS/kmod-*-$(uname -r)*.x86_64.rpm "$ZFS_REPO_DIR"
|
||||
|
||||
# update repo
|
||||
$ cd "$ZFS_REPO_DIR"
|
||||
$ createrepo --update .
|
||||
|
||||
See also: `<http://zfsonlinux.org/generic-rpm.html>`_
|
||||
|
||||
Checklist
|
||||
+++++++++
|
||||
|
||||
If there is a new version: Are the RPM of the new versions of spl-x.y.z and
|
||||
zfs-x.y.z in ``/afs/psi.ch/software/linux/dist/scientificlinux/7x/x86_64/zfs/``?
|
||||
|
||||
Are the kmod-RPM's for the newest kernel in
|
||||
``/afs/psi.ch/software/linux/dist/scientificlinux/7x/x86_64/zfs/``?
|
||||
|
||||
Flash Player
|
||||
,,,,,,,,,,,,
|
||||
|
||||
Download
|
||||
++++++++
|
||||
|
||||
Current Flash-Player must be downloaded from `Adobe
|
||||
<https://get.adobe.com/de/flashplayer/otherversions/>`_ and copied to
|
||||
``${DIST_DIR}/nonfree/all``.
|
||||
|
||||
Checklist
|
||||
+++++++++
|
||||
|
||||
Is the newest version installed in
|
||||
``/afs/psi.ch/software/linux/dist/scientific/xx/nonfree/all/`` (``xx`` in
|
||||
``57``, ``60``, ``64``)?
|
||||
|
||||
|
||||
NVidia
|
||||
,,,,,,
|
||||
|
||||
syslog-ng
|
||||
,,,,,,,,,
|
||||
|
||||
openntpd
|
||||
,,,,,,,,
|
||||
|
||||
@@ -1,10 +0,0 @@
|
||||
Storage
|
||||
=======
|
||||
|
||||
Currently, data is generally stored on AFS. In particular:
|
||||
|
||||
- ``/afs/psi.ch/software/mirror``: Mirrors of external repositories and
|
||||
software, e.g. CentOS, EPEL.
|
||||
- ``/afs/psi.ch/software/linux/kickstart``: Kickstart files and related
|
||||
tools/packages.
|
||||
- ``/afs/psi.ch/software/linux/dist/``: YUM repositories used at PSI.
|
||||
Reference in New Issue
Block a user