Kleine und große Linux AHAs
Beiträge getaggt mit netzwerk
Home NAS mit iSCSI – Initiator (Teil 2/3)
06. Apr
In Teil I (hier) hatten wir die Einrichtung des Servers inkl. iSCSI-Target gezeigt. Teil II zeigt die Einrichtung des Initiators – des Clients.
Pakete
Wir gehen von einem Ubuntu Karmic (9.10) aus. Um iSCSI nutzen zu können wird das Paket open-iscsi benötigt.
apt-get install open-iscsi
Konfiguration
Nach der Installation findet sich ein neues Verzeichnis unter /etc/ -> iscsi – dort befinden sich die Konfigurationsdateien …
initiatorname.iscsi
Dort steht quasi der Name des Initiators. Unter Debian wird bei der Installation eine ID generiert, die eindeutig ist. Möchte man den Client jedoch eindeutig zuordnen können, so sollte man den Namen in etwas “sprechendes” anpassen.
iscsid.conf
In dieser Datei werden die Defaults definiert, die von dem Daemon am Ende genutzt werden. Um mit unserer Serverseitigen Konfiguration zu arbeiten funktioniert die folgende:
node.startup = automatic node.conn[0].startup = automatic node.session.auth.authmethod = CHAP node.session.auth.username = linux-aha node.session.auth.password = secret node.session.auth.username_in = linux-aha node.session.auth.password_in = password discovery.sendtargets.auth.authmethod = CHAP discovery.sendtargets.auth.username = linux-aha discovery.sendtargets.auth.password = secret node.session.timeo.replacement_timeout = 120 node.conn[0].timeo.login_timeout = 15 node.conn[0].timeo.logout_timeout = 15 node.conn[0].timeo.noop_out_interval = 5 node.conn[0].timeo.noop_out_timeout = 5 node.session.err_timeo.abort_timeout = 15 node.session.err_timeo.lu_reset_timeout = 20 node.session.initial_login_retry_max = 8 node.session.cmds_max = 128 node.session.queue_depth = 32 node.session.iscsi.InitialR2T = Yes node.session.iscsi.ImmediateData = No node.session.iscsi.FirstBurstLength = 262144 node.session.iscsi.MaxBurstLength = 16776192 node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768 node.session.iscsi.FastAbort = Yes
Damit ist die Konfiguration bereits erledigt.
Discover
Um das ganze ans Rennen zu bringen muss man einen sog. Discover ausführen. Das ist vergleichbar mit einem SCSI Busscan. Da wir die Default Konfiguration für open-iscsi bereits angepasst haben, kann man den Discover Befehl auf das nötigste reduzieren:
root@machine$: iscsiadm -m discovery -t sendtargets -p <iSCSI Targethost> iqn.2008-04.local.home:SecureISCSI
So oder so ähnlich sollte der Output aussehen. Es sollte also – vergleichbar mit einem SCSI Busscan ein Device gefunden werden.
Mit dem Discover wurde nun unterhalb von /etc/iscsi/nodes die Konfiguration für dieses Device angelegt. Dadurch ist das Device dem Daemon bekannt und kann beim Systemstart gesucht und ggf. verbunden werden. Nach dem Discover genügt ein restart des Daemons um das Device im System verfügbar zu machen.
/etc/init.d/open-iscsi restart
Platte da ?
Nach dem restart sollte die neue Platte vorhanden sein. Am einfachsten hilft ein “fdisk -l” dabei, die neue Platte zu finden.
Home NAS mit iSCSI – Server & iSCSI Target (Teil 1/3)
05. Apr
Zuhause in irgendeiner Art ein System zu haben um Daten zu speichern, ist mittlerweile nichts besonderes mehr. Die einen nutzen diese Speicher um der Familie gemeinsamen Zugriff zu gewähren, die anderen um Daten – beispielsweise vom Laptop – zu sichern. Wenn das NAS dann auch gespiegelte Festplatten besitzt dürfte eigentlich nicht viel passieren.
Man sollte sich wirklich einmal Gedanken darum machen was los ist, wenn man die Daten des Laptops oder des Rechners zu Hause verliert – zum Beispiel durch einen Festplattendefekt. Also mir persönlich ist das keine angenehme Vorstellung. Deshalb habe ich mir auch das System aufgebaut, welches hier beschrieben wird. Ich finde es wirklich einfach zu benutzen und es erfüllt seinen Zweck mehr als manche gekauften Lösungen.
Warum überhaupt iSCSI ?
Wenigstens unter Linux (mit anderen OSs kenne ich das nicht) hat das ganze den Charme, das man die per iSCSI an gereichte Festplatte (oder das Volume) als normale Festplatte sieht – als Blockdevice. Das ist ein Unterschied zu beispielsweise NFS oder Samba. Des Weiteren ist iSCSI, sofern man eine passende Netzwerkgeschwindigkeit hat, auch recht schnell. Um das ganze recht performant nutzen zu können sollte man also wenigstens über Gigabit Ethernet verfügen. Damit ist auch schon ein weiterer Vorteil von iSCSI angesprochen, der es gerade auch in Firmen interessant macht – man benötigt “nur” Netzwerk. Keine spezielle Verkabelung oder ähnliches. In Firmen würde man allerdings das iSCSI Geschäft über zwei (redundante) dedizierte Netzwerkinterfaces laufen lassen.
Der “Server”
Der “Server” besteht aus einem PC, der mit mindestens zwei Festplatten ausgestattet ist. Server schreibe ich in Anführungszeichen, da die Hardware natürlich keine Serverhardware ist und mein System auch nur dann läuft, wenn es gebraucht wird. Des Weiteren ist an dem PC ein USB Stick angeschlossen, der mit >4GB das Betriebssystem beherbergt. Der USB Stick deshalb, da man auf diese Weise die beiden vorhandenen Festplatten komplett für das Raid nutzen kann und nicht einen Teil für das OS verliert. Man kann es natürlich auch anders machen – ich habs halt so gemacht.
OS
Auf dem USB Stick wird das OS installiert. Dazu bootet man beispielsweise mit einer Ubuntu Live CD (ich habe den Ubuntu Server genommen) und installiert anstatt auf die Platten auf den Stick. Da wir lediglich die eingebauten Festplatten als iSCSI bereitstellen möchten, sind während der Installation keine besonderen Pakete nötig – einfach ein Minimalsystem installieren. Auf die Installation an sich gehe ich hier nicht weiter ein.
Raid
Nachdem das System installiert ist und erfolgreich von dem USB Stick bootet, kann man das Raid Device erstellen. Dazu müssen die Tools installiert werden:
apt-get install mdadm
Nach der Installation kann mit Hilfe von
mdadm --create /dev/md0 --level=1 raid-devices=2 /dev/sda1 /dev/sdb1
das Raid Device angelegt werden. In dem Beispiel würde das Device aus /dev/sda1 und /dev/sdb1 bestehen. Damit auch bei Problemen nichts falsch läuft, sollte man die Raid Konfiguration in die /etc/mdadm/mdadm.conf eintragen. Das sieht beispielsweise so aus:
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=1bc8e95a:40e106f6:7756543e:82c7b110 devices=/dev/sda1,/dev/sdb1
Bereits nach dem …create Befehl beginnt das System die Platten zu synchronisieren. Diesen Vorgang sollte man abwarten, bevor man die Platten benutzt.
iSCSI Target
Um iSCSI nutzen zu können, muss das Paket iscsitarget installiert werden.
apt-get install iscsitarget
Nach der Installation findet sich unter /etc/ eine neue Konfigurationsdatei -> ietd.conf. Diese ist für die Konfiguration des iSCSI Target (-> Server) verantwortlich. Um unseren Server einzurichten verwenden wir einfach folgende Konfiguration:
Target iqn.2008-04.local.home:SecureISCSI IncomingUser linux-aha secret OutgoingUser linux-aha password Lun 0 Path=/dev/md0,Type=fileio Alias SecureISCSI MaxConnections 1 InitialR2T Yes ImmediateData No MaxRecvDataSegmentLength 8192 MaxXmitDataSegmentLength 8192 MaxBurstLength 262144 FirstBurstLength 65536 DefaultTime2Wait 2 DefaultTime2Retain 20 MaxOutstandingR2T 8 DataPDUInOrder Yes DataSequenceInOrder Yes ErrorRecoveryLevel 0 HeaderDigest CRC32C,None DataDigest CRC32C,None Wthreads 8
Mit dieser Konfiguration ist iscsitarget fertig konfiguriert und nach einem reload des Dienstes steht die Platte zur Verfügung.
Wie man sieht gibt es unter iSCSI auch eine – naja – Authentifizierung. Das ganze als sicher zu bezeichnen würde ich mich nicht wagen, allerdings ist es besser als nichts und man kann sich damit auch ein wenig vor Fehlern schützen, in dem man verschiedene Benutzer und Passwörter vergibt.
Im nächsten Teil geht es dann um den Initiator – den Client.
Fragen über Fragen
02. Mrz
Linux Problem und beim googlen noch keine Lösung gefunden ?
Also wenn es nicht gerade um Anfängerfragen – sorry – geht, könnt ihr uns ja mal fragen. Mit welchen Themen wir uns so beschäftigen könnt ihr auf unserer Seite sehen und vielleicht kann man aus einer Frage auch einen Artikel machen, der für andere ebenfalls interessant ist.
Also einfach hier als Kommentar die Frage einstellen und damit vielleicht auch anderen helfen. Mal gespannt was da kommt …
Mehr Bandbreite: Bonding mit Cisco – Doppelbonding ?
01. Mrz
Wie in dem Original Artikel beschrieben, ist es nicht möglich ein Bonding dieser Art über mehrere Switches einzurichten. Dadurch hat man ein Redundanzproblem. Sollte dieser eine Switch ausfallen, so hat das System die Verbindung zum Netzwerk komplett verloren.
Die Idee war nun quasi “bond bonded Interfaces”. Also 2 bonding Interfaces zu einem weiteren zusammenfassen und dadurch beides bekommen. Das ganze würde dann also so aussehen:
Leider darf ich die Welt enttäuschen. Das funktioniert nicht. Wenigstens zur Zeit können unter Linux keine bonding Interfaces Slaves für ein weiteres bonding Interface sein. Laut RedHat: “Bonding on top of bonded interface would not work properly due to the implementation design of the kernel code”.
xdrp: auch ne Möglichkeit für Remote Zugriff
26. Feb
Es gibt unter Linux viele Möglichkeiten sich remote an einem System anzumelden – auch viele das grafisch zu tun. Da gibt es zum Beispiel XDMCP, X11 über einen ssh Tunnel, VNC, freenx oder das kommerzielle Pendant, … All diese Möglichkeiten waren mir bisher bekannt und ich habe sie auch schon mal ausprobiert. Aus irgendeinem Zufall bin ich nun auf was – für mich – neues gestossen: xrdp.
xrdp kann quasi VNC in das RDP Protokoll umschreiben und dadurch VNC über RDP zur Verfügung stellen. Das ganze ist recht interessant, da der RDP Client bekannterweise in einem von mir nicht zu nennenden “Betriebssystem” zur Standardausrüstung gehört und somit von diesen Clients aus keine extra Software / Installation benötigt wird.
Installation
Die Installation unter Ubuntu ist denkbar simpel -> apt-get install xrdp.
Konfiguration
xrdp läuft nach der Installation automatisch. Allerdings muss man um Zugriff auf den Rechner zu gewähren über die Gnome Desktop Einstellungen den VNC Server starten. Das ganze findet sich unter Menü-System-Einstellungen-Entfernter Bildschirm. Dort muss man “Anderen Benutzern erlauben, Ihren Bildschirm anzuzeigen” und “Anderen Benutzern erlauben, Ihren Bildschirm zu steuern” aktivieren. Des Weiteren sollte man ein Passwort setzen. Dieses hat jedoch nichts mit dem Anmeldepasswort des Accounts zu tun.
Anmeldung per RDP
Nun wird der RDP Client mit dem Rechner verbunden. Es erscheint ein Menü, in diesem man den Typ “Console” für die Sitzung wählt und kann dann mit dem vergebenen Passwort auf seine Sitzung zugreifen.
Naja
Also so wie ich es beschrieben habe gefällt es mir an sich selbst nicht. Ein großer Nachteil der Lösung ist, dass der Vino-Server (VNC Server unter Gnome) bei einem gesperrten Bildschirm versagt -> einen schwarzen Bildschirm zeigt. Des Weiteren ist in diesem Szenario der RDP Port als auch der VNC Port auf der Maschine offen. Gepaart mit dem “schwachen” Passwort welches wie oben konfiguriert haben, ist das nicht wirklich Sicher.
Man kann den Vino-Server auch deinstallieren und dafür x11vnc nehmen. Damit funktioniert das ganze auch bei gesperrtem Bildschirm. Leider ist damit die Performance um einiges schlechter. Ich habe keine Einstellung gefunden mit der x11vnc über xrdp so flüssig läuft wie mit dem Vino-Server. Da beißt sich die Katze in den Schwanz.
Mehr Bandbreite: Bonding mit Cisco
25. Feb
Gründe um Server mehrfach an die Netzwerkinfrastruktur anzubinden gibt es mehrere. In den meisten Fällen wird das (unter Linux) so genannte “bonding” dazu genutzt, einen Server an mehrere Switches anzubinden um die Redundanz zu erhöhen, wobei die Durchsatzrate dabei nicht erhöht wird – es wird immer nur eine Verbindung genutzt; sollte ein Switch ausfallen ist das System trotzdem weiterhin erreichbar.
| |
|port3 port3|
+-----+----+ +-----+----+
| |port2 ISL port2| |
| switch A +--------------------------+ switch B |
| | | |
+-----+----+ +-----++---+
|port1 port1|
| +-------+ |
+-------------+ host1 +---------------+
eth0 +-------+ eth1
Quelle: http://www.cyberciti.biz/howto/question/static/linux-ethernet-bonding-driver-howto.php
Meeeehr Bandbreite
Was wir hier möchten ist mehr Bandbreite. Dazu kann man – z.B. mit einem Cisco Switch – den Linux Bonding Mechanismus dazu nutzen, beide Verbindungen an einen Switch zu bündeln und dem entsprechend die Bandbreite zu verdoppeln. Damit habe ich auch schon ein Problem dabei angesprochen. Dieser Mechanismus funktioniert nur auf einem Switch. Man kann keinen “Etherchannel” (aus Cisco Sicht) über mehrere Switches bauen. Das damit entstandene Problem ist, dass ich keine Redundanz aufbauen kann im Sinne von “siehe oben”. Fällt dieser eine Switch aus, ist auch die Netzwerkverbindung komplett weg.
+----------+ +----------+ +--------+
| |eth0 port1| +-------+ Host B |
| Host A +------------+ switch |port3 +--------+
| +------------+ | +--------+
| |eth1 port2| +------------------+ Host C |
+----------+ +----------+port4 +--------+
Quelle: http://www.cyberciti.biz/howto/question/static/linux-ethernet-bonding-driver-howto.php
Konfiguration auf der Linux Seite
Die Konfiguration auf der Linux Seite sieht an sich eine normale Bonding Konfiguaration vor; hier die kurze Version für ein bond0:
/etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE=eth0 USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none
/etc/sysconfig/network-scripts/ifcfg-eth1:
DEVICE=eth1 USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none
/etc/sysconfig/network-scripts/ifcfg-bond0:
DEVICE=bond0 IPADDR=192.168.1.1 NETMASK=255.255.255.0 NETWORK=192.168.1.0 BROADCAST=192.168.1.255 ONBOOT=yes BOOTPROTO=none USERCTL=no
Normalerweise trägt man nun in der /etc/modprobe.conf folgendes ein (eine Variante):
alias bond0 bonding options bond0 mode=1 miimon=100
Damit wird das Modul für bonding geladen und festgelegt in welchem Modus das ganze arbeitet.
- mode=1 -> bedeutet “active-backup” – eine aktive Verbindung und die andere als Backup (unbenutzt für Traffic)
- miimon=100 -> damit wird alle 100 millisekunden per MII geprüft
Wir möchten aber nicht active-backup sondern einen PortChannel nach “IEEE 802.3ad” -> Dynamic link aggregation. Laut Doku:
Creates aggregation groups that share the same speed and duplex settings. Utilizes all slaves in the active aggregator according to the 802.3ad specification.
Dabei wird also eine Gruppe aus “Links” gebildet, die dann zusammen genutzt werden. Die Konfiguration dafür auf der Linux Seite ist sehr einfach, da lediglich die Einstellung für das bonding Device in der /etc/modprobe.conf geändert werden müssen. Also:
alias bond0 bonding options bond0 mode=4 lacp_rate=1 miimon=100
- mode=4 -> IEEE 802.3ad; ein Protokollstandard, den auch Cisco verwenden kann
- lacp_rate=1 -> dieser Parameter ist optional und legt fest, wie oft die Link-Parameter zwischen Switch und Server abgeglichen werden sollen (s. Bonding Howto)
Konfiguration der Cisco Seite
Auf dem Switch wird ein neuer Port-Channel angelegt …
interface Port-channel24 description POC-to-Linux-Server switchport <switchport access vlan 152 | switchport mode trunk> switchport mode access no ip address spanning-tree portfast end
und dann die korrespondierenden Interfaces …
interface GigabitEthernet3/33 description POC-to-Linux-Server switchport <switchport access vlan 152 | switchport mode trunk> switchport mode access no ip address channel-protocol lacp channel-group 24 mode passive end
Wie in den Beispielen zu sehen, kann man den Port-Channel so einrichten, dass nur ein VLAN durchgereicht wird oder auch als Trunk. Im Trunk mode würden dann alle VLANs durchgereicht und man könnte über eine VLAN Netzwerkkonfiguration beispielsweise einen “HT Router” (High Throughput) bauen.
An sich war es das. Der Server sollte nun die doppelte Bandbreite zum Switch hin haben. Am sinnigsten ist eine solche Anbindung natürlich an den zentralen Netzwerkkomponenten (Core Switches / Backbone). Es bringt nicht viel mit 2 oder sogar 4 Gbit/s an einen Switch angebunden zu sein, der seinerseits nur mit 1Gbit/s an dem Backbone angeschlossen ist.
sftp Server Teil II – “Jail made easy”
08. Feb
Im ersten Teil haben wir das aktuelle openssh Paket für RHEL gebaut und sollten das auch mittlerweile installiert haben. Die Konfiguration des SSH-Servers hat sich nur wenig geändert. Es gibt eigentlich auch nur wenig neue Stellen die hier für uns interessant sind. Aber wir beginnen am Anfang:
Gruppe für sftp
Die Steuerung ob ein Benutzer in einer “gechrooteten” Umgebung landet wird über eine Gruppe gesteuert. Diese könnte man beispielsweise “sftpchroot” nennen. Diese Gruppe wird also angelegt:
groupadd sftpchroot
Benutzer anlegen
Als nächstes muss der Benutzeraccount angelegt werden, der sich auch in der Gruppe sftpchroot befindet:
useradd testuser -G sftpchroot
(Passwort setzen oder disablen, je nach dem ob sich per Key oder Passwort eingeloggt werden soll. Eine Shell benötigt der User auch nicht unbedingt.)
Benutzerhome anpassen
Das Benutzerhome (/home/testuser) muss von den Rechten her angepasst werden, damit das “chrooten” funktioniert. Gleichzeitig legen wir ein Verzeichnis (exchange) an, in welches der Benutzer über sftp schreiben darf.
chown root:sftpchroot /home/testuser mkdir /home/testuser/exchange chown testuser:testuser /home/testuser/exchange
Möchte man die Authentifizierung per Key machen, so muss folgendes ebenfalls eingerichtet werden:
mkdir /home/testuser/.ssh chown testuser:testuser /home/testuser/.ssh
Der Key kommt dann in die authorized_keys; die Rechte werden auf 0600 gesetzt und fertig.
Logging
Wir möchten genau sehen, welche Befehle auf dem SFTP Server abgesetzt werden. Daher muss auch das Logging aufgesetzt werden. Dazu ist es nötig, dass in jedem Home ein dev Verzeichnis angelegt wird (-> mkdir /home/testuser/dev). Dort wird dann vom dem Syslog Server des Vertrauens eine Pipe angelegt und damit ist das Logging im System.
Wir verwenden den syslog-ng (syslog-ng). Die Konfiguration dafür sieht wie folgt aus:
source s_sftpchroot {
# Please add each chrooted environment here
# These logs stay on the local machine; not sended to the syslog-server
unix-stream ("/home/testuser/dev/log");
};
destination d_sftplog { file("/var/log/sftp_chrooted.log"); };
log { source(s_sftpchroot); destination(d_sftplog); };
Jede Chroot Umgebung muss hier im Abschnitt “source” eingetragen werden. Damit fließen alle sftp logs in eine Datei. Alternativ kann natürlich auch für jeden Benutzer ein eigenes Log geschrieben werden. Welche Konfigteile dazu angepasst werden müssen sollte ersichtlich sein
Openssh Chroot
Nun zu dem früher schwierigsten, heute jedoch einfachsten Teil. Das Openssh Chroot. Ich zeige einfach die Konfiguration – it`s that easy !
Subsystem sftp internal-sftp Match group sftpchroot X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp -l VERBOSE ChrootDirectory /home/%u
Mit dieser Konfiguation am Ende der sshd_config (/etc/ssh) bekommt jeder Benutzer, der sich in der Gruppe sftpchroot befindet, besondere Optionen. Unter anderem wird lediglich der interne sftp-server (internal-sftp) zugelassen, der mit dem Parameter “-l VERBOSE” sämtliche Befehle des Benutzers loggt. Fertig.
switchport per tcpdump bestimmen
05. Mai
Das unter Cisco verfügbare CDP Protokoll (Cisco Discovery Protocol) kann man nutzen – wenn eingeschaltet – um den Port zu bestimmen, an dem ein Server angeschlossen ist. Dazu muss man lediglich per tcpdump das CDP Paket empfangen und anzeigen. Der Rest ist an sich verständlich.
tcpdump -nn -v -i -s 1500 -c 1 'ether[20:2] == 0x2000'
Der Output dazu sieht dann beipielsweise so aus:
tcpdump: listening on bond0, link-type EN10MB (Ethernet), capture size 1500 bytes
15:16:16.901794 CDPv2, ttl: 180s, checksum: 692 (unverified), length 364
Device-ID (0x01), length: 8 bytes: 'SWITCH1'
Version String (0x05), length: 251 bytes:
Cisco IOS Software, Catalyst 4000 L3 Switch Software (cat4000-I5S-M), Version 12.2(25)EWA7, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2006 by Cisco Systems, Inc.
Compiled Mon 16-Oct-06 18:52 by dchih
Platform (0x06), length: 14 bytes: 'cisco WS-C4948'
Address (0x02), length: 13 bytes: IPv4 (1) 192.168.151.2
Port-ID (0x03), length: 19 bytes: 'GigabitEthernet1/27'
Capability (0x04), length: 4 bytes: (0x00000029): Router, L2 Switch, IGMP snooping
VTP Management Domain (0x09), length: 2 bytes: ''''
Native VLAN ID (0x0a), length: 2 bytes: 157
Duplex (0x0b), length: 1 byte: full
AVVID trust bitmap (0x12), length: 1 byte: 0x00
AVVID untrusted ports CoS (0x13), length: 1 byte: 0x00
1 packets captured
1 packets received by filter
0 packets dropped by kernel
Daraus lässt sich der Switchname (SWITCH1) herauslesen, der Port (GigabitEthernet1/27) und auch die VLAN ID (157) uvm. Wenn das Interface per Bonding betrieben wird, bekommt man hiermit lediglich die Information des aktiven Ports.




