Festplatte in Software-RAID

Im ersten Schritt die neue Festplatte mit fdisk, genau wie die noch funktionierende partitionieren. Hat man eine funktionierende Platte /dev/sda und möchte deren Partitionen auf das neue Device /dev/sdb spiegeln, geht man wie folgt vor.

  • Kommando fdisk /dev/sda starten (funktionierende Platte)
  • mit Befehl p die Partitionstabelle anzeigen
  • mit Befehl q fdisk verlassen
  • Kommando fdisk /dev/sdb starten (neue Platte)
  • neue Partitionen mit Befehl n anlegen (die Start- und Endpunkte können direkt von der Tabelle der funktionierenden Platte übernommen werden)
  • den Typ fd auf alle neuen Partitionen mit t setzen
  • neue Partitionstabelle mit w schreiben

Mit raidhotadd müssen dann die Raid-Devices wieder aufbauen. Im folgenden wird dies beispielhaft am md0 gezeigt. Die Information, welches Partition zu welchem Device gehört, findet man in der Datei /etc/mtab.

raidhotadd /dev/md0 /dev/sdb1

Zuletzt überprüft man mit dem Kommando cat /proc/mdstat, das der Spiegel wieder aufgebaut wird bzw. aufgebaut wurde.

Installation Nagios 2.0

Die folgende Beschreibung basiert auf einem Fedora Core 5.

Sicherung der Verzeichnisse /etc/nagios und /usr/lib/nagios.

