IT-Blog von Sebastian van de Meer

Kategorie: Self-Hosting & Infrastruktur (Seite 9 von 10)

Server selbst betreiben — Erfahrungen mit FreeBSD-Jails, Nginx, Postfix, Dovecot, Matrix und der eigenen Infrastruktur.

Hinzufügen der GPG Keys zum DNS

GnuPG bietet seit längerem verschiedene Möglichkeiten DNS Server nach gpg/pgp Schlüsseln zu fragen. Die aus meiner Sicht einfachste und schnellste ist PKA.

Kann der GPG Client den Schlüssel selbstständig aus dem Internet laden muss ich mich nicht mehr darum kümmern meinen aktuellen öffentlichen Schlüssel auf allen möglichen Key-Servern zu verteilen. Kommt der Schlüssel oder die Information zum Schlüssel und dessen Fingerprint noch von dem DNS Server, welcher für die Domain/Zone zuständig ist, kann man sich noch etwas sicherer sein. Ist diese Zone dann noch per DNSsec (http://www.kernel-error.de/dnssec) geschützt… Ja dann kann man noch etwas sicherer sein! 100%tige Sicherheit gibt es nicht, ich kann mich nur den 100% annähern. Um so besser mir dieses gelingt um so sicher kann ich mir sein 🙂

Wie geht es nun? Recht einfach. Ich exportiere meinen public key und sorge dafür das http clients (https ist nicht wirklich nötig, da der Schlüssel am Ende eh mit dem Fingerprint verglichen wird) diesen herunterladen können. Dann erstelle ich einen Fingerprint meines Schlüssels und veröffentliche beide Informationen zusammen mit der/den E-Mail Adressen in der DNS Zone.

OK los geht es. Zuerst besorge ich mir die Key-ID meines GPG-Keys:

$ gpg --list-keys kernel-error@kernel-error.com

Nun exportiere ich den öffentlichen Teil meines GPG-Keys, den public Key:

$ gpg --export --armor 0F9874D8 > kernel-error.asc

Jetzt brauche ich noch den Fingerprint meines GPG-Keys:

$ gpg --list-keys --fingerprint 0F9874D8

Nun beginne ich die records für meine DNS Zonen zu bauen. Diese sehen wie folgt aus:

E-Mail Adresse (das @ wird zu ._) gefolgt vom record Type TXT sowie dem Fingerprint ohne Leerzeichen und der HTTP-Adresse des öffentlichen Schlüssels.

Für mich schaut es so aus:

Zone kernel-error.com:

kernel-error._pka.kernel-error.com.  TXT         "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

Zone kernel-error.de:

kernel._pka.jabber.kernel-error.de.  TXT         "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"
kernel-error._pka.kernel-error.de.  TXT         "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

Zone vandemeer.de:

sebastian._pka.vandemeer.de.  TXT         "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

Ob sich die records abrufen lassen teste ich mit dig:

dig +short kernel-error._pka.kernel-error.com. TXT

Klappt dieses probiere ich ob gpg auch alles findet. Da ich den Schlüssel natürlich bereits in meinem Keyring habe, sage ich gpg dass es einen neuen Keyring unter /tmp/ anlegen soll. In diesen wird dann auch der Public Key importiert, wenn alles funktioniert 🙂 Das echo „foo“ | ist nur damit gpg auch Daten hat die es anfassen soll!

Es ist NICHT sicher, daß der Schlüssel zu dem in der User-ID
Genannten gehört. Wenn Sie *wirklich* wissen, was Sie tun,
können Sie die nächste Frage mit ja beantworten

Diesen Schlüssel trotzdem benutzen? (j/N) j
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.10 (GNU/Linux)

hQIMAyLQ0wrCELyPAQ//SaagWN6N57qIN1s0IksGwbXpchBTTW4FWZVotKUeHeHv
6LQ2abOL3ulRbzIHOmYINT3CUJ3Pf0DmFm44UqXP0Ay/R0PpANNqumshP8J+0aBY
YyhImPEk4s6qK8rJqD0+0F5sWrX7A2bPbmBHmp6BDQSpIUKxTXFTChJ0Hx7n/ntn
X3iLIpl3NYzvWd78Q+7lFcH9TDL+tLb655lwbZ4HcaQOT6NAkHAL76Td8CDQdbUM
Iu7UcZrpVebAaT7dL0HcifpNy+Vfo3xzq7b/MQsHxYASgafwtuOLCJr7Mi1bJqsk
eLZgxtLsflhgnkK/4Yj/zz7TosvUKb6ZemMxok6B95tmIMmBzJt9QPtBhuF6Uhgc
Vr6E6YSM3dKOy3e2N2YEYS/eXUk68S/2B+PtSBRxMuwMB9qIfLxqZPDrMgSoSOOz
7IaBqAy+HZ7JQdYDBg+6uLrf17+hjiX9g3X/sJB002lTqEJ5aIz+fe1QBXwqM97b
7hcOQCbEm1XQOFJmJWPsgROvpQhMZvd8ylLSIKtIKHqWgn0CkobABQ5Y9HJVkpO2
+DID8yT4Iy/be/YfCzU56i2AnswduZpK3bc2DLEPORVRp6PloNOmNhTXtf6IsN1X
mZfGr3sycFq7XNY9M5nha6Jco2ZdBSgebcKNZlkPF7f1GMDfnAAJgwUcX0QMSp7S
PwFvh2D0NqPcl1Rb7ManjL5tpR0NCjnxVEPNRv0j+2Ejr7LGKH/yqZVbnr+eiSRX
FPSvDQJVgT65sPIyn0k6tg==
=k7cd
-----END PGP MESSAGE-----

Tja, damit sollte wohl nun jeder meinen GPG-Key über meinen per DNSsec geschützten DNS Server besorgen können.

DNS konfigurieren um die XMPP Information zu verteilen

Warum vergessen nur immer alle die DNS Informationen zu ihrem neuen Jabber-Server zu setzten? Ich bin heute sicher zum 12 mal nach einem Problem gefragt worden welches damit zusammen hing. Die Info fehlt aber auch in _fast_ jedem Howto. Kopieren denn wirklich alle nur noch Zeile für Zeile? Als Wikipedia mal einen Tag ausgesetzt hat, konnten tausende keine Hausaufgaben abgeben. Irgendwie habe ich dass Gefühl, wenn Google mal einen Tag aussetzten würde könnten tausende „Admins“ nichts installieren oder Probleme lösen ;-P

Also um es noch mal in Google zu werfen:

Damit die Kommunikation zwischen den Jabber-Server sauber läuft müssen die nötigen DNS Records vorhanden sein. Für meinen Bind schaut es so aus wie im folgenden Beispiel:

_jabber._tcp.jabber.kernel-error.de.       IN SRV   0 0 5269   jabber.kernel-error.de.
_xmpp-server._tcp.jabber.kernel-error.de.  IN SRV   0 0 5269   jabber.kernel-error.de.
_xmpp-client._tcp.jabber.kernel-error.de.  IN SRV   0 0 5222   jabber.kernel-error.de.

Testen lässt sich dieses am Ende natürlich mit dig:

$ dig SRV _xmpp-server._tcp.jabber.kernel-error.de +short
0 0 5269 jabber.kernel-error.de.

$ dig SRV _xmpp-client._tcp.jabber.kernel-error.de +short
0 0 5222 jabber.kernel-error.de.

Ejabberd Dualstack IPv4 und IPv6

Wie so oft führen viele Wege nach Rom. Damit Ejabberd auf der IPv4 und den IPv6 Adressen gleichzeitig lauscht hat sich für mich folgender als gut erwiesen:

In der Konfigurationsdatei: /etc/ejabberd/ejabberd.cfg

Im Abschnitt Listening Ports einfach in die Portkonfiguration inet4 sowie inet6 aufnehmen:

{5222, ejabberd_c2s, [
                        inet4,
                        inet6,
                        {access, c2s},
                        {shaper, c2s_shaper},
                        {max_stanza_size, 65536},
                        %%zlib,
                        starttls, {certfile, "/etc/ejabberd/ejabberd.pem"}
                       ]},

Schon arbeitet Ejabberd mit beiden:

# netstat -an|grep 5222
tcp6       0      0 :::5222                 :::*                    LISTEN     
tcp6       0      0 *:5222                 *:*                    LISTEN    


Ach ja, Ejabberd Version ist gerade: 2.1.5

Wechsel von Openfire zu Ejabberd

Ich betreibe nun schon seit…. Oha…. Seit langem 🙂 einen eigenen Jabber-Server.

Jetzt ist das Teil alles andere als ein großes System mit mehreren tausend Usern. Er wird genutzt von der Familie, ein paar Freunden und Bekannten. Mehr sollte und soll es auch nie werden. Vor knapp zwei Jahren habe ich auf Openfire gesetzt. Openfire bietet eine recht ausgereifte klickibunti Oberfläche. Leider kamen in der letzten Zeit immer mal wieder nervige Bugs hinzu.  

Zum einen ist kein Paket für meine Umgebung dabei. Also muss ich das Ding immer von Hand reinwursten. Dann hat es mich einiges an Überzeugungsarbeit gekostet das Openfire nicht als root laufen will, wer will schon Software als root ausführen? Dann waren da noch ein paar Bugs bezüglich SSL in der Server zu Server Kommunikation und diesen nervigen Dialback errors…..  Nun scheint die aktuelle Version: 3.7.1 sowie auch das nightly build 2011-12-21 ein Problem mit IPv6 und DNS zu haben. So genau bin ich auch jetzt nicht dahinter gekommen.  

Wie auch immer!
Das Kraken – IM Gateway scheint leicht eingeschlafen zu sein, Openfire selbst ist in seiner Weiterentwicklung auch etwas seltsam. Vielleicht hat das Projekt geforkt und ich habe es verpasst? Ist ja auch schon vorgekommen, zuletzt verpasste ich StarOffice zu OpenOffice (peinlich peinlich). Da mir nun drei mal ein Bug bei Openfire so vor das Scheinbein getreten hat, dass keine nutzbare Funktion von Jabber übergeblieben ist (zumindest so wie ich sie mir vorstellen, also mit IPv6 und Verschlüsselung. Habe ich mich dazu entschieden zu Ejabberd zu wechseln.

Ejabberd hat fertige Pakete für meine Umgebung im Repository. Somit kann ich auch auf einfache Sicherheitsupdates hoffen. Transporter für ICQ / MSN… sind selbstverständlich überhaupt kein Problem und da Facebook (Familie ihr wisst schon….) direkt per Jabber erreichbar ist, ist alles gut 🙂

Meine paar Konten habe ich recht schnell aus Openfire und in Ejabberd bekommen. Nun läuft mein Messanger also über Ejabberd.

2012.05.03 13:40:26 org.jivesoftware.openfire.session.LocalOutgoingServerSession - Error authenticating domain with remote server: domain.org
java.lang.NumberFormatException: For input string: "4860:4860::8888"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
    at java.lang.Integer.parseInt(Integer.java:458)
    at java.lang.Integer.parseInt(Integer.java:499)
    at com.sun.jndi.dns.DnsClient.<init>(DnsClient.java:105)
    at com.sun.jndi.dns.Resolver.<init>(Resolver.java:44)
    at com.sun.jndi.dns.DnsContext.getResolver(DnsContext.java:553)
    at com.sun.jndi.dns.DnsContext.c_getAttributes(DnsContext.java:413)
    at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:213)
    at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:121)
    at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:109)
    at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:123)
    at org.jivesoftware.openfire.net.DNSUtil.srvLookup(DNSUtil.java:199)
    at org.jivesoftware.openfire.net.DNSUtil.resolveXMPPDomain(DNSUtil.java:131)
    at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSession(LocalOutgoingServerSession.java:269)
    at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain(LocalOutgoingServerSession.java:167)
    at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPacket(OutgoingSessionPromise.java:261)
    at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(OutgoingSessionPromise.java:238)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

XenServer mit Nagios überwachen

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.


XenServer Linux Softwareraid

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 🙂

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!

Citrix XenCenter SR local ISO library

XEN Server

Zu den Virtualisierungsumgebungen von VMware ist XEN vor allem mit dem Cirtix XenServer eine echte Alternative. Hier finden sich nur ein paar vielleicht sogar lesenswerte oder hilfreiche Informationen.

Wikipedia schreibt dazu:
http://de.wikipedia.org/wiki/Citrix_Systems

Citrix Systems

Die Citrix Systems, Inc. ist ein US-amerikanisches Softwareunternehmen, das 1989 von Ed Iacobucci gegründet wurde und jetzt in Fort Lauderdale in Florida ansässig ist. Citrix-Aktien werden an der NASDAQ unter dem Kürzel CTXS gehandelt. Citrix Systems ist in 35 Ländern aktiv. Das Unternehmen ist Mitglied in der Linux Foundation.

Der Hauptsitz der Region „Central Europe“ befindet sich in Hallbergmoos bei München. Die Citrix Systems International GmbH hat ihren Sitz in Schaffhausen in der Schweiz.

Laut eigenen Angaben setzen 230.000 Unternehmen weltweit Citrix-Technologien ein, darunter 99 Prozent aller Fortune Global 500-Konzerne. Seit der Übernahme von XenSource Inc. im Oktober 2007 verantwortet Citrix Systems das Xen Open Source Hypervisor-Projekt.

Citrix XenServer

Seit Oktober 2007 umfasst das Citrix-Produktportfolio auch die Virtualisierungstechnologie Xen. Dies ermöglicht komplett homogene Infrastrukturen. Von der Bare-Metal-Virtualisierungsplattform in Rechenzentren über Plattformen zur Anwendungsbereitstellung, (Windows/Web/OS via ICA-Protokoll), über das Anwendungs- oder OS-Streaming über jede Art von Verbindung an jeden Ort bis hin zu Appliances für Security und WAN Optimierung kann Citrix Produkte liefern, welche durch ihr modulares Design optimal zusammen aber auch separat genutzt werden können.

Seit April 2009 stellt Citrix auch eine geringfügig eingeschränkte kostenfreie Version von XenServer zur Verfügung.

Eigenen Jabber-Server einrichten: Schritt-für-Schritt-Anleitung

Ich nutze Jabber schon länger als Messenger. Nun habe ich mir die Frage gestellt ob es nicht sinnvoll ist einen eigenen Jabber-Server zu betreiben…. Hier kann man nun etwas dazu lesen!

Warum ich Jabber benutze kann man schnell erkennen, wenn man sich das Thema Policy durchliest! Zudem bietet Jabber extrem viele Vorteile. Ich zähle mal ein paar auf 😀

– Jabber ist OpenSource, jeder kann sich also den Code anschauen. Es wird schwer hier Schadcode zu verstecken.
– Gerade weil jeder an den Code kann, kann auch jeder recht gut neue Software dafür entwickeln.
– Es gibt Transporter um, sofern man möchte, auch Verbindung zu ICQ, AIM, MSN usw. zu bekommen.
– Verschlüsselung per SSL/TLS/GPG usw. ist meist kein Problem und sehr einfach einsetzbar.
– Es gibt nicht ein zentrales Hauptsystem, welches bei einem Ausfall direkt alles lahm legt. Es besteht aus einem Netzwerk vieler kleiner Systeme, welche unabhängig voneinander funktionieren. Fällt eines aus, sind die User dieses Systems nicht mehr zu erreichen. Alle anderen sind davon nicht betroffen.

Klingt doch schon mal toll, oder? Warum nun also ein eigener Jabber Server?

Nun ja, natürlich um herauszufinden wie es funktioniert und ob ich es hin bekomme. Dann ist man unabhängiger von anderen Systemen und kann seine eigenen Regeln aufstellen. Alles lässt sich so konfigurieren und einrichten, wie man es selbst gerne hätte. Man kann selbst bestimme, welche Module in welcher Form nutzbar sein sollen….

Ich habe dann etwas mit verschiedenen Servern auf meinem Testsystem herumprobiert. Getestet habe ich jabberd, ejabberd und openfire. Hängen geblieben bin ich am Ende bei Openfire in Kombination mit dem Kraken IM Gateway Plugin. Dieser Server ist nur für mich, die Familien und einige enge Freunde geplant. Würde es ein großer öffentlicher Server werden sollen, hätte ich mich sicher für einen anderen Server entschieden! Für meinen Plan bringt dieser aber alles mit was ich brauche und dieses schnell und einfach! Zusätzlich spricht mein PSI mit dem Server auch über IPv6! IPv6 Kompatibilität ist für mich inzwischen recht wichtig und es war an einigen Stellen schon: „Das Zünglein an der Waage“.

Unter Debian war die Installation schnell durch. Ich musste für das Plugin etwas suchen, das lag aber eher an meiner situativen Unfähigkeit 😀 Das Plugin ermöglicht die Verbindung in andere IM Netzte, wie ICQ, MSN, AIM, Facebook usw. usw… Denn dieses Plugin stellt die so genannten Transporter!

Thema Policy

In den AIM Terms of Service findet sich beispielsweise folgende Stelle:

You or the owner of the Content retain ownership of all right, title and interest in Content that you post to public areas of any AIM Product. However, by submitting or posting Content to public areas of AIM Products (for example, posting a message on a message board or submitting your picture for the „Rate-A-Buddy“ feature), you grant AOL, its parent, affiliates, subsidiaries, assigns, agents and licensees the irrevocable, perpetual, worldwide right to reproduce, display, perform, distribute, adapt and promote this Content in any medium. Once you submit or post Content to any public area on an AIM Product, AOL does not need to give you any further right to inspect or approve uses of such Content or to compensate you for any such uses. AOL owns all right, title and interest in any compilation, collective work or other derivative work created by AOL using or incorporating Content posted to public areas of AIM Products.

Bei der Accepable Use Policy schaut es meiner Meinung nach nicht besser aus:

You agree that by posting any material or information anywhere on the ICQ Services and Information you surrender your copyright and any other proprietary right in the posted material or information. You further agree that ICQ LLC. is entitled to use at its own discretion any of the posted material or information in any manner it deems fit, including, but not limited to, publishing the material or distributing it.

Bei Microsoft findet man ähnliches…..

Ist doch eine Super Sache, oder?

Aber kann man es ihnen wirklich vorhalten? Die Jungs stellen „kostenlos“ Serversysteme, Infrastruktur, Manpower usw usw…. Glaubt man denn wirklich das diese Dienstleister das aus reiner Nächstenliebe machen? Einen gewissen Plan werden die schon verfolgen und die müssen auch Geld mit ihrem Produkt verdienen. Wenn die jetzt schon in ihren Policys schreiben, dass man als Nutzer die Rechte an allem abgibt was man in irgendeiner Weise in deren Service wirft. Dann…. Na dann werden die doch GAAANNNNZZZ sicher nichts blödes mit diesen Daten anstellen, oder?


Um kurz zu zeigen wie anpassungsfähig jabber ist, habe ich hier noch ein paar Bilder.

Zuhause nutze ich das Siemens Gigaset C470IP. So kann ich schnell und einfach die Sipgate- und SIP-Accounts erreichbar machen. Dieses sogar so, dass jeder ohne Vorkenntnisse damit einfach telefonieren kann! Zusätzlich habe ich einen Jabber-Account auf meinem Server für ein Gigaset C47H erstellt.

Das Telefon hat also einen Messenger, welcher sich mit meinem Jabber-Server verbindet und darüber Nachrichten empfangen und verschicken kann.

Gigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem MessangerGigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem Messanger neue NachrichtGigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem Messanger neue Nachricht
Der Jabber Messenger des Gigaset C47H
ist online und mit dem Jabber-Server
verbunden.
Am Gigaset C47H ist eine neue Jabber
Message angekomen!
Die Jabber Nachricht wird am Mobilteil
gelesen. Nun könnte man auch
antworten.

Auch wenn mich einige für verrückt erklären werden, ich finde es total geil 😀

Zusammen mit den Transportern könnte ich das Telefon auch für MSN / Facebook / ICQ  usw. usw.. erreichbar machen. Na ja, wenn ich wollte 😛


*Update 19.05.2012*

Vergesst bei eurem Jabber-Server nicht die DNS SVR RECORDS 🙂

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