chruetertee.ch

Seit FreeBSD 7.0 besteht die Möglichkeit, ein UFS Dateisystem mit Journaling statt mit Softupdates zu betreiben. Möchte man nun eine neue Festplatte in ein bestehendes System einfügen und diese mit UFS Journaling versehen, so muss zuerst UFS Journaling für die neue Festplatte, in diesem Beispiel /dev/ad1, konfiguriert werden:

# gjournal label /dev/ad1

Danach kann das gjournal Kernelmodul wie folgt geladen werden:

# gjournal load
GEOM_JOURNAL: Journal 2439108283: ad1 contains data.
GEOM_JOURNAL: Journal 2439108283: ad1 contains journal.
GEOM_JOURNAL: Journal ad1 clean.

Nun kann die neue Festplatte mit UFS2 formatiert werden. Durch die -J Option wird das Journaling aktiviert:

# newfs -J /dev/ad1.journal

Nun kann das neue Dateisystem ins System gemountet werden. Mit UFS-Journaling ist es auch möglich das Dateisystem mit der async Option zu mounten, ohne dass man ein inkonsistentes Dateisystem zu befürchten hat.

# mkdir /mnt/backup
# mount -o async /dev/ad1.journal /mnt/backup

Damit das Dateisystem bei einem Neustart des Systems automatisch gemountet werden kann, muss zuerst der entsprechende Eintrag in der /boot/loader.conf gemacht werden:

# echo 'geom_journal_load="YES"' >> /boot/loader.conf

Danach kann der Eintrag in der /etc/fstab erstellt werden:

/dev/ad1.journal        /mnt/backup     ufs     rw,async        2       2

Anschliessend wird das neue Dateisystem mit Journaling nach einem Neustart automatisch ins System eingebunden.

# mount
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ad0s1e on /tmp (ufs, local, soft-updates)
/dev/ad0s1f on /usr (ufs, local, soft-updates)
/dev/ad0s1d on /var (ufs, local, soft-updates)
/dev/ad1.journal on /mnt/backup (ufs, asynchronous, local, gjournal)

Mehr Informationen zu UFS Journaling findet man in der Manpage gjournal(8).

Mit Hilfe von doc kann die DNS Konfiguration einer Domain auf Fehler überprüft werden. doc findet man im FreeBSD Portbaum unter dns/doc:

# cd /usr/ports/dns/doc && make install clean

Nun kann der Domainname der Domain, welche überprüft werden soll, an doc übergeben werden:

# doc chruetertee.ch
Doc-2.2.3: doc chruetertee.ch
Doc-2.2.3: Starting test of chruetertee.ch.   parent is ch.
Doc-2.2.3: Test date - Sa 28 Jun 2008 13:32:14 CEST
Summary:
   No errors or warnings issued for chruetertee.ch.
Done testing chruetertee.ch.  Sa 28 Jun 2008 13:32:30 CEST

Mit der -v Option können zusätzliche Informationen zu den durchgeführten Tests angezeigt werden:

# doc -v chruetertee.ch

Im Verzeichnis, in dem doc ausgeführt wurde, wird eine Logdatei mit allen Testausgaben erstellt:

# cat log.chruetertee.ch.

Eine Übersicht, welche Tests durchgeführt wurden, findet man in der Datei /usr/local/lib/doc/INFO. Mehr Informationen zu doc findet man in der Manpage doc(8).

In der Datei /usr/ports/Mk/bsd.sites.mk, sind die Server hinterlegt, von welchen über die Ports der Quellcode von größeren Softwareprojekten heruntergeladen werden kann. Ebenfalls ist die Reihenfolge, in welcher die Server angefragt werden, in dieser Datei hinterlegt. Diese Reihenfolge kann nun angepasst werden, so dass das Herunterladen zuerst von Servern versucht wird, welche bessere Antwortzeiten haben. Dazu kann das Skript fastest_sites verwendet werden, welches man im FreeBSD Portbaum unter ports-mgmt/fastest_sites findet:

# cd /usr/ports/ports-mgmt/fastest_sites && make install clean

Führt man das Skript aus, werden die Antwortzeiten der verschiedenen Server getestet. Die Ausgabe kann in eine Datei geschrieben werden:

# fastest_sites > /usr/local/etc/ports_sites.conf
 => Checking servers for MASTER_SITE_GENTOO (50 servers)
 => Checking servers for MASTER_SITE_TCLTK (6 servers)
 => Checking servers for MASTER_SITE_GET_E (6 servers)
 => Checking servers for MASTER_SITE_EASYSW (5 servers)
 => Checking servers for MASTER_SITE_PERL_CPAN (19 servers)
 => Checking servers for MASTER_SITE_PACKETSTORM (5 servers)
 => Checking servers for MASTER_SITE_GNUPG (14 servers)
