Jan 29

cron ist ein Dienst, der schon seit den Anfängen von Linux mit „on Board“ ist. Dieser führt in regelmässigen angegebenen Abständen bestimmte Arbeiten aus.
Jedes mal, wenn cron seinen Dienst beendet hat, schreibt dieser eine Statuszeile in die /var/log/messages.

Die message wird somit relativ schnell unübersichtlich. Damit cron seine eigene Log-Datei erhält, müßen wir das den syslog-Daemon sagen. Denn cron schreibt nicht direkt in die messages, sondern übergibt die Statusmeldung an den syslog-Daemon. Diese schreibt dann alle eintreffenden Nachrichten in die zuständige Datei.

Befehl für Shell/Batch:
vi /etc/syslog-ng/syslog-ng.conf

 

Dort suchen wir nach … was relativ weit oben in der Datei steht. I.d.R. ist diese nicht auskommentiert.
Sollte ein # davor zu finden sein, so ist dieses zu entfernen.

Zitat:
filter f_cron { facility(cron); };

 

Ziemlich am Ende der Datei finden wir dann folgende beiden Einträge, die i.d.R auskommentiert sind.
Hier entfernen wir das # Zeichen.

Zitat:
destination cron { file(„/var/log/cron“); };
log { source(src); filter(f_cron); destination(cron); };

 

Nun würde syslog schon mal den Statuseintrag von cron in die Log von cron schreiben. Problem dabei ist nur, das nun die messages UND die cron den Eintrag erhält.
In der Mitte der Datei finden wir folgende Regel. Diese ist zu erweitern:

Zitat:
ALT:
filter f_messages { not facility(news, mail) and not filter(f_iptables); };
NEU:
filter f_messages { not facility(news, mail) and not filter(f_iptables) and not filter(f_cron); } ;

 

Das wars schon. Damit das ganze auch gültig wird, re-starten wir syslog.

Befehl für Shell/Batch:
/etc/init.d/syslog restart

 

Jan 28

Hier wird erklärt, wie wir Mailman auf ein Suse 11.1 System installieren.
Es wird davon ausgegangen, das Postfix (MTA) lauffähig ist.

Dank Yast, wird Mailman weitesgehend eingerichtet.

Befehl für Shell/Batch:
yast -i mailman

 

Damit wir Mailman auch über die Weboberfläche ansprechen können, müßen wir das den Apachen auch sagen:

Befehl für Shell/Batch:
vi /etc/sysconfig/apache2

 

Hier suchen wir nach „APACHE_SERVER_FLAGS„. i.d.R sollte dieser Eintrag leer sein. Andernfalls erweitern auf:

Zitat:
APACHE_SERVER_FLAGS=“SSL MAILMAN“

 

Mailman selbst beistzt kein SMTP und nutzt deshalb den MTA. In unseren Beipiel: Postfix.
Hier erweiteren wir die alias_maps um einen weiteren Eintrag, der direkt für Mailman gilt:

Befehl für Shell/Batch:
vi /etc/postfix/main.cf

 

Dort suchen wir nach alias_maps und erweitern diesen um folgenden Eintrag: „hash:/var/lib/mailman/data/aliases

Zitat:
alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases

 

Die Grundeinstellungen sind somit vorgenommen. Den Mailman hat uns die Vhost und einige andere notwenigen Einstellungen schon vorgenommen.
Diese rufen wir uns mal auf, damit wir mehr als nur die minimalen Grundeinstellungen bekommen

Befehl für Shell/Batch:
vi /usr/lib/mailman/Mailman/mm_cfg.py

 

Hier merken wir uns gleich mal die Domain, die Mailman anhand unseres System festgestellt hat. Dies ist die Adresse, die wir später über den Browser aufrufen werden.

In der letzten Zeile fügen wir nun eine neue Zeile hinzu, das Mailman sagt, das er mit uns in Deutsch „sprechen“ soll:

Zitat:
DEFAULT_SERVER_LANGUAGE = ‚de‘

 

Größtes Problem könnte es sein, das Mailmann für die Maillinglisten ein öffentliches Verzeichniss anlegt. d.h. irgendwann werden Mailing Listen Inhaber Ihre Postings in den Suchmaschinen wiederfinden. Dies kann aber unerwünscht sein. Mit folgenden Neu-Eintrag unterdrücken wir das Erstellen eines solchen Verzeichnisses:

Zitat:
DEFAULT_ARCHIVE = Off

 

Zitat:
Hinweiss: Wie zuvor schon genannt, hat Mailman den SMTP von MTA. Sprich: Mailman versendet nicht selbst die Emails, sondern schickt diese an Localhost. Wer an Localhost „horcht“ ist abhängig davon, was Ihr installiert habt. Z.b. Postfix, Sendmail etc.
Eine Mailliste ist in der Regel dafür da, das viele Mails auf einmal versendet werden können. Wer aber eine Mailling Liste hat, wo z.b. 10.000 Email Empfänger wird sicherlich schnell auf ein Problem treffen. Denn wenn z.b. in Postfix nicht gesagt worden ist, das 10.000 Mails auch rausgesendet werden dürfen, wird ein Problem bekommen.

 

Abfragen wir dies schnell mit:

Befehl für Shell/Batch:
postconf -d smtpd_recipient_limit

 

(Ungetestet) Mit den nachfolgenden Befehl können wir wohl Mailman auch sagen, das dieser nur 500 Mails verschicken soll. Postfix selbst darf aber 1000.

Zitat:
SMTP_MAX_RCPTS = 500

 

… dieser Eintrag kommt ebenfalls in die mm_cfg.py.

Bevor wir die Dienste starten, legen wir noch ein Passwort für das Webfrontend von Mailman fest.

Kurz Angemerkt:
Merke: Jede Mailing Liste hat sein eigendes Kennwort, was i.d.R. nur der Mailing-Listen Verwalter kennen wollte. Der Adminstrator erhält über das Master Passwort einen globalen Zugriff auf alle Mailinglisten. Ein solches Master Passwort legen wir wie folgt fest:

 

Befehl für Shell/Batch:
/usr/lib/mailman/bin/mmsitepass

 

Nun sollten die Grundlegenden Dinge eingerichtet sein. Zeit die Dienste neuzustarten und Mailman leben einzuhauchen.

Zitat:
/etc/init.d/postfix restart
/etc/init.d/apache2 restart
/etc/init.d/mailman start

 

Beim ersten Start von mailman kann folgener Fehler auftretten:

Zitat:
Starting mailmanSite list is missing: mailman

 

Mailman sagt uns hier, das die mailing Liste: „mailman“ nicht besteht. Dies scheint Grundvoraussetzung von Mailman zu sein. Ein Eintrag, wo wir diesen Ändern können, haben wir bis dato noch nicht gefunden. Ergo legen wir diese einfach an:

Befehl für Shell/Batch:
/usr/lib/mailman/bin/newlist mailman

Danach können wir mailman nochmal starten. Nun müßte dieser mit „done“ erfolgreich gestartet sein.

Jetzt können wir über den Browser Mailman aufrufen. Hierzu geben wir als erstes die Domain ein, die wir uns oben aus der Config gemerkt haben.
Zusätzlich hängen wir /mailman/admin/ an, damit wir ins Mailman Verzeichniss springen.

Z.B. hostname.domain.de/mailman/admin/

Da wir noch keine Mailling Liste erstellt haben, werden wir da noch nicht allzuweit kommen. Also springen wir wieder aus Admin raus uns hängen /create an:

Z.B. hostname.domain.de/mailman/create

Hier können wir nun alle Einstellungen für die neue Maillingliste einstellen. In der letzten Frage: „Authorisierungs-Passwort“ geben wir das Master Passwort vom Admin ein.

Über den Befehl rmlist kann man übrigens eine Liste wieder löschen:

Befehl für Shell/Batch:
/usr/lib/mailman/bin/rmlist

 

Wenn hier die Meldung … kommt, dann das ganze nochmal mit -a:

Zitat:
Archive nicht entfernt. Nochmals mit -a aufrufen, um sie zu entfernen

 

Befehl für Shell/Batch:
/usr/lib/mailman/bin/rmlist -a

 

Jan 26

TLS ist ein Zertifikat, die für vielen Bereichen Verwendung finden kann. Z.b. für verschlüsselte Webseiten oder für den verschlüsselten Email Verkehr.

Hier wird ein Zertifikat erstellt und selbst signiert. Da wir diesen später in Dovecot + Postfix einfügen, sind wir hier im der Pfadstruktur von Postfix.
Wo Ihr dieses Zertifikat erzeugt ist aber prinzipell egal.

Befehl für Shell/Batch:
mkdir /etc/postfix/tls
cd /etc/postfix/tls

 

Nun erzeugen wir einen privaten RSA Key. In einer 2048Bit Länge

Befehl für Shell/Batch:
openssl genrsa -out mail.key 2048

 

Als nächstes erzeugen wir eine sogannte CSR-Datei (Certificate Signing Request [engl.])
Wichtig hier ist bei der Abfrage bei: Common Name das hier hier eure korrekte Domain eintragt. z.b. webspace-for-you.de oder wenn es über eine Subdomain läuft: pop3s.webspace-for-you.de
Abhängig davon, was Ihr (eure Kunden) als Posteingangsserver / Postausgangsserver eintragen müssen.
Die Passwort-Abfrage lassen wir einfach leer. (Enter)

Befehl für Shell/Batch:
openssl req -new -key mail.key -out mail.csr

 

Zitat:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‚.‘, the field will be left blank.
—–
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Brandenburg
Locality Name (eg, city) []:Lübben
Organization Name (eg, company) [Internet Widgits Pty Ltd]:webspace-for-you Team
Organizational Unit Name (eg, section) []:webspace-for-you Team
Common Name (eg, YOUR name) []:webspace-for-you.de
Email Address []:info@DEINE_EMAIL_ADDY.de

Please enter the following ‚extra‘ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

 

So wie es oben beschrieben worden ist, gilt es immer. Also immer wenn Ihr ein SSL Zertifikat erstellen wollt.
Dieses Zertifikat muß aber noch signiert werden. Hier gibt es 2 Möglichkeiten:
* von ein Trust-Center z.b. PSW(kommerziell, aber ohne Fehlermeldung)
* wir selbst (Kostenfrei, aber Browser und Email-Client werden einmalig einen Fehler anzeigen)

Wir erzeugen nun einen kostenfreies lizensiertes Zertifikat, mit einer Laufzeit (Gültigkeit) von 10 Jahren.

Befehl für Shell/Batch:
openssl x509 -req -days 3650 -in mail.csr -out mail.cert -signkey mail.key

 

create_tls

 

Jan 24

Installationsquellen (Repo) in Yast hinzufügen

Linux Kommentare deaktiviert für Installationsquellen (Repo) in Yast hinzufügen

In OpenSuse 11.1 (Stand: 24.01.09) sind in den Installationsquellen kein PHPMyAdmin implantiert.
Dies ist jetzt nur ein Beispiel (von vielen möglichen), warum man zusätzliche Installationsquellen hinzufügen sollte. Denn diese stehen dann in der Installationsumgebung zur Verfügung.

Folgende Beispiele beziehen sich auf OpenSuse 11.1.
Die Version spielt hierbei keine Rolle, da die Quellen anhand eures Systemes automatisch eingelesen werden.

Hinzufügen der Quellen von PHPMyAdmin:

Befehl für Shell/Batch:
zypper ar -t YUM ftp://ftp5.gwdg.de/pub/opensuse/repositories/server:/php:/applications/openSUSE_11.1/ phpmyAdmin

 

Ebendfalls sind nur sehr wenige Apache Module gelistet. Wir wollen aber alle zur Auswahl haben:

Befehl für Shell/Batch:
zypper ar -t YUM ftp://ftp5.gwdg.de/pub/opensuse/repositories/Apache/openSUSE_11.1 Apache

 

Sinnvoll ist es auch, die aktuellsten Kernels parat zu haben:

Befehl für Shell/Batch:
zypper ar -t YUM http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_Factory/

 

Prinzipell kann man sich alles hinzufügen, was man als Sinnvoll erachtet.
Das Prinzip ist hierfür denkbar einfach:

Zitat:
http://download.opensuse.org/repositories/

 

Hier sind alle Repositories aufgeführt.
Hier sucht man sich nun den entsprechenden Dienst/Programm aus.
Die Verzeichnissstruktur weicht dabei je nach Programmauswahl ab.
Generell sucht man sich aber sein Betriebsystem aus und begibt sich dann in diesen Ordner.
In den meisten Fällen findet sich darin eine Datei mit der Endung ***.repo
Diese Datei sagt YAST, was in diesen Pfad alles zu finden ist.
Wenn Ihr z.B. in den Ordner x64_64 (oder i586) geht, könnt Ihr auch schon in vornherein sehen, was „Angeboten“ wird.

Kopiert euch den Pfad der repo Datei und hängt diese an folgenden Befehl an:

Befehl für Shell/Batch:
zypper ar -t YUM

 

Kurz Angemerkt:
Sobald Ihr in YAST unter OnlineUpdate (YOU) reingeht, erhaltet Ihr den Hinweiss, das ein GPG-Schlüssel noch importiert werden muß. Das ist der Schlüssel von der neuen Quelle, die Ihr hinzugefügt habt. Einfach auf Importieren gehen und die neuen Quellen werden beim Update berücksichtigt.

 

Jan 18

Hier beschreiben wir, wie man seinen 3Ware HDD Controller auf den aktuellsten Stand bringt und die Webbasierende ControllerSoftware 3DM2 installiert.
Dieses Howto bezieht sich auf ein Linux System, was 64-Bit ist und einen Controller: 9550SXU-4LP. Wer 32-Bit verwendet, kann hier natürlich dieses Howto genauso verwenden = muß aber entsprechend drauf achten, das er immer die 32-bit Version runterläd. Ebendso seinen Controller. Rest sollte gleich sein.

Windows Benutzer nutzen einfach die 3Ware CD worauf sich ein Windows Tool befindet, die den ganzen Update Prozess wesentlich einfacher macht.

Los geht’s:

Als ersten benötigen wir natürlich die Controller Firmware.

Zitat:
http://www.3ware.com/support/download.asp

 

Hier wählt man nun seinen Controller aus. Unter „Select 3ware Product“ holen wir uns als erstes die aktuellste Firmware Version.

Diese laden wir nun vom Server aus runter:

Beispiel für ein 9550SXU (Aktueller Stand: 18.01.2009)

Befehl für Shell/Batch:
wget http://www.3ware.com/download/Escalade9650SE-Series/9.4.3/9.4.3-9xxx-Upgrade.zip
unzip 9.4.3-9xxx-Upgrade.zip

 

Es werden 2 Datein entpackt, wo wir aber nur die prom0006.img benötigen.

Damit wir das Firmwareimage auch einspielen können, benötigen wir noch das Tool tw_update.

Dies finden wir ebendfals unter „Select 3ware Product“ und da dann tw_update. Danach noch eurer entsprechendes OS wählen. Für dieses Howto Linux 64-Bit.

Dies laden wir wieder auf unseren Server und entpacken es auch gleich

Befehl für Shell/Batch:
wget http://www.3ware.com/download/Escalade9650SE-Series/9.4.3/tw_cli-linux-x86_64-9.4.3.tgz
tar xfv tw_cli-linux-x86_64-9.4.3.tgz

 

Nun haben wir beides und können anfangen, den Controller auf den aktuellen Stand zu bringen.

Unbedingt Lesen:
Hinweis: Für die nächsten Befehle übernehmen wir keinerlei Garantie. Sollte eurer Controller durch das Update nicht mehr booten oder ähnliches, können wir hier nicht zur Haftung gezogen werden.

 

Befehl für Shell/Batch:
./tw_update fw=prom0006.img

Die Warnungen durchlesen und befolgen. Danach Y und Enter. Danach wird das Update auf den Controller geladen.
The new image will take effect after reboot.“ => dann tun wir das auch.

Jan 18

Sicherlich möchte der eine oder andere auch seinen Controller auch per Webinterface verwalten. Hierzu hat 3Ware die Software 3DM2.

Hierzu laden wir uns das Programm erstmal runter:

Zitat:
http://www.3ware.com/support/download.asp

Unter „Select 3ware Product“ wählt Ihr euren Controller au. Unter der Rubrik „Combined 3DM2 and CLI„ wählt Ihr eurer entsprechendes OS aus. Für Linux 64 bit würde das:

Befehl für Shell/Batch:
wget http://www.3ware.com/download/Escalade9690SA-Series/9.5.1/3DM2_CLI-Linux-x86_64-9.5.1.1.tgz
tar xfvz 3DM2_CLI-Linux-x86_64-9.5.1.1.tgz

 

Die Installationsroutine braucht u.a. das Paket bc. Damit wir es per Webinterface auch aufrufen können, natürlich auch den Apachen. Für Suse ist hier yast zuständig. Für Debian apt.

Befehl für Shell/Batch:
yast -i bc apache2 <= für SUSE aptitude install bc apache <= für Debian

 

Befehl für Shell/Batch:
./setupLinux_x64.bin –console

 

Console steht für den Textmodus. Solltet Ihr eine Grafische Oberfläche haben, dann kann dieser Zusatz weggelassen werden.

In der Installation folgende Tastatureingaben

Zitat:
1 = für weiter. Installation beginnt.

q = für das Beenden der Anzeige „ Lizenzbedingungen“
1 = für das wechseln von „Nicht akzeptieren“ zu „Akzeptieren“
0 = für das akzeptieren dieser Lizenzbedingungen

1 = für weiter
ENTER = wenn der vorgeschlagene Pfad = /opt/AMCC akzeptabel sein soll. Ansonsten ändern.
1 = für weiter

0 = für Softwareauswahl bestätigen (default = alles wird installiert)
1 = für weiter

0 = für weiter und aktivieren von Logging

1 = für Weiter und Beginn der Installation
3 = Fertig + Beenden der Installation.

 

Die Weboberfläche ist nun über:

Allgemeine Information:
http://localhost:888
oder
http://127.0.0.1:888

 

(ggf. mit https:// versuchen)

Zusätzlich kann man das Webinterface auch über eure ServerIP erreichen.

Allgemeine Information:
https://123.123.123.123:888

 

Egal wie Ihr auf die Weboberfläche zugreift lautet das Passwort nach der Neuinstallation für den User:
Administrator => 3ware.

Das Passwort sollte man DRINGEND ändern.
Unter „3DM 2 Settings“ sollte man dann auch gleich die Email Zustellung bei Fehlern einstellen.
Im Falle eines Problems, wird dann eine EMail verschickt.

Sonstiges:

Bei Fehlern, kann man in die /opt/AMCC/log.txt schaun.
Die config für 3DM2 findet man unter /etc/3dm2/3dm2.conf
Der zuständige Datei für das SSL-Zert lautet: /etc/3dm2/3dm2.pem (ggf. ersetzen wenn eigenes SSL vorhanden)

3DM2 wird über … neugestartet.

Befehl für Shell/Batch:
/etc/init.d/tdm2 restart

 

Jan 11

Wir beschreiben hier anhand von XEN das Rücksetzen bzw. Verändern des Root-Passwortes in einer Gastumgebung (DomU)

  1. Der Gast darf nicht laufen. Also beenden wir diesen 
    Befehl für Shell/Batch:
    xm shutdown <gastname>
  2.  

  3. Als nächstes mounten wir die Gastumgebung: 
    Befehl für Shell/Batch:
    mount -o loop /<pfad_zum_container>/<datei> /mnt  

    (Verwenden Sie eine XVDA Container Datei, so lesen Sie bitte den Thread „XVDA Conatiner mounten“)

  4.  

  5. danach chrooten wir uns in die Gastumgebung
    Befehl für Shell/Batch:
    chroot /mnt  

    (wenn ihr alles korrekt gemacht habt, dann verändert sich jetzt die shell ein wenig)

  6.  

  7. mittels … können wir nun das Passwort vom Root ändern
  8. Befehl für Shell/Batch:
    passwd  

Ggf. könnte die Fehlermeldung … kommen:

Zitat:
Öffnen von /dev/urandom zum Lesen nicht möglich: Datei oder Verzeichnis nicht gefunden
Erstellen eines Salt-Werts für die blowfish-Verschlüsselung nicht möglich  


passwort_setzen_error


Grund hierfür ist, das den Befehl „passwd“ die Entropie(Umwandlung) aus /dev/urandom fehlt.

Hinweiss zum Shell/Batch Code:
Hinweiss: Führen Sie den nachfolgenden Befehl vorzugsweise in der chroot-Umgebung aus.
Andernfalls könnte es passieren, das Sie die falsche Datei kopieren.
(wenn die passwd von Hauptsystem anders/defekt sein sollte)

Befehl für Shell/Batch:
cp /etc/default/passwd /dev/urandom

Mittels cp haben wir nun die Datei (die uns vorher gefehlt hat) entsprechend kopiert. Danach können Sie passwd erneut + erfolgreich ausführen.

passwort_setzen

 

Jan 09

Im vorheigen Artikel habe ich erklärt, wie wir ein Update für unsere Karte vornehmen.

Wie im Abspann schon genannt, sind die Netzwerkeinstellungen in den Hersteller Zustand zurückgesetzt worden. (DHCP aktiv)
d.h. die Karte ist nun nicht mehr über die damals eingerichtete IP-Adresse zu erreichen.

Supermicro bietet hier 3 verschiedene Datein zur Auswahl an.

Linux 32-bit => ipmicfg-linux_x86
Linux 64-bit => ipmicfg-linux_x86_64
Dos => ipmicfg.exe

Ich beschriebe das jetzt anhand eines Linux 64-bit System. Es ist aber egal, um welches System es sich dabei handelt. Es sind immer die gleichen Befehle. Nur auf die korrekte Datei muß beim Download geachtet werden.

Zuerst laden wir uns die Datei auf unseren Server. Ich gehe dabei davon aus, das wir über SSH bzw. VNC-Viewer mit den Server verbunden sind.

Auf der Shell laden wir uns nun die entsprechende Datei runter.

Bei Linux 32-bit

Befehl für Shell/Batch:
wget http://hilfedatenbank.de/wp-content/uploads/ipmicfg-linux_x86.zip
unzip ipmicfg-linux_x86.zip

Bei Linux 64-bit

Befehl für Shell/Batch:
wget http://hilfedatenbank.de/wp-content/uploads/ipmicfg-linux_x86_64.zip
unzip ipmicfg-linux_x86_64.zip

Windows Benutzer laden es einfach oben nur runter.

Linux Benutzer müßen die Datei noch ausführbar machen. Da wir die Datei später wieder löschen, machen wir das am schnellsten mit

Befehl für Shell/Batch:
chmod 777 ipmicfg-linux.x86
chmod 777 ipmicfg-linux.x86_64

Nun ist die Datei ausführbar und wird mittels … gestartet

Befehl für Shell/Batch:
./ipmicfg-linux.x86
./ipmicfg-linux.x86_64  

Zitat:
IPMICFG-Linux Version 1.06 (Build 070824) Copyright 2007 SuperMicro Computer Inc.
Usage: IPMICFG-Linux params (Example: IPMICFG -m 192.168.1.123)
-m         Show IP and MAC
-m IP      Set IP (format:###.###.###.###)
-a MAC     Set MAC (format: ##:##:##:##:##:##)
-k         Show Subnet Mask
-k Mask    Set Subnet Mask (format:###.###.###.###)
-dhcp on   Enable the DHCP
-dhcp off  Disable the DHCP
-g         Show Gateway IP
-g IP      Set Gateway IP (format:###.###.###.###)
-r         BMC cold reset
-garp on   Enable the Gratuitous ARP
-garp off  Disable the Gratuitous ARP  

IP Adresse setzen

Befehl für Shell/Batch:
./ipmicfg-linux.x86 -m 123.123.123.123
./ipmicfg-linux.x86_64 -m 123.123.123.123
ipmicfg.exe -m 123.123.123.123  

Netzwerkmaske setzen:

Befehl für Shell/Batch:
./ipmicfg-linux.x86 -k  255.255.255.0
./ipmicfg-linux.x86_64 -k  255.255.255.0
ipmicfg.exe -k  255.255.255.0  

Gateway setzen:

Befehl für Shell/Batch:
./ipmicfg-linux.x86 -g 123.123.123.0
./ipmicfg-linux.x86_64 -g 123.123.123.0
ipmicfg.exe -g 123.123.123.0  

Ein Reboot der Karte oder sogar des Servers ist nicht von nöten. Ein Aufruf  der IP Adresse im Browser eurer Wahl zeigt uns nun den altbekannten Loginscreen.
Nach dem Update waren nur die Netzwerkeinstellungen verloren gegangen. Die Benutzerebene blieb erhalten.
Somit können wir uns mit den alten Passwörtern weiterhin einloggen.

kvm_login_screen1

 

Jan 09

Wer ein Mainboard von der Firma „Supermicro“ sein eigen nennen darf, der hat die Möglichkeit, eine KVM-over-IP Karte auf sein Mainboard zu betreiben.
Dies ermöglicht den Benutzer, seinen Server bis auf BIOS Ebene zu verwalten. Dabei braucht er nicht direkt vor den Server zu sitzen, sondern kann diesen von überall aus der Welt steuern.
Irgendwann ist aber mal der Zeitpunkt gekommen, wo man seine Karte auf den Aktuellsten Stand bringen möchte.
In diesen Artikel wollen wir Ihnen dies erklären.

!!!Eins vor weg!!!
Nachdem ein Update vorgenommen wird, werden die Netzwerkkarten Einstellungen auf der Karte resettet.
Stand: von Version 1.47 auf Version: 1.59. Evtl. fixt das Supermicro in den nächsten Versionen, so dass nichts mehr manuell vorgenommen werden muß.
Problematisch wird es allerdings erst dann, wenn auf den Server kein lauffähiges Betriebssystem mehr vorhanden ist. Führt also zur Sicherheit erst ein Reboot durch und schaut, ob der Server nach kurzer Zeit wieder online zu erreichen ist. Es spielt hierbei keine Rolle, ob Linux 64 oder 32Bit verwendet. Ebendso Windows.

Los gehts:
Ich gehe davon aus, das die KVM-Karte bisher noch einwandfrei über die Weboberfläche zu erreichen ist.
Loggt euch hierbei über die Weboberfläche auf die KVM Karte ein.

kvm_login_screen

 

Im nachfolgenden Interface unter „Maintenance“ gibt es den Punkt „Device Information

kvm_weboberflaeche

 

Unter den Punkt „Firmeware Version“ können Sie die aktuelle Version entnehmen. Diese merken wir uns:

kvm_firmeware_detail_alt1

 


Nun suchen wir uns zu unserer KVM-Karte erstmal die passende Firmeware Datei (insofern überhaupt eine aktuellere vorliegt)

Unter: http://www.supermicro.com/products/accessories/addon/sim.cfm kann man sich seine Karte raussuchen. Dank bildlicher Abbildung, sollte jeder seine Karte identifizieren können. Wer seine Karte noch nie gesehen hat und diese Informationen auch nirgends erfahren kann, der hat bis dato ein großes Problem. Weder im Webinterface noch über die Consolen-Tools konnten wir diese Informationen entnehmen. Hinweise hierzu sind gern erwünscht. Besonders die Ausgabe unter „Hardware Revision“ wären hier Interessant.
Sollte der Wert „0x22“ einer bestimmten KVM-Karte zugeordnet sein, so handelt es sich hierbei um die „AOC-SIMLP-B(+)

Im obrigen Link suchen wir uns nun in der Tabelle die Karte raus. Unter Downloads in der Tabelle finden wir dann „[ Driver ]„.
Darin finden wir dann den Ordner:  „Firmeware
Hier sind 2 Ordner aufgeführt. „SIMBL“ und „SIMxx
Im Ordner SIMxxx finden wir dann eine Readme, die wir zur Sicherheit nochmal schnell durchforsten.
Dort finden wir folgende Zeilen:

Zitat:
SIM IPMI WITH KVM-Over-LAN Support:
Models: AOC-SIMLP-3+, AOC-SIMLP-B+, AOC-SIMSO+, AOC-SIM1U+, AOC-SIM1U-3B+, AOC-SIMLC+
Firmware: ugsim157.bin

 

SIM IPMI WITHOUT KVM-Over-LAN Support:
Models: AOC-SIMLP-3, AOC-SIMLP-B, AOC-SIMSO, AOC-SIMLC, AOC-SIM1U, AOC-SIM1U-3B
Firmware: ubsim157.bin  

Sucht hier eure Karte raus und merkt euch die Firmeware Datei. Ist eure Karte nicht dabei, seit Ihr m falschen Ordner.
Speichert euch diese Datei auf euren Rechner (Client).


Anhand des Dateinamens können wir auch schon erkennen, das es sich in diesen Fall um die Version: 1.57 handelt.
Zurück im Webinterface gehen wir in „Update Firmware„. (Ebendfalls unter  „Maintenance“)
Dort wählen wir nun die zuvor gespeicherte Datei aus und gehen dann auf  „Update„.

Das wars schon.
Im nachfolgenden Artikel erklären ich, wie wir der KVM Karte wieder eine IP vergeben, damit wir auf die Weboberfläche wieder kommen.
Denn nachdem das Update durchgeführt worden ist, ist die Karte Netzwerkmässig im Default Zustand.

kvm_firmeware_detail_neu

 

Jan 08

Laut Handbuch und Support-Team SOLLTE durch das entfernen des DSR*** aus DSView3 das Webinterface wieder freigeschaltet werden.
2 mal haben wir dies versucht…. 2 mal klappte es nicht.
Wie man dieses Problem behebt steht im anderen Thread.

Möglichkeit 1:
Den Switch selbst über die OSCAR Verbindung (local) zurücksetzen.
Edit: „Angeblich“ soll es nun in der aktuellen Firmeware Version nicht mehr gehen. Evtl. kann das mal jm prüfen.

Hier verbindet man einfach nur eine PS2 Tastatur und einen VGA-Monitor an den Switch selbst. Die OSCAR Verbindung wird mittels der <Druck>-Taste angezeigt.

oscar

Möglichkeit 2:
Wir gehen über die RS232 Schnittstelle direkt auf den Switch und schmeißen das SSL-Zertifikat was der DSView anlegt manuell raus.
Wir brauchen hier ein Null-Modem-Kabel und natürlich ein PC oder Laptop der noch eine Serielle Schnittstelle hat. (Alternative: USB to RS232 Adapter)

dsr4020_b

 

In Windows rufen wir dann das Hyperterminal auf (Unter Programme/Zubehör/)

hyperterminal

 

Danach sind wir schon mit der Console verbunden.

console_dsr

 

Punkt 2 => Security Configuration
Darin gibt es dann ein Punkt: Unbind from DSView 3 Server
Nun ist das Zertifikat entfernt und das Webinterface ist automatisch wieder freigeschalten

Ein Reboot soll wohl nicht notwendig sein => wer möchte, kann dies aber dort auch gleich vornehmen.

Nun kann der Switch wieder über die Weboberfläche angesprochen werden oder erneut mit DSView verbunden werden.
In einen anderen Artikel beschreibe ich, wie man den „Secure Mode“ ausschaltet.