Archiv des Autors: hermann

Worauf würde ich bei einem root Server achten

Neulich habe ich mit Kollegen über Dayz gesprochen, ich glaube jeder der die Serie The Walking Dead mag wird das Spiel mögen. Im Endeffekt geht es in dem Spiel darum zu überleben. Man durchsucht Häuser oder Fabriken nach Nahrung, Wasser, Rucksäcken und Waffen. Aber neben Zombies laufen auch andere Mitspieler durch die Welt und die sind ebenfalls auf der Suche nach Nahrung und so weiter. Irgendwann kamen wir dann ins Gespräch, ob sich ein eigener Server für Dayz lohnen würde. Zwei weitere Kollegen bekamen unser Gespräch mit und hatten ebenfalls das Interesse an einem eigenen root Server bzw Sie würden sich beteiligen. Es stand im übrigen schnell fest das es kein Windows Server werden sollte. Neben Dayz wäre Webspace für einen nodejs, Tomcat oder Owncloud ebenfalls interessant.

Bei einem Kaffee haben wir dann zusammengesessen und überlegt was der benötigte root Server alles benötigen würde. Mittlerweile waren alle davon begeistert Owncloud zu nutzen, denn nach den ganzen NSA Geschichten traute manch einer seinem Anbietern für E-Mail, Kontakte und Terminen nicht mehr so recht. Da man über Owncloud auch Dateien zwischen verschiedenen Endgeräten synchronisieren kann, würde hier sicherlich genügend Speicherplatz benötigt werden. Neben dem Speicherplatz kam noch die Frage auf, ob man für https ein selbst zertifiziertes Zertifikat nutzt oder eins von einer Zertifizierungsstelle.

Hier die Punkte die zu klären waren:
– Verfügbarkeit des Servers
– Grafische Oberfläche
– Festplattenkapazität
– Performance des Systems
– Anzahl der Domains
– Anzahl der IP Adressen
– SSL Zertifikate
– Welche Betriebssysteme stehen zur Verfügung
– Vertragslaufzeit
– wird zusätzliche Festplattenkapazität für Backups angeboten oder erstellt der Anbieter Sicherungen auf die wir zurückgreifen können
– Kosten
– was passiert wenn man über das monatliche Transfervolumen überschreitet
– Erreichbarkeit des Anbieters

Bei der Recherche der einzelnen Anbieter stießen wir auf die Seite http://rootservermieten.com , dort konnten wir einige Punkte in Erfahrung bringen und einzelne Anbieter miteinander vergleichen.

Es sind mittlerweile ein paar Kaffeepausen vergangen aber einen Server haben wir bislang immer noch nicht. Mit Dayz habe ich auch noch nicht angefangen, den ich fürchte das Spiel könnte mich von der Frühjahrsgartenarbeit abhalten.

mac os mavericks langsamer Zugriff auf Sambafreigabe

Ein Kollege arbeitet seit Jahren mit Mac OS und für seine Bildablage etc nutzt er Sambafreigaben, die er auf einem Linux(Ubuntu) eingerichtet hat.

Bisher hat er die Verbindung über smb://192.168.1.10 aufgebaut und hatte an der Zugriffsgeschwindigkeit nichts auszusetzen. Seit dem Update auf Mavericks wird die Verbindung zur Sambafreigabe nur langsam aufgebaut und Inhalte der Freigabe werden meistens nicht dargestellt.

Das Problem liegt bei der Implementierung des SMB2 Protokolls bei Mavericks, es gibt hier einen Unterschied zu Linux und Windows. Wenn die Freigabe über cifs://192.168.1.10 eingebunden wird, kann die Freigabe mit der gewohnten Zugriffsgeschwindigkeit genutzt werden.

google Kalender in einer windows 8 Kachel

Einige mögen die Kacheln unter Windows 8, andere mögen sie nicht und ganz andere Fragen sich warum es keine Updates mehr für Windows XP gibt.
Über die einzelnen Kacheln können Programme gestartet werden, Newsfeeds, Wetter oder die nächsten Termine angezeigt werden.
Für Google Nutzer ist es kein Problem die Emails über Outlook abzurufen, zu bearbeiten und zu versenden. Die Termine des Google Kalenders lassen sich über einen kleinen Umweg in der vorinstallierten Kalender App darstellen.

Zunächst öffnet man im Browser seiner Wahl den Google Kalender, über das Zahnrad rechts gelangt man in die Einstellungen. In dem Reiter Kalender den gewünschten Kalender auswählen und dort über den grünen Button „ICAL“ die benötigte URL beziehen.

Jetzt auf der Seite http://calender.live.com anmelden und importieren auswählen. Im Anschluss unter den Menüpunkt abonnieren die URL des google Kalender hinterlegen, nach einem Klick auf Abonnieren startet die Synchronisierung.

Leider kann es bis zu 24 Stunden dauern, das ein Termin in der Kalender Kachel dargestellt wird.

calenderlive

brbd unter centos installieren

Angenommen man betreibt einen kleinen Server auf dem Daten abgelegt werden, diese werden zur Sicherheit auf zum Beispiel einem Raid abgelegt. Nun sollen die abgelegten Daten beim Ausfall des Server schnellstmöglich auf einem anderen System zur Verfügung stehen. Eine Möglichkeit die Daten auf den anderen Server zu kopieren wäre ein cronjob der alle x Minuten rsync ausführt. Eine weitaus bessere Lösung ist drbd.
Grob gesagt ist drbd ein Raid zwischen zwei Servern und wer mehr darüber wissen möchte, sollte sich die Seite http://www.drbd.org/ anschauen.

Zunächst muss unter centos das Repository installiert werden:
rpm -Uvh http://elrepo.org/elrepo-release-6-5.el6.elrepo.noarch.rpm
Im Anschluss die benötigten Programme installieren
yum install drbd84 kmod-drbd84

Für das drbd device habe ich auf beiden Servern(drbd1,drbd2) /dev/sdb angelegt und die Netzwerkkarten eth1 über ein Crossover Kabel miteinander verbunden.

Die Konfiguration des drbd Device erfolgt in der Datei /etc/drbd.d/data.res:

resource data {
net{
csums-alg md5;
}
disk {
resync-rate 40M;
}
on drbd1 {
device /dev/drbd1;
disk /dev/sdb;
address 192.168.1.1:7789;
meta-disk internal;
}
on drbd2 {
device /dev/drbd1;
disk /dev/sdb;
address 192.168.1.2:7789;
meta-disk internal;
}
}

Dann die drbd devices auf beiden Servern initialisieren:
drbdadm create-md data

Ausgabe:
Writing meta data...
initializing activity log
NOT initializing bitmap
New drbd meta data block successfully created.
success

Im Anschluss das drbd auf beiden Servern starten /etc/init.d/drbd start und das Device aktivieren drbdadm up data.

Über cat /proc/drbd kann man feststellen ob die beiden drbd’s miteinander verbunden sind.
cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r—–

Sollte dort anstatt Connected WFConnection stehen, konnte keine Verbindung hergestellt werden.

Zum Schluss muss auf einem der Server das drbd device als primary gesetzt werden, automatisch startet dann die Synchronisierung.

drbdadm primary --force data

Die Ausgabe von cat /proc/drbd sieht dann wie folgt aus
1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
ns:0 nr:0 dw:0 dr:70296 al:0 bm:4 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:10415772
[>....................] sync'ed: 0.8% (10168/10236)M
finish: 0:02:28 speed: 69,632 (69,632) K/sec

Während die Synchronisierung läuft, kann bereits das Dateisystem auf gewohntem Weg (mkfs.ext4 /dev/drbd1) formatiert werden.

Nach der Formatierung kann das drbd device gemountet und genutzt werden.

drbd Resource auf dem anderen Server mounten

Möchte man das drbd Device auf dem anderen Server mounten, muß man es zunächst unmounten und das drbd device von Primary auf Secondary setzen.

umount /dev/drbd1
drbdadmin secondary data

Nun kann auf dem zweiten Server das drbd Device als primary gesetzt und gemounted werden.

Anmerkung
Ich bin in dem kleinen Artikel nicht auf die Iptables eingegangen, diese müssen natürlich auch entsprechend angepasst werden.
Demnächst werde ich einen Artikel erstellen in dem es darum geht, das eine Clustersoftware das setzen des Primary drbd device und das mounten übernimmt.

[gerrit] Benutzer auf einen Branch einschränken

Im Gerrit ist es möglich, das ein Benutzer nur den Zugriff auf einen bestimmten Branch bekommt.

Für das Lese und Schreibrecht auf den Branch develop(refs/heads/develop) werden die Rechte Read, Push und Create Referenz benötigt.

Wenn der Benutzer nur das angegebene Recht hat, ist er nicht mehr in der Lage auf das gitweb zuzugreifen. Um das gitweb nutzen zu können, benötigt der Benutzer das Read Recht auf refs/*.
Hat der Benutzer jedoch das Recht, kann er auf alle Branches innerhalb des Repositorys zugreifen.