Heute legt man daher die Datei /etc/hal/fdi/policy/mouse-wheel.fdi mit folgendem Inhalt an:

1
2
3
4
5
6
7
8

<match key="info.product" string="TPPS/2 IBM TrackPoint">
 <merge key="input.x11_options.EmulateWheel" type="string">true</merge>
 <merge key="input.x11_options.EmulateWheelButton" type="string">2</merge>
 <merge key="input.x11_options.XAxisMapping" type="string">6 7</merge>
 <merge key="input.x11_options.YAxisMapping" type="string">4 5</merge>
 <merge key="input.x11_options.ZAxisMapping" type="string">4 5</merge>
 <merge key="input.x11_options.Emulate3Buttons" type="string">true</merge>
</match>

Danach noch den Cache von HAL loeschen, HAL und GDM neu starten, und das neue Scrolling geniessen:

sudo rm /var/cache/hald/fdi-cache
sudo /etc/init.d/hal restart
sudo /etc/init.d/gdm restart

The installation of the client on modern Linux distributions is pretty straight forward.

1. get the packages
2. compile the kernel module
3. mess around in some config files

First step: get the packages
sudo apt-get install
openafs-client openafs-doc openafs-modules-dkms openafs-krb5 krb5-clients krb5-config krb5-user krb5-doc
(Yes, we’ll install the -doc-Packages, because everyone likes documentation)

Last step: the config files
Open /etc/krb5.conf and edit the sections containing the following:

1
2
3
4
5
6
7
8
9
10
11
12

[libdefaults]
        default_realm = MYCELL.NET
[realms]
        MYCELL.NET = {
                kdc = kdc1.mycell.net
                kdc = kdc2.mycell.net
                admin_server = kdc1.mycell.net
                default_domain = mycell.net
        }
[domain_realm]
        .mycell.net = MYCELL.NET
        mycell.net = MYCELL.NET

You should translate mycell.net to your local cell settings, but you already knew that, right? Ask your AFS Admin, if you are not sure about the correct values.

You may also take a look at /etc/openafs/afs.conf.client, /etc/openafs/ThisCell and /etc/openafs/CellServDB, but in most cases there’s no need to change something within these three files. If you need to get an updated version of /etc/openafs/CellServDB, just get it via FTP from grand.central.org.
wget -O /etc/openafs/CellServDB
ftp://ftp.central.org/pub/cellservdb/CellServDB

The very last step: restart the client
sudo /etc/init.d/openafs-client restart
Now the magic happens. The missing kernel module will be compiled in time and the OpenAFS-Client gets started. The benefit: remember updating your kernel and updating every single module again and again? dkms will help you, that you only need to update the kernel – the modules will be upgraded automagicly.

You’re done! kinit and aklog will be your best friends from now on!

The installation of the client on modern Linux distributions is pretty straight forward.

1. get the packages
2. compile the kernel module
3. mess around in some config files

First step: get the packages
sudo apt-get install
openafs-client openafs-doc openafs-modules-source openafs-krb5 krb5-clients krb5-config krb5-user krb5-doc
(Yes, we’ll install the -doc-Packages, because everyone likes documentation)

Next step: build the kernel module
Maybe you’ll need some more packages for this step:
sudo apt-get install module-assistant build-essential
Now start the module assistant, to build the openafs-module.
sudo module-assistant

The first entries “UPDATE” and “PREPARE” could take a few minutes, because eventually missing packages (e.g. kernel sources or headers, or the compiler-chain) will be installed. “SELECT” will open the next window, where you should search the module and select it.

Now build the module. The next question will be “would you like to install the build module?”, but you should now have a guess what to do
You should now exit the module assistant.

Last step: the config files
Open /etc/krb5.conf and edit the sections containing the following:

1
2
3
4
5
6
7
8
9
10
11
12

[libdefaults]
        default_realm = MYCELL.NET
[realms]
        MYCELL.NET = {
                kdc = kdc1.mycell.net
                kdc = kdc2.mycell.net
                admin_server = kdc1.mycell.net
                default_domain = mycell.net
        }
[domain_realm]
        .mycell.net = MYCELL.NET
        mycell.net = MYCELL.NET

You should translate mycell.net to your local cell settings, but you already knew that, right? Ask your AFS Admin, if you are not sure about the correct values.

