BlogBlog ÜbersichtjailscriptportsoptFreeBSDLinksThermoskanne

UFS Journaling auf neuer Festplatte aktivieren

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).

Comments (2)  Permalink

MASTER_SITES aus bsd.sites.mk nach Antwortzeiten sortieren

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"
 Permalink

Sparc-Systeminformation im EEPROM oder NVRAM anzeigen oder verändern

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).

 Permalink

ZFS Dateisystem mit mehreren Snapshots replizieren

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

Related Entries:
ZFS-Statistiken anzeigen
ZFS-Installation mit Hilfe von mfsBSD
FreeBSD nur auf ZFS installieren
Alle Änderungen eines ZFS-Pools anzeigen
Automatisch ZFS Snapshots erstellen
Comments (1)  Permalink

ZFS Dateisystem replizieren

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

Related Entries:
ZFS-Statistiken anzeigen
ZFS-Installation mit Hilfe von mfsBSD
FreeBSD nur auf ZFS installieren
Alle Änderungen eines ZFS-Pools anzeigen
Automatisch ZFS Snapshots erstellen
Comments (1)  Permalink

Informationen über eine Laptop-Batterie auslesen

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.

 Permalink

FreeBSD Ports mit Hilfe von porttools erstellen oder aktualisieren

Möchte man einen FreeBSD Port erstellen oder aktualisieren, so können verschiedene Aufgaben mit porttools vereinfacht werden. Zuerst müssen die porttools installiert werden. Diese findet man im FreeBSD Portbaum unter ports-mgmt/porttools:

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

Ruft man die porttools das erste Mal auf, wird die .porttools Konfigurationsdatei angelegt, und die verfügbaren Module der porttools angezeigt:

# port
===> Generating /home/beat/.porttools configuration file
FreeBSD Port Tools 0.77
Usage:  port <command> [<options>]

Available commands:
commit  - commit a port into the FreeBSD Ports CVS Repository
create  - create new port from template using newfile(1)
diff    - generate diff against original port version
fetch   - fetch distfile(s) of new port version
getpr   - get patch/shar from a PR
help    - display this command summary
install - install a port
submit  - submit Problem Report with new port, or port change/update
test    - test port (build, install, package, deinstall)
upgrade - upgrade a port

In der angelegten ~/.porttools Datei können nun Variablen gesetzt werden, welche von den porttools verwendet werden. Für was die Variablen verwendet werden, findet man in der Manpage porttools(5).

# FreeBSD Port Tools configuration file - see porttools(5)
# vim: ft=sh
EMAIL="beat@chruetertee.ch"
FULLNAME="Beat Gätzi"
ORGANIZATION=""
BUILDROOT="/tmp"
ARCHIVE_DIR=""
DIFF_MODE="CVS"
DIFF_VIEWER="more"
PORTLINT_FLAGS="abct

Um einen neuen Port zu erstellen, wechselt man in das Verzeichnis, in dem man den Port erstellen möchte und erstellt den Port mit Hilfe des create-Modules:

# cd /tmp
# port create portsopt

Es wurde nun ein Verzeichnis für den Port angelegt und eine Vorlage vom Makefile, pkg-descr und der pkg-plist erstellt:

# ls portsopt
Makefile   pkg-descr  pkg-plist

Jetzt können im Makefile die Variablen CATEGORIES, COMMENT, PORTVERSION, und MASTER_SITES gesetzt werden. Gegebenenfalls müssen die restlichen Variablen auch noch gesetzt werden, damit der Quellcode des Ports heruntergeladen werden kann:

# cd portsopt
# cat Makefile 

# New ports collection makefile for:    portsopt
# Date created:         2008-05-03
# Whom:                 Beat Gätzi <beat@chruetertee.ch>
#
# $FreeBSD$
#

PORTNAME=       portsopt
PORTVERSION=    1.4
#PORTREVISION=  0
#PORTEPOCH=     0
CATEGORIES=     ports-mgmt
MASTER_SITES=   http://www.chruetertee.ch/files/download/
#MASTER_SITE_SUBDIR=
#PKGNAMEPREFIX=
#PKGNAMESUFFIX=
#DISTNAME=
#EXTRACT_SUFX=
#DISTFILES=
#DIST_SUBDIR=   ${PORTNAME}
#EXTRACT_ONLY=

MAINTAINER=     beat@chruetertee.ch
COMMENT=        Shows WITH(OUT)-knobs of a port makefile

.include <bsd.port.pre.mk>
.include <bsd.port.post.mk>

Nicht benötigte Variablen können aus dem Makefile entfernt werden. Nun kann mit Hilfe des porttools der Quellcode heruntergeladen werden. Die Prüfsummen des Ports werden automatisch erstellt. Diese müssen noch mit den offiziellen Prüfsummen verglichen werden:

# port fetch
=> portsopt-1.4.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch from http://www.chruetertee.ch/files/download/.
portsopt-1.4.tar.gz                           100% of 1126  B 1348 kBps
# cat distinfo 
MD5 (portsopt-1.4.tar.gz) = 9062b0fa280e98750dc29a13c41617e3
SHA256 (portsopt-1.4.tar.gz) = 845d6518ff2369fc6f17b6fa0299cba6e3251c7d2568b34c78e603d1a3d556f7
SIZE (portsopt-1.4.tar.gz) = 1126

Nun müssen die restlichen Variablen und make-Targets erstellt werden, die zum Bauen des Ports benötigt werden. Damit auch alle installierten Dateien beim Deinstallieren des Portes wieder entfernt werden, müssen alle Dateien in der Datei pkg-plist aufgelistet werden. Welche Dateien alles installiert werden, kann zum Beispiel mit ftrace herausgefunden werden. Werden nur wenige Dateien oder Verzeichnisse erstellt, können diese auch im Makefile unter PLIST_FILES und PLIST_DIRS aufgeführt und die Datei pkg-plist kann gelöscht werden. Wie die pkg-plist aufgebaut ist, findet man im Porters Hanbook. In der Datei pkg-descr muss nun noch eine Beschreibung des Programms erstellt und die URL zur offiziellen Seite des Programms eingefügt werden. Ist der Port fertig, kann er mit port test getestet werden. Der Port wird dabei standardmässig nach /tmp installiert:

# port test
===> Validating port with portlint
WARN: Makefile: only one MASTER_SITE configured.  Consider adding additional mirrors.
0 fatal errors and 1 warning found.
===> flags: PREFIX=/tmp/portsopt-1.4 NO_DEPENDS=yes PKG_DBDIR=/tmp/pkg_db.ud9qtv5I 
===> Cleaning workspace before port test
===>  Cleaning for portsopt-1.4
===>  Extracting for portsopt-1.4
=> MD5 Checksum OK for portsopt-1.4.tar.gz.
=> SHA256 Checksum OK for portsopt-1.4.tar.gz.
===>  Patching for portsopt-1.4
===>  Configuring for portsopt-1.4
===>  Installing for portsopt-1.4
===>   Generating temporary packing list
===>  Checking if ports-mgmt/portsopt already installed
install  -o root -g wheel -m 555 /usr/ports/ports-mgmt/portsopt/work/portsopt-1.4/portsopt /tmp/portsopt-1.4/sbin
===>   Registering installation for portsopt-1.4
===>  Building package for portsopt-1.4
Creating package /usr/ports/packages/All/portsopt-1.4.tbz
Registering depends:.
Creating bzip'd tar ball in '/usr/ports/packages/All/portsopt-1.4.tbz'
===> Checking pkg_info
portsopt-1.4        Shows WITH(OUT)-knobs of a port makefile
===> Checking shared library dependencies
===>  Deinstalling for ports-mgmt/portsopt
===>   Deinstalling portsopt-1.4
===> Extra files and directories check
===> Cleaning up after port test
===>  Cleaning for portsopt-1.4
===>  Removing existing /tmp/portsopt-1.4 dir
===> Done.

Treten beim Testen keine Fehler auf, kann der Port mittels einem Problem Report eingesandt werden. Dazu kann einfach port submit im Port-Verzeichnis eingegeben werden:

# port submit

Nun wird ein Editor mit dem Problem Report geöffnet. Die wichtigsten Teile des Problem Reports sind bereits ausgefüllt. Auch ist der neue Port als shar-Archiv bereits angehängt. Speichert man den Problem Report und schliesst den Editor, wird nachgefragt, was man damit machen möchte. Um den Problem Report abzusenden kann s gedrückt werden:

s)end, e)dit or a)bort? s

Den Problem Report findet man nach einiger Zeit im GNATS und wird danach von einem FreeBSD-Commiter in den Portbaum aufgenommen.

Mit den porttools lassen sich nicht nur Ports erstellen, sondern auch bestehende Ports aktualisieren. Dazu sichert man zuerst den aktuellen Port:

# cd /usr/ports/www
# cp -Rp fluxcms fluxcsm.orig

Nun können alle Änderungen am Port durchgeführt werden. Die Änderungen können danach auch wieder mit port test geprüft werden. Möchte man die gemachen Änderungen anschauen, kann dazu port diff verwendet werden. Hat der originale Port den Suffix .orig, kann dies den porttools mit der -d Option übergeben werden:

# ls -d /usr/ports/www/fluxcms*
/usr/ports/www/fluxcms/      /usr/ports/www/fluxcms.orig/
# cd /usr/ports/www/fluxcms
# port diff -d .orig

Sind alle Änderungen abgeschlossen, können diese wieder mit einem Problem Report eingesandt werden. Auch hier wird der Patch automatisch von den porttools erstellt. Dazu muss auch wieder der Suffix des originalen Portverzeichnisses mit -d übergeben werden. Der Problem Report wird standardmässig als "non-critical" und der Dringlichkeit low eingesandt. Das kann, wenn nötig, mit der -s und der -s Option, zum Beispiel bei einem Sicherheitsupdate ,überschrieben werden. Gültige Werte bei -s sind non-critical, serious oder critical, bei -p low, medium oder high.

# port submit -d .orig

Nun müssen im Editor noch in der Zeile Synopsis der Platzhalter [SUMMARIZE CHANGES] durch einen kleine Beschreibung der Änderung ersetzt werden. Bei Description sollte der Platzhalter [DESCRIBE CHANGES] durch eine ausführlichere Beschreibung der Änderungen ersetzt werden. Beim Beenden des Editors muss das Versenden des Problem Reports wieder bestätigt werden.

Mehr Informationen wie man FreeBSD Ports erstellt oder aktualisiert findet man im FreeBSD Porter's Handbook. Mehr Informationen zu den porttools findet man in der Manpage port(1) .

Vielen Dank an Martin für seine hilfreichen Anregungen beim Erstellen dieses Artikels.

Related Entries:
Gespeicherte Optionen nach OptionsNG konvertieren
Ports-Subversion-Repository spiegeln
sysinstall-Ersatz für neuere FreeBSD-Versionen
Alte FreeBSD-Port Patchdateien aufsplitten
FreeBSD-Portbaum auf Fehler überprüfen
 Permalink

ccache in einer Tinderbox verwenden

Kompiliert man Ports in einer Tinderbox mehrere Male, so kann die Zeit die zum Kompilieren benötigt wird, mit Hilfe von ccache reduziert werden. ccache findet man im FreeBSD Portbaum unter devel/ccache:

# cd /usr/ports/devel/ccache && make install clean

Nun muss ein Tarball, mit den für die Tinderbox benötigten Dateien, erstellt werden. Die FreeBSD Version mit welcher ccache gebaut worden ist, sollte mit der Version der Tindebox-Jail, in welcher man ccache verwenden möchte, übereinstimmen da sonst unter Umständen gewisse Bibliotheken nicht gefunden werden:

# cd /tmp
# mkdir opt
# cp /usr/local/bin/ccache opt
# cd opt
# ln -s ccache gcc
# ln -s ccache cc
# ln -s ccache g++
# ln -s ccache c++
# cd ..
# tar cf ccache.tar opt

Nun kann der ccache-Tarball in das Verzeichnis einer Tinderbox-Jail kopiert werden, in welcher man ccache verwenden möchte. Zum Beispiel:

# cp /tmp/ccache.tar /usr/local/tinderbox/jails/6

Danach muss ccache in der Tinderbox aktiviert werden. Mit der -s Option kann festgelegt werden, wieviel Speicherplatz ccache verwenden darf:

# cd /usr/local/tinderbox/scripts && ./tc configCcache -e -c /ccache -s 10G

Die Dateien die ccache nun anlegt, werden unter /usr/local/tinderbox/ccache gespeichert. Mehr Informationen zu ccache findet man in der Manpage ccache(1).

Related Entries:
Tinderbox aufräumen
Wartezeit von tinderd ändern
Quellcode in der Tinderbox speichern
Tinderbox-Jail ohne Kompilieren erstellen
RSS-Feed der zuletzt gebauten Ports einer Tinderbox
 Permalink

CVSup mit SSH tunneln

Möchte man aus einem Netz, in dem Verbindungen auf TCP/5999 nicht zugelassen sind, CVSup benutzen, um Quelldateien zu erneuern, so kann kann man den CVSup Verkehr mit SSH tunneln. Voraussetzung ist, dass SSH-Verbindungen zugelassen sind und man einen Rechner besitzt, der per SSH erreichbar ist und von dem TCP/5999 auf einen CVSup-Server erlaubt ist. Nun kann ein SSH-Tunnel aufgebaut werden:

# ssh -2 -N -f -L <Lokaler Port>:<CVSup Server>:<Port CVSup Server> <Benutzername>@<Server>

Dabei wird der SSH-Tunnel im Hintergrund aufgebaut. Im folgenden Beispiel wird als lokaler Port 5999 und cvsup2.ch.freebsd.org als CVSup-Server verwendet:

# ssh -2 -N -f -L 5999:cvsup2.ch.freebsd.org:5999 benutzer@proxy.chruetertee.ch

Mit sockstat(1) kann überprüft werden, ob der Tunnel aufgebaut ist:

# sockstat -4 | grep 5999
beat     ssh        1466  4  tcp4   127.0.0.1:5999        *:*

Nun kann in der CVSup-Konfiguration als CVSup-Server der lokale Rechner angegeben werden:

# grep "default host" /usr/sup/standard-supfile
*default host=localhost

Hat man als lokalen Port 5999 gewählt, kann c(v)sup direkt gestartet werden, ansonsten muss mit der -p Option der lokale Port angegeben werden:

# csup -L 2 -p <lokaler Port> <Pfad zu CVSup-Konfiguration> 
 Permalink

Smart Array RAID Controller auf FreeBSD verwalten

Auf einem Server mit einem Smart Array Controller kann der RAID Controller mit Hilfe des hpacucli (HP Array Configuration Utility CLI) direkt aus dem Betriebssystem heraus verwaltet werden. hpacucli findet man im FreeBSD Portsbaum unter sysutils/hpacucli:

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

Danach kann hpacucli gestartet werden, wobei die vorhandenen RAID Controller erkannt werden. Möchte man sich danach alle verfügbaren Kommandos von hpacucli anschauen, kann help eingegeben werden.

# hpacucli
HP Array Configuration Utility CLI 7.50.18.0
Detecting Controllers...Done.
Type "help" for a list of supported commands.
Type "exit" to close the console.

=>

Alle verfügbaren Informationen zu allen verfügbaren RAID Controllern, in diesem Beispiel nur einer, erhält man mit ctrl all show:

=> ctrl all show 
Controller Smart Array P400 at 0
Bus Interface: PCI
Slot: 0
Serial Number: 123456789
Cache serialnumber: 123456789
RAID 6 (ADG) Status: Enabled
RAID 6 (ADG) Enabler Status: Enabled
Controller Status: OK
Chassis Slot: 1
Hardware Revision: Rev D
Firmware Version: 2.08
Rebuild Priority: Medium
Expand Priority: Medium
Surface Scan Delay: 15 sec
Cache Board Present: True
Cache Status: OK
Accelerator Ratio: 100/0 (read/write)
Total Cache Size: 512 MB
Battery Pack Count: 1
Battery Status: OK

Möchte man sich nur den Status des Controllers anzeigen lassen, kann dies mit ctrl all show status gemacht werden:

=> ctrl all show status
Smart Array P400 in Slot 0
Controller Status: OK
Cache Status: OK
Battery Status: OK

Möchte man sich nun die Komponenten des Controllers genauer anschauen, kann der Controller festgelegt werden:

=> set target ctrl slot=0
controller slot=0

Nun lassen sich die Informationen zu allen Festplatten an diesem Controller mit pd all show anzeigen:

=> pd all show
Smart Array P400 in Slot 0
physicaldrive 1:1
Port: 2I
Box: 1
Bay: 1
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 73.4 GB
Transfer Speed: 3.0 Gbps
Rotational Speed: 10000
Firmware Revision: HPD5
Serial Number: 3123456789
physicaldrive 1:2
Port: 2I
Box: 1
Bay: 2
Status: OK
Drive Type: Data Drive
Interface Type: SAS
Size: 73.4 GB
Transfer Speed: 3.0 Gbps
Rotational Speed: 10000
Firmware Revision: HPD5
Serial Number: 123456789

Auch die daraus erstellten "Logical Drives" können mit ld all show angezeigt werden:

=> ld all show
Smart Array P400 in Slot 0
Logical Drive: 1
Size: 68.3 GB
Fault Tolerance: 1+0
Heads: 255
Sectors Per Track: 32
Cylinders: 17562
Stripe Size: 128 KB
Status: Ok
Array Accelerator: Enabled
Has Data On Drive: True
Unique Identifier: 123456704C3953554112345678
Preferred Controller Chassis Slot: 1

Nun kann man mit hpacucli direkt neue "Logical Drives" erstellen und Parameter des Controllers während des Betriebs verändern. Eine komplette Übersicht der Befehle findet man auf folgender Seite: http://people.freebsd.org/~jcagle/hpacucli-readme

Mehr Informationen zu FreeBSD auf HP Proliant Servern findet man auf folgender Seite: http://people.freebsd.org/~jcagle/

Der Status eines "Logical Drives" kann auch mit cciss_vol_status ausgelesen werden.

 Permalink
Prev Next131-140/305