mkdir nagios20
cd nagios20
mkdir etc_nagios
cp -rp /etc/nagios/* etc_nagios/
mkdir usr_lib_nagios
cp -rp /usr/lib/nagios/* usr_lib_nagios/
mkdir var_lib_mysql
cp -rp /var/lib/mysql/* var_lib_mysql/

Um die Daten auf den neuen Server zu spielen, wird die Windows-Freigabe mit dem neuen The Common Internet File System (CIFS) eingebunden. Die neue Fedora Core benutzt dieses anstatt von smbmount.

mount -t cifs -o username=administrator //dc01/public /mnt/lan

Downlaod der neuen Mysql- und Perl-Pakete:

wget MySQL-client-standard-5.0.18-0.rhel4.i386.rpm
wget MySQL-server-standard-5.0.18-0.rhel4.i386.rpm
wget MySQL-shared-standard-5.0.18-0.rhel4.i386.rpm
wget perl-DBI-1.40-5.i386.rpm

Deinstallation der vorhandenen Pakete:

rpm -e perl-DBD-MySQL-2.1021-3
rpm -e perl-DBD-Pg-1.21-2
rpm -e perl-DBI-1.32-9 --nodeps
rpm -e mysql-server-3.23.58-2.3
rpm -e mysql-devel-3.23.58-2.3
rpm -e mysql-3.23.58-2.3 --nodeps
mv /var/lib/mysql/nagio* /tmp/

Installtion des neuen MySQL:

rpm -ivh MySQL-shared-standard-5.0.18-0.rhel4.i386.rpm
rpm -ivh MySQL-client-standard-5.0.18-0.rhel4.i386.rpm
rpm -ivh MySQL-server-standard-5.0.18-0.rhel4.i386.rpm
rpm -ivh perl-DBI-1.40-5.i386.rpm
chkconfig mysql on

Der MySQL läuft nur, wenn SELinux deaktiviert ist. Wurde es bei der Installation eingerichtet, kann es über die Datei /etc/sysconfig/selinux wieder deaktiviert werden.

Hat man die Mysql-Tabellen von einer früheren Version verwendet, müssen diese aktualisiert werden:

cat /usr/share/mysql/mysql_fix_privilege_tables.sql | /usr/bin/mysql --no-defaults --force --user=root --host=localhost --database=mysql -u root -p

Für die Plugins macht es Sinn alle möglichen Perl-Module zu installieren. Des weiteren benötigt der Grundwork-Apache die libphp5 Datei.

yum install perl-*
yum install php
yum install libXpm.so.4

Die Ip-Adresse des neuen Nagios-Servers muss aufgelöst werden. Am einfachsten kann man dies über die /etc/hosts/ realsisieren.

/usr/bin/mysqladmin -u root password ’new-password‘
/usr/bin/mysqladmin -u root -h nagios2.federn-brand.de password ’new-password‘

Kennwort vom MySQL-Server zurücksetzen:

mysqladmin -u root -p password ''

Installation des neuen Nagios:

rpm -ivh groundwork-monitor-os-4.5-11.i586.rpm

Linux-Konsole am seriellen Kabel

Mit Hilfe der Datei /etc/inittab kann man ein getty an die serielle Schnittstelle binden. Beim folgenden Eintrag steht ttyS0 für COM1: unter Windows.

T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100

Die Konsole lässt sich über ein serielles Null-Modem-Kabel mit einer Geschwindigkeit von 9600 bps, ohne Parität und mit 8 Datenbits nutzen.

Möchte man auch den Bootloader über die serielle Konsole steuern, muss man entsprechende Parameter setzen.

Anpassungen für GRUB in der /boot/GRUB/menu.lst:

title Debian GNU/Linux, kernel 2.6.15-1-k7
root (hd0,0)
kernel /boot/vmlinuz root=/dev/sda1 ro console=tty0 console=ttyS0,9600n8
initrd /boot/initrd.img-2.6.15-1-k7
savedefault
boot

Änderungen für LILO in der /etc/lilo.conf:

image = /boot/vmlinuz
root = /dev/hda3
label = "Debian GNU/Linux, kernel 2.6.15-1-k7"
append ="console=tty0 console=ttyS0,9600n8"

Bei LILO darf der Befehl lilo nicht vergessen werden, um die Änderungen zu übernehmen.

Weitere Infos finden sich im Serial HOWTO und Linux-Konsole und Bootloader über serielles Kabel.

JavaServer Faces (JSF)

statische Navigation

Ist das action-Attribut einer UICommand-Komponente schon bei der Erstellung der JSP-Seite bekannt, spricht man von statischer Navigation.

<h:commandLink action=“links“>
   <h:outputText value=“zur Linkseite“ />
</h:commandLink>

Der Wert des action-Attributs ist fest codiert. JSF schaut in der Konfigurationsdatei nach, ob es für die Seite, die diese Aktion ausgelöste hat, eine Navigationsregel gibt, welche einen Navigationsfall besitzt, der den Rückgabewert (Wert des action-Attributs) erwartet. Ist dies der Fall, wird auf die Folgeseite weitergeleitet. Ist keine entsprechende Regel definiert, wird die gleiche Seite nochmal angezeigt.

dynamische Navigation

<h:commandLink action=“#{LinkList.update}“>
<h:outputText value=“zur Linkseite“ />
</h:commandLink>

Bei der dynamischen Navigation wird beim action-Attribut auf eine Methode verwiesen. Diese muss folgende Anforderungen erfüllen:

  • Sie muss öffentlich (public) sein.
  • Sie muss in einer Managed-Bean definiert sein und dieses muss in der Anwendungskonfigurationsdatei registriert sein.
  • Sie darf keine Parameter erwarten.
  • Sie muss einen String als Rückgabewert liefern.

In der faces-config.xml wird nach einem Navigationsfall gesucht, dessen
<from-outcome>-Attribut mit dem Rückgabewert der Methode übereinstimmt. Ist dies der Fall, wird auf die entsprechende Seite weitergeleitet, ansonsten auf die auslösende Seite zurückverwiesen.

Cancel

Verwendet man Konverter oder Validatoren kann es vorkommen, das man eine Seite verlassen möchte auch wenn die Validierung fehlschlägt. Das Attribut immediate verhindert ein Update des Modells.

<h:commandButton immediate="true" action="success" value="Cancel" />

Links

Splitter, DSL-Router und PPPoE

Eine vorhandene LAN-Verkabelung kann für die Verbindung Splitter und DSL-Router verwendet werden, wenn alle vier Adernpaare (1+2, 3+6, 4+5, 7+8) beschaltet sind. Modem und Splitter nutzen das Aderpaar 4+5. Nicht 1+2 und 3+6, diese werden von (Fast-)Ethernet verwendet.

Die Länge des Kabels zwischen Modem und Splitter darf maximal 100 Meter betragen und muss mindestens der Kategorie 3 (Cat3) entsprechen.

An einem Modem können beliegig viele PPPoE-Geräte angeschlossen werden. Einzige Einschränkung ist die dynamisch zwischen allen Nutzern aufgeteilte Bandbreite.

Soll bei einem T-DSL-Anschluss die Fehlerkorrektur deaktiviert werden (Fastpath), muss ein entsprechender Antrag bei der T-Com gestellt werden. Sollten bei der automatischen Einrichtung Bitfehler auftreten, wird der Antrag abgelehnt. Wird Fastpath per Default aktiviert (der Fall bei manchen Vollanschlussanbietern) können bei entsprechenden Störungen Datenpakete verloren gehen.

http://www.speedcheck.arcor.de/

Java Logging

Beim Programmstart wird geprüft, ob im user.home schon ein Verzeichnis für die Anwendung angelegt wurde. Wenn nicht wird es an dieser Stelle nachgeholt. Im zweiten Schritt werden die Einstellungen fürs Logging geladen. Diese sind Bestandteil der Anwendung (und können später vom Anwender überschrieben werden).

[code lang=“java“]// Verzeichnis prüfen
File logDir = new File(System.getProperty(„user.home“) +
System.getProperty(„file.separator“) + „.app“);
if(! logDir.exists()) logDir.mkdir();
// Einstellungen laden
String res = „/my/app/logging.properties“;
InputStream is = getClass().getResourceAsStream(res);
LogManager.getLogManager().readConfiguration(is);[/code]

Die Einstellungen fürs Logging werden in einem Properties-File gespeichert. Folgendes Beispiel konfiguriert den FileHandler und legt für den ConsolenHandler einen SimpleFormatter fest. In der Darstellung wurde zur besseren Lesbarkeit java.util.logging durch jul ersetzt.

.level = OFF

handlers= jul.FileHandler, jul.ConsoleHandler

jul.FileHandler.level = ALL
jul.FileHandler.pattern = %h/.app/my.log
jul.FileHandler.limit = 50000
jul.FileHandler.count = 3
jul.FileHandler.append = true
jul.FileHandler.formatter = jul.SimpleFormatter

jul.ConsoleHandler.level = ALL
jul.ConsoleHandler.formatter = jul.SimpleFormatter

my.app.MyClass.level = FINE

Erhält man eine Meldung wie Can’t set level for java.util.logging.ConsoleHandler hat man vielleicht nur ein Leerzeichen hinter dem Wert mit angegeben.

Um einen Logger nutzen zu können, leitet man diesem vom Root-Logger ab.

[code lang=“java“]private static java.util.logging.Logger logger =
java.util.logging.Logger.getLogger(„my.class.name“);[/code]

Webstart

Die Ausgabe einer Webstart-Anwendung wird unter %userdir%\Anwendungsdaten\Sun\Java\Deployment\log geschrieben. Vorausetzung ist, das das Protokollieren angeschaltet ist. Unter Start / Ausführen / javaws / Menü Bearbeiten / Einstellungen / Erweitert / Debugging kann die Protokollierung konfiguriert werden. Die Log-Datei javaws.log wird automatisch rotiert.

Links

Java Logging Overview

Logging in Tomcat 5.5

Webmin und Squid Analysis Report Generator

Um SARG im Webmin zu nutzen, wird als erstes das Standard-Webmin-Modul installieren. Die eigentliche Installation der Binary kann bequem per RPM erfolgen. In der Webmin-Modul-Konfiguration muss man den Pfad zur /etc/sarg/sarg.conf anpassen und im Webmin-Modul die Pfade für die Ausgabe und das Log. Ein Apache wird für die Anzeige der Reports nicht benötigt, da der Webmin über seinen Port 10000 diese zur Verfügung stellt.

Update Spamassassin

Spamassassin stolpert über präparierte E-Mails. Mit der Spamassassin 3.1.3 haben die Entwickler eine korrekierte Version Online gestellt. Im folgende wird das Update auf einer Fedora Core 4 beschrieben. Installiert war spamassassin-3.0.3-4.fc4.

Zur Vorbereitung wird eine Verzeichnis angelegt und in diesem ein Backup der bestehenden Konfiguration und die neuen Quellen abgelegt:

[code lang=“bash“]mkdir spamassassin-3.1.3
cd spamassassin-3.1.3
mkdir etc_mail
cp -rp /etc/mail/spamassassin ./etc_mail/
mkdir usr_share_spamassassin
cp -rp /usr/share/spamassassin ./usr_share_spamassassin/
wget Mail-SpamAssassin-.tar.gz[/code]

Das aktuelle Source-Paket kann dann direkt als RPM übersetzt werden. Bei der vorliegenden Installation fehlte das Kommando rmpbuild. Kein großes Problem, denn mit dem Befehl yum install rpm-* wurden alle fehlenden Pakete (eine Menge) nachinstalliert.

[code lang=“bash“]rpmbuild -tb Mail-SpamAssassin-3.1.3.tar.gz[/code]

Nach dem übersetzen findet man die fertigen Pakete unter /usr/src/redhat/RPMS/i386/.

Die Sourcen (inkl. Dokumentation) findet man unter /usr/src/redhat/BUILD/Mail-SpamAssassin-3.1.3. Das in der Datei INSTALL beschriebene Verfahren mit yum install spamassassin für nicht zum Erfolg, den im Repository liegt eine alte 3.0.6 Version.

Weil beim vorliegenden System das Perl-Modul Bestandteil SpamAssassin-Paket war, muss im ersten Schritt die Deinstallation mit der Option –nodeps erfolgen. Im zweiten Schritt werden dann die neu übersetzten Pakete installiert.

[code lang=“bash“]cd /usr/src/redhat/RPMS/i386/
rpm -e spamassassin-3.0.3-4.fc4 –nodeps
rpm -Uvh perl-Mail-SpamAssassin-3.1.3-1.i386.rpm
rpm -Uvh spamassassin-3.1.3-1.i386.rpm
chkconfig spamassassin on
/etc/init.d/spamassassin start[/code]