Nach Update auf XenServer-5.6.1-fp1 kein Netzwerk mehr

Heute habe ich ein Update für meinen Citrix XenServer 5.6.0 auf XenServer 5.6.1 Feature Pack 1 durchgeführt. Das Backup der Daten in den VMs versteht sich von selbst. Der Citrix XenServer läuft auf einem selbst zusammengestellen Computer (leider kein Server wie man ihn kennt ;-)). Das Mainboard ist das ASRock P43TWINS1600 und die NIC ist eine RTL 8111/8168B PCI Express Gigabit Ethernet Controller. Weiterlesen

Subversion (SVN) einrichten von A bis Z

Subversion Logo

Subversion Logo

In diesem Beitrag schreibe ich darüber, wie man Subversion (SVN) von A bis Z auf seinem Server einrichtet. Das Tutorial geht quasi von Nichts bis zum ersten externen Subversion (SVN) Checkout. Zudem wird auch Dropbox in den Beitrag miteinbezogen. Der Beitrag kann 1:1 ausprobiert werden.

Inhalt

Was ist Subversion (SVN)?
Eigener Subversion (SVN) Server vs. Dropbox
Die Umgebung
Die Konfiguration des Subversion (SVN) Servers
Erstes Repository anlegen
Die Konfiguration des externen Zugangs
Die Konfiguration des Clients
Der erste externe Checkout
Subversion (SVN) kombiniert mit Dropbox
Schlusswort
Quellen

Was ist Subversion (SVN)?

Subversion (SVN) ist ein Versionsverwaltungssystem für Dateien und Ordner. Für jede Änderung an einer Datei oder an einem Ordner gibt es eine neue Version. Ältere Versionen von Dateien und Ordner können wenn nötig wiederhergestellt werden.

Ich habe mir aus folgenden Gründen einen Subversion (SVN) Server konfiguriert

  • Daten sind über HTTPS von praktisch überall erreichbar
  • Daten müssen nicht mehr mit USB von PC zu PC kopiert werden weil sie zentral auf dem Server liegen
  • Versionsverwaltungssystem. Schluss mit „Ach, auf welchem PC liegt nun die aktuellste Version der Datei?“
  • Backup. Auf jedem Client liegt quasi ein Backup der Daten

Eigener Subversion (SVN) Server vs. Dropbox

Über die Pros und Contras gibt es sicher unterschiedliche Ansichten. Ich freue mich auf die Diskussion in den Kommentaren ;-).

Dropbox Pro

  • Benötigt keinen eigenen Server
  • Wahrscheinlich höhere Verfügbarkeit als eigener Server
  • Dateien und Ordner werden ohne weiteres Skrippten automatisch synchronisiert
  • Sehr einfache Bedienung für einen Benutzer

Dropbox Contra

  • Speicherplatz nur 2GB (bis zu 10GB gratis)
  • Daten sind extern gehostet
  • Versionen älter 30 Tage können nicht mehr wiederhergestellt werden

Eigener Subversion (SVN) Server Pro

  • Mehr Speicherplatz (hängt natürlich vom Server ab)
  • Daten sind nicht extern gehostet
  • Keine Zeitlimitierung der Versionen
  • Man kann selbst ausprobieren und konfigurieren (grösserer Lerneffekt)
  • Grösserer Funktionsumfang als Dropbox (erweiterbar)

Eigener Subversion (SVN) Server Contra

  • Ein eigener Server wird benötigt der 24h * 7d läuft
  • Ausfälle sind wahrscheinlicher
  • Ein gewisses Know How muss vorhanden sein

Zusammenfassend hat der eigene Subversion (SVN) Server mehr Ressourcen und Dropbox dafür eine höhere Verfügbarkeit, jedoch sind die Daten mit Dropbox extern gehostet. Mit Subversion (SVN) und Dropbox in Kombination kann man das Maximum erreichen.

Umgebung

Dies ist die Umgebung in diesem Beitrag. Eure Umgebung muss nicht exakt die gleiche sein. Bei Unsicherheiten fragt einfach in den Kommentaren oder schreibt mir.

Externer Zugang

  • DynDNS Adresse wie zum Beispiel root1024.dyndns.info

Router

  • pfSense
  • DNS Forwarding konfigurierbar
  • DynDNS konfigurierbar

Server

  • Aktuelles Debian
  • Apache Webserver
  • Subversion

Client

  • Windows 7
  • Tortoise SVN Client

Die Konfiguration des Subversion (SVN) Servers

Apache / Subversion installieren und für die Adresse konfigurieren
Apache / Subversion installieren

aptitude install subversion apache2 libapache2-svn

Neue Seite von der Default Seite kopieren

cp /etc/apache2/sites-available/default /etc/apache2/sites-available/root1024.dyndns.info

Verzeichnis für die neue Seite erstellen

mkdir /var/www/root1024.dyndns.info
touch /var/www/root1024.dyndns.info/index.html
chown -R www-data:www-data /var/www/root1024.dyndns.info/

In /etc/apache2/sites-available/root1024.dyndns.info werden die Werte ServerName und DocumentRoot angepasst

ServerName root1024.dyndns.info # Deine Adresse
DocumentRoot /var/www/root1024.dyndns.info/ # Pfad zum Verzeichnis der Seite

Die Seite aktivieren

a2ensite /etc/apache2/sites-available/root1024.dyndns.info

und apache neustarten

/etc/init.d/apache2 restart

Nachdem wir im DNS Server einen Eintrag von root1024.dyndns.info –> SVN Server IP eingerichtet haben, ist die Webseite jetzt über http://root1024.dyndns.info erreichbar.
Apache um SSL erweitern
Das SSl Modul von Apache aktivieren

a2enmod ssl

Neue Seite von der SSL-Default Seite kopieren

cp /etc/apache2/sites-available/default-ssl /etc/apache2/sites-available/root1024.dyndns.info-ssl

Das SSL Zertifikat erstellen

mkdir /etc/apache2/ssl
openssl req -new -x509 -days 365 -nodes -out /etc/apache2/ssl/apache.pem -keyout /etc/apache2/ssl/apache.pem
ln -sf /etc/apache2/ssl/apache.pem /etc/apache2/ssl/`/usr/bin/openssl x509 -noout -hash < /etc/apache2/ssl/apache.pem`.0
chmod 600 /etc/apache2/ssl/apache.pem

In /etc/apache2/sites-available/root1024.dyndns.info-ssl werden die Werte ServerName, DocumentRoot und SSLCertificateFile angepasst. Die Zeile SSLCertificateKeyFile wird auskommentiert oder entfernt.

ServerName root1024.dyndns.info
DocumentRoot /var/www/root1024.dyndns.info
SSLCertificateFile    /etc/apache2/ssl/apache.pem
#       SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

Ohne Kommentare sieht die Datei so aus

<IfModule mod_ssl.c>
<VirtualHost _default_:443>
        ServerAdmin webmaster@localhost
        ServerName root1024.dyndns.info
        DocumentRoot /var/www/root1024.dyndns.info/
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/root1024.dyndns.info/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog /var/log/apache2/error.log

        LogLevel warn

        CustomLog /var/log/apache2/ssl_access.log combined

        Alias /doc/ "/usr/share/doc/"
        <Directory "/usr/share/doc/">
                Options Indexes MultiViews FollowSymLinks
                AllowOverride None
                Order deny,allow
                Deny from all
                Allow from 127.0.0.0/255.0.0.0 ::1/128
        </Directory>

        SSLEngine on

        SSLCertificateFile    /etc/apache2/ssl/apache.pem

        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                SSLOptions +StdEnvVars
        </Directory>

        BrowserMatch ".*MSIE.*" \
                nokeepalive ssl-unclean-shutdown \
                downgrade-1.0 force-response-1.0
</VirtualHost>
</IfModule>

Die Seite aktivieren

a2ensite /etc/apache2/sites-available/root1024.dyndns.info-ssl

und apache neustarten

/etc/init.d/apache2 restart

Die Webseite ist jetzt unter https://root1024.dyndns.info erreichbar.

Erstes Repository anlegen

Ein neues Repository wird mit

mkdir -p /var/local/subversion/projekt
chown -R www-data:www-data /var/local/subversion/projekt
svnadmin create --fs-type fsfs /var/local/subversion/projekt

angelegt. In den Dateien /etc/apache2/sites-available/root1024.dyndns.info und /etc/apache2/sites-available/root1024.dyndns.info-ssl muss noch der Block

<Location /projekt> # Teil der URL https://root1024.dyndns.info/projekt
	DAV svn
	AuthType Basic # oder Digest
	AuthName "Projekt" # Bereichsname bei der Authentifizierung
	AuthUserFile /etc/apache2/subversion.passwd # Pfad zur Datei mit Benutzern und Passwörtern
	SVNPath /var/local/subversion/projekt # Pfad zum Repository
	Require valid-user # Nur gültige Benutzer haben Zugriff auf das Repository
</Location>

hinzugefügt werden. Der erste Benutzer für Subversion (SVN) wird mit

htpasswd -c /etc/apache2/subversion.passwd Benutzer

erstellt. Jeder weitere Benutzer mit

htpasswd /etc/apache2/subversion.passwd Benutzer

Stefan hat mich noch auf AuthType Digest hingewiesen. Mit dieser Einstellung wird bei der Authentifizierung über HTTP das Passwort nicht im Klartext, sondern verschlüsselt gesendet. So kann das Passwort nicht gesnifft werden. Die übertragenen Daten sind jedoch immer noch unverschlüsselt, weshalb man SSL (HTTPS) nutzen sollte! Mit SSL (HTTPS) werden die Authentifizierung und die übertragenen Daten verschlüsselt, somit reicht wenn über SSL (HTTPS) AuthType Basic.

Die Konfiguration des externen Zugangs

DynDNS

Um den Router aus dem Internet zu erreichen verwendet ihr entweder direkt eure öffentliche IP oder ihr richtet bei DynDNS einen Account und eine Adresse ein. Zweites ist empfohlen, wenn ihr eine dynamische öffentliche IP habt. Der Router leitet später die richtigen Anfragen an den Subversion (SVN) Server weiter.

Nachdem ihr einen Account bei DynDNS erstellt und eine Adresse (Hostname) eingerichtet habt, ist euer Router über die Adresse erreichbar. Dies kann einfach mit nslookup geprüft werden.

nslookup root1024.dyndns.info
Server:  Router
Address:  192.168.0.1

Nicht autorisierende Antwort:
Name:    root1024.dyndns.info
Address:  88.198.47.75

Falls die öffentliche IP wechselt muss der Router DynDNS die neue öffentliche IP mitteilen. Dies muss noch am Router konfiguriert werden. Bei pfSense befindet sich die Konfiguration unter „Services –> Dynamic DNS“. Auf dieser Seite den Bereich „Dynamic DNS client“ aktivieren und die Daten ausfüllen mit Adresse (Hostname) wie zum Beispiel root1024.dyndns.info, User und Passwort.

Nun könnt ihr euren Router vom Internet her über die Adresse (Hostname) immer erreichen, auch wenn die öffentliche IP wechselt.

Firewall Regel

Damit der Router alle Anfragen auf Port 443 an den Subversion (SVN) Server weitergibt, muss im Router noch eine Firewall Regel konfiguriert werden. In pfSense geschieht dies unter „Firewall –> NAT“. In pfSense kann die NAT Regel wie folgt konfiguriert werden:

Firewall Regel

Firewall Regel

DNS Forwarding

Mit einem älteren Router habe ich das Problem gehabt, dass die Anfrage an die Adresse zum Provider ging und vom Provider an meinen Subversion (SVN) Server. Die Geschwindigkeit war aus unerklärlichen Gründen kleiner als 1KB/s. Der Router hat nicht gemerkt, dass die Adresse auf eine IP im internen Netzwerk zeigt. Solltet ihr ähnliche Probleme haben, leitet die Adresse wie zum Beispiel root1024.dyndns.info an eurem DNS Server gleich an die IP des Subversion (SVN) Servers weiter.

Jetzt ist der Subversion (SVN) Server vom Internet via HTTPS (Port 443) und vom internen Netzwerk via HTTPS (Port 443) und HTTP (Port 80) über die Adresse verfügbar.

Die Konfiguration des Clients

Auf dem Windows Client muss nur ein SVN Client wie zum Beispiel TortoiseSVN (download 32 Bit | download 64 Bit) installiert werden. Die Installation von TortoiseSVN benötigt einen Neustart des Computers.

Der erste externe Checkout

Das Repository sollte von extern über einen Browser erreichbar sein. Funktioniert dies ist der erste externe Checkout mit TortoiseSVN schnell erledigt.

Checkout

Checkout

Subversion (SVN) kombiniert mit Dropbox

Die SVN Daten können in Dropbox ausgelagert werden für den Fall, dass der eigene Subversion (SVN) Server einmal nicht erreichbar sein sollte. Die Daten können einfach mit rsync oder robocopy synchronisiert werden. Die .svn Ordner können in cmd einfach mit

FOR /F "delims=" %var IN ('dir C:\Users\Benutzer\Desktop\projekt /b /s /a:H .svn') DO rmdir /S /Q %a

und unter Linux mit

find /tmp/projekt/ -name .svn -exec rm -r {} \;

gelöscht werden.

Schlusswort

Alles in Allem bin ich mit meinem privaten Subversion (SVN) Server, den ich schon seit ca. 2 Jahren nutze, sehr zufrieden. Ich hoffe der Beitrag hilft euch weiter bei der Installation und Konfiguration von einem Subversion (SVN) Server. Ich muss noch betonen, dass man mit einem eigenen Subversion (SVN) Server sehr viel mehr Möglichkeiten hat als in diesem Beitrag aufgezeigt werden.

Bei Fragen einfach einen Kommentar schreiben oder das Kontaktformular benutzen. Freue mich wie immer über Kritik und Lob.

Quellen

Ubuntuusers Subversion

Ubuntuusers Apache SSL

Systempartition (C:\) in Windows Server 2003 online vergrössern

Windows bringt standardmässig das Tool Diskpart zum verändern von Partitionen mit. Leider ist es mit Diskpart in Windows Server 2003 nicht möglich eine Systempartition online (ohne Neustart) zu vergrössern. Dafür muss man auf ein zusätzliches Tool wie zum Beispiel Expart von Dell zugreifen.

Mit Expart lassen sich die Systempartition wie auch andere Partitionen einfach online (ohne Neustart) erweitern. Expart kann gratis bei Dell heruntergeladen werden. Die Benutzung des Tools ist einfach und selbsterkärend.

Debian unrar splitted files

Heute hatte ich viele verschiedene, gesplittete RAR Files in einem Ordner, welche ich alle automatisch entpacken wollte. Klar hätte ich alles mit Winrar entpacken können, weil die Files auf einem Sambashare liegen. Jedoch hätte dies unnötig das Netzwerkbelastet und wo bleibt denn da der Spass an der Kommandozeile?

Unrar 0.0.1

Als erstes habe ich mir unrar-free von den Debianpacketquellen installiert. unrar-free liegt in den Debianpacketquellen jedoch erst in Version 0.0.1 vor und dieser Bugreport zeigt, dass das entpacken von splitted RAR Files mit unrar-free Version 0.0.1 nicht funktioniert!

Unrar 3.93

Kurzerhand habe ich mir von rarlab die aktuellste Version 3.93 von RAR heruntergeladen.

rarlinux-3.9.3.tar.gz entpacken und nach /usr/local/bin verschieben

tar -xf rarlinux-3.9.3.tar.gz
mv rar /usr/local/bin/

Splitted RAR Files können so entpackt werden

/usr/local/bin/rar/unrar x rarfile.part1.rar

Mehrere Splitted RAR Files können so entpackt werden

for f in *.part1.rar; do /usr/local/bin/rar/unrar x "$f"; done

Warum sollte man in diesem Fall immer den kompletten Pfad zu unrar angeben?
Ganz einfach, ist eine ältere Version von unrar installiert, wird unter Umständen automatisch diese ausgeführt.

user@server:~$ unrar --version
unrar 0.0.1
user@server:~$ /usr/local/bin/rar/unrar --version
UNRAR 3.93 freeware      Copyright (c) 1993-2010 Alexander Roshal

Diese Befehle sollten ebenfalls für Ubuntu funktionieren.
Viel Spass beim automatischen entpacken ;-).

Pagefile Grösse von 4095 MB überschreiten (/PAE)

Kürzlich  wollte ich auf einem Terminal Windows Server 2003 ein Pagefile hinzufügen, dass grösser als 4095 MB war. Der Server wird für Citrix verwendet. Windows hat sich aber vehement dagegen gewehrt und wollte das Pagefile grösser 4095 MB nicht anlegen.

Kurzerhand habe ich bei Microsoft die Lösung gefunden (http://support.microsoft.com/?id=237740)

Notes To create a larger page file, you must load the Physical Address Extension (PAE) kernel. In Windows Server 2003, PAE is automatically enabled when the server is using Hot Add Memory devices. Alternatively, you can force the PAE kernel by adding the /PAE switch in the Boot.ini file.

Der Parameter /PAE muss der Datei boot.ini hinzugefügt werden. Somit kann der Prozessor mehr RAM ansprechen. (PAE Physical Adress Extension)

Die Datei boot.ini kann mit Start –> Ausführen

notepad %systemdrive%\boot.ini

bearbeitet werden.

Nun kann nach einem Reboot problemlos ein Pagefile grösser als 4 GB angelegt werden.

Automatischer Download einer Datei per FTP mit einem Bash Script

Von meinem Blog (und allgemein von allen meiner Webseiten) wird regelmässig ein Backup beim Hoster erstellt. Das Backup lade ich zeitgesteuert mit einem Bash Script herunter.

Damit sich der Benutzer, welcher das Script dann ausführt, einfach am FTP Server anmelden kann, wird die Datei ~/.netrc angelegt

# FTP Verbindungsdaten
machine ftp.hoster.ch
login strenggeheim
password strenggeheim

Die Datei muss die Rechte 600 haben!

Das Script sieht dann so aus

#!/bin/bash

# Laedt das Backup von root1024 herunter

REMOTE=/backup.tar.gz
LOCAL=/tmp/"`date +%F`".tar.gz

ftp ftp.hoster.ch << DONE
get $REMOTE $LOCAL
DONE

Das << DONE bedeutet, dass jetzt mehrere Zeilen Eingabe kommen. Es wird alles ausgeführt bis zur Zeile DONE.

Das wars schon. Richtet euch doch auch ein automatisches Backup von euren Webseiten ein. Der Initialaufwand ist klein und man ist später froh, wenn man ein Backup erstellt hat.

Zeit auf Debianservern synchronisieren mit NTP (Network Time Protocol)

Vor Kurzem habe ich bemerkt, dass die virtuellen Debianserver auf dem Citrix XenServer in der Zeit ein Abweichung von +/- 2 Minuten haben. Da ich jetzt dann Backups zeitgesteuert per Cron erledigen will, sollten die Server alle die gleiche Zeit haben. Dies geht sehr einfach mit dem Network Time Protocol (NTP). Mit NTP lassen sich Uhren von Computern und Servern über das Internet mit einem Zeitserver synchronisieren. Verfügbare Zeitserver gibt es rechts auf der Hauptseite des Projekts pool.ntp.org. Man sollte wenn möglich immer die Zeitserver nehmen, welche am nächsten zu einem stehen.

Einfach ntp installieren

aptitude install ntp

Die Konfigurationsdatei von ntp ist /etc/ntp.conf und sieht nach der Installation von ntp so aus

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool:
server 0.debian.pool.ntp.org iburst dynamic
server 1.debian.pool.ntp.org iburst dynamic
server 2.debian.pool.ntp.org iburst dynamic
server 3.debian.pool.ntp.org iburst dynamic

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust

# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

Ich musste nichts mehr weiter konfigurieren, date zeigt jetzt auf die Sekunde genau die Zeit der Atomuhr an. Trotzdem stelle ich die Zeitserver noch auf diese in der Schweiz um

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool:
server 0.ch.pool.ntp.org iburst dynamic
server 1.ch.pool.ntp.org iburst dynamic
server 2.ch.pool.ntp.org iburst dynamic
server 3.ch.pool.ntp.org iburst dynamic

Der Dienst kann gesteuert werden mit

/etc/init.d/ntp {start|stop|restart|try-restart|force-reload|status}

Der Server muss nicht nur als Client fungieren, er könnte auch als ein NTP Server konfiguriert werden.

This client is too old to work with working copy ‚.‘.

Heute wollte ich auf einem Debian Lenny Daten in ein SVN Repository einchecken. Da kam mir eine Fehlermeldung entgegen:

# svn commit .
svn: This client is too old to work with working copy '.'.  You need to get a newer Subversion client, or to downgrade this working copy.
See http://subversion.tigris.org/faq.html#working-copy-format-change
for details.

Die Version des SVN Clients auf Debian ist tiefer als die Version des Repositories. SVN Client auf Debian: 1.5.1. SVN Client auf Windows: 1.6.12. Jeder SVN Client muss mindestens die Version 1.6.12 haben, um mit dem SVN Repository arbeiten zu können. Für Debian war aber über aptitude update kein Update verfügbar. Den SVN Client gibt es im Moment im regulären Repository von Debian nur in Version 1.5.1. Package.

Einen aktuelleren SVN Client in Version 1.6.12 stellt Debian Backports zur Verfügung. Package. Debian ist sehr stabil, dafür sind nicht alle Programme up to date. Genau da setzt Debian Backports an. Es stellt die Programme in einer aktuelleren Version als Repository zur Verfügung.

So wird der aktuellere SVN Client Version 1.6.12 von Debian Backports installiert:
Der Datei /etc/apt/sources.list die Zeile

deb http://backports.debian.org/debian-backports lenny-backports main

hinzufügen. Den Befehl

aptitude update

ausführen. Subversion von Debian Backports installieren

aptitude -t lenny-backports install subversion

Jetzt ist Subversion auf der aktuellen Version und man kann mit dem SVN Repository wieder arbeiten :D.

In der FAQ von Subversion habe ich noch einen Beitrag gefunden, wie man die Version eines SVN Repositories downgraden kann: http://subversion.apache.org/faq.html#working-copy-format-change