Ich bin ein großer Freund von Konsolen. Aufgaben lassen sich hier meist viele schneller und einfacher erledigen als mit jeder GUI. Seit einiger Zeit nutze ich nun goosh.org als, sagen wir mal Google-Frontend 🙂 Schaut es euch einfach mal an!
Autor: kernel-error (Seite 41 von 48)
Diese Richtung ist bei mir ja eher selten… Denn noch habe ich mir gestern das Album Befehl von ganz Unte von Deichkind gekauft.
Tja, was soll ich sagen? Es gefällt mir 🙂 ganz vorne mit dabei sind: Illegale Fans sowie Roll das Fass rein!
Inzwischen bin ich richtig genervt. Die Menge an Funknetzwerken welche inzwischen durch meine Bude strahlen bringt mein Teewasser ganz ohne zutun zum Kochen. Die Marketingfutzies der großen Internetanbieter haben ganze Arbeit geleistet. Jeder glaubt nun es sei überhaupt kein Problem ein eigenes Funknetzwerk aufzubauen. Sicher auf Knopfdurck, sofern man nicht gerade eine Vodafonebox hat (ich lach mich schlapp). Zu allem Überfluss bricht nun hin und wieder meine Verbindung zusammen *strampel*.
Also habe ich nun mal nen kleinen Zettel geschrieben und an die Nachbarschaft verteilt. Ok ok… Es wird nichts weiter bringen, versucht habe ich es aber 😛
Solaris 11 und OpenIndiana: gMTP für die Dateiübertragung einrichten
Ich nenne schon seit einigen Jahren einen Creative ZEN Mozaic mein Eigen. Diesen konnte ich damals gegen einen Creative Muvo v100 eintauschen, welcher seither eine Telefonanlage mit Warteschleifenmusik füttert. Ja, der Muvo war schon ein feines Gerät… Der ZEN Mozaic hat mehr Platz und mehr Möglichkeiten. Für meine Zwecke ein schönes Gerät. Leider lässt sich dieser nur per MTP (http://de.wikipedia.org/wiki/Media_Transfer_Protocol) mit Daten befruchten. Unter Windows natürlich kein Problem, Linux Syteme bringen selbst Fuse Treiber mit usw. usw… Solaris selbst bringt hier erstmal nichts mit.
Jetzt möchte ich natürlich meine Podcast Sendungen und vor allem meine Musik auf den Creative ZEN Mozaic packen. Google hat mir gMTP (http://gmtp.sourceforge.net/) empfholen.
Es installiert sich //fast// von alleine und es funktioniert überraschend gut. Die beste Lösung die ich besher gefunden habe.
Einfach schnell hier herunterladen:
http://gmtp.sourceforge.net/#Downloads
Auspacken:
$ gunzip gmtp-1.3.1-i386.pkg.gz
Installieren:
$ pkgadd -d gmtp-1.3.1-i386.pkg
The following packages are available:
1 gmtp gMTP - A Simple MP3 Player Client for Solaris
(i386) 1.3.0
Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]:
Es fehlen noch ein paar Abhängigkeiten. Diese installiere ich schnell mit:
$ pkg install medialib libid3tag id3lib
Ich habe natürlich vorher das SFE eingebunden!
Libmtp fand sich leider nicht als Paket. Daher musste ich es schnell selbst kompilieren.
Hier ist das Tarball zu finden:
http://sourceforge.net/projects/libmtp/
Auspacken:
$ gunzip libmtp-1.1.1.tar.gz $ tar xvf libmtp-1.1.1.tar x libmtp-1.1.1, 0 bytes, 0 tape blocks x libmtp-1.1.1/missing, 11419 bytes, 23 tape blocks x libmtp-1.1.1/AUTHORS, 1587 bytes, 4 tape blocks x libmtp-1.1.1/ChangeLog, 99246 bytes, 194 tape blocks x libmtp-1.1.1/libmtp.sh, 1257 bytes, 3 tape blocks x libmtp-1.1.1/libmtp.pc.in, 334 bytes, 1 tape blocks x libmtp-1.1.1/config.rpath, 0 bytes, 0 tape blocks x libmtp-1.1.1/libmtp.pc, 334 bytes, 1 tape blocks x libmtp-1.1.1/configure.ac, 5439 bytes, 11 tape blocks x libmtp-1.1.1/config.h.in, 5373 bytes, 11 tape blocks x libmtp-1.1.1/util, 0 bytes, 0 tape blocks x libmtp-1.1.1/util/mtp-hotplug.c, 10884 bytes, 22 tape blocks x libmtp-1.1.1/util/Makefile.in, 19249 bytes, 38 tape blocks x libmtp-1.1.1/util/mtp-probe.c, 2327 bytes, 5 tape blocks x libmtp-1.1.1/util/Makefile.am, 216 bytes, 1 tape blocks x libmtp-1.1.1/TODO, 5124 bytes, 11 tape blocks x libmtp-1.1.1/config.guess, 44892 bytes, 88 tape blocks x libmtp-1.1.1/install-sh, 13663 bytes, 27 tape blocks x libmtp-1.1.1/examples, 0 bytes, 0 tape blocks x libmtp-1.1.1/examples/files.c, 3755 bytes, 8 tape blocks x libmtp-1.1.1/examples/connect.h, 1523 bytes, 3 tape blocks x libmtp-1.1.1/examples/pathutils.h, 1147 bytes, 3 tape blocks x libmtp-1.1.1/examples/getplaylist.c, 2531 bytes, 5 tape blocks x libmtp-1.1.1/examples/emptyfolders.c, 3117 bytes, 7 tape blocks x libmtp-1.1.1/examples/newplaylist.c, 3090 bytes, 7 tape blocks x libmtp-1.1.1/examples/thumb.c, 3181 bytes, 7 tape blocks x libmtp-1.1.1/examples/getfile.c, 2495 bytes, 5 tape blocks x libmtp-1.1.1/examples/trexist.c, 1815 bytes, 4 tape blocks x libmtp-1.1.1/examples/albumart.c, 4283 bytes, 9 tape blocks x libmtp-1.1.1/examples/playlists.c, 2358 bytes, 5 tape blocks x libmtp-1.1.1/examples/albums.c, 3433 bytes, 7 tape blocks x libmtp-1.1.1/examples/common.h, 1143 bytes, 3 tape blocks x libmtp-1.1.1/examples/connect.c, 4395 bytes, 9 tape blocks x libmtp-1.1.1/examples/filetree.c, 4062 bytes, 8 tape blocks x libmtp-1.1.1/examples/util.h, 987 bytes, 2 tape blocks x libmtp-1.1.1/examples/util.c, 1956 bytes, 4 tape blocks x libmtp-1.1.1/examples/newfolder.c, 2220 bytes, 5 tape blocks x libmtp-1.1.1/examples/delfile.c, 2850 bytes, 6 tape blocks x libmtp-1.1.1/examples/sendtr.c, 12189 bytes, 24 tape blocks x libmtp-1.1.1/examples/evolution-sync.sh, 3186 bytes, 7 tape blocks x libmtp-1.1.1/examples/pathutils.c, 7308 bytes, 15 tape blocks x libmtp-1.1.1/examples/sendfile.c, 2731 bytes, 6 tape blocks x libmtp-1.1.1/examples/Makefile.in, 25800 bytes, 51 tape blocks x libmtp-1.1.1/examples/format.c, 2288 bytes, 5 tape blocks x libmtp-1.1.1/examples/tracks.c, 4804 bytes, 10 tape blocks x libmtp-1.1.1/examples/folders.c, 3661 bytes, 8 tape blocks x libmtp-1.1.1/examples/Makefile.am, 1645 bytes, 4 tape blocks x libmtp-1.1.1/examples/reset.c, 2230 bytes, 5 tape blocks x libmtp-1.1.1/examples/detect.c, 8427 bytes, 17 tape blocks x libmtp-1.1.1/depcomp, 18615 bytes, 37 tape blocks x libmtp-1.1.1/Makefile.in, 27139 bytes, 54 tape blocks x libmtp-1.1.1/aclocal.m4, 80086 bytes, 157 tape blocks x libmtp-1.1.1/config.sub, 33387 bytes, 66 tape blocks x libmtp-1.1.1/README, 36487 bytes, 72 tape blocks x libmtp-1.1.1/doc, 0 bytes, 0 tape blocks x libmtp-1.1.1/doc/Doxyfile.in, 46716 bytes, 92 tape blocks x libmtp-1.1.1/doc/examples.h, 405 bytes, 1 tape blocks x libmtp-1.1.1/doc/Makefile.in, 10846 bytes, 22 tape blocks x libmtp-1.1.1/doc/mainpage.h, 528 bytes, 2 tape blocks x libmtp-1.1.1/doc/Makefile.am, 397 bytes, 1 tape blocks x libmtp-1.1.1/README.windows.txt, 2878 bytes, 6 tape blocks x libmtp-1.1.1/libmtp.sh.in, 1257 bytes, 3 tape blocks x libmtp-1.1.1/configure, 505284 bytes, 987 tape blocks x libmtp-1.1.1/Makefile.am, 649 bytes, 2 tape blocks x libmtp-1.1.1/ltmain.sh, 282765 bytes, 553 tape blocks x libmtp-1.1.1/hotplug.sh.in, 5055 bytes, 10 tape blocks x libmtp-1.1.1/src, 0 bytes, 0 tape blocks x libmtp-1.1.1/src/playlist-spl.c, 25484 bytes, 50 tape blocks x libmtp-1.1.1/src/libmtp.sym, 2551 bytes, 5 tape blocks x libmtp-1.1.1/src/libmtp.c, 304334 bytes, 595 tape blocks x libmtp-1.1.1/src/device-flags.h, 11410 bytes, 23 tape blocks x libmtp-1.1.1/src/libusb-glue.c, 64392 bytes, 126 tape blocks x libmtp-1.1.1/src/libusb-glue.h, 5990 bytes, 12 tape blocks x libmtp-1.1.1/src/music-players.h, 69263 bytes, 136 tape blocks x libmtp-1.1.1/src/libmtp.h, 34743 bytes, 68 tape blocks x libmtp-1.1.1/src/util.h, 1615 bytes, 4 tape blocks x libmtp-1.1.1/src/unicode.h, 1546 bytes, 4 tape blocks x libmtp-1.1.1/src/ptp-pack.c, 60195 bytes, 118 tape blocks x libmtp-1.1.1/src/util.c, 3223 bytes, 7 tape blocks x libmtp-1.1.1/src/libmtp.h.in, 34751 bytes, 68 tape blocks x libmtp-1.1.1/src/playlist-spl.h, 1367 bytes, 3 tape blocks x libmtp-1.1.1/src/ptp.c, 179847 bytes, 352 tape blocks x libmtp-1.1.1/src/Makefile.in, 21543 bytes, 43 tape blocks x libmtp-1.1.1/src/ptp.h, 107562 bytes, 211 tape blocks x libmtp-1.1.1/src/gphoto2-endian.h, 4610 bytes, 10 tape blocks x libmtp-1.1.1/src/README, 716 bytes, 2 tape blocks x libmtp-1.1.1/src/unicode.c, 5492 bytes, 11 tape blocks x libmtp-1.1.1/src/Makefile.am, 2560 bytes, 5 tape blocks x libmtp-1.1.1/src/_stdint.h, 76 bytes, 1 tape blocks x libmtp-1.1.1/INSTALL, 9480 bytes, 19 tape blocks x libmtp-1.1.1/m4, 0 bytes, 0 tape blocks x libmtp-1.1.1/m4/ltversion.m4, 686 bytes, 2 tape blocks x libmtp-1.1.1/m4/ltsugar.m4, 4372 bytes, 9 tape blocks x libmtp-1.1.1/m4/ltoptions.m4, 11950 bytes, 24 tape blocks x libmtp-1.1.1/m4/lt~obsolete.m4, 6126 bytes, 12 tape blocks x libmtp-1.1.1/m4/stdint.m4, 24070 bytes, 48 tape blocks x libmtp-1.1.1/m4/libtool.m4, 281197 bytes, 550 tape blocks x libmtp-1.1.1/m4/byteorder.m4, 12349 bytes, 25 tape blocks x libmtp-1.1.1/m4/iconv.m4, 6865 bytes, 14 tape blocks x libmtp-1.1.1/COPYING, 26426 bytes, 52 tape blocks
Ins Verzeichnis wechseln, konfigurieren, mit gmake kompilieren und installieren.
$ cd libmtp-1.1.1 $ ./configure --prefix=/usr $ gmake $ gmake install
Schon lässt sich gMTP per /usr/local/bin/gmtp starten und nutzen.
Für die Bilderliebhaber:
Man man man… Jetzt habe ich mich doch tatsächlich 1 Stunde lang in etwas sehr sinnlosem verrannt. *kopfschüttel*
Da will ich mal eben ein Bild mittels xsane von einem USB-Scanner einlesen. Da findet xsane auf dem Solaris 11 System den Scanner nicht. Genau so verhält es sich mit einer USB Digitalkamera….. Ich habe ja überall nachgeschaut, nur wohl ohne Verstand!
Die Lösung war natürlich recht simpel. Einfach mal das Paket: libusbugen installieren. *Narf*
Das folgende habe ich auf den Citrix XenServer in Version 5.6SP2 bis 6.2.0 anwenden können.
Im Grunde geht es darum auf dem „freien“ Citrix XenServer nrpe (Nagios Remote Plugin Executor) zu installieren um diesen mit Nagios auf einfache Weise überwachen zu können. Natürlich bietet der Cirtix XenServer ebenfalls die Möglichkeit ihn per SNMP zu überwachen und diese Version zu zu bevorzugen…. Für das eine oder andere Script ist die Ausführung per nrpe denn noch einfacher und schneller umzusetzen, als per snmp. Denn noch bitte beachten… Diese Version ist zwar absolut funktionsfähig und fast gefahrlos für das System, denn noch ist es „hereingefummelt“ und muss nach Versionsupgrade wieder (passend für die jeweilige Version) eingespielt werden. Die eigentliche Nagiosanbindung soll hier nicht Thema sein. Beispiele dazu kann man gerne bei mir erfragen.
So dann wollen wir mal:
Ich habe eine -schlechte- Angewohnheit. Ich erstelle immer gerne im Root das Verzeichnis 001 um dort meine Daten „herum zu würfeln“.
$ mkdir /001 $ cd /001
Im Grunde basiert der Citrix XenServer auf Redhat Linux/Fedora… Also können wir für diesen Fall auch die (Extra Packages for Enterprise Linux) epel nutzen.
$ wget http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm $ rpm -hiv epel-release-5-4.noarch.rpm $ sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/epel.repo
So und schon sollten wir die zusätzlichen Pakete nutzen können. In diesen findet sich sinnigerweise auch direkt nrpe, was wir gleich installieren:
$ yum install --enablerepo=epel nrpe $ chkconfig nrpe on
Das chkconfig nrpe on sorgt dafür dass der Service direkt beim Start des Systems mitgestartet wird. Wichtig ist nun noch die passenden Löcher in die Firewall des XenServers zu schießen. Sonst läuft zwar der Dienst, wir bekommen von außen aber keine Verbindung. Hier muss nur in der folgenden Datei eine Zeile ergänzt werden:
$ nano -w /etc/sysconfig/iptables ….. -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5666 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT ….
Damit wären wir schon feritg. Natürlich sollte man nun noch die Nagios Plugins installieren, Programme und Temperaturen von Festplatten oder IPMI auszulesen.
$ yum install --enablerepo=epel nagios-plugins hddtemp ….
Für IPMI (Intelligent Platform Management Interface) müssen ggf. noch die nötigen Kernelmodule geladen werden:
$ modprobe ipmi_devintf $ modprobe ipmi_si
Konfigurieren lässt sich nrpe nun wie bekannt über:
$ nano -w /etc/nagios/nrpe.cfg
Die Konfiguration von nrpe und Nagios ist aber unabhängig von der Installation auf dem XenServer.
Ich habe gerade den Hinweis bekommen, dass es helfen könnte wenn ich hier erwähne dass man sich die Nagios Plugins noch zusätzlich installieren muss. Dieses Stimmt natürlich 🙂 Ich habe mir mit der Zeit einen Satz recht weit „angepasste“ Nagios Plugins zusammengestellt. Diese schiebe ich mir oft (unter Berücksichtigung der Abhängigkeiten) einfach passend hin und her kopiere. Vielleicht ein Grund warum ich das -vergessen- habe zu erwähnen.
Wer die Freie Version des Citrix XenServers einsetzt hat in den meisten Fällen seine virtuellen Maschinen im Local Storage liegen. Natürlich hat ein Hardwareraid für diesen Speicherplatz Vorteile, aber er hat auch Nachteile.
Wie man hier dem XenServer nun einen Local Storage auf der Basis eine Softwarraids unterschieben kann, darum geht es hier!
Alle nötigen Schritte lassen sich direkt auf der Konsole des XenServers ausführen und ist vollständig mit Boardmitteln realisierbar. Die Konfiguration überlebt auch jegliche Updates/Upgrades von der Citrix XenServer Version 5.6 bis 6.1.0.
Wir gehen nun mal davon aus, eine 60GB SSD als Systemplatte für den eigentlichen Citrix XenServer zu haben und ein Softwareraid Level 5 aus drei Festplatten bauen zu wollen.
Damit hätten wir folgende Konfiguration:
/dev/sda => Systemplatte /dev/sdb => Erste Festplatte RAID /dev/sdc => Zweite Festplatte RAID /dev/sdd => Dritte Festplatte RAID
Die für das Softwareraid vorgesehenen Festplatten sollten natürlich keine Daten enthalten und keine Informationen im MBR (Master Boot Record) haben. Diesen löschen wir also zur Sicherheit mit:
$ dd if=/dev/zero of=/dev/sdb bs=1 count=1024 $ dd if=/dev/zero of=/dev/sdc bs=1 count=1024 $ dd if=/dev/zero of=/dev/sdd bs=1 count=1024
Auf den drei Festplatten muss anschließend jeweils eine neue Partition angelegt werden. Diese Partition muss vom Type FD (Linux Raid Autodetect) sein.
$ fdisk /dev/sd[b,c,d] N => neue Partition T => Type setzten => FD W => neue Partitionstabelle auf Platte schreiben Q => fdisk beenden
Mit diesen vorbereiteten Platten kann nun das eigentliche Softwarraid erstellt werden:
$ mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
Nun heißt es warten bis das Resilvering durchgelaufen ist. Wie weit es fortgeschritten ist lässt sich so beobachten:
$ watch –n 1 'cat /proc/mdstat'
Natürlich können wir jetzt schon auf das neue Softwareraid Laufwerk zugreifen. Ein Reboot sollte man aber erst nach dem ersten korrekten Resilvering durchführen.
Damit nun der Citrix XenServer Kenntnis von diesem neuen Speicherplatz erzählt, müssen wir es ihm noch „schmackhaft“ machen!
Zuerst legen wir auf diesem neuen Laufwerk nun eine Partition vom Type 8E (Linux LVM) an:
$ fdisk /dev/md0 N => neue Partition T => Type setzten => 8E W => neue Partitionstabelle auf Platte schreiben Q => fdisk beenden
Wunderbar 🙂 Dann schieben wir es mal dem XenServer unter:
$ mdadm --examine --scan > /etc/mdadm.conf $ pvcreate /dev/md0p1 $ xe sr-create type=lvm content-type=user device-config:device=/dev/md0p1 name-label="RAID-5"
Fertig…. Nun kann man schon im XenCenter den neuen lokalen Speicher RAID-5 finden und nutzen.
Es ist auch möglich dem Citrix XenServer einen lokalen Storage auf dieser Basis unter zu schiebe, der größer ist als 2TB. Dieses geht leider nicht mehr ganz mit Boardmitteln, da fdisk einfach die nötige Struktur nicht mehr anlegen kann. Der eingesetzte Kernel kann es aber sehr wohl ansprechen und verwalten. Hierzu schreibe ich sich später noch mal was. 😀
* U-P-D-A-T-E *
Zusammen mit gdisk lassen sich nun auch GPT Partitionen anlegen 🙂
XenServer und die smartmontools – Festplatten S.M.A.R.T.
Self-Monitoring, Analysis and Reporting Technology
Local ISO Repository
Citrix XenServer und local ISO Repository
Man kann zwar über das „klickbunit“ Interface XenCenter für seinen einzelnen XenServer neue ISO libarays anlegen, diese können dann leider nur auf einem Windows File Shareing (CIFDS) oder NFS ISO Share liegen. Klar, man könnte nun eine VM auf dem XenServer installieren und dort einen solchen Share anlegen O_o oder eine Kiste neben den Server stellen, welcher die ISOs vorhält. In größeren Umgebungen kein Problem… Im „Kleinen“ schon mal nervig.
Ich habe für mich eine einfache Lösung gefunden. Ich schraube einfach eine weitere kleine Platte in den Server, lege dort die für mich wichtigen ISOs ab und baue mir eine lokale ISO library. So habe ich die nötigen ISOs immer auf der Kiste, selbst wenn alles andere aus sein sollte.
Also lokalen Speicherplatz für die ISOs habe ich an eine 160GB SATA Platte von WD gedacht. Diese wird nicht gespiegelt oder ähnliches, da die ISO Files für mich erstmal keinen Wert haben. Brennt die Platte wirklich ab, kopiere ich die ISO Files halt auf eine neue.
Nach dem Einbau ist die WD Platte in meinem System als /dev/sde zu finden. Als erstes werde ich nun auf ihr eine primäre Patrion vom Type 83 (Linux) anlegen:
$ fdisk /dev/sde The number of cylinders for this disk is set to 19457. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Command (m for help):
Die Hilfe zu fdisk kann sicher jeder selbst lesen… Ich schaue als erstes über p nach ob ich wirklich auf der richtigen Platte bin, denn p listet mir die Partitionen auf der Platte auf. Dann erstell ich mit n ==> p ==> 1 eine neue primäre Partition und schreibe am Ende alles mit w auf die Platte. q beendet als letztes fdisk.
Nun muss ich die neue Partition noch formatieren. Als Dateisystem finde ich ext3 ganz passend:
$ mkfs.ext3 -L ISO-Store /dev/sde1
mke2fs 1.39 (29-May-2006)
Filesystem label=ISO-Store
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
19546112 inodes, 39072080 blocks
1953604 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
1193 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Nun erstelle ich einen Mountpoint unter welchem ich die Platte einbinden möchte:
$ mkdir /ISOs
Schon kann ich die Platte mounten:
$ mount /dev/sde1 /ISOs
Noch schnell eine kontrolle ob alles dort ist wo es hin soll:
$ mount|grep ISO /dev/sde1 on /ISOs type ext3 (rw)
Mit einem Eintrag in die fstab (ich muss immer aufpassen nicht vfstab zu schreiben) sorge ich nun dafür dass die neue Platte bei jedem Start des Servers wieder eingebunden wird.
$ vi /etc/fstab
und dann folgende Zeile einfügen:
/dev/sde1 /ISOs ext3 defaults 0 0
Jetzt kommt das wirklich spannende. XEN die neue Platte als localen ISO Speicher schmackhaft zu machen:
$ xe sr-create name-label=ISOs type=iso device-config:legacy_mode=true device-config:location=/ISOs content-type=iso 00da02b3-8b46-bade-6d00-e109e262ede9
Schaut doch schon gut aus, oder? Dann lassen wir uns mal die neue ISO library anzeigen:
$ xe sr-list uuid=00da02b3-8b46-bade-6d00-e109e262ede9
uuid ( RO) : 00da02b3-8b46-bade-6d00-e109e262ede9
name-label ( RW): ISOs
name-description ( RW):
host ( RO): xenserver01-kernel-error.local
type ( RO): iso
content-type ( RO): iso
Warum auch immer, wird die Platte bei mir an diesem Punkt immer ausgehangen. Ich könnte es jetzt einfach wieder mounten und nutzen, würde denn noch vorschlagen hier den Server selbst einmal zu rebooten. So kann man gleich sehen ob die Platte wieder richtig eingebunden wird. Nach dem Reboot schaue ich also nach ob die Platte wieder richtig eingehangen wurde:
$ mount|grep ISO/dev/sde1 on /ISOs type ext3 (rw)
Jetzt kopiere ich das nötige ISO auf die Platte:
scp WindowsSvrStd2008R2.iso root@10.44.2.88:/ISOs WindowsSvrStd2008R2. 100% |******************************************************************************************************************************************************************************************| 3052 MB 01:28
Im XenCenter sollte man nun schon das neue SR mit dem Namen „ISOs“ sehen. Klicke man nun am Reiter Storage auf Rescan wird das hochgeladene ISO gefunden und kann verwendet werden. Ich muss nun also nur noch alle meine ISOs dort hochschieben und fertig ist!
Regeln oder gute Vorsätze!
Meine Erfahrungen im Zusammenhang mit der IT haben gezeigt, dass es sehr hilfreich seien kann, wenn ich mich an ein paar Regeln halt. Diese Regeln oder besser guten Vorsätze habe ich mir selbst aufgestellt. Da ich immer und sehr gerne dazu lerne, ändert sich die eine oder andere Regeln hin und wieder. Hinter vielen Regeln steht meist eine kleine Geschichte. Immer mal wieder ist eine der Regeln aus einem Fehler entstanden, welcher mir passiert ist. Tja, wer ist schon fehlerlos? Aus Fehlern lernt man ja schließlich doppelt so gut, oder?
#01 – Nenne das Kind beim Namen!
Ich habe oft erlebt wie einige Informationen etwas „verschönert“ oder lange umschrieben wurden. So lang bis keiner mehr verstanden hat um was es geht und welche Probleme jetzt wirklich hinter dieser Entscheidung stehen können. Ich glaube eine klar verständliche und genaue Ansage ist wichtig. Sprechen alle über das Gleiche und haben die gleichen Informationen, passieren viele Fehler erst gar nicht und wenn doch, haben sich alle bewusst dafür entschieden.
Abschließend eine E-Mail mit den Absprachen an alle Beteiligten und schon schlafen alle besser!
#02 – Nicht ohne Backup!
Mal eben schnell den Patch einspielen oder das Upgrade auf die neue Version der Warenwirtschaft…. Im Raidverbund ist eine Platte kaputt, ich tausche die mal kurz und stoße das Resilvering an! Das habe ich schon tausend mal gemacht, das ist tausend mal ohne ein Problem durchgelaufen. Ich spare mir jetzt die Zeit fürs Backup…. Der alte Server wird jetzt über die nächsten 4 Tage migriert. Hier für beide Systeme eine Datensicherung einzurichten, kostet unnötig Geld und braucht viel Zeit, wir lassen das.
Nein, so geht es nicht! Immer wenn man etwas nicht gebrauchen kann geht etwas schief. Daher Regel #02: Nicht ohne Backup.
Natürlich gibt es eine Ausnahme von dieser Regel. Dafür muss Regel #01 beachtet werden und die entscheidenden „Internetausdrucker“ müssen einen Zettel unterschreiben, auf welchem so was steht wie: Ja, wir haben keine Dasi und ja, wenn etwas schief geht ist alles weg… Warum unterschreiben? Ganz einfach: Die „Internetausdrucker“ werden meist erst nervös, wenn sie etwas unterschreiben und sich selbst damit in der Pflicht sehen.
#03 – Geht das Backup?
Klar haben wir ein Backup. Das läuft jeden Tag und wir achten darauf das es immer ohne Fehler und zu 100% durchläuft. Das ist vor 5 Jahren von einem Experten eingerichtet worden. Seither läuft es ohne ein Problem.
Schön schön… Hat denn schon mal jemand versucht Daten aus diesem Backup zurück zu hohlen? Kann jemand diese komische Sicherungssoftware bedienen und bekommt man die Software im Fall der Fälle noch oder hat man dann nur einen Datenhaufen der einem nichts bringt? Hin und wieder sollte man doch mal testen ob sich die Daten aus dem Backup wirklich wiederherstellen lassen. Klappt es nicht, weiß man es bevor es ein Problem ist, klappt es weiß man wie lange es wohl dauern könnte! Ist es aus Kostengründen nicht gewünscht: Regel #01
Regelmäßige Tests des kompletten Backupsystems gehören in einen disaster revocery plan (DRP) Regel #13
#04 – Wie wichtig ist das überhaupt?
Es sollte immer abgesprochen und möglichst schriftlich fixiert sein, welche Priorität welches System für das jeweilige Unternehmen hat. Eine Firma kann problemlos drei oder vier Tage ohne E-Mails auskommen, andere sind nach 4 Stunden pleite. Unter Beachtung von Regel #01 sollte dieses _VORHER_ durchgesprochen werden. Wenn man jetzt noch Preise neben die gewünschte Verfügbarkeit schreibt, findet man schon zusammen.
#05 – Datenschutz!
Selten ist man als Systemadministrator der Datenschutzbeauftragte. Da man als Systemadministrator oft der Einzige mit „dem Überblick“ ist, sollte man entdeckte Probleme ansprechen und festhalten. Ein Administrator ist für mich eine besondere Vertrauensperson. Daher sollte ein Administrator immer darauf achten, dieses Vertrauen zu verdienen und zu behalten!
#06 – Ansprechpartner
Der Serverraum brennt, wie war noch gleich die Nummer von / wem überhaupt? Ohne Ansprechpartner geht es nicht. Je nach Unternehmensgröße sollte(n) der/die Ansprechpartner und deren Vertretung klar sein. Ein guter Ansprechpartner hat dabei ein gewisses technisches Grundverständnis (und versteht den Humor von Technikern). Ein richtig guter Ansprechpartner hat sogar noch die Möglichkeit einige Dinge selbst zu entscheiden. Ansprechpartner fallen ebenfalls aus Regel #13 heraus 🙂
#07 – Ein totes Pferd kann man nicht reiten.
Ein richtig altes Windows System kann man nur in ganz ganz ganz ganz extrem sehr sehr engen Grenzen noch „warten“, ähnlich es mit verbrauchter Hardware und und und… Selbst ein Microsoft Windows Server der vorletzten Generation machen in vielen Fällen keinen Sinn mehr. Natürlich muss man es immer abwägen und man sollte es selbst gut begründen können. Dennoch sollte man keine Angst vor einem _NEIN_ haben. Es gibt einfach Systeme und Techniken die sind tot und für diese kann man einfach keine Verantwortung übernehmen. Microsoft soll hier nur als Beispiel herhalten, ich bin ebenfalls schon Debian Systemen über den Weg gelaufen die aus den Archive quellen bedient wurden *kopfschüttel*.
Klar geht immer noch mal „etwas“, dieses nur im Zusammenhang mit Regel #01
#08 – Vergesse die Workarounds nicht!
Es gibt Probleme die sich nicht lösen lassen. Dieses weil, man es selbst gerade nicht besser weiß, es einfach wirklich nicht geht oder die Kosten für eine echte Lösung nicht zu rechtfertigen sind. Für diese Fälle gibt es Workarounds, welche man nur nicht vergessen sollte. Nicht da man später suchen müsste wie es noch gleich ging, nein damit der Workaround nicht der Standard wird! Unter Beachtung von Regel #01 sollte das Thema immer mal wieder aufgegriffen und bewertet werden. Selbstreden mit Sinn und Verstand. Es soll ja keine ABM werden.
#09 – Es lebe die Dokumentation!
Jetzt mal unter Freunden. Niemandem macht Dokumentation Spaß! Es ist nur leider wichtig…. Man kann sie nicht mal an den Azubi abgeben, denn beim Korrekturlesen muss man so viel ändern, da hätte man es direkt selbst machen können.
Zur Dokumentation muss ich mich in einigen Fällen selbst immer wieder motivieren. Vor allem wenn ich selbst davon überzeugt bin es nie wieder zu brauchen (da irrt man sich schon mal). Vielleicht braucht es mal ein Kollege?!?!
#10 – Hohl den Schraubendreher!
Wenn ich mit dem kleinen unpassenden Schraubendreher nur feste genug an der Schraube hier, dann müsste! Nein, im Werkzeugkasten (der immer im Auto liegt, welches wie immer viel zu weit weg steht da mal wieder kein Parkplatz…) ist ein passender. Also los, hohlen. Das richtige Handwerkszeug ist wichtig. Nicht nur in Hard- sondern auch in Software.
#11 – Ist der Stecker drin?
Es klingt dumm, ja. Der Benutzer sagt er habe alles schon probiert, dennoch sollte man zumindest einen kurzen Blick darauf werfen um sich ein eigenes Bild zu machen. Zu oft war zwar der Stecker drin, nur leider der von der Kaffeemaschine 🙂 Ein gutes, angepasstes troubleshooting erleichtert einem extrem das Leben. Man sollte sich selbst einmal damit auseinandersetzten und für sich einen klaren „Wegweiser“ erstellen. Es hilft einem den Punkt zu finden an dem man sich verrannt hat.
#12 – Jedem sein Login!
Jeder sollte einen personalisierten Account mit eigenem Kennwort haben. Nicht um dem jeweiligen vorhalten zu können was er da wieder verfriemelt hat oder um bei Problemen auf jemanden zeigen zu können. Meist werden Probleme am System ja nicht vorsätzlich verursacht. Personalisierte Accounts helfen sehr dabei, nachvollziehen zu können, was gelaufen ist und davon zu lernen. Wenn sich jeder mit seinem Namen anmeldet verändert dieses alleine schon den Umgang mit dem System. Zusätzlich lassen sich erteilte Berechtigungen so schnell und einfach in einem Audit kontrollieren. Hat mein ein zentrales Benutzermanagement lassen sich Zugänge und Rechte schnell und einfach sperren. Es soll ja Mitarbeiter geben die kündigen oder sogar gekündigt werden!
#13 – DRP
Es sollte immer einen DRP (disaster recovery plan) geben. Schon beim erstellen dieses Planes werden einem extrem viele Dinge bewusst die man sonst schnell unbeachtet lässt. Systeme werden priorisiert, es gibt Verantwortliche und Ansprechpartner. Es gibt einen Plan! Dieser wird regelmäßig geprüft usw… Ein DRP gibt nicht nur dem Admin Sicherheit auch das Unternehmen kann ruhig schlafen da es einen Plan für den Notfall gibt. Von genau diesem Plan profitieren dauerhaft und sofort viele andere Projekte und Systeme. Denn alles muss sich daran messen!
