Kleine und große Linux AHAs
Systemmanagement
Tipps und Tricks für Systemmanagement (Scripte, HowTos, Erfahrungen, …)
pam_mount
30. Nov
Wie bereits geschrieben musste ich mir für die “komfortable” Nutzung meines verschlüsselten /home Verzeichnisses etwas neues einfallen lassen. Gesagt getan. Das PAM Modul pam_mount ist Dein Freund. Wenn ich mir das so recht ansehe, ist diese Lösung auch wirklich schön und ich bin ein wenig traurig, dass ich das nicht früher schon einmal gefunden habe – aber egal.
pam_mount ist ein PAM Modul, welches bei der Anmeldung ausgeführt wird. Man kann definieren, welcher Benutzer welches Verzeichnis bei der Anmeldung mountet. Das ganze funktioniert eben auch mit über cryptsetup angelegten Volumes, die mit dem bei der Anmeldung angegebenen Passwort dann auch gemountet werden (sofern das Passwort passt).
Die Einrichtung ist sehr einfach:
-
das Paket libpam-mount installieren
-
unter /etc/security/ die Datei pam_mount.conf.xml als root öffnen
-
nach der Zeile "<!-- Volume definitions -->" eine Definition wie z.B. "<volume fstype="crypt" path="/dev/sda7" mountpoint="/home" options="fsck" />" eintragen
Mit dieser Konfiguration wird bei einer Anmeldung versucht /home auf /dev/sda7 mit dem angegebenen Passwort (das Passwort des Benutzers) zu mounten. Eine Zeile wie
<volume user="testuser" fstype="crypt" path="/dev/sda7" mountpoint="/home/testuser" options="fsck" />
würde entsprechend das ganze nur versuchen, wenn der User testuser sich anmeldet und auch nur dessen Home mounten.
Wichtig zu wissen – für diverse Szenarien – ist, dass man für ein mit cryptsetup eingerichtetes Volume auch mehrere Passwörter vergeben kann. Damit ist es möglich die Konfiguration des ersten Beispiels für mehrere Benutzer einzurichten. Ebenfalls wichtig ist, dass wenn man das Passwort ändert, man ebenfalls das Passwort des verschlüsselten Laufwerks ändern muss (das geschieht über … addkey, … remove key).
Problem mit LUKS (cryptsetup) unter Ubuntu 9.10 (Karmic)
25. Nov
Zuhause habe ich mein komplettes Home verschlüsselt. Das ist bereits seit ~ Ubuntu 8.04 so. Dabei habe ich auf cryptsetup / LUKS (dm-crypt) zurückgegriffen. Das ganze finde ich recht komfortabel, da man während des Bootvorgangs nach der Passphrase gefragt wird und damit dann alles erledigt ist – fein bei einem System an dem nur einer arbeitet in Verbindung mit der automatischen Anmeldung. Bisher ging das ganze auch mit allen neueren Ubuntu Updates – bis Karmic.
Es gibt dabei zwei verschiedene Szenarien:
- man kann gar keine Passphrase eingeben, da die Tastatur anscheinend gar nicht richtig funktioniert
- während der Eingabe der Passphrase werden Meldungen ins Terminal geschrieben, die das ganze damit “zerschiessen” (upstart ??)
Vorerst habe ich mir damit geholfen /home nicht automatisch einzubinden, sondern vor der Anmeldung auf ein Terminal zu wechseln und das ganze dann manuell zu machen (cryptdisk_start home; mount /home). Das ist nicht wirklich komfortabel
Zur Zeit bin ich dabei das ganze auf PAM umzustellen, damit /home über PAM bei der Anmeldung gemountet wird. Werde das versuchen wenn ich Zeit dazu habe.
Multipath mit Priorisierung
08. Okt
Mit Hilfe von Multipath kann man eine Art “Bonding” für Storage Devices erreichen. Es werden quasi mehrere Pfade zu einem (z.B.) SAN Device angebunden, jedoch nur ein Pfad und ein übergeordnetes Device genutzt. Vergleichbar mit Bonding aus dem Netzwerkbereich (Redundante Anbindung ans Netzwerk mit Hilfe von zwei Netzwerkkarten).
Um die Einrichtung von Multipath generell soll es in diesem Artikel nicht gehen. Es geht um die Priorisierung der Pfade. Warum Priorisierung ? Angenommen wir haben zwei Rechenzentren. Es befindet sich jeweils ein SDS (Storage Domain Server) in RZ1 und RZ2. Nun möchte man, dass die Server in RZ1 auch den SDS Server im RZ1 nutzen und vice versa.
Einige Hersteller von SAN Komponenten wie HP, IBM, Hitachi und auch andere stellen dazu Programme zur Verfügung, die in die Multipath Konfiguration eingebunden werden können. Diese Programme erkennen die vom SAN “gewünschten” Pfade und setzen dem entsprechend die Priorität. Hat man nun das Glück das SAN eines Herstellers mit nur wenig Linux Unterstützung nutzen zu dürfen, so sieht das ganze leider anders aus. Wir haben dieses Glück
Wie funktioniert generell die Priorisierung unter Multipath ?
Das ist recht einfach, wenn auch nicht so einfach herauszufinden. Es gibt einen Parameter Namens “prio_callout”. Dieser Parameter hat als Argument ein Programm, welches von Multipath ausgeführt wird um die Priorität eines Devices zu bestimmen.
prio_callout "/sbin/mpath_prio_emc /dev/%n"
Dabei gibt das Programm lediglich eine Zahl – also die Priorität zurück (nicht als return code, sondern als normaler Output (STDOUT)). Als Variable kann “%n” (z.B. sda) übergeben werden. Das Device innerhalb einer Gruppe (eine Gruppe sind die Pfade, die zu dem gleichen Device führen) mit der höchsten Priorität gewinnt.
Keine Unterstützung des Herstellers ?
Wenn der Hersteller kein Programm liefert um die vom SAN gewünschte Priorität zu bestimmen (wie im Beispiel oben EMC), dann muss das ganze eben von Hand gemacht werden.
Man benötigt im Prinzip ein Script, welches eine Konfigurationsdatei einliest, in der die Informationen über Pfadpriorisierung enthalten sind und diese entsprechend zurück gibt. Ich habe das Script “multipath_prio.sh” genannt.
#!/bin/bash
# This script determines the multipath path prioritiy
# by manually configuring a priority to - if wanted - each path
#
# see config file for further information - /etc/multipath_prio.conf
#
# configure multipath:
# prio_callout "/usr/bin/mpath_prio.sh /block/%n"
#
# Ronny Becker, 09.2009
# parms
CONFIG="/etc/multipath_prio.conf"
# DEBUG
# level 0 - none
# level 1 - all
DEBUG=0
LOGFILE="/tmp/multipath_prio.log"
# div checks
if [ ! -e $CONFIG ]; then
if [ $DEBUG == 1 ]; then echo "`date` ${1} -- no config found: 0" >> $LOGFILE; fi
echo 0
exit
fi
if [ -z ${1} ]; then
if [ $DEBUG == 1 ]; then echo "`date` ${1} -- no parm given: 0" >> $LOGFILE; fi
echo 0
exit
fi
# get config data
# /sbin/scsi_id -i -g -u -s /block/sdc
# -> 2:0:0:1: 360030d90303031707838353062757369
# --> in configfile "2:0:0:1: 360030d90303031707838353062757369-1"
# the higher priority wins
SCSI_DATA="`/sbin/scsi_id -i -g -u -s ${1}`"
DATASET="`grep "^${SCSI_DATA}" $CONFIG`"
# if no line found
if [ $? != 0 ]; then
if [ $DEBUG == 1 ]; then echo "`date` ${1} -- grep to config not ok: 0" >> $LOGFILE; fi
echo 0
exit
fi
PRIORITY=${DATASET#*-}
if [[ $PRIORITY =~ ^[0-9] ]]; then
if [ $DEBUG == 1 ]; then echo "`date` ${1} -- OK: $PRIORITY" >> $LOGFILE; fi
echo $PRIORITY
exit
else
if [ $DEBUG == 1 ]; then echo "`date` ${1} -- no numeric value found" >> $LOGFILE; fi
echo 0
fi
Die Konfigurationsdatei sieht so aus:
# Configfile for multipath_prio.sh
#
# Use multipath_prio.sh to set manually preferred
# path priority.
#
# How:
# get scsi device information and ID by using:
# /sbin/scsi_id -i -g -u -s /block/ (ex. sdb)
#
# you get:
# 2:0:0:1: 360030d90303031707838353062757369
#
# put that line into the multipath_prio config including
# the priority setting:
# 2:0:0:1: 360030d90303031707838353062757369-1
# (priority of 1)
#
# - higher priority wins
#
# - if you only want to prefer one path, its enough to
# configure only this - the other path defaults to 0.
#
# - default is 0 (if no line matching and on errors)
#
# Ronny Becker, 09.2009
3:0:2:0: 360030d9030324e4147494f5353494c42-9
4:0:0:0: 360030d9030324e4147494f5353494c42-0
Das Format in der Konfigurationsdatei entspricht dem Output von “/sbin/scsi_id -i -g -u -s /block/<DEVICE>”.
Wie kann man nun herausfinden, welcher Pfad zu welcher SDS zeigt ? Da wir QLogic HBAs nutzen, konnten wir auf das Tool “ql-hba-snapshot” von QLogic selbst zurückgreifen. Das Programm mit dem Parameter “-v -a” aufgerufen zeigt genau welches Device welche LUNs verbunden hat. Um nun definitiv herauszufinden welche SDS dahinter steckt, muss man die WWPN des SDS kennen und entsprechend mit dem snapshot Tool vergleichen.
Am Ende muss der Parameter prio_callout in der /etc/multipath.conf auf das neue Script multipath_prio.sh konfiguriert werden – fertig. Das ganze ist ein wenig schwierig zu beschreiben – sollte jemand Fragen haben kann er sich an uns wenden.
Aufzeichnen von Administratortätigkeiten II
05. Okt
“timing_shorter.sh”
Cooler Name für etwas ganz einfaches. Man wird schnell feststellen, dass das abspielen einer Aufnahme schnell “langweilig” wird, da alle Pausen in voller Länge aufgezeichnet wurden. Wenn also jemand 30 Minuten lang nichts macht, dann sind diese 30 Minuten 1-1 in der Aufzeichnung.
Um dieses Problem zu umgehen läuft vor dem Cleanup Script der “timing_shorter”. Dieses Script erkennt alle Zeilen innerhalb der .timing Datei die > 3 Sekunden sind; diese werden auf 3 Sekunden gekürzt. Damit sind die Pausen maximal 3 Sekunden lang.
#!/bin/bash
# This reduces the time for typescript
# pauses (when user gives no input and
# system gives no output) to max 3 secs
# by changing the .timing file.
#
# No changes to the typescript !
#
# Ronny Becker, 09.2009
#set -x
for TIMINGFILE in `find /adminmon/timing/ -mmin +300`
do
TIMINGLINE=0
cat $TIMINGFILE | while read LINE
do
(( TIMINGLINE++ ))
if [ ${LINE%\.*} -gt 3 ]; then
sed -i "${TIMINGLINE}s/^.*\./3\./" $TIMINGFILE
fi
done
done
Das Script sollte vor dem Cleanup laufen.
Das Cleanup Script
Wir möchten die Dateien die während einer Aufzeichnung entstehen verwaltbar machen. Dazu sollen die zusammengehörigen Dateien gepackt werden – die Originale werden dann gelöscht. Womit das Problem des Zugriffs ( auf die .timing Dateien ) auch spätetstens gelöst ist.
#!/bin/bash
ADMINMON_PATH="/adminmon"
for SCRIPTFILE in `find ${ADMINMON_PATH}/output/ -mmin +300`
do
MAINNAME=`basename $SCRIPTFILE`
MAINNAME=${MAINNAME%\.*}
echo $SCRIPTFILE
echo $MAINNAME
if [ -e ${ADMINMON_PATH}/timing/${MAINNAME}.timing ]; then
tar -czf ${ADMINMON_PATH}/pairing/${MAINNAME}.tgz ${ADMINMON_PATH}/timing/${MAINNAME}.timing $SCRIPTFILE
if [ $? != 0 ]; then
echo "Fehler bei tar $MAINNAME"
continue
else
rm -f ${ADMINMON_PATH}/timing/${MAINNAME}.timing $SCRIPTFILE
fi
else
tar -czf ${ADMINMON_PATH}/pairing/${MAINNAME}_notiming.tgz $SCRIPTFILE
if [ $? != 0 ]; then
echo "Fehler bei tar $MAINNAME"
else
rm -f $SCRIPTFILE
fi
fi
done
Das Script einfach per cron alle X ausführen und gut.
Aufzeichnen von Administratortätigkeiten
28. Sep
Nahezu jeder Admin ist heute mit dem Problem der “Kontrollen” und “Nachweispflicht” konfrontiert. Dabei sind Changes / Changemanagement der Anfang und das komplette “Monitoring der Administratortätigkeiten” die logische Konsequenz. Dazu werden beispielsweise auf einem Terminalserver alle Sitzungen per Video aufgezeichnet. Was ich nun suchte war eine Möglichkeit die kompletten Bildschirmausgaben einer SSH Sitzung aufzuzeichnen. Damit könnten dann sämtliche Befehle … recht einfach nachvollzogen werden, bzw. sogar zur Fehlerfindung genutzt werden wenn der Admin Unsinn gemacht hat und selbst nachvollziehen möchte was er eigentlich gemacht hat.
Ob das ganze sinnvoll oder nicht ist, das soll an dieser Stelle nicht diskutiert werden. Es geht darum eine Lösung für diese Anforderung zu finden.
Ich habe lange nach einer Lösung gesucht. Die gibt es auch. Es sind die Boxen zweier Hersteller, die den kompletten ssh Traffic, teilweise sogar inklusive X11 und auch anderer Protokolle aufzeichnen. Schaut man sich jedoch die Preise für eine solche Lösung an, dann überlegt man sich doch zweimal, ob man wirklich so viel Geld dafür ausgeben möchte / muss. Eines vorweg: Die Boxen wurden von mir nicht getestet, da das ganze preislich völlig uninteressant war.
Also wurde Dr. Google bemüht und auch diverse Kollegen wurden gefragt – leider nirgendwo eine wirkliche Lösung.
Naja, wie man es so aus der Community gewöhnt ist wird sich dann eben selbst hingesetzt und versucht etwas zu “bauen”. Ganz neu erfinden musste ich das ganze nicht. Es gab – wie so schön unter Linux – schon diverse Möglichkeiten und Tools. Dabei ist eines das zentrale und wichtigste: script. Mit Hilfe von script ist es möglich z.B. Befehlsfolgen aufzuzeichnen inkl. der Ausgabe. Wobei die Ausgabe ebenfalls alls Steuerzeichen für die Ausgabe enthällt. Im Endeffekt entsteht ein “Video” der Ausgabe, welches man beispielsweise zum Support schicken kann.
Das Programm um die Aufnahmen zu erstellen und abzuspielen war also gefunden. Als nächstes musste eine Lösung gefunden werden um die Aufzeichung automatisch und auch sicher zu starten. Es bringt nur relativ wenig wenn ich von einem Benutzer erwarte einen Befehl zu starten wenn er sich anmeldet, bzw. wäre es auch ein wenig albern das ganze als bsp. SOX konformes Monitoring zu deklarieren, wenn ich einfach den Prozess beenden kann und dem entsprechend dann machen kann was ich möchte ohne dass das ganze aufgezeichnet wird. Dazu wurden diverse Schritte nötig die im folgenden Howto enthalten sind.
Prerequisites
- jumphost (Server, über den alle ssh Zugriffe auf Server gestartet werden; dieser Host sollte der einzige sein, der Zugriff auf die Server hat (iptables, …))
- script (normalerweise in den linux-utils Paketen enthalten)
- das wars schon
Technische anpassungen
Anpassen der /etc/bashrc
Um den Benutzern nach der Umstellung weiterhin zu erlauben eigene alias Definitionen, bzw. Funktionen zu setzen, wird in der /etc/bashrc eine Kleinigkeit hinzugefügt:
# additional aliases to be set by the user
if [ -e /home/$USER/.bashrc_user ]; then
. /home/$USER/.bashrc_user
fi
Dadurch kann jeder Benutzer sich in der Datei ~/.bashrc_user seine eigenen Definitionen hinterlegen.
Anpassen der ~/.bashrc
Meldet ein Benutzer sich am Jumphost an, so muss das Programm “script” automatisch gestartet werden. Dies wird über die ~/.bashrc realisiert. Diese sieht aus wie folgt:
# jumphost configuration
#
# If you want to set own alias definitions, please
# create a file .bashrc_user in your homedirectory !!
#
script -c "/bin/bash --rcfile /etc/bashrc" -f -q -t 2>/adminmon/timing/`date +%Y%m%d_%H%M%S`-$$-$USER.timing /adminmon/output/`date +%Y%m%d_%H%M%S`-$$-$USER.script
wait
exit
Verzeichnisse
Die Daten (.script, .timing) werden in eigenen Verzeichnissen gesammelt. .script in einem Verzeichnis, welches nur von root gelesen und beschrieben werden darf, und eines für die .timing Dateien auf die der Benutzer kompletten Zugriff hat. Eigentlich könnte man sagen, dass doch beide Dateien in einem Verzeichnis liegen könnten, auf die der Benutzer selbst keinen Zugriff hat – richtig. Leider funktioniert das nicht mit script. script schreibt die Bildschirmausgaben per Parameter in eine Datei – also mit den Rechten des Benutzerkontextes unter dem script gestartet wird. Die Timing Informationen werden jedoch als Ausgabe auf STDERR von script ausgegeben und umgelenkt (s. Befehl in der .bashrc) – die .timing Datei wird also mit den Rechten des Benutzers geschrieben. script wird während der Konfiguration (s.u.) die setuid root Rechte bekommen. Dadurch wird das Programm zwar vom Benutzer gestartet, allerdings mit root Rechten. Das gilt wie eben beschrieben für die Ausgabedatei der Bildschirmdaten, jedoch nicht für die Umleitung der Timing Informationen. Daher die Verzeichnisse mit den verschiedenen Rechten.
[root@machine adm32]# ls -la /adminmon/
total 20
drwxrwxrwx 4 root root 4096 Sep 25 11:05 .
drwxr-xr-x 25 root root 4096 Sep 25 11:05 ..
drwx------ 2 root root 4096 Sep 25 14:22 output
drwxrwxrwx 2 root root 4096 Sep 25 14:22 timing
script setuid root
Aus oben genanntem Grund muss /usr/bin/script das setuid root Bit bekommen.
[root@machine adm32]# chmod u+s /usr/bin/script
Überwachungsscript
Das Überwachungsscript ist für die Überwachung der angemeldeten Benutzer verantwortlich. Überwachung in dem Sinne, als dass jeder Benutzer einen laufenden script Prozess besitzen muss – ansonsten wird er automatisch abgemeldet.
#!/bin/bash
# Security Script to check if all users are
# monitored by script to get typescripts of
# their doing.
#
# If a user runs a session without this, the
# user session will be terminated.
#
# Ronny Becker, 09.2009
#set -x
NOT="root bin daemon adm shutdown halt mail uucp operator ftp nobody dbus avahi mailnull smmsp nscd ntp vcsa rpc rpcuser nfsnobody sshd pcap haldaemon rpm xfs gdm"
# do a dumb loop
while [ 0 == 0 ]; do
# get processlist
PSDATA=`ps a -o user,tname,pid,command | sed 's/ *//'`
# users online ?
# to get unique users, set username = username(p)tty;
for ACTUSER in `who | awk '{print $1$2}'`; do
# if the user is in NOT list - continue
if [[ $NOT =~ ${ACTUSER%pts*} ]]; then
continue
else
# get proc information
DATA=`echo "$PSDATA" | grep "pts${ACTUSER#*pts}"`
if [[ $DATA =~ script\ -c\ /bin/bash\ --rcfile\ /etc/bashrc\ -f ]]; then
# delete /dev/null if you want to have more logging
echo "$ACTUSER: Proc found" > /dev/null
else
echo "$DATA" | while read PROCDATA; do
if [[ $PROCDATA =~ \-bash ]]; then
PID2KILL=`echo "$PROCDATA" | awk '{print $2}'`
# check if proc ist running > 10 secs
TIMEDIFF=$((`date +%s` - `stat --format=%Z /proc/${PID2KILL}`))
if [ $TIMEDIFF -lt 5 ]; then logger -t script_security -p local0.notice "User: ${ACTUSER%pts*} Msg: lt 5 secs without"; continue; fi
echo "Diese Session wird nun geschlossen, da die Protokollierung nicht mehr sichergestellt ist." | write ${ACTUSER%pts*}
sleep 3
kill -9 $PID2KILL
logger -t script_security -p local0.warning "User: $ACTUSER Msg: User killed PID: $PID2KILL"
fi
done
# delete /dev/null if you want to have more logging
echo "$ACTUSER: No proc found" > /dev/null
fi
fi
done
sleep 5;
done
Das Script überprüft alle 5 Sekunden den Status der Benutzer und loggt eventuelle “Zwischenfälle” per syslog. Zusätzlich müssen Benutzer mind. 5 Sekunden lang im System angemeldet sein, bevor die Session geschlossen wird. Das kommt daher, dass ein Benutzer den script Befehl erst während der Anmeldung startet und ansonsten die Session beendet werden könnte bevor er wirklich angemeldet ist.
Dieses Script muss quasi immer im Hintergrund laufen (als root). Als Daemon überwacht es dann jede Session.
Hilfe von cfengine
Bei einigen der “tasks” kann cfengine gute Dienste leisten. z.B. wenn es darum geht die ~/.bashrc eines jeden Benutzers zu prüfen oder die Verzeichnissrechte unterhalb von /adminmon. Desweiteren kann cfengine prüfen ob das Überwachungsskript läuft.
Abspielen einer Aufnahme
Aufnahmen werden mit Hilfe von “scriptreplay” abgespielt.
scriptreplay 20090925_142228-8287-adm31.timing 20090925_142228-8287-adm31.script
Um eine Aufnahme während der Wiedergabe anzuhalten, genügt der Shortcut STRG+S (Pause); zum Fortfahren STRG-Q.
Noch offen
- Cleanup Script erstellen (die zusammengehörigen .script / .timing Dateien sollten in ein .tar gepackt werden)
- Script erstellen um größere Wartezeiten in denen nichts passiert zu minimieren. Dazu werden einfach alle Werte (z.B.) > 5 innerhalb der .timing Datei auf 5 gesetzt.
Squid ntlm check
24. Jun
Wir betreiben einen Squid mit ntlm authentifizierung. Das System lief unter Squid2 absolut stabil.
Vor einiger Zeit sind wir auf Squid3 umgestiegen. In Squid3 sind einige caching Optionen im Bezug auf Credentials aus Squid2 entfernt worden. Dadurch muss man die Anzahl der ntlm_authenticator Prozesse um einiges – bei uns von 80 auf 900 – erhöhen. Das ist eine. Des Weiteren läuft die Autentifizierung trotz der hohen Anzahl Prozesse bei uns nicht stabil. Ohne weitere Fehlermeldung erlaubt Squid manchmal keinen Zugriff auf den Proxy (wir verwenden aktuell Squid3-STABLE13).
Um das ganze mit Nagios zu prüfen muss der Plugin natürlich auch ntlm beherrschen – eine Prüfung auf die ebenfalls vorhandene Basic authentifizierung würde ja nicht weiterhelfen. Damit bis Dato kein Programm bekannt war mit dem man ohne großen Aufwand auch ntlm auf einem Proxy testen kann hatten wir keinen solchen Test. Aber jetzt
Durch einen Zufall bin ich auf “curl” aufmerksam geworden. curl ist sowas wie “wget”, gemacht um Daten zu oder von Servern mit Hilfe von diversen Protokollen (HTTP, HTTPS, FTP, FTPS, TFTP, DICT,TELNET, LDAP or FILE) zu übertragen (-> man curl).
curl kann aber auch ntlm und das auch über einen Proxy. Also habe ich mir einen kleinen Plugin für Nagios geschrieben, der mit den Credentials eines Accounts aus den Benutzerverzeichnis die Seite eines bekannten Suchmaschinenbetreibers aufruft. Damit wird also die Authentifizierung als auch die Internetverbindung an sich getestet.
#!/bin/bash # This checks if the proxy ntlm authentication works # # Nothing clever done, but it works. # # Ronny Becker, 06.2009 #set -x PROXY=$1 URL="" DATA=`curl --connect-timeout 2 -m 2 -I --proxy-ntlm --proxy-user : --url $URL --proxy http://${PROXY}: 2>/dev/null` if [[ $DATA =~ 'HTTP/1.0 200 OK' ]] then echo "ok" exit 0 else echo "URL no accessible" exit 2 fi
MySQL Tuning Script
08. Mai
Ein einfaches Script um tuning Vorschläge für MySQL zu bekommen kann man hier finden. Der Vorteil dieses Scripts im Vergleich zu “Standardtipps” ist, dass es die lokele Installation analysiert und konkret Vorschläge macht wie man die laufende Installation etwas verbessern kann.
Neuer Kernel und VMware Config
07. Mai
Sobald ein neuer Kernel auf einem VMware Gast installiert wird, muss nach dem nächsten Reboot vmware-config-tools.pl aufgerufen werden, um unter anderem die Netzwerk Kernel Module für den neuen Kernel einzurichten. Dumm nur, ohne Netzwerk muss alles über die Konsole durchgeführt werden.
Abhilfe bringt folgendes InitV Script: (/etc/init.d/vmwareautoconfig)
#!/bin/bash
# chkconfig: 2345 00 00
# description: Checks and installs automatically vmware modules for new kernel
if [ "$1" == "start" ] ; then
if [ ! -e /lib/modules/`uname -r`/.vmware_installed ]; then
/usr/bin/vmware-config-tools.pl --default >/var/log/vmware_config_last.log 2>&1
touch /lib/modules/`uname -r`/.vmware_installed
fi
fi
Auf einem Red Hat System noch mit ausführbar machen und mit chkconfig --add vmwareautoconfig in den Bootprozess einbinden und man muss sich nie wieder um vmware-config-tools.pl kümmern.
Kurz zum Skript:
Sobald ein neuer Kernel bootet, für den vmware-config-tools.pl noch nicht ausgeführt wurde (siehe Trigger Datei), führt es vmware-config-tools.pl --default aus. Im Anschluss wird die Trigger Datei /lib/modules/<kernel>/.vmware_installed erzeugt.
Soll vmware-config-tools.pl noch einmal beim nächsten Boot ausgeführt werden, einfach /lib/modules/<kernel>/.vmware_installed löschen.
Der Bootvorgang läuft dann wie gewohnt weiter und der VMware Gast hat gleich beim ersten Boot Netzwerk!
RPM und 64bit Systeme
05. Mai
Eieieiei, immer wieder muss ich nachschauen und aufs neue den rpm Befehl zusammen basteln. Jetzt schreibe ichs mal auf:
RPMs inklusive Architektur auf einem 64bit RHEL System auflisten lassen:
rpm -qa --qf "%{NAME}-%{VERSION}-%{RELEASE} (%{ARCH})\n"
Wenn ein Paket für mehrere Architekturen installiert ist, kann man mittels .
rpm -qi glib2.x86_64
Und deinstallieren des 64Bit Paketes:
rpm -e glib2.x86_64