You may also take a look at /etc/openafs/afs.conf.client, /etc/openafs/ThisCell and /etc/openafs/CellServDB, but in most cases there’s no need to change something within these three files. If you need to get an updated version of /etc/openafs/CellServDB, just get it via FTP from grand.central.org.
wget -O /etc/openafs/CellServDB
ftp://ftp.central.org/pub/cellservdb/CellServDB

The very last step: restart the client
sudo /etc/init.d/openafs-client restart
Stopping AFS services:.
Starting AFS services: openafs afsd.
afsd: All AFS daemons started.

You’re done! kinit and aklog will be your best friends from now on!

In order to build successfully, we’ll need some more packages, so fire up apt-get:
sudo apt-get install build-essential libtool autotools-dev automake1.9 subversion zlib1g-dev cython libglib2.0-dev libltdl-dev libcurl4-openssl-dev liblua5.1-0-dev libfontconfig1-dev libvlc-dev libx11-dev libdbus-1-dev libbz2-dev libid3tag0-dev libpng12-dev libtiff4-dev libungif4-dev libjpeg62-dev libfreetype6-dev libpam0g-dev libxcursor-dev libxml2-dev libssl-dev autoconf pkg-config libpng3-dev libxkbfile-dev libsqlite3-dev libimlib2-dev libtagc0-dev libtag1-dev libxmu-dev libxdamage-dev libxcomposite-dev libasound2-dev
all necessary dependencies will be installed.

Ready? Go!
sudo ./easy_e17.sh -i -e –packagelist=full
This will take a while, so get a coffee and a sandwich. But there are a few steps we can do aside.
Open a new terminal window and create the file /usr/share/xsessions/e17.desktop with the following content:

1
2
3
4
5
6
7

[Desktop Entry]
Encoding=UTF-8
Name=e17
Comment=
Exec=/opt/e17/bin/enlightenment_start
Icon=
Type=Application

Now edit /etc/environment or your local shell-config and append “:/opt/e17/bin” to the $PATH-entry (Without the quotes, of course).

Next time you’ll log off and see your GDM again, there should be an entry “e17″ in the window manager section.

Ohne viel dazu zu sagen (ich mag’s eigentlich nur aufschreiben, damit ich’s mir selbst irgendwann mal merken kann):
gpg --recv-keys --keyserver pgp.mit.edu ASDFJKLÖ1234
gpg --armor --export ASDFJKLÖ1234 | apt-key add -

Den entsprechenden Key (hier: ASDFJKLÖ123) natürlich vorher mit den Release-Pages von Debian bzw. welchem apt-getriebenen Linux auch immer gegenprüfen.

Nachdem wir die letzten beiden Jahre schon Parallel-Events zum Chaos Communication Congress im Forum41 abgehalten haben, wollen wir uns auch in diesem Jahr wieder vom 27. bis 30. Dezember 2009 im Forum41 treffen, dieses mal unter dem Motto “Dragons everywhere“, dem “distributed 26C3″-Konzept, dass die Organisatoren vom CCC dieses Jahr erstmalig als “Experiment” starten wollen (wir haben das ja schon die letzten beiden Jahre geübt).

Worum gehts?
Viele wollen, können aber aus den verschiedensten Gründen nicht zum Chaos Communication Congress nach Berlin pilgern oder sind der Meinung, dass man sich die Vorträge auch bequem von zu Hause aus per Stream anschauen kann. Genau diese Leute wollen wir damit ansprechen und erreichen.

Das Event wird gemütlich sein, Spaß am Gerät, belebende Getränke wie Club Mate oder Jolt Cola dürfen konsumiert werden (natürlich auch alle anderen nichtalkoholischen Getränke), es wird vermutlich wieder gebruncht oder zusammen Pizza gebacken (oder zu mindest gemeinsam bestellt und verspeist).

Das Ganze findet in Schwetzingen im Forum41 statt. Wer UUGRN schon länger begleitet wird das kennen, war vielleicht sogar schonmal auf einem der FIXME-Treffen dort.

Wer unsere Events kennt weiss, dass diese ohne Voranmeldung sind und auch keinen Eintritt kosten. “Spaß am Gerät” impliziert, dass man eigene Hardware mitbringen darf/soll. Wir sind eine Unix User Group, entsprechend werden Themen rund um unixoide Betriebssysteme vermutlich einen gewissen Focus haben, was jetzt Windows-User nicht so direkt ausgrenzen soll … wir sind schließlich tolerant.

