Tag Archives: HowTo

HowTo: gitolite auf Debian Wheezy

Das Netz ist natürlich voll von HowTos zum Thema gitolite, in diesem hier nutze ich aber nicht die bleeding edge Version von upstream sondern das Debian-Paket. Eine gewisse Hilfe für’s Verständnis und bei der Installation war die Dokumentation für gitolite 2.x, denn in Wheezy ist Version 2.3 verpackt.

Installation

Geht los mit Installation des Pakets gitolite. Wenn der bei der Installation dpkg nichts konfiguriert haben will, dann gibt man danach nochmal ein:

dpkg-reconfigure gitolite

Dort wird dann ein SSH public key abgefragt für den Admin-Nutzer. In meinem Fall hab ich hier für die Testinstallation auf dem selben Rechner den folgenden Pfad angegeben, ansonsten kopiert man seinen public key ins Eingabefeld:

/home/adahl/.ssh/id_rsa.pub

Damit liegt jetzt hier unterhalb von /var/lib/gitolite1 folgendes:

% ls -la /var/lib/gitolite
insgesamt 28
drwxr-xr-x  5 gitolite gitolite 4096 Jun 17 13:51 ./
drwxr-xr-x 58 root     root     4096 Jun 17 13:47 ../
drwx------  8 gitolite gitolite 4096 Jun 17 13:47 .gitolite/
-rw-r--r--  1 gitolite gitolite 4217 Jun 17 13:47 .gitolite.rc
-rw-------  1 gitolite gitolite    0 Jun 17 13:47 projects.list
drwx------  4 gitolite gitolite 4096 Jun 17 13:47 repositories/
drwx------  2 gitolite gitolite 4096 Jun 17 13:47 .ssh/

Da mein public key bereits hinterlegt ist, kann ich direkt zum nächsten Schritt übergehen und das Admin-Repo clonen, welches bei der Installation angelegt wurde:

git clone gitolite@localhost:gitolite-admin

Wie man sieht, hatte ich den dedizierten Nutzer gitolite genannt, für Produktionsumgebung ist vielleicht git eine bessere Wahl.

Ganz wichtig: beim Ändern der Config muss man stets drauf achten, dass man sich nicht selbst aussperrt. Für das Repository gitolite-admin muss man Schreibrechte für irgendeinen Key behalten, auf den man auch Zugriff hat und der unterhalb von keydir im Repo liegt, sonst hat man keine Möglichkeit mehr ohne große Schmerzen diese Rechte wiederzuerlangen.

Konfiguration

Als nächstes habe ich die Datei /var/lib/gitolite/.gitolite.rc angepasst. Berücksichtigt sind hier bereits, dass ich sowohl git-daemon als auch gitweb einsetzen und die Repos auf einen anderen Rechner spiegeln will. D.h. ich habe folgende Einträge geändert:

$REPO_UMASK = 0027;
$GL_GITCONFIG_KEYS = "gitolite.mirror.*";
$REPO_BASE="/srv/repos/git";

Der letzten Zeile ist erhöhte Beachtung zu schenken. Die bereits angelegten Repositories gitolite-admin und testing aus /var/lib/gitolite/repositories müssen nämlich in den geänderten Pfad verschoben werden.2 Damit der Zugriff über gitweb funktioniert, habe ich den Nutzer www-data der Gruppe git hinzugefügt und die Rechte des Repository-Verzeichnisses gelockert:3

sudo addgroup www-data git
sudo chmod g+rx /var/lib/gitolite/repositories

Die eigentliche Konfiguration erfolgt dann wie bei gitolite üblich über das admin-Repository nachdem man es geklont hat:

git clone gitolite@myfancyserver:gitolite-admin

Wie man das im Einzelnen macht, kann man in der Doku zu gitolite v2 nachlesen. Das ist nicht Debian-spezifisch.

gitweb mit lighttpd

Für einen schnellen Überblick mit dem Webbrowser ist das Paket gitweb installiert. Als Webserver kann vermutlich irgendein Webserver dienen. Für lighttpd habe ich eine Datei /etc/lighttpd/conf-available/80-gitweb.conf angelegt und mit den für diesen Browser üblichen Mechanismen aktiviert. Der Inhalt sieht so aus:4

# -*- depends: cgi -*-
server.modules += ("mod_setenv")
setenv.add-environment = ("GITWEB_CONFIG" => "/etc/gitweb.conf")
alias.url += ( "/gitweb" => "/usr/share/gitweb" )

$HTTP["url"] =~ "^/gitweb/" {
        server.indexfiles = ("gitweb.cgi")
        cgi.assign = ( ".cgi" => "" )
}

Es ist außerdem das Modul 10-cgi.conf zu aktivieren:

sudo lighty-enable-mod cgi
sudo lighty-enable-mod gitweb

In der /etc/gitweb.conf sind auch noch Anpassungen zu tätigen. Hier meine geänderten Zeilen:

$projectroot = "/var/lib/gitolite/repositories";
$projects_list = "/var/lib/gitolite/projects.list";
@diff_opts = ('--find_renames', '--minimal');

Urspünglich war jetzt hier noch eine Beschreibung zum Mirroring, ich verschiebe das auf später und tu es in einen separaten Artikel … O:-)

  1. auch den Pfad kann man beim dpkg-reconfigure angeben. []
  2. Dieser Schritt kann natürlich entfallen, wenn man die Repositories im Standard-Pfad belässt. []
  3. Die Rechte der bei der Installation angelegten Repositories sind allerdings immernoch so restriktiv, dass sie nicht über gitweb angezeigt werden können. Bei <code>gitolite-admin</code> will man das sowieso nicht und statt <code>testing</code> legt man sich vielleicht ein weiteres Testrepository an, um zu sehen, ob das mit den Rechten beim neu anlegen richtig klappt. []
  4. Siehe auch gitweb im ArchWiki. []

Port based VLAN mit Netgear GS108Tv2

Wir bauen im Netz39 gerade das Netzwerk ein bisschen um und wollen dabei auch mehrere logisch getrennte Netze einrichten. Die Routerhardware hat genau zwei Netzwerkkarten und kann nicht mehr bekommen, aber der Switch kann VLAN. D.h. was ich prinzipiell gern aufbauen möchte, ist etwa folgendes:

vlan

VLAN auf dem Router konfigurieren ist mit fli4l kein Problem, aber der Switch in meinem Testsetup1 hat mich grübeln lassen. So ging es dann. Erstmal die VLANs unter VLAN Configuration anlegen, hier mit den IDs 11 und 22:

netgear_vlan_1

Dann kommt sozusagen die Einrichtung des ausgehenden Verkehrs unter VLAN Membership. Hier wollen wir den Netzwerkverkehr aus den VLANs 11 und 22 beide auf dem Port zum Router haben und dort sollen die Tags drin bleiben, damit der Router das auch wieder aufdröseln kann. Deswegen wird Port 2 am Switch für beide VLANs mit T markiert, damit der Verkehr auf dem Port getaggt wird.2 Bisschen umständlich ist es, dass man jedes VLAN einzeln auswählen und dann unten noch die Liste mit den Ports aufklappen und alles einzeln bestätigen muss.3 Für den Netzwerkverkehr zu unseren dummen Geräten, die kein VLAN können oder davon nichts wissen sollen, lassen wir den Switch die Tags entfernen, markieren also die Ports 6 bis 8 mit U wie untag, was aber dennoch heißt, dass der Verkehr aus diesen VLANs über diese Ports rausgeht. Das sieht dann hier so aus:

netgear_vlan_2

… und …

netgear_vlan_3

Jetzt müssen wir uns noch um den eingehenden Verkehr kümmern, also das was ohne VLAN-Tag in den Switch gelangt. Dazu geht man auf Port PVID Configuration und kann dort dann einem Port genau ein VLAN zuordnen:

netgear_vlan_4

Ich hoffe, ich hab das alles richtig verstanden und keinen Quatscht jetzt hier erzählt. Es scheint aber zu funktionieren.

Update: Wenn man sich die PVID-Konfiguration nochmal ansieht, so wird Traffic auf den Ports 1 bis 5, der kein Tag hat, der VLAN-ID 1 zugewiesen. Da per default auf allen Ports U aka untag für die ID gesetzt ist, verlässt also ungetagter Verkehr von allen Ports den Switch auf allen Ports wieder. Was man jetzt vermutlich will: auf den Ports 6 bis 8 das U bei VLAN-ID noch rausnehmen, damit da wirklich nur Traffic des jeweiligen VLANs ankommt, und nicht noch der andere Traffic auch noch.

  1. welches leider nicht der Switch ist, der später auch Verwendung finden wird. []
  2. Das was wir hier mit Port 2 gemacht haben, also Tags von verschiedenen VLANs in den Paketen belassen, wird an einigen Stellen im Netz als VLAN-trunk bezeichnet. []
  3. Wegen so dämlichem UI gibt es solche HowTos … []

Wireshark als normaler Nutzer ausführen

Mit jedem neuen Rechner und damit jeder neuen Installation kommen jedesmal die gleichen Probleme auf einen zu. Aktuell hab ich hier im Büro eine neue Maschine mit Debian Wheezy und ich will Wireshark als normaler Nutzer ausführen. Laut /usr/share/doc/wireshark/README.Debian muss dumpcap installiert sein und richtig eingerichtet und man muss selbst der Gruppe wireshark angehören. Das genannte Tool ist Teil des Pakets wireshark-common und das lässt sich wie folgt umkonfigurieren:

sudo dpkg-reconfigure wireshark-common

Es öffnet sich ein Menü, man stellt das gewünschte ein. Nutzer zur passenden Gruppe hinzufügen mit Debian-Mitteln sieht dann so aus:

sudo addgroup adahl wireshark

Ausloggen und neu wieder einloggen, damit die Gruppenberechtigungen wirksam werden und dann tut das.

HowTo: GnuPG mit unbegrenztem Signing-Key und ablaufendem Encryption-Key

Sperrig, die Überschrift, also worum geht’s? Ich zitiere mal aus dem GnuPG-Handbuch:

Wenn Sie ein neues Schlüsselpaar erzeugen, werden standardmäßig ein DSA-Hauptschlüssel zum Unterschreiben und ein ElGamal-Unterschlüssel zum Entschlüsseln erzeugt. Dies ist von Vorteil, weil die Aufgaben der beiden Schlüssel verschieden sind und es sinnvoll sein könnte, den beiden Schlüsseln verschiedene Verfallsdaten zu geben. Der DSA-Hauptschlüssel wird benutzt, um digitale Unterschriften zu leisten, und er bestätigt Ihre Identität dadurch, daß andere ihn signiert haben. Der ElGamal-Unterschlüssel wird nur benutzt, um an Sie geschickte verschlüsselte Daten zu entschlüsseln. Typischerweise sollte eine digitale Signatur eine lange oder unbegrenzte Gültigkeitsdauer haben; Sie wollen ja auch die Unterschriften auf Ihrem Schlüssel, die Sie mühsam zusammengetragen haben, nicht verlieren. Andererseits sollte der ElGamal-Unterschlüssel in gewissen Zeitabständen gewechselt werden, um Ihre Datensicherheit zu erhöhen, da ein Angreifer, wenn der ElGamal-Unterschlüssel geknackt ist, alle Dokumente lesen kann, die für diesen Schlüssel verschlüsselt worden sind oder es noch werden.

Darauf folgt noch ein kurzer Hinweis, dass das etwas umständlich ist, aber wie genau man das anstellt, ist quasi als Hausaufgabe überlassen und deswegen1 zeige ich das jetzt hier.

Zunächst erstellt man sich einen Schlüssel ohne Ablaufdatum, der Wizard packt sonst auf beide Unterschlüssel ein Ablaufdatum und das wollen wir ja eigentlich nicht:

gpg --gen-key

Heutzutage ist das kein DSA/ElGamal-Paar, sondern beides sind RSA-Schlüssel, aber Details kann man in einem beliebigen HowTo zur Schlüsselerstellung nachlesen. In meinem Fall hab ich zu Testzwecken das hier erhalten:

pub   4096R/8C5DE4C1 2013-09-27
  Schl.-Fingerabdruck = 1EDD 0AF2 9CA3 A110 A30F  D404 3C63 79A9 8C5D E4C1
uid                  Alice (Testschlüssel) 
sub   4096R/79C6C593 2013-09-27

Als nächstes bearbeite ich diesen Schlüssel:

gpg --edit-key 0x8C5DE4C1

Hier gibt es jetzt eine Reihe von Befehlen, die man sich mit help anzeigen lassen kann. Zunächst ist list ganz hilfreich. Die Ausgabe davon:

gpg> list

pub  4096R/8C5DE4C1  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  4096R/79C6C593  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: E   
[ uneing.] (1). Alice (Testschlüssel) 

Den Unterschlüsseln ist ein »sub« vorangestellt, allerdings nicht nummeriert. Man wählt nun den Encryption-Key aus mit key 1 oder wenn man bereits mehrere Unterschlüssel hat, muss man durchzählen, die sind freundlicherweise geordnet. GnuPG markiert den soeben ausgewählten Unterschlüssel mit einem Sternchen:

gpg> key 1

pub  4096R/8C5DE4C1  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub* 4096R/79C6C593  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: E   
[ uneing.] (1). Alice (Testschlüssel) 

Der nächste Befehl ist expire. Zuvor kann man sich mit list nochmal überzeugen, dass auch nur der Unterschlüssel ausgewählt ist. GnuPG ist an der Stelle aber so freundlich bei der Nachfrage nochmal klar zu stellen, dass man nur das Ablaufdatum des Unterschlüssels ändert. Sieht dann so aus:

gpg> expire
Ändern des Verfallsdatums des Unterschlüssels.
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
        = Schlüssel verfällt nach n Tagen
      w = Schlüssel verfällt nach n Wochen
      m = Schlüssel verfällt nach n Monaten
      y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 2
Key verfällt am So 29 Sep 2013 12:47:52 CEST
Ist dies richtig? (j/N) j

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Alice (Testschlüssel) "
4096-Bit RSA Schlüssel, ID 8C5DE4C1, erzeugt 2013-09-27

                              
pub  4096R/8C5DE4C1  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub* 4096R/79C6C593  erzeugt: 2013-09-27  verfällt: 2013-09-29  Aufruf: E   
[ uneing.] (1). Alice (Testschlüssel) 

Hier sieht man jetzt, dass der Key, dem das »pub« vorangestellt ist und bei dem es sich um den Signing-Key (SC) handelt, immernoch kein Verfallsdatum hat, der Encryption-Key (E) hingegen schon.

Bis hier hin wäre das das Vorgehen, wenn man sich einen neuen Schlüssel erstellt oder bereits einen hat, der bisher kein Ablaufdatum hat. Hat man seinen Schlüssel bereits auf einen Keyserver geladen, empfehle ich nicht am Ablaufdatum rumzufummeln. Solche Änderungen kommen womöglich nie beim Gegenüber an. Dann lieber neuen Schlüssel machen.

Was nun, wenn der Encryption-Key droht abzulaufen? Man fügt mit addkey einen neuen hinzu. GnuPG fragt dann nach allerlei Details, u.a. wie lange der neue Unterschlüssel gültig sein soll. Bei der Frage, was für ein Unterschlüssel es werden soll, wählt man einen für »nur verschlüsseln« und dort sinnvollerweise die Variante RSA mit der vorgebenen oder einer größeren Schlüssellänge:

gpg> addkey
Schlüssel ist geschützt.

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Alice (Testschlüssel) "
4096-Bit RSA Schlüssel, ID 8C5DE4C1, erzeugt 2013-09-27

Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (3) DSA (nur unterschreiben/beglaubigen)
   (4) RSA (nur signieren/beglaubigen)
   (5) Elgamal (nur verschlüsseln)
   (6) RSA (nur verschlüsseln)
Ihre Auswahl? 6
RSA-Schlüssel können zwischen 1024 und 4096 Bit lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 
Die verlangte Schlüssellänge beträgt 2048 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
        = Schlüssel verfällt nach n Tagen
      w = Schlüssel verfällt nach n Wochen
      m = Schlüssel verfällt nach n Monaten
      y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 1m
Key verfällt am So 27 Okt 2013 11:57:50 CET
Ist dies richtig? (j/N) j
Wirklich erzeugen? (j/N) j
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
.............+++++
..........+++++

pub  4096R/8C5DE4C1  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub* 4096R/79C6C593  erzeugt: 2013-09-27  verfällt: 2013-09-29  Aufruf: E   
sub  2048R/C82D05DE  erzeugt: 2013-09-27  verfällt: 2013-10-27  Aufruf: E   
[ uneing.] (1). Alice (Testschlüssel) 

Hier hab ich jetzt gleichzeitig zwei gültige Encryption-Keys, aber das diente ja nur zum Zeigen und Ihr werdet den Key auch auf keinem Keyserver finden.

Mit save verlässt man den Editiermodus und dann lädt man den mit neuem Encryption-Key versehenen Schlüssel wie gewohnt auf den Keyserver hoch.

Übrigens habe ich meinem eigenen PGP-Schlüssel mit dieser Methode auch gerade einen frischen Encryption-Key spendiert. Falls sich Euer Mailprogramm beschwert, dass Ihr mir keine verschlüsselten Mails mehr schicken könnt, ladet Euch mal meinen aktuellen Public-Key! ;-)

  1. und weil ich Frank Lanitz das mal auf einer Keysigningparty bei den Chemnitzer Linux-Tagen versprochen hatte, ach und wegen der im Netz39 bevorstehenden Keysigningparty, na und natürlich, weil der Encryption-Key bei mir bald abläuft … []

HowTo: FreeBSD als HVM-DomU in Xen auf Debian Wheezy

Zu Hause und im Netz39 e.V. läuft je ein Server mit Debian Wheezy auf amd64 und als Virtualisierungssystem wird Xen benutzt. Linux-Gäste werden paravirtualisiert und das läuft schon seit Jahren fluffig. Für bestimmte Zwecke muss es aber auch mal ein anderes System sein und das ist im Hackerspace ein aktuelles FreeBSD 9.1 und zu Hause ein Debian GNU/kFreeBSD, also kein Debian GNU/Linux, sondern eben das Debian mit dem ganzen GNU Userland und einem FreeBSD-Kernel. In beiden Fällen ist auch die VM die 64-Bit-Variante und die Hardwarevirtualisierung der jeweiligen Prozessoren soll genutzt werden. Was fehlt: die initiale Config für die VM und da hab ich gesucht, recherchiert und probiert und präsentiere jetzt, was bei mir funktioniert hat. Zu Hause sieht’s so aus:

vcpus = 2
memory = 1024
name = 'kleopatra'
builder = 'hvm'
kernel = 'hvmloader'
disk =  [
                'phy:/dev/mapper/heaven-kleopatra,hda,w',
                'file:/home/alex/debian-7.1.0-kfreebsd-amd64-netinst.iso,hdc:cdrom,r',
        ]
boot = 'dc'
vif = [ 'mac=00:16:3E:XX:XX:XX,bridge=xenbr0' ]
vfb = [ 'type=vnc' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

Und im Space:

vcpus       = 1
memory      = 512
name        = 'hydrogen'
builder     = 'hvm'
kernel      = 'hvmloader'
disk        = [
            'phy:/dev/mapper/vgmarx-wasserstoff,hda,w',
            'file:/media/images/FreeBSD-9.1-RELEASE-amd64-disc1.iso,hdc:cdrom,r',
          ]   
boot        = 'dc'
vif     = [ 'mac=00:16:3E:XX:XX:XX,bridge=xenbr0' ]
vfb     = [ 'type=vnc' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

In beiden Fällen hatte ich zuvor Xen nach der Anleitung im Debian-Wiki aufgesetzt. Die XX in den Mac-Adressen sind durch zufällige Werte zwischen 00h und FFh zu ersetzen. Die Erzeugung von Zufallszahlen und die Umrechnung ins Hexadezimalsystem überlasse ich als Hausaufgabe.

Nach dem Start der DomU macht man einen SSH-Tunnel auf für den VNC-Port und verbindet sich mit seinem bevorzugten VNC-Client1 auf localhost:

ssh -L 5900:localhost:5900 yourxenhost

Nach der Installation in der Config die Bootreihenfolge anpassen bzw. das CD-Image rausnehmen, fertig.

  1. unter KDE benutze ich krdc, auch wenn ich den Namen grauslig finde []

echo echo echo

Der Netzwerkdienst echo ist laut allwissender Müllhalde im inetd implementiert. Muss man wissen. Und dann muss man noch wissen, wie der aktiviert wird, ist er per default logischerweise nicht. Unter Debian Wheezy mit dem inetd aus dem Paket openbsd-inetd fügt man an geeigneter Stelle folgende Zeile zu /etc/inetd.conf hinzu:

echo    stream  tcp     nowait  root    internal

HowTo: DSL-Router loggt zu rsyslog auf Debian Wheezy

Gestern schrieb ich, wie ich mal eben schnell Daten sammle wie oft mein Router sich neu verbindet. So ganz elegant ist das nicht, weil es quasi am Router vorbei geschieht und der Router ja selbst am besten weiß, was er tut. Das vorliegende Modell kann den Output seines syslog an einen anderen Server schicken und da wertet man dann direkt die Logs aus, nur wie macht man das, wenn der Server ein rsyslog auf einem Debian Wheezy ist?

Zunächst aktiviert man mal die Funktion, dass der syslog überhaupt Nachrichten von anderen annehmen soll. Das passiert in /etc/rsyslog.conf und es sind die Zeilen auszukommentieren, die die entsprechenden Module laden.

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

Ich hab der Einfachheit mal beide aktiviert, weil ich nicht wusste, was der Router probieren wird. Dann wollte ich, dass alle Logmeldungen des Routers in einer Datei landen und nicht zwischen die normalen Log-Dateien des Systems mit dem rsyslog geraten. Wichtig ist, dass hier rsyslog 5.8.11 arbeitet und daher die Änderungen an der Config-File-Syntax bei v6 und höher, die upstream in der Doku beschrieben sind, noch nicht gelten. Mit ein bisschen manpage, HowTo, Wiki und dergleichen lesen und etwas Rumprobieren, habe ich dann folgendes in die neu angelegte Datei /etc/rsyslog.d/remote.conf geschrieben:

$template PathWithHostName, "/var/log/remote/%HOSTNAME%.log"
:source, !isequal, "falbala"    -?PathWithHostName
& ~

Ich schmeiße quasi alles, was nicht vom loghost “falbala” kommt, auf dem der rsyslog läuft, in einen Unterordner remote und in nach dem Host getrennt, wo es herkommt. Jetzt muss ich nur noch ein paar Tage Daten sammeln und dann hab ich ein bisschen Statistik in der Hand, die hoffentlich ausreicht damit mein ISP eine sofortige Kündigung akzeptiert …

Nachtrag: Damit das Log nicht irgendwann überläuft, empfiehlt es sich auch noch logrotate anzupassen. Ich habe dazu /etc/logrotate.d/rsyslog als Beispiel für eine separate /etc/logrotate.d/rsyslog-custom genommen und das dort eingetragen:

/var/log/remote/*.log {
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript
}

Microsoft Visual C++ 6 und CMake

Warum man eine steinalte Entwicklungsumgebung mit einem modernen Build-System zusammen benutzen will, lässt sich nicht nur mit »Weil es geht!« begründen, es gibt sogar handfeste Argumente dafür, doch der Reihe nach.

Aus Gründen hab ich hier einige MFC-Projekte vorliegen, die in Visual Studio 6 entwickelt wurden, für das hier auch eine gültige Enterprise-Lizenz existiert. Bekommen habe ich Quellcode eines älteren Projekts ohne die Projektdateien. Neu zu entwickeln ist ein vergleichbares Programm und da Entwicklungsumgebung und KnowHow verfügbar sind, wird das neue Projekt eben auch in Visual Studio 6 entwickelt, die Programme laufen ja trotzdem.

Mit CMake füge ich dem Quellcode jetzt einfach die passenden Dateien mit dem Namen “CMakeList.txt” hinzu und lasse mir von CMake ein Projekt für VS6 erzeugen. Vorteil: ich brauche keine Projektdateien im Versionsverwaltungssystem ablegen, kann mir das auschecken wohin ich will und mein Quellcodebaum enthält nur das nötigste. De facto war ich so sogar in der Lage, das alte Projekt, wo mir die Projektdateien fehlten, mit CMake zu bauen und dem auf die Finger zu gucken. Soviel zum »warum«, es folgt jetzt das »wie« …

Zunächst mal sei gesagt, wenn schon Visual Studio 6, dann auch das letzte Service Pack installieren. Ist ein FAQ1 und das Service Pack gibt’s bei Microsoft.

Da ich hier eine MFC-Anwendung entwickeln will, also ein Tool mit GUI, reicht mir der reine Code nicht aus, sondern ist sind noch ressource files nötig. Bevor ich also später die Projektdateien mit CMake generieren lasse, erzeuge ich mit dem Assistenten von Visual Studio ein neues MFC-Projekt, in meinem Fall »Dialogfeldbasierend«:

MFC-Anwendungs-Assistent Dialogfeldbasierend

Den Rest des Assistenten klickt man nach eigenen Vorstellungen durch und dann kann man Visual Studio erstmal wieder schließen. Man hat jetzt einen Ordner vorliegen, in dem folgende Dateien liegen:

von VS6 erzeugte Dateien für ein neues MFC-Projekt

Davon kopieren wir jetzt den Ordner res und folgende Dateien an einen neuen Ort:

  • foo.aps
  • foo.clw
  • foo.cpp
  • foo.h
  • foo.rc
  • fooDlg.cpp
  • fooDlg.h
  • Resource.h
  • StdAfx.cpp
  • StdAfx.h

Das ist jetzt unser neuer Source-Ordner und dort wird nun eine Datei namens CMakeLists.txt angelegt. Fortgeschrittene CMake-Nutzer können das auch auf getrennte Unterordner für Programmcode, Header und externe Ressourcen aufteilen, spar ich mir hier mal und zeige nur wie das mit einer einzigen CMakeLists.txt aussehen kann:

project(foo)
cmake_minimum_required(VERSION 2.8)

find_package(MFC)

set(FOO-H
    foo.h
    fooDlg.h
    Resource.h
    StdAfx.h
)

set(FOO-RC
    foo.rc
)

set(FOO-SRC
    foo.cpp
    fooDlg.cpp
    StdAfx.cpp
)

add_definitions(-D_AFXDLL)
set(CMAKE_MFC_FLAG 2)
add_executable(${PROJECT_NAME} WIN32
    ${FOO-H}
    ${FOO-RC}
    ${FOO-SRC}
)

install(TARGETS ${PROJECT_NAME} DESTINATION ${CMAKE_INSTALL_PREFIX})

Zu set(CMAKE_MFC_FLAG 2) bitte nochmal selbständig die Doku lesen und nicht verwirren lassen, die dort gezeigten Code-Abschnitte sind aus älteren Versionen vom Installer von CMake selbst kopiert. Wie eingangs angedeutet, machen wir jetzt einen Build außerhalb des Source-Verzeichnisses und rufen dazu das CMake-GUI auf:

CMake GUI für unser Mini-Projekt

Nach einem Klick auf Configure wird man nach dem Generator gefragt. Dort wählt man Visual Studio 6 aus der Liste und bestätigt. Ein weiterer Klick auf Generate erzeugt dann die Projektdateien im zuvor eingestellten Build-Ordner, alles oben im Screenshot zu sehen. Mit einem Doppelklick auf die Datei foo.dsw öffnet sich dann Visual Studio und man kann sein Projekt bauen. Schick auch, dass es gleich ein Unterprojekt gibt, was einem die Anwendung installiert. Theoretisch gibt’s auch noch CPack, womit man sich dann noch gleich einen Installer backen kann, aber das würde jetzt hier zu weit führen. ;-)

das von CMake erzeugte VC6-Projekt

Wenn das alles soweit schön kompiliert, kann man den Source-Ordner so nehmen wie er ist und in das Versionsverwaltungssystem seiner Wahl packen. Projektdateien für Visual Studio generiert sich dann jeder Entwickler selbst mit CMake. Bisschen umständlich ist das später beim Hinzufügen von neuen Dateien ins Projekt, weil man die CMakeLists.txt parallel pflegen muss, aber das ist es meiner Meinung nach wert.

  1. Visual Studio 6 Compiler : Freezing CMake Configuration []

Deactivate Nautilus automount in KDE

Auf meinem Laptop (Samsung NC10) läuft zu meiner vollen Zufriedenheit ein Debian Squeeze mit KDE. Seit einiger Zeit wurde beim Anstecken externer Datenträger (USB-Stick, SD-Karte, …) derselbe automatisch gemountet und es wurde Nautilus geöffnet, der Dateimanager von Gnome. Dieses Verhalten hat mich ziemlich genervt, weil ich a) selbst entscheiden möchte, ob ich was mounten will oder nicht, so wie das bei KDE auch default ist und weil b) ein Dateimanager geöffnet wird, den ich eigentlich gar nicht benutze (bzw. benutzen will).

Bei der Recherche im Netz stieß ich auch folgenden Foreneintrag: newly installed KDE: don’t want Nautilus window when USB memory inserted. Die dort beschriebene Lösung funktioniert im Prinzip, nur halt wie dort bereits erwähnt, nicht genau so.

Ich habe dann das Paket gconf-editor installiert und den entsprechenden Editor gestartet. Die Keys hatten sich tatsächlich geändert, aber waren auffindbar:

Ich habe die Haken bei den Keys media_automount und media_automount_open entfernt und damit das von mir gewünschte Verhalten wieder hergestellt. :-)

IPv6 in Debian und Ubuntu deaktivieren

In Netzen, wo jemand anderes Admin ist, kann man sich nicht alles aussuchen, unter anderem nicht, wann auf IPv6 umgestellt wird. In einem speziellen Netz, bekam ich kürzlich die Bitte IPv6 bis auf weiteres zu deaktivieren. Was bei Windows XP ein Häkchen ist, erfordert unter Debian und Ubuntu je nach Version unterschiedliche Schritte. Die Informationen dazu im Netz sind vielfältig und widersprüchlich, daher hier nochmal meine Lösungen. Ob das jeweils geklappt hat, kann man mit `ifconfig` oder `ip addr show` überprüfen, auch ein `netstat -lt` sollte dann keine Dienste mehr zeigen, die auf IPv6 lauschen.

Debian 5.0 Lenny

‘ipv6’ ist hier noch ein Kernelmodul, es genügt ein Eintrag in der Datei /etc/modprobe.d/blacklist – vorausgesetzt, man verwendet den Distributionskernel 2.6.26, bei einem neueren Kernel aus den Backports sieht das ggf. schon aus wie bei Squeeze, hab ich jetzt hier nicht extra geprüft.

# ipv6
blacklist ipv6

Debian 6.0 Squeeze

IPv6 ist hier direkt in den Kernel kompiliert. Es kann über sysctl deaktiviert werden. Laut /etc/sysctl.d/README.sysctl trägt man das am besten in /etc/sysctl.d/local.conf ein. Der Eintrag lautet wie folgt:

net.ipv6.conf.all.disable_ipv6=1

Ubuntu 10.04 Lucid

Hier verhält es sich ähnlich wie bei Debian Squeeze. Allein die Datei in /etc/sysctl.d bekommt hier einen anderen Namen. Laut /etc/sysctl.d/README soll sie so heißen:

End-users can use 60-*.conf and above

Ich hab die Datei 60-disableipv6.conf genannt, der Inhalt ist ebenso:

net.ipv6.conf.all.disable_ipv6=1