[...]

Die erstellte Datei kann nun in /etc/make.conf eingebunden werden. Dazu kann einfach folgende Zeile an die Datei angehängt werden:

.include "/usr/local/etc/ports_sites.conf"

Mit Hilfe von dvtm kann man ein Terminalfenster in mehrere Terminals aufteilen. Im FreeBSD Portbaum ist dvtm unter sysutils/dvtm vorhanden:

# cd /usr/ports/sysutils/dvtm && make install clean

Um dvtm anzupassen, kann die config.h Datei entsprechend geändert werden. Diese muss dann beim Kompilieren des Ports über die Variable DVTM_CONF angegeben werden:

# cd /usr/ports/sysutils/dvtm && make DVTM_CONF=/<Pfad zu eigener Konfig>/config.h install clean

Startet man nun dvtm, wird ein neues Terminal geöffnet:

# dvtm

Zum Ausführen von dvtm-Befehlen muss zuerst eine bestimmte Tastenkombination gedrückt werden. Standardmässig ist das Ctrl+g (Strg+g auf der deutschen Tastatur). Möchte man zum Beispiel das vorhandene Terminalfenster in zwei Terminals unterteilen, drückt man Ctrl+g und danach c.

Hat man nun mehrere Terminals geöffnet, kann die Anordnung der Terminals mit Ctrl+g Leertaste geändert werden. Alternativ kann auch direkt mit Ctrl+g b, Ctrl+g g oder Ctrl+g t die gewünschte Anordnung gewählt werden.

Nun kann mit Ctrl+g j oder Ctrl+g k das aktive Terminal gewechselt werden. Verwendet man dvtm auf einer X Oberfläche, kann mit der Maus in das gewünschte Fenster geklickt werden. Möchte man unter X Text mit der Maus markieren, um diesen in die Zwischenablage zu kopieren, oder Text aus der Zwischenablage in ein Terminal kopieren, muss dazu die Shift-Taste gedrückt werden.

Einzelne Terminals können mit Ctrl+g x geschlossen werden. dvtm beendet man mit Ctrl+g q.

Folgendes Bild zeigt dvtm mit fünf offenen Terminals, in denen mcabber, newsbeuter, mutt und screen laufen.

Mehr Informationen zu dvtm und alle möglichen Tastenkombinationen findet man in der Manpage dvtm(1).

Mit der foreach-Schleife können in der tcsh Operationen auf mehreren Dateien gleichzeitig ausgeführt werden. Startet man eine foreach-Schleife, muss eine Variable deklariert werden und angegeben werden, welche Dateien modifiziert werden sollen. Danach können die Befehle, die auf den Dateien angewendet werden sollen, angegeben werden. Anschliessend wird die Schleife mit end beendet. Im folgenden Beispiel wird allen Dateien der Suffix .orig angehängt:

#  ls
file0  file1  file2  file3
# foreach file (*)
foreach? mv $file $file.orig
foreach? end
# ls
file0.orig  file1.orig  file2.orig  file3.orig

Nun können auf den Dateinamen Substitution Patterns der tcsh verwendet werden. So wird im folgenden Beispiel der Suffix .orig durch .test ersetzt:

# foreach file (*)
foreach? mv $file $file:s/.orig/.test/
foreach? end
# ls
file0.test  file1.test  file2.test  file3.test

Soll der Suffix entfernt werden, kann dies mit $file:r gemacht werden:

# foreach file (*)
foreach? mv $file $file:r
foreach? end
# ls
file0  file1  file2  file3

Nun kann der erste Buchstabe des Dateinamens mit Hilfe von $file:u in einen Grossbuchstaben umgewandelt werden:

# foreach file (*)
foreach? mv $file $file:u
foreach? end
# ls
File0  File1  File2  File3

Umgekehrt kann der erste Buchstaben auch wieder in einen Kleinbuchstaben geändert werden:

# foreach file (*)
foreach? mv $file $file:l
foreach? end
# ls
file0  file1  file2  file3

Mehr Informationen zu der foreach-Schleife und den Substitution Patterns der tcsh findet man in der Manpage tcsh(1).

Verwendet man FreeBSD auf einem SPARC-Rechner, so können mit Hilfe von eeprom die Systeminformationen, welche im EEPROM oder NVRAM gespeichert sind, angeschaut werden:

# eeprom -a
tpe-link-test?: true
scsi-initiator-id: 7
keyboard-click?: false
keymap:
ttyb-rts-dtr-off: false
ttyb-ignore-cd: true
ttya-rts-dtr-off: false
ttya-ignore-cd: true
ttyb-mode: 9600,8,n,1,-
ttya-mode: 9600,8,n,1,-
pcia-probe-list: 1,2,3,4
pcib-probe-list: 1,2,3
mfg-mode: off
diag-level: min
#power-cycles: 87
system-board-serial#:
system-board-date:
fcode-debug?: false
output-device: screen
input-device: keyboard
load-base: 16384
boot-command: boot
auto-boot?: true
watchdog-reboot?: false
diag-file: -r
diag-device: disk:b
boot-file:
boot-device: /pci@1f,0/pci@1,1/ide@3/disk@0,0:a disk net
local-mac-address?: false
ansi-terminal?: true
screen-#columns: 80
screen-#rows: 34
silent-mode?: false
use-nvramrc?: false
nvramrc: devalias pgx24 /pci@1f,0/pci@1,1/SUNW,m64B
security-mode: none
security-password:
security-#badlogins: 6
oem-logo:
oem-logo?: false
oem-banner:
oem-banner?: false
hardware-revision:
last-hardware-update:
diag-switch?: false

Nun können einzelne Werte mit Hilfe von eeprom auch verändert werden:

# eeprom diag-level=max
diag-level: min -> max

Von FreeBSD unterstützte SPARC-Systeme findet man auf der FreeBSD/sparc64 Webseite, mehr Informationen zu eeprom und eine Beschreibung der Variablen findet man in der Manpage eeprom(8).

ZFS Dateisysteme können einfach von einem Pool in einen anderen repliziert werden. Möchte man nun ein ZFS Dateisystem mit mehreren Snapshots in einen anderen Pool replizieren, müsste man jeden Snapshot einzeln replizieren:

# zfs list
NAME                          USED  AVAIL  REFER  MOUNTPOINT
tank                         2.05G  64.9G  18K    /tank
tank/home                    2.05G  64.9G  2.05G  /usr/home
tank/home@now                  19K      -  1000M  -
tank/home@afterupload          19K      -  1.95G  -
tank/home@aftermodification      0      -  2.05G  -
tank2                         116K  66.9G    18K  /tank2

Um dies zu vereinfachen, kann zfs-replicate installiert werden. zfs-replicate findet man im FreeBSD Portbaum unter sysutils/zfs-replicate:

# cd /usr/ports/sysutils/zfs-replicate && make install clean

Nun muss nur das ZFS Dateisystem angegeben werden, welches repliziert werden soll, und alle Snapshots werden automatisch mit repliziert. Mit der -v Option wird jeweils angezeigt, welche Schritte notwendig sind, um das Dateisystem zu replizieren:

# zfs-replicate -v tank/home tank2
Sending tank/home@now to tank2.
Sending tank/home@afterupload to tank2.
(incremental to tank/home@now.)
Sending tank/home@aftermodification to tank2.
(incremental to tank/home@afterupload.)

Erstellt man nun einen neuen Snapshot und führt zfs-replicate nochmals aus, wird nur der neue Snapshot übertragen:

# zfs snapshot tank/home@tape
# zfs-replicate -v tank/home tank2
Sending tank/home@tape to tank2.
(incremental to tank/home@aftermodification.)

Mehr Informationen zu zfs-replicate findet man auf folgender Webseite: http://blogs.sun.com/constantin/entry/useful_zfs_snapshot_replicator_script

Mit Hilfe von ZFS können Daten einfach von einem ZFS-Pool in einen anderen repliziert werden. Im folgenden Beispiel befinden sich Daten im ZFS-Pool tank. Diese sollen in den zweiten Pool tank2 repliziert werden:

# zfs list
NAME        USED  AVAIL  REFER  MOUNTPOINT
tank       1000M  66.0G    18K  /tank
tank/home  1000M  66.0G  1000M  /usr/home
tank2       110K  66.9G    18K  /tank2

Zuerst muss ein Snapshot der aktuellen Daten erstellt werden:

# zfs snapshot tank/home@now

Danach kann der Snapshot mit zfs send in einen Stream umgewandelt werden. Dieser wird mit zfs receive in den neuen Pool geschrieben. Verwendet man beim zfs receive die -vn Optionen, werden die Daten nicht geschrieben, sondern es wird nur angezeigt, welche Operationen durchgeführt werden würden:

# zfs send tank/home@now | zfs receive -vn tank2/home
would receive full stream of tank/home@now into tank2/home@now

Nun werden die Daten in den neuen Pool repliziert:

# zfs send tank/home@now | zfs receive tank2/home
# zfs list
NAME             USED  AVAIL  REFER  MOUNTPOINT
tank            1000M  66.0G    18K  /tank
tank/home       1000M  66.0G  1000M  /usr/home
tank/home@now       0      -  1000M  -
tank2           1000M  66.0G    20K  /tank2
tank2/home      1000M  66.0G  1000M  /tank2/home
tank2/home@now      0      -  1000M  -

Ändern sich nun Daten im originalen Pool, kann ein neuer Snapshot erstellt werden:

# dd if=/dev/zero of=/home/beat/test2 bs=10M count=100
# zfs snapshot tank/home@afterupload
# zfs list
NAME                    USED  AVAIL  REFER  MOUNTPOINT
tank                   1.95G  65.0G    18K  /tank
tank/home              1.95G  65.0G  1.95G  /usr/home
tank/home@now            19K      -  1000M  -
tank/home@afterupload      0      -  1.95G  -
tank2                  1000M  66.0G    20K  /tank2
tank2/home             1000M  66.0G  1000M  /tank2/home
tank2/home@now             0      -  1000M  -

Möchte man nun die Änderungen, welche zwischen den ersten und den zweiten Snapshot auf dem originalen Pool vorgenommen wurden, replizieren, kann mit der -i Option von zfs send der Snapshot angegeben werden, welcher schon repliziert wurde. Danach werden nur die Änderungen übertragen:

# zfs send -i tank/home@now tank/home@afterupload | zfs receive -vn tank2/home
would receive incremental stream of tank/home@afterupload into tank2/home@afterupload
# zfs send -i tank/home@now tank/home@afterupload | zfs receive tank2/home # zfs list
NAME                     USED  AVAIL  REFER  MOUNTPOINT
tank                    1.95G  65.0G    18K  /tank
tank/home               1.95G  65.0G  1.95G  /usr/home
tank/home@now             19K      -  1000M  -
tank/home@afterupload       0      -  1.95G  -
tank2                   1.95G  65.0G    20K  /tank2
tank2/home              1.95G  65.0G  1.95G  /tank2/home
tank2/home@now            19K      -  1000M  -
tank2/home@afterupload      0      -  1.95G  -

ZFS Dateisysteme können auch zwischen Pools auf verschiedenen Rechnern repliziert werden. Dazu muss sich allerdings root per SSH anmelden können:

# zfs send tank/home@now | ssh root@<Rechner> 'zfs receive tank/home'

Mehr Informationen zu ZFS findet man in der Manpage zfs(8). Eine kleine Einführung in ZFS auf FreeBSD findet man hier: http://www.chruetertee.ch/blog/archive/2007/05/26/zfs-auf-freebsd.html

Wird zum Beispiel beim Kompilieren viel Text in einer Konsole ausgegeben, können Ausgaben der Standardfehlerausgabe (stderr) leicht übersehen werden. Mit Hilfe von hilite können diese farblich hervorgehoben werden. hilite findet man im FreeBSD Portsbaum unter sysutils/hilite:

# cd /usr/ports/sysutils/hilite && make install clean

Nun kann mit hilite eine gewünschte Shell gestartet werden. Danach werden alle Ausgaben der Standardfehlerausgabe rot hervorgehoben:

# hilite tcsh
# echo test stdout
test stdout
# echo test stderr > /dev/stderr 
test stderr

Auf FreeBSD lassen sich mit Hilfe von acpiconf Informationen über eine Laptop-Batterie auslesen. Zuerst muss die Batterienummer bestimmt werden:

# dmesg | grep -i batt
battery0: <ACPI Control Method Battery> on acpi0

Diese kann danach mit der -i Option an acpiconf übergeben werden. Danach werden alle Informationen zu dieser Batterie angezeigt:

# acpiconf -i 0
Design capacity:        71280 mWh
Last full capacity:     30890 mWh
Technology:             secondary (rechargeable)
Design voltage:         10800 mV
Capacity (warn):        1544 mWh
Capacity (low):         200 mWh
Low/warn granularity:   1 mWh
Warn/full granularity:  1 mWh
Model number:           IBM-08K8918
Serial number:          549
Type:                   LION
OEM info:               SANYO
State:                  high 
Remaining capacity:     98%
Remaining time:         unknown
Present rate:           0 mW
Voltage:                12300 mV

Mehr Informationen zu acpiconf findet man in der Manpage acpiconf(8), acpiconf ist bereits im FreeBSD Basissystem vorhanden.