Eingeladen sind Mitglieder und Freunde/Umfeld von UUGRN e.V. und NoName e.V. und solche, die uns kennen lernen wollen.

Nochmal Kompakt:
Was: Dragons everywhere / 26c3
Wo: Forum41, Schwetzingen
Wann: 27.12. bis 30.12. jeweils während der Videoübertragungen
Wer: Mitglieder, Freunde und solche die es werden wollen

Links:

• https://wiki.uugrn.org/UUGRN:Dragons_everywhere (alle Details / Orga)
• http://events.ccc.de/congress/2009/wiki/index.php/Dragons_everywhere
• https://wiki.uugrn.org/Spass_am_Geraet
• http://www.proclima.com/ (Sponsor für das Forum41)
• https://wiki.uugrn.org/Forum41
• http://events.ccc.de/congress/2009/
• http://fixme.uugrn.org/
• http://www.uugrn.org/

Wer vorher schonmal vorbei schauen will ist schon jetzt herzlich zum kommenden FIXME Treffen am 4. Dezember 2009 ab 20 Uhr im Forum41
eingeladen.

PS: es darf getwittert werden: #fixme, #26c3 und #c3fixme

Das original Announcement von Raphael ist im Archiv der Mailing-Liste der UUGRN zu finden.

This calendar is available via

• webcal, perfect for subscribing in iCal, Thunderbird and Outlook
• direct download
• web view (looks pretty strange)

I’m planing to update this calendar (so don’t just download it, subscribe it) in case of any changes.
Please keep in mind, that all the times are listed for the timezone Berlin/Germany and that germany switched back from daylight saving time (DST) to normal time today!

But … let me help you, dear user: screen -Dr!

My processes were not interrupted, even for the time my SSH-connection was down. Thanks to the almighty gods of Unix! *insertprayershere*

Don’t start processes outside of screen! It’s a shame.

Das erste Orga-Treffen zum Projekt “Linux Tag Rhein-Neckar 2010″ wird am 24 Oktober 2009 um 20 Uhr im “drei Lilien” in Mannheim stattfinden. (Bürgermeister-Fuchs-Straße, Ecke Gartenfeldstrasse)

Die Agenda für das Erste Treffen ist relativ übersichtlich:

• ab 20 Uhr: Begrüßung, Kennenlernen
• anschließend: Workshop mit Ideensamlung und Brainstorming zum Thema Linuxtag Rhein-Neckar
• abschließend: Planung für das zweite Treffen.

Das Treffen ist für alle Interessierten offen und wer helfen möchte soll sich eingeladen fühlen sich anzuschließen.

Mehr Informationen:

• zum Location-Update
• Blogpost zum ersten Treffen auf linuxtag-rhein-neckar.de
• linuxtag-rhein-neckar.de
• Preview hier in diesem Blog
• Linuxtag Rhein Neckar auf Twitter
• Twitter-Suche nach #lxrn

Unter Anderem behandelt er

• WLAN mit wpa_supplicant
• den ifplugd
• eigene VPN-Scripte einbinden
• automatische Erkennung der Netze

und einiges mehr.
Durchaus lesenswert.

Aus dem Umfeld der Ubuntu Users Mannheim wurde die Idee geboren, einen Linuxtag in Mannheim zu veranstalten. Gute Idee! Allem voran braucht so ein Projekt eine schlagfertige Gruppe an Mitstreitern, denn so ein Projekt hält sehr viele spannende Aufgaben bereit.

[Quelle: Raphael via linuxtag-rhein-neckar.de]

Für das erste Meeting der Orgas – natürlich bist Du eingeladen, falls Du helfen magst – wird im Moment ein Termin gesucht.

Ziel des Treffen ist es, alle Aktivisten für das Projekt Linuxtag Rhein-Neckar 2010 zusammen zu bringen. Jeder ist dazu eingeladen, auch Du!

Links:

• Website: linuxtag-rhein-neckar.de
• und der zugehörige RSS-Feed
• Termin-Suche für Orga-Treffen
• Mitmachen!
• Announcement auf der uugrn-Mailingliste

dmidecode is a tool for dumping a computer’s DMI (some say SMBIOS) table contents in a human-readable format. This table contains a description of the system’s hardware components, as well as other useful pieces of information such as serial numbers and BIOS revision.

…und gleich produktiv verwendet. Danke Stefan.

Inspiriert von Anil habe ich mir die nötigen Pakete für OpenAFS genauer angesehen, speziell die Dependencies.

openafs-client:

openafs-fileserver

openafs-krb5

krb5-user

krb5-clients

• … auf Windows
• … auf Linux
• … auf MacOS X

Vielleicht erspare ich so dem ein oder anderen Besucher die Suche.

The Teredo IPv6 tunneling protocol encapsulates IPv6 packets into UDP/IPv4 datagrams, to allow hosts behind NAT devices to access the IPv6 Internet.
Miredo is a Teredo client (as per RFC 4380): it can provide IPv6 connectivity to a dual-stack IPv6/IPv4 host even if it is located behind a NAT. It can also operate as a Teredo relay which forwards IPv6 packets between the IPv6 Internet and remote Teredo clients.

Miredo wird auf debianoiden Systemen per apt-get installiert und ist sofort nutzbar.

apt-get install miredo

Keine Konfiguration notwendig. Das schafft man in deutlich unter zwei Minuten

% ip ad sh teredo
5: teredo:
 mtu 1280 qdisc pfifo_fast state UNKNOWN qlen 500
    link/[65534]
    inet6 2001:f:53aa:erfg:3447:asdf:261c:b068/32 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::ffff:ffff:ffff/64 scope link
       valid_lft forever preferred_lft forever

Leider sind gute Tutorials zu dieser Thematik recht selten, aber vielleicht hilft Euch ja das Folgende. Ich beziehe mich auf die aktuelle Version von OpenVPN aus Debian GNU/Linux. Das Prinzip ist allerdings bei jeder OpenVPN-Installation gleich.

Beginnen wir mit einem “leeren” Debian, und installieren als ersten Schritt die notwendigen Pakete.

apt-get update
apt-get install openvpn openssl

Debian wird den OpenVPN-Dienst direkt starten, welcher aber nicht wirklich weit kommen wird, daher beenden wir ihn per /etc/init.d/openvpn stop.

In /usr/share/doc/openvpn/examples/easy-rsa/2.0 finden wir die notwendigen Scripte um die Zerifikate für die Clients sowie den Server zu erstellen. Als erstes kopieren wir den Inhalt dieses Verzeichnises in /etc. (Wer noch kein Backup-System für /etc hat, dem sei etckeeper ans Herz gelegt – man sollte Backups machen. Wirklich.)

Die Datei vars enthält ein paar default Werte, die auf den persönlichen Geschmack geändert werden sollten, denn hier werden die Meta-Infos für die Zertifikate abgelegt. Sobald die Datei angepasst ist, den Inhalt “sourcen”.

. ./vars

Die zwei Punkte sind wichtig, kein Tippfehler. Da wir mit einer neuen Grund-Installation anfangen, übernimmt das Script clean-all etwas Aufräumarbeit für uns. Danach per

./build-ca

die Zertifizierungsstelle ins Leben rufen. Um bei vielen Zertifikaten nicht durcheinander zu kommen, empfiehlt es sich im Feld “common name” den FQDN des VPN-Servers oder ähnlich sinnvolle Inhalte anzugeben. Im nächsten Schritt erstellen wir das Server-Zertifikat, also das Zertifikat, welches später der OpenVPN-Dienst auf dem VPN-Server verwendet.

./build-key-server <Servername>

“common name” füllen wir wieder sinnvoll aus. Zeit den ersten Client-Schlüssel zu erstellen:

./build-key <Clientname>

Beim Client-Zertifikat soll sich bitte jeder selbst überlegen, ob ein “Challenge Password” Sinn ergibt oder nicht. Effektiv bedeutet das nichts anderes, als das der Benutzer ein Passwort eingeben muß um den Tunnel zu starten.

Als letzte Aktion vorerst, generieren wir noch die Diffie Hellman Parameter (nicht nachfragen – wer’s wirklich wissen will, Google hilft weiter.) und sind dann bereit für die OpenVPN-Config.

./build-dh

Im Unterverzeichnis keys finden sich nun die relavanten Dateien der Zertifkate, die wir an die richtige Stelle im Verzeichnisbaum kopieren.

cp ca.crt ca.key dh1024.pem <Servername>.crt <Servername>.key /etc/openvpn

Die Datei /etc/openvpn/openvpn.conf ist der nächste Schritt. Der Inhalt sollte in etwa so aussehen:

port 1194
proto tcp
dev tun
ca ca.crt
cert <Servername>.crt
key <Servername>.key
dh dh1024.pem
server 172.16.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
user nobody
group users
persist-key
persist-tun
status openvpn-status.log
verb 3
client-to-client

Wer verhindern möchte, daß die verbundenen Clients miteinander kommunizieren können, entfernt die letzte Zeile. Die Zeile server 172.16.0.0 255.255.255.0 enthält das Range an IP-Adressen, die den VPN-Clients ausgegeben werden (recht ähnlich zu DHCP). Hier bitte natürlich ein valides Subnetz eintragen.

Mit /etc/init.d/openvpn start starten wir den OpenVPN-Dienst, und ein beherztes ifconfig bzw. ip ad sh sollte uns ein tun0 Interface zeigen.

Nun zum Client.

Die OpenVPN-Config des Clients sollte in etwa diesen Inhalt haben:

client
dev tun
proto tcp
remote <Servername> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert <Clientname>.crt
key <Clientname>.key
comp-lzo
verb 3

Die Dateien ca.crt, <Clientname>.crt und <Clientname>.key müssen natürlich vorher vom Server auf den Client übertragen werden. Wenn der Client nun gestartet wird, sollte eine Verbindung zum VPN-Server aufgebaut werden. Falls nicht, Ruhe bewahren und Log-Dateien ansehen.

Was fehlt noch? Auf dem VPN-Server müssen wir noch IP-Routing aktivieren, um das VPN-Client Netz mit dem lokalen Netz zu verbinden. Auf Linux geht das recht simpel per:

echo 1 > /proc/sys/net/ipv4/ip_forward

Diese Zeile möchte man wohl in einem der init-Scripte oder im Firewall-Script verstecken, oder per post-up hook in der /etc/network/interfaces definieren.

Das war’s. Eigentlich einfach, oder? Soll ein weiteres Zertifikat für einen weiteren Client erstellt werden, einfach die Zeile ./build-key <Clientname> wiederholen. Es empfiehlt sich die Zertifikate nicht auf dem VPN-Server liegen zu lassen, also das ganze easy-rsa-Verzeichnis nach getaner Arbeit auf eine andere Maschine zu verschieben. Ebenfalls bitte regelmäßig Backups davon anfertigen.

Je nach Setup muß die Route in das VPN-Client Netz noch auf den anderen Maschinen gesetzt werden.

Auf Linux per route add -net 172.16.0.0/16 gw a.b.c.d und auf Windows per route -p add 172.16.0.0 mask 255.255.0.0 a.b.c.d.

The Debian Project is pleased to announce the official release of Debian GNU/Linux version 5.0 (codenamed Lenny) after 22 months of constant development.

[From Debian -- News -- Debian GNU/Linux 5.0 released ]

Wurde aber auch Zeit.

So lasset die Update-Orgien beginnen…

Die entsprechenden Sourcen muessen natuerlich bekannt sein:
/etc/apt/sources.list:
deb http://ftp.de.debian.org/debian/ experimental main contrib non-free
deb-src http://ftp.de.debian.org/debian/ experimental main contrib non-free

apt-get install
openafs-client/experimental openafs-krb5/experimental openafs-modules-source/experimental

Danach noch das Kernel-Modul neu bauen (der module-assistant hilft) und den 1.5.50er Client geniessen.

Getestet unter 2.6.26 sowohl i386 als auch AMD64 – funktioniert soweit ich das sehen kann wunderbar.

Hinweis:
Um nicht beim naechsten dist-upgrade auf experimental zu rutschen, bitte noch folgendes:
/etc/apt/apt.conf:
APT::Default-Release "stable"; bzw.
/etc/apt/apt.conf:
APT::Default-Release "testing";

Quell-Host:
dpkg --get-selections > selections

Ziel-Host:
apt-get update
dpkg --set-selections < selections
apt-get -u dselect-upgrade


apt-get install menu menu-xdg xdg-utils
ln -s /etc/xdg/menus/debian-menu.menu /etc/xdg/menus/applications.menu

openafs-client:

openafs-fileserver

openafs-krb5

Soweit ja noch ganz überschaubar.

krb5-user

krb5-clients

“The resulting nodes will have several shapes; normal packages are boxes, pure provides are triangles, mixed provides are diamonds, missing packages are hexagons. Orange boxes mean recursion was stopped [leaf packages], blue lines are pre-depends, green lines are conflicts.”

[man apt-cache]

Erzeugen kann man solche Grafiken recht einfach mit dem graphviz-Paket.
apt-cache dotty Paket > /tmp/dotfile
dot -Tgif -o Paket.gif /tmp/dotfile

openafs-client in etch/stable: 1.4.2-6etch1
openafs-client in etch-backports: 1.4.7.dfsg1-3~bpo40+1
openafs-client in lenny/testing: 1.4.7.dfsg1-5

Mit dem Hintergedanken, daß Lenny im September 2008 erscheinen wird sollte, darf sich jeder jeder für sich überlegen, ob ein Upgrade auf Lenny oder Backports die richtige Wahl sind.

SSH Public-Keys sind toll. Kerberos ist besser!

Kerberos-Tickets kann man für SSH-Verbindungen nutzen, in etwa bildet man damit das Verhalten von SSH Public-Keys nach. Es kann allerdings mehr.

Was braucht man?

Einen Kerberos-Principal für den Benutzer und einen Principal für den Host. Den Key für den Host legt man mit einem random-Passwort an und exportiert ihn anschließend noch.
kadmin: ank user
kadmin: ank -randkey host/maschine
kadmin: ktadd -k /tmp/maschine.keytab host/maschine

Auf einem sicheren Weg nun die exportierte Datei auf den SSH-Server in /etc/krb5.keytab kopieren oder besser gleich verschieben.

Änderung am SSHd

Endweder man verwendet direkt das Paket ssh-krb5 oder man passt en existierenden SSHd etwas an.

/etc/ssh/sshd_config:
# Kerberos options
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes
# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes


Kerberos Client auf dem Server

Das Paket krb5-user muß installiert sein.

/etc/krb5.conf:
[libdefaults]
 default_realm = REALM
[realms]
 REALM = {
  kdc = kdc-master:88
  kdc = kdc-slave:88
  admin_server = kdc-master:749
  default_domain = domain
}
[domain_realm]
  .domain = REALM
  domain = REALM


Das war’s fast schon.

Der User

Im Home-Verzeichnis des Users die .k5login erzeugen und mit den Principals die sich anmelden dürfen füllen.
user@REALM
nocheinuser@REALM

Pro Zeile einen Principal.
That’s it.

Eine gute Möglichkeit trotzdem ein Debian “stable” zu installieren, ist den Kernel des Installations-Mediums auszutauschen – oder man bedient sich fertiger Images denen das bereits angetan wurde. Die Lösung kommt hierbei aus Japan, genauer gesagt von Kenshi.

Die fertigen Images für i386 und AMD64 stehen zum Download bereit und lassen sich auf dem R200 prima nutzen um ein stable-Release zu installieren. Wem der 2.6.25-2 nicht gefällt, kann danach direkt ein “Downgrade” zu 2.6.18-6 machen, denn damit läuft der R200 problemlos.

In meine Falle:
Linux appsrv01 2.6.18-6-xen-amd64 #1 SMP Fri Jun 6 06:38:05 UTC 2008 x86_64 GNU/Linux

Eine Alternative ist das Etch ½-Projekt.

Etch and a half is the nickname for a project to add newer packages (kernel, Xorg drivers and debian-installer) within the stable Debian ‘etch’ release to increase its usefulness to users with hardware that requires updated drivers.

Das Archiv heißt momentan (Stand: 06/08) tw_cli-linux-x86-9.5.0.1.tgz für unsere 9550SX. Einfach auspacken und das Binary tw_cli aufrufen.

Mit info werden alle vorhandenen Controller aufgelistet. info c0 listet die Details des ersten Controllers auf. help gibt eine Übersicht über alle Befehle. Und wenn nicht grade irgendwo “degraded” auftaucht, kann sich der Admin beruhigt zurücklehnen.

Type help <command> to get more details about a particular command.

Und was richtig schön ist: tw_cli info c0 spuckt die Infos aus und beendet sich wieder selbst. Das schreit ja förmlich nach einem Shell-Script und etwas grep.