BlogBlog ÜbersichtjailscriptportsoptFreeBSDLinksThermoskanne

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

Text der Standardfehlerausgabe hervorheben

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

IP Rechner für die Kommandozeile

Mit ipcalc kann durch eine IP-Adresse und eine Netzmaske die dazugehörigen Netzwerk- und Broadcast-Adresse auf der Kommandozeile berechnet werden. ipcalc findet man im FreeBSD Portsbaum unter net-mgmt/ipcalc:

# cd /usr/ports/net-mgmt/ipcalc && make install clean

Nun kann die IP-Adresse und die Netzmaske an ipcalc übergeben werden. Die berechneten Werte werden danach ausgegeben:

# ipcalc 217.150.245.53 255.255.255.192
Address: 217.150.245.53 11011001.10010110.11110101.00 110101
Netmask: 255.255.255.192 = 26 11111111.11111111.11111111.11 000000
Wildcard: 0.0.0.63 00000000.00000000.00000000.00 111111
=>
Network: 217.150.245.0/26 11011001.10010110.11110101.00 000000
HostMin: 217.150.245.1 11011001.10010110.11110101.00 000001
HostMax: 217.150.245.62 11011001.10010110.11110101.00 111110
Broadcast: 217.150.245.63 11011001.10010110.11110101.00 111111
Hosts/Net: 62 Class C

Möchte man ein vorhandenes Netz in kleinere Netze aufsplitten, kann mit der --s Option angegeben werden, wie viele Rechner in den neuen Subnetzen enthalten sein müssen. Folgendes Beispiel splittet ein 192.168.0.0/24 Netz in zwei Subnetze, in welchen einmal 10 und einmal 40 Rechner Platz haben können:

#  ipcalc 192.168.0.0/24 --s 10 40
Address: 192.168.0.0 11000000.10101000.00000000. 00000000
Netmask: 255.255.255.0 = 24 11111111.11111111.11111111. 00000000
Wildcard: 0.0.0.255 00000000.00000000.00000000. 11111111
=>
Network: 192.168.0.0/24 11000000.10101000.00000000. 00000000
HostMin: 192.168.0.1 11000000.10101000.00000000. 00000001
HostMax: 192.168.0.254 11000000.10101000.00000000. 11111110
Broadcast: 192.168.0.255 11000000.10101000.00000000. 11111111
Hosts/Net: 254 Class C, Private Internet

1. Requested size: 10 hosts
Netmask: 255.255.255.240 = 28 11111111.11111111.11111111.1111 0000
Network: 192.168.0.64/28 11000000.10101000.00000000.0100 0000
HostMin: 192.168.0.65 11000000.10101000.00000000.0100 0001
HostMax: 192.168.0.78 11000000.10101000.00000000.0100 1110
Broadcast: 192.168.0.79 11000000.10101000.00000000.0100 1111
Hosts/Net: 14 Class C, Private Internet

2. Requested size: 40 hosts
Netmask: 255.255.255.192 = 26 11111111.11111111.11111111.11 000000
Network: 192.168.0.0/26 11000000.10101000.00000000.00 000000
HostMin: 192.168.0.1 11000000.10101000.00000000.00 000001
HostMax: 192.168.0.62 11000000.10101000.00000000.00 111110
Broadcast: 192.168.0.63 11000000.10101000.00000000.00 111111
Hosts/Net: 62 Class C, Private Internet

Needed size: 80 addresses.
Used network: 192.168.0.0/25
Unused:
192.168.0.80/28
192.168.0.96/27
192.168.0.128/25

Mehr Informationen zu ipcalc erhält man mit der --help Option:

# ipcalc --help
 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

Temporäre Dateien in einem Shellskript verwenden

Erstellt man in einem Shellskript mehrere temporäre Dateien, so muss sichergestellt werden, dass die Dateien noch nicht existieren. Dazu kann man mktemp verwenden. Die X im übergeben Dateinamen werden von mktemp durch einen einmaligen Schlüssel ersetzt. Der Pfad zur erstellten Datei wird von mktemp zurückgegeben:

# mktemp /tmp/test.XXXXXXXXXX
/tmp/test.d8zo9nRkAd

Nun kann mktemp zum Beispiel wie folgt in einem Shellskript verwendet werden:

TMPFILE=`mktemp /tmp/test.XXXXXXXXXX` || exit 1
echo "Test" >> ${TMPFILE}

mktemp ist auf FreeBSD und OpenBSD bereits im Basissystem vorhanden. Mehr Informationen zu mktemp findet man in der Manpage mktemp(1).

 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

SSL-verschlüsselte Dienste testen

Unverschlüsselte Netzwerkdienste wie HTTP/POP3/IMAP/SMTP können mit telnet(1) auf ihre Funktionalität getestet werden:

# telnet www.chruetertee.ch 80
Trying 217.150.245.53...
Connected to www.chruetertee.ch.
Escape character is '^]'.
GET /
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.chruetertee.ch/">here</a>.</p>
</body></html>
Connection closed by foreign host.

Wird der Datenverkehr mit SSL verschlüsselt, kann telnet nicht mehr verwendet werden. Möchte man den Dienst trotzdem testen, kann s_client von OpenSSL verwendet werden. Zuerst werden Informationen zum Zertifikat und der SSL-Verbindung angezeigt, danach können Befehle wie mit telnet abgesetzt werden:

# openssl s_client -connect www.chruetertee.ch:443
CONNECTED(00000003)
<Zertifikatisinfo>
---
Certificate chain
0 s:/C=CH/ST=Zurich/L=Zurich/O=chruetertee.ch/CN=www.chruetertee.ch/emailAddress=hostmaster@chreutertee.ch
i:/C=CH/ST=Zurich/L=Zurich/O=chruetertee.ch/CN=www.chruetertee.ch/emailAddress=hostmaster@chreutertee.ch
---
Server certificate
-----BEGIN CERTIFICATE-----
<Zertifikat>
-----END CERTIFICATE-----
subject=/C=CH/ST=Zurich/L=Zurich/O=chruetertee.ch/CN=www.chruetertee.ch/emailAddress=hostmaster@chreutertee.ch
issuer=/C=CH/ST=Zurich/L=Zurich/O=chruetertee.ch/CN=www.chruetertee.ch/emailAddress=hostmaster@chreutertee.ch
---
No client certificate CA names sent
---
SSL handshake has read 1231 bytes and written 340 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
SSL-Session:
<Session Info>
---
GET /
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.chruetertee.ch/">here</a>.</p>
</body></html>
closed

OpenSSL und s_client sind auf FreeBSD und OpenBSD bereits im Basissystem vorhanden. Mehr Informationen zu s_client findet man in der Manpage s_client(1), eine Übersicht der OpenSSL Tools findet man in der Manpage openssl(1).

Comments (2)  Permalink
Prev Next51-60/84