Kleine und große Linux AHAs
Beiträge getaggt mit redhat
Owned: Meine Gnome3 “Ausflüge”
02. Mai
Da steh ich nun, ich armer Tor,
und bin so klug als wie zuvor.
Naja, so oder so ähnlich. So wie auch viele meiner Kollegen bin ich jemand, der – gerade was meinen Desktop angeht – sehr gerne immer das neueste an Software hat. Gnome3 sollte da keine Ausnahme sein. Aber wie? Wie siehts denn aus mit Ubuntu? Oder muss ich was anderes nehmen?
Für maverick hatte ich schon öfter mal nach einen funktionierenden, aktuellen PPA gesucht und nichts richtiges gefunden. Was dann? LMDE (Linux Mint Debian Edition) habe ich mittlerweile zu Hause installiert, da mir Ubuntu mit Unity nicht so recht passt (strategisch möchte ich das nicht unterstützen). Aber auch dafür gibt es noch kein Gnome3 
Naja, machen wir es rund. Was hab ich getan?
zu Hause
Zu Hause hab ich Fedora 15 (beta) installiert. Da ich über einige Jahre mit RedHat gearbeitet habe, konnte ich mich da recht schnell zurecht finden. Und ich muss sagen es funktioniert prima. Auch die Sache mit meinem ISCSI Laufwerk auf der NAS-Box (s. hier) habe ich ohne Probleme ans Laufen gebracht. Gnome3 funktioniert und bisher gab es keine Abstürze.
Ich muss auch einigen anderen Bloggern oder Berichten Recht geben, dass man sich sehr schnell daran gewöhnt und es dann auch mag. Persönlich finde ich die Oberfläche sehr modern und von der Bedienung her fortschrittlich. Einziges Manko sehe ich darin – wie auch viele andere – dass es zu wenig Tools gibt um den Desktop anzupassen. Selbst einen Menüeintrag kann man nur über Umwege realisieren.
Das Aussehen der Shell kann man anpassen – mit Hilfe des Tools Gnome-Tweak. Aber auch das ist noch ausbaufähig 
Arbeitsplatz
Nachdem Natty dann letzte Woche das Licht der Welt erblickte wurde es Zeit auch in der Firma den Rechner in die neue Welt zu hieven. Also erst ein Update auf Natty und mit Natty sollte es ja – laut diversen Beschreibungen – möglich sein Gnome3 zu installieren. Nach dem Update auf Natty waren schon mal die Desktop Effekte nicht mehr nutzbar. Also Treiber deinstalliert und neu installiert, reboot und gut – ging wieder. Dann Gnome3? Ja.
Gedacht, getippt und es erschien ein Gnome3 Desktop. Sah soweit ganz gut aus, aber … Naja, das Theme passte alles nicht mehr. Diverse Menüeinträge funktionierten einfach nicht (Systemeinstellungen).
Naja, ging ja noch.
Dann hab ich Empathy eingerichtet. Wollte doch unbedingt die neue Benachrichtigungsleiste mit der man auch direkt auf Chats antworten kann ausprobieren. Sah soweit gut aus. Bis zur 5 Nachricht – mit der sich dann der komplett Desktop verabschiedete. Das passierte dann auch nach einen Neustart noch öfter.
Ok, das war am Freitag Nachmittag. Also erst mal übers Wochenende so stehen lassen.
Nach dem Wochenende gabs dann Updates aus dem Gnome3 PPA. Also voller Hoffnung installiert. Danach war dann alles futsch. Der GDM funktionierte gar nicht mehr. Das System fror ein bevor der Anmeldebildschirm erschien. Das wars dann.
Also Ubuntu 10.10 Stick genommen und das ganze neu installiert. Home zurückgesichert und mein guter Gnome 2 Desktop ist wieder da. Alles gut.
Fazit
Gnome3 gefällt – wenn auch noch einiges an Arbeit ist. Den Ubuntu Test kann ich nicht wirklich empfehlen – mit Fedora sieht das um einiges besser aus.
Generell fehlt dem neuen Desktop noch einiges an Tools, die den persönlichen Desktop konfigurieren lassen. Auch Dinge die eigentlich logisch erscheinen sind meiner Meinung nach erst Ansatzweise umgesetzt. So sucht die Suche in Gnome3 (das Suchfeld rechts oben) nur in den zuletzt geöffneten Dateien, bzw. in den Anwendungen. Warum bringt man dort nicht direkt die Funktionalität rein die Gnome-Do, Kupfer oder Synapse auf den Desktop bringen? Des Weiteren gibt es zu Zeit kein Tool um das Menü zu editieren, bzw. eigene Menüeinträge anzulegen (das geht manuell über .desktop Einträge in .local/share/apps/).
Ich hoffe Ubuntu wird auch eine Version mit vernünftig integriertem Gnome3 anbieten. Ansonsten muss ich mir eine Alternative suchen. Bis dahin wird auf meinem Heimrechner Fedora mit Gnome3 laufen und das Arbeitsgerät mit Ubuntu 10.10 mit Gnome2.
(No Ratings Yet)
Loading ...
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 …
(No Ratings Yet) Loading ...
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”.
(No Ratings Yet) Loading ... 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.
(No Ratings Yet) Loading ...
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.
(No Ratings Yet) Loading ...“service” Befehl unter Ubuntu
09. Okt
Wir arbeiten auf dem Desktop mit Ubuntu – die Server sind alle RedHat. Der “service” Befehl, mit dem man Dienste starten und stoppen kann, ist unter RedHat schon immer (?) vorhanden. Unter Ubuntu / Debian bisher nicht. Zufällig haben wir nun festgestellt, dass service mittlerweile funktioniert.
Schön. Soll noch einer sagen die Unterschiede zwischen den Distributionen wären wahnsinnig groß
(No Ratings Yet) Loading ...Multipath mit Priorisierung
08. Okt
Mit Hilfe von Multipath kann man eine Art “Bonding” für Storage Devices erreichen. Es werden quasi mehrere Pfade zu einem (z.B.) SAN Device angebunden, jedoch nur ein Pfad und ein übergeordnetes Device genutzt. Vergleichbar mit Bonding aus dem Netzwerkbereich (Redundante Anbindung ans Netzwerk mit Hilfe von zwei Netzwerkkarten).
Um die Einrichtung von Multipath generell soll es in diesem Artikel nicht gehen. Es geht um die Priorisierung der Pfade. Warum Priorisierung ? Angenommen wir haben zwei Rechenzentren. Es befindet sich jeweils ein SDS (Storage Domain Server) in RZ1 und RZ2. Nun möchte man, dass die Server in RZ1 auch den SDS Server im RZ1 nutzen und vice versa.
Einige Hersteller von SAN Komponenten wie HP, IBM, Hitachi und auch andere stellen dazu Programme zur Verfügung, die in die Multipath Konfiguration eingebunden werden können. Diese Programme erkennen die vom SAN “gewünschten” Pfade und setzen dem entsprechend die Priorität. Hat man nun das Glück das SAN eines Herstellers mit nur wenig Linux Unterstützung nutzen zu dürfen, so sieht das ganze leider anders aus. Wir haben dieses Glück 
Wie funktioniert generell die Priorisierung unter Multipath ?
Das ist recht einfach, wenn auch nicht so einfach herauszufinden. Es gibt einen Parameter Namens “prio_callout”. Dieser Parameter hat als Argument ein Programm, welches von Multipath ausgeführt wird um die Priorität eines Devices zu bestimmen.
prio_callout "/sbin/mpath_prio_emc /dev/%n"
Dabei gibt das Programm lediglich eine Zahl – also die Priorität zurück (nicht als return code, sondern als normaler Output (STDOUT)). Als Variable kann “%n” (z.B. sda) übergeben werden. Das Device innerhalb einer Gruppe (eine Gruppe sind die Pfade, die zu dem gleichen Device führen) mit der höchsten Priorität gewinnt.
Keine Unterstützung des Herstellers ?
Wenn der Hersteller kein Programm liefert um die vom SAN gewünschte Priorität zu bestimmen (wie im Beispiel oben EMC), dann muss das ganze eben von Hand gemacht werden.
Man benötigt im Prinzip ein Script, welches eine Konfigurationsdatei einliest, in der die Informationen über Pfadpriorisierung enthalten sind und diese entsprechend zurück gibt. Ich habe das Script “multipath_prio.sh” genannt.
#!/bin/bash
# This script determines the multipath path prioritiy
# by manually configuring a priority to - if wanted - each path
#
# see config file for further information - /etc/multipath_prio.conf
#
# configure multipath:
# prio_callout "/usr/bin/mpath_prio.sh /block/%n"
#
# Ronny Becker, 09.2009
# parms
CONFIG="/etc/multipath_prio.conf"
# DEBUG
# level 0 - none
# level 1 - all
DEBUG=0
LOGFILE="/tmp/multipath_prio.log"
# div checks
if [ ! -e $CONFIG ]; then
if [ $DEBUG == 1 ]; then echo "`date` ${1} -- no config found: 0" >> $LOGFILE; fi
echo 0
exit
fi
if [ -z ${1} ]; then
if [ $DEBUG == 1 ]; then echo "`date` ${1} -- no parm given: 0" >> $LOGFILE; fi
echo 0
exit
fi
# get config data
# /sbin/scsi_id -i -g -u -s /block/sdc
# -> 2:0:0:1: 360030d90303031707838353062757369
# --> in configfile "2:0:0:1: 360030d90303031707838353062757369-1"
# the higher priority wins
SCSI_DATA="`/sbin/scsi_id -i -g -u -s ${1}`"
DATASET="`grep "^${SCSI_DATA}" $CONFIG`"
# if no line found
if [ $? != 0 ]; then
if [ $DEBUG == 1 ]; then echo "`date` ${1} -- grep to config not ok: 0" >> $LOGFILE; fi
echo 0
exit
fi
PRIORITY=${DATASET#*-}
if [[ $PRIORITY =~ ^[0-9] ]]; then
if [ $DEBUG == 1 ]; then echo "`date` ${1} -- OK: $PRIORITY" >> $LOGFILE; fi
echo $PRIORITY
exit
else
if [ $DEBUG == 1 ]; then echo "`date` ${1} -- no numeric value found" >> $LOGFILE; fi
echo 0
fi
Die Konfigurationsdatei sieht so aus:
# Configfile for multipath_prio.sh
#
# Use multipath_prio.sh to set manually preferred
# path priority.
#
# How:
# get scsi device information and ID by using:
# /sbin/scsi_id -i -g -u -s /block/ (ex. sdb)
#
# you get:
# 2:0:0:1: 360030d90303031707838353062757369
#
# put that line into the multipath_prio config including
# the priority setting:
# 2:0:0:1: 360030d90303031707838353062757369-1
# (priority of 1)
#
# - higher priority wins
#
# - if you only want to prefer one path, its enough to
# configure only this - the other path defaults to 0.
#
# - default is 0 (if no line matching and on errors)
#
# Ronny Becker, 09.2009
3:0:2:0: 360030d9030324e4147494f5353494c42-9
4:0:0:0: 360030d9030324e4147494f5353494c42-0
Das Format in der Konfigurationsdatei entspricht dem Output von “/sbin/scsi_id -i -g -u -s /block/<DEVICE>”.
Wie kann man nun herausfinden, welcher Pfad zu welcher SDS zeigt ? Da wir QLogic HBAs nutzen, konnten wir auf das Tool “ql-hba-snapshot” von QLogic selbst zurückgreifen. Das Programm mit dem Parameter “-v -a” aufgerufen zeigt genau welches Device welche LUNs verbunden hat. Um nun definitiv herauszufinden welche SDS dahinter steckt, muss man die WWPN des SDS kennen und entsprechend mit dem snapshot Tool vergleichen.
Am Ende muss der Parameter prio_callout in der /etc/multipath.conf auf das neue Script multipath_prio.sh konfiguriert werden – fertig. Das ganze ist ein wenig schwierig zu beschreiben – sollte jemand Fragen haben kann er sich an uns wenden.
(1 votes, average: 5,00 out of 5) Loading ...
