Schlagwort-Archive: Versionskontrolle

Linux-Server-Konfiguration versionieren mit etckeeper und git

Einleitung

Arbeitet man an Konfigurationseinstellungen eines Linux-Servers, kann es hilfreich sein, die geänderte Konfiguration zu versionieren. Im Fehlerfall können so Änderungen schnell und einfach zurückgenommen werden. Im weitaus günstigeren Erfolgsfall entsteht durch die Versionierung eine lückenlose Dokumentation der Änderungen.

Pakete

Die erforderlichen Pakete installieren:

apt-get install git-core etckeeper

Weiter mit der Einrichtung…

Konfiguration

In /etc/etckeeper/etckeeper.conf wird git als Versionsveraltung ausgewählt.

# The VCS to use.
#VCS="hg"
VCS="git"
#VCS="bzr"
#VCS="darcs"

In der gleichen Daten können die Paketmanager ausgewählt werden, hier die entsprechende Konfiguration für Debian-basierte Systeme:

# The high-level package manager that's being used.
# (apt, pacman-g2, yum etc)
HIGHLEVEL_PACKAGE_MANAGER=apt

# The low-level package manager that's being used.
# (dpkg, rpm, pacman-g2, etc)
LOWLEVEL_PACKAGE_MANAGER=dpkg

Git-Benutzer konfigurieren:

git config --global user.name "Tom Tester"
git config --global user.email "ttester@krausix.de"
git config --global core.editor "vim"

## zum Überprüfen
git config --global -l

Die Initialisierung wird mit der Paketinstallation automatisch durchgeführt, somit besteht also sofort Betriebsbereitschaft.  🙂

Bedienung

Nachfolgend noch einige Hinweise und Beispiele zur Nutzung. Hierbei befinden wir uns im Verzeichnis /etc.

Änderungen durchführen

Ändern wir /etc/apache2/httpd.conf und dokumentieren die Änderung:

## Änderungen vornehmen

vi /etc/apache2/httpd.conf

## Änderungen anzeigen

git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   apache2/httpd.conf
#
no changes added to commit (use "git add" and/or "git commit -a")

## Commit der Änderungen

git commit -a -m "changed httpd.conf"
[master b88e415] changed httpd.conf
 1 files changed, 1 insertions(+), 0 deletions(-)

## Änderungen prüfen

git log
commit b88e4152cf00cada1ced69bd5cfc7f3e4070f3be
Author: Tom Tester <ttester@krausix.de>
Date:   Wed Mar 4 03:18:20 2015 +0100

    changed httpd.conf

Was aber, wenn die Änderung nicht zum gewünschten Erfolg geführt hat?

Änderungen rückgängig machen

Ändern wir irgendetwas in der Apache-Konfigurationsdatei /etc/apache2/httpd.conf und machen die Änderung sofort wieder rückgängig:

## Änderungen vornehmen

vi /etc/apache2/httpd.conf

## Änderungen anzeigen

git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   apache2/httpd.conf
#
no changes added to commit (use "git add" and/or "git commit -a")

## Änderungen zurücknehmen

git checkout apache2/httpd.conf

## Prüfen

git status
# On branch master
nothing to commit (working directory clean)

Hierbei ist nicht mehr zu erkennen, dass die Datei geändert und wiederhergestellt wurde.

Bereits durchgeführte Änderungen rückgängig machen

Wurden die Änderungen bereits mittels commit durchgeführt, ist die Vorgehensweise eine andere:

git revert HEAD

Finished one revert.
[master 5b0cf27] Revert "changed httpd.conf"
 1 files changed, 0 insertions(+), 1 deletions(-)

Hierbei wird automatisch ein commit abgesetzt. Mittels git show kann die Änderung angezeigt werden:

git show

commit 5b0cf27caf82965dbad90fefd299bda1c0ff7b56
Author: Tom Tester <ttester@krausix.de>
Date:   Wed Mar 4 03:27:41 2015 +0100

    Revert "changed httpd.conf"
    
    This reverts commit b88e4152cf00cada1ced69bd5cfc7f3e4070f3be.

diff --git a/apache2/httpd.conf b/apache2/httpd.conf
index 54515a8..be91ec3 100644
--- a/apache2/httpd.conf
+++ b/apache2/httpd.conf
@@ -18,4 +18,3 @@
 #      "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
 #</VirtualHost>
 
-#

Zum Schluss noch die Möglichkeit, Dateien gänzlich von der Versionierung auszuschließen.

Dateien von Versionierung ausschließen

Um Dateien von der Versionierung auszuschließen, müssen sie in .gitignore aufgeführt werden:

[...]

# end section managed by etckeeper

ZU_IGNORIERENDE_DATEI

Da die zukünftig zu ignorierende Datei bereits während der Initialisierung bestanden hat, muss sie noch entfernt werden.

git rm --cached ZU_IGNORIERENDE_DATEI
git add .gitignore
git status
git commit -a -m "removed ZU_IGNORIERENDE_DATEI"

Have fun!

Subversion und WebSVN – Debian 6

Erforderliche Pakete

Zunächst wird Subversion, WebSVN und das zugehörige Apache Modul libapache2-svn installiert.

apt-get install subversion libapache2-svn websvn

Bei der Frage, ob WebSVN konfiguriert wird, bestätigen wir, ebenso die automatische Apache-Konfiguration. Als Pfadangaben wird /var/lib/svn jeweils üernommen.

Repository

Erst wird ein entsprechendes Verzeichnis erstellt.

mkdir /var/lib/svn

Darin wird dann ein leeres Subversion-Repository erzeugt.

svnadmin create /var/lib/svn/<repository1>

Im Anschluss werden die Dateiberechtigungen gesetzt, damit Apache auf das Repository zugreifen kann.

chown -R www-data /var/lib/svn

Die Datei /var/lib/svn/<repository1>/conf/svnserve.conf wird bearbeitet, hierbei werden die Kommentarzeichen bei folgenden drei Zeilen entfert:

anon-access = none
auth-access = write
password-db = passwd

In der Datei /var/lib/svn/<repository1>/conf/passwd werden die Benutzer hinterleget.

<benutzer1> = <passwort>
<benutzer2> = <passwort>

WebSVN

Benutzer und Passwort…

htpasswd -cm /etc/apache2/dav_svn.passwd <benutzername>

Benutzer dürfen lesen und schreiben, jeder andere kann lesend zugreifen. Die Datei /etc/apache2/dav_svn.authz wie folgt erstellen:

[/]
* = r
<benutzer> = rw
<benutzer> = rw

Die Konfiguration des Apache-Moduls wird unter /etc/apache2/mods-available/dav_svn.conf angepasst.

<Location /svn>

  # Uncomment this to enable the repository
  DAV svn

  # Set this to the path to your repository
  SVNPath /var/lib/svn
  # Alternatively, use SVNParentPath if you have multiple repositories under
  # under a single directory (/var/lib/svn/repo1, /var/lib/svn/repo2, ...).
  # You need either SVNPath and SVNParentPath, but not both.
  #SVNParentPath /var/lib/svn

  # Access control is done at 3 levels: (1) Apache authentication, via
  # any of several methods.  A "Basic Auth" section is commented out
  # below.  (2) Apache <Limit> and <LimitExcept>, also commented out
  # below.  (3) mod_authz_svn is a svn-specific authorization module
  # which offers fine-grained read/write access control for paths
  # within a repository.  (The first two layers are coarse-grained; you
  # can only enable/disable access to an entire repository.)  Note that
  # mod_authz_svn is noticeably slower than the other two layers, so if
  # you don't need the fine-grained control, don't configure it.

  # Basic Authentication is repository-wide.  It is not secure unless
  # you are using https.  See the 'htpasswd' command to create and
  # manage the password file - and the documentation for the
  # 'auth_basic' and 'authn_file' modules, which you will need for this
  # (enable them with 'a2enmod').
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd

  # To enable authorization via mod_authz_svn
  AuthzSVNAccessFile /etc/apache2/dav_svn.authz

  # The following three lines allow anonymous read, but make
  # committers authenticate themselves.  It requires the 'authz_user'
  # module (enable it with 'a2enmod').
  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
  </LimitExcept>

</Location>

Los gehts…

Subversion starten und die Apachekonfiguration neu laden.

svnserve -d -r /var/lib/svn
/etc/init.d/apache2 force-reload

Der Zugriff auf WebSVN erfolgt über http://url-oder-ip-des-svn-servers/websvn.

Soll Subversion nach einem Reboot nicht von Hand gestartet werden, kann folgender Cronjob helfen:

@reboot svnserve -d -r /var/lib/svn

Zentrales Git Repository

Vorwort

Git ist ein Versionskontrollsystem, welches ursprünglich für die Entwicklung am Linux-Kernel entstanden ist, dieser Artikel beschreibt, wie ein zentrales Git Repository unter Debian (hier Debian 6) aufgesetzt werden kann. Hierbei soll jedem Benutzer eine lokale Kopie des Repository zur Entwicklung zur Verfügung stehen. Die Änderungen können schließlich in das Hauptrepository einfließen. Mit Gitosis können Git-Repositories einfach und sicher verwaltet werden. Gitosis nutzt SSH zur Authentifizierung, es trennt die Benutzer von bestehenden Linux-User-Accounts.

Installation von Git

Für die Installation wird das Paket git-core genutzt und die zugehörigen Abhängigkeiten installiert.

 apt-get install git-core

Die Konfiguration erfolgt weiter unten.

Installation Gitosis

Auch hier wird das Paket gitosis samt den zugehörigen Abhängigkeiten installiert.

apt-get install gitosis

Konfiguration Gitosis

Schlüsselverzeichnis erstellen (Server)

Gitosis nutzt zur Authentifizierung SSH mit dem RSA Public-Private Key Mechanismus. Auf dem Server wird zunächst ein Verzeichnis erstellt, in welches später die öffentlichen Schlüssel der Clients abgelegt werden.

mkdir -p /etc/gitosis/sshkeys
chown -R gitosis:gitosis /etc/gitosis/sshkeys/

Schlüssel erstellen (Clients)

Auf den Clients, welche administrativen Zugang erhalten, werden die Schlüsselpaare erstellt. Die folgenden Abfragen nach Speicherort und Passphrase können ohne Eingabe quittiert werden.

ssh-keygen -t rsa

Standardmäßig werden die Informationen unterhalb des Home-Verzeichnisses im Verzeichnis .ssh abgelegt.

Kopieren des öffentlichen Schlüssels (Client) auf den Server

Der öffentliche Schlüssel id_rsa.pub wird in das vormals erstellte Verzeichnis kopiert.

scp ~/.ssh/id_rsa.pub root@<git-server>:/etc/gitosis/sshkeys/<username>

Hierbei wird <git-server> durch IP-Adresse oder Rechnername des zentralen Repository-Servers ersetzt, <username> wird mit dem Benutzernamen der administrativen Benutzer gefüllt. Die Benutzer- und Gruppenberechtigungen auf dem Repository-Server werden anschließend gesetzt.

chown -R gitosis:gitosis /etc/gitosis/sshkeys/

Git-Repository erstellen (Server)

Die Initialisierung des Repositories erfolgt unter dem Benutzer gitosis.

su gitosis
gitosis-init < /etc/gitosis/sshkeys/<username>

Repository auschecken (Client)

Auf dem Client wird das Git-Repository samt Einstellungen ausgecheckt.

git clone gitosis@<git-server>:gitosis-admin.git

Entwicklungs-Repository erstellen (Client)

Nachdem das Admin-Repository ausgecheckt wurde, können Änderungen durchgeführt werden. Ein Entwicklungs-Repository develrepository wird erstellt.

[group develrepository]
writable = develrepository
members = <username>@<git-client>

Die Änderungen an der Konfiguration werden hochgestellt:

git commit -a -m "Testrepository namens develrepository erstellt"
git push

Das Verzeichnis des Repositorys wird auf dem Client vorbereitet:

mkdir develrepository
cd develrepository
git init

Das Verzeichnis wird mit Inhalt (testdatei) gefüllt. Anschließend wird hochgestellt:

touch testdatei
echo "Inhalt" > testdatei
git add .
git remote add origin gitosis@<git-server>:develrepository
git commit -a -m "Initialer commit"
git push --all

Weiteren administrativen Benutzer erstellen

Auf dem Client wird die Datei ~/gitosis-admin/gitosis.conf erweitert um den neuen Benutzer.

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = <username>@<client> <other-username>@<other-client>

[...]

Diese Änderung wird dann committed und hochgestellt.

git commit -a -m "Benutzer <other-username>@<other-client> zur Gruppe gitosis-admin hinzugefügt."
git push

Zur Erstellung eines weiteren administrativen Benutzers, wird auf dem neuen Client wie zuvor beschrieben ein weiteres Schlüsselpaar erstellt. Es wird anschließend auf den bestehenden Client kopiert.

ssh-keygen -t rsa

scp ~/.ssh/id_rsa.pub <client>:/tmp/<other-username>@<other-client>.pub

Auf dem bestehenden Client wird der vormals kopierte öffentliche Schlüssel ins Schlüsselverzeichnis übernommen. Die Änderungen werden committed und übertragen:

cp /tmp/<other-username>@<other-client>.pub keydir/

git add keydir/<other-username>@<other-client>.pub

git commit -m "Schlüssel <other-username>@<other-client>.pub hinzugefügt."

git push

Installation Gitweb (Server)

Gitweb wird aus den Paketquellen samt Abhängigkeiten installiert.

apt-get install gitweb

Konfiguration Gitweb (Server)

Konfigurationsdatei anpassen

Die Konfigurationsdatei /etc/gitweb.conf wird angepasst. Hier wird das Verzeichnis $projectroot auf „/srv/gitosis/repositories“ gesetzt:

# path to git projects (<project>.git)
$projectroot = "/srv/gitosis/repositories";

# directory to use for temp files
$git_temp = "/tmp";

# target of the home link on top of all pages
#$home_link = $my_uri || "/";

# html text to include at home page
$home_text = "indextext.html";

# file with project list; by default, simply scan the projectroot dir.
$projects_list = $projectroot;

# stylesheet to use
$stylesheet = "gitweb.css";

# javascript code for gitweb
$javascript = "gitweb.js";

# logo to use
$logo = "git-logo.png";

# the 'favicon'
$favicon = "git-favicon.png";

Apache-Konfiguration anpassen

Eine neue Seitenkonfiguration /etc/apache2/sites-available/gitweb wird erstellt:

<VirtualHost *>
  ServerName git
  ServerAdmin webmaster@example.com
  DocumentRoot /srv/gitosis/repositories
  SetEnv GITWEB_CONFIG /etc/gitweb.conf
  Alias /gitweb.css /usr/share/gitweb/gitweb.css
  Alias /git-logo.png /usr/share/gitweb/git-logo.png
  Alias /git-favicon.png /usr/share/gitweb/git-favicon.png
  ScriptAlias /gitweb.cgi /usr/lib/cgi-bin/gitweb.cgi
  DirectoryIndex gitweb.cgi
</VirtualHost>

Apache muss auf das Repository-Verzeichnis zugreifen können. Anschließend aktivieren und den Webserver neu laden, danach sind die Repositories unter http://<git-server>/gitweb zu erreichen.

usermod -g www-data gitosis
a2ensite gitweb
/etc/init.d/apache2 reload

Apache absichern

Im produktiven Einsatz muss der Zugriff unbedingt abgesichert werden.