Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
TEIL I: Einstieg in Linux
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
TEIL II: Grundlagen
5 Kernel
6 Grundlagen aus Anwendersicht
TEIL III: Die Shell
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
TEIL IV: System- & Netzwerkadministration
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP & Co.
20 DNS-Server
21 Secure Shell
TEIL V: Die grafische Oberfläche
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
TEIL VI: Systeminterna
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
TEIL VII: Programmierung und Sicherheit
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in Computersicherheit
33 Netzwerksicherheit überwachen
TEIL VIII: Anhang
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Buch-DVDs
F Glossar
G Literatur
Stichwort
Ihre Meinung?

Spacer
Linux von Johannes Plötner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
Rheinwerk Computing
1282 S., 5., aktualisierte Auflage 2012, geb., mit 2 DVDs
49,90 Euro, ISBN 978-3-8362-1822-1
Pfeil 30 Softwareentwicklung
Pfeil 30.1 Interpreter und Compiler
Pfeil 30.1.1 C und C++
Pfeil 30.1.2 Perl
Pfeil 30.1.3 Java
Pfeil 30.1.4 Tcl
Pfeil 30.1.5 Was es sonst noch gibt
Pfeil 30.2 Shared Libraries
Pfeil 30.2.1 Vorteile der Shared Libraries
Pfeil 30.2.2 Statisches Linken
Pfeil 30.2.3 Dateien
Pfeil 30.3 Debugging
Pfeil 30.3.1 Vorbereitung
Pfeil 30.3.2 Konsolenarbeit
Pfeil 30.3.3 DDD
Pfeil 30.4 Profiling
Pfeil 30.4.1 Compiler-Option
Pfeil 30.4.2 gprof verwenden
Pfeil 30.4.3 Profiling-Daten lesen
Pfeil 30.5 Tracing
Pfeil 30.6 Hilfe beim Finden von Bugs
Pfeil 30.6.1 ProPolice
Pfeil 30.6.2 Flawfinder und RATS
Pfeil 30.6.3 Electric Fence
Pfeil 30.7 Integrierte Entwicklungsumgebungen
Pfeil 30.8 Make
Pfeil 30.8.1 Makefile
Pfeil 30.8.2 Makros
Pfeil 30.8.3 Shellvariablen in Makefiles
Pfeil 30.8.4 Einzelne Targets übersetzen
Pfeil 30.8.5 Spezielle Targets
Pfeil 30.8.6 Tipps im Umgang mit Make
Pfeil 30.9 Die GNU Autotools
Pfeil 30.10 lex/flex und yacc/bison
Pfeil 30.10.1 flex grundlegend anwenden
Pfeil 30.10.2 bison/yacc grundlegend anwenden
Pfeil 30.11 Unix-Software veröffentlichen
Pfeil 30.12 Manpages erstellen
Pfeil 30.12.1 groff nutzen
Pfeil 30.12.2 Manpages installieren
Pfeil 30.13 Versionsmanagement
Pfeil 30.13.1 CVS
Pfeil 30.13.2 Subversion
Pfeil 30.13.3 Git
Pfeil 30.14 Wichtige Bibliotheken
Pfeil 30.14.1 Entwicklung grafischer Oberflächen
Pfeil 30.14.2 Weitere Bibliotheken
Pfeil 30.15 Zusammenfassung
Pfeil 30.16 Aufgaben

Rheinwerk Computing - Zum Seitenanfang

30.13 VersionsmanagementZur nächsten Überschrift

Seit einigen Jahren werden sogenannte Versionsmanagement-Systeme in der Softwareentwicklung immer populärer. Da gibt es beispielsweise Visual SourceSafe von Microsoft oder Subversion für Unix, Windows und Linux. Diese Systeme kümmern sich primär darum, dass mehrere Entwickler ohne weitere Probleme an einer Software – und damit auch an den gleichen Quelldateien – arbeiten können. Die Dateien werden dabei auf einem System abgelegt, auf das alle Zugriff haben. Ein Entwickler kann von solch einem System die aktuellen Quelldateien (und damit auch die Veränderungen, die von anderen an den Dateien vorgenommen wurden) auf seinen Rechner übertragen und ist gleichzeitig in der Lage, seine eigenen Änderungen an dieses System zu übermitteln.

Wir werden uns in diesem Buch auf die zwei populärsten Versionsmanagement-Systeme für Linux und Unix konzentrieren: CVS und Subversion. Der Vollständigkeit halber sei erwähnt, dass es für beide Systeme auch Skripte (CVS) bzw. Apache-Module (Subversion) für den Zugriff via Webbrowser gibt.


Rheinwerk Computing - Zum Seitenanfang

30.13.1 CVSZur nächsten ÜberschriftZur vorigen Überschrift

CVS, das Concurrent Versions System, gibt es schon seit vielen Jahren. Es ist noch immer eines der meistgenutzten Versionsmanagement-Systeme. Viele große Projekte wie das OpenBSD-Projekt verwenden CVS. Wir selbst nutzen CVS ebenfalls seit einigen Jahren für die Arbeit an unseren Büchern und an einigen gemeinsamen Projekten.

Ein Projekt anlegen

Repository

Zunächst muss man ein Projektverzeichnis erschaffen, auf das alle Entwickler zugreifen können. Dazu genügt bereits ein SSH-Server. Auf diesem legt man unter dem gemeinsamen Benutzer, in diesem Fall »swendzel«, ein Verzeichnis für das jeweilige Projekt an. Es empfiehlt sich dabei, ein globales CVS-Verzeichnis (Repository) einzurichten, in das man alle Projekte eingliedern kann. So erspart man sich später die Arbeit, die Umgebungsvariable CVSROOT für jedes Projekt zu ändern.

Listing 30.71 Das Projekt »projekt« anlegen

$ cd
$ mkdir .cvs
$ mkdir .cvs/CVSROOT
$ mkdir .cvs/projekt

CVS-Projekte werden Module genannt. Module bezeichnen Verzeichnisse im CVS-Repository, in denen die Dateien eines Projekts enthalten sind.

Entwicklungsbeginn

Auf den jeweiligen Entwickler-Workstations setzt man nun die Shellvariable CVSROOT auf den CVS-Benutzer des Projektsystems und das entsprechende Verzeichnis in der Form Benutzer@Host:/Verzeichnis. Zudem sollte man ssh verwenden, was durch CVS_RSH angegeben wird.

Listing 30.72 CVSROOT setzen

$ export CVSROOT='swendzel@192.168.0.2:/home/swendzel/.cvs'
$ export CVS_RSH="ssh"

Bevor die Entwicklung beginnen kann, muss jeder Entwickler noch den aktuellen Auszug des jeweiligen Moduls aus dem CVS-Repository laden. An dieser Stelle kommt zum ersten Mal das Tool cvs zum Einsatz. Man verwendet dessen Befehl checkout, der alle aktuellen Dateien überträgt und somit eine lokale Kopie des aktuellen Projektverzeichnisses anlegt.

Listing 30.73 Checkout von »projekt«

$ ls
$ cvs checkout projekt
cvs checkout: Updating projekt
$ ls
projekt

Dateien und Veränderungen

add und commit

Als Nächstes fügt man eine Datei zum Projekt hinzu, beispielsweise eine .c-Datei. Diese legt man zunächst lokal an und überträgt sie dann mit dem Befehl add ins Repository-Modul. Anschließend nutzt man den Befehl commit, um die lokalen Änderungen auf das CVS-System zu übertragen. Dieses Kommando verwendet man auch, wenn man etwas an einer bereits bestehenden Datei verändert hat und die Änderungen auf das CVS-System übertragen möchte. Hinter dem Parameter -m wird dabei ein Kommentar zu dieser Veränderung eingetragen.

Listing 30.74 Eine Quellcode-Datei erstellen und übertragen

$ cd projekt
$ cat << EOF >test.c
> #include <stdio.h>
>
> int main(int argc, char *argv[]) {
> printf("Hello!\n");
> return 0;
> }
> EOF
$ cvs add test.c
cvs add: scheduling file `test.c' for addition
cvs add: use `cvs commit' to add this file permanently
$ cvs commit -m 'Erste Version von test.c'
cvs commit: Examining .
RCS file: /home/swendzel/.cvs/projekt/test.c,v
done
Checking in test.c;
/home/swendzel/.cvs/projekt/test.c,v <-- test.c
initial revision: 1.1
done

delete

Soll hingegen eine Datei gelöscht werden, wird der Befehl delete verwendet. Damit keine unbeabsichtigten Löschvorgänge durchgeführt werden, erklärt sich CVS jedoch erst bereit, eine Datei zu löschen, wenn man diese auch lokal gelöscht hat. Auch hiernach müssen wieder mit commit die Änderungen an den CVS-Server geschickt werden.

Listing 30.75 delete

$ cvs delete test.c
cvs remove: file `test.c' still in working directory
cvs remove: 1 file exists; remove it first
$ rm test.c
$ cvs delete test.c
cvs remove: scheduling `test.c' for removal
cvs remove: use `cvs commit' to remove this file
permanently
$ cvs commit -m ''
cvs commit: Examining .
Removing test.c;
/home/swendzel/.cvs/projekt/test.c,v <-- test.c
new revision: delete; previous revision: 1.1
done

up

Nun arbeiten in der Regel mehrere Entwickler an einem Projekt. Damit diese ebenfalls Änderungen an den Quellcodes durchführen und eventuell neue Dateien einbringen können, sollte man sich diese Änderungen und neuen Dateien in regelmäßigen Abständen herunterladen. Dies wird mit dem Befehl up (auch update) erledigt. Man sollte dabei den Parameter -d übergeben. Dieser legt, falls notwendig, neue Verzeichnisse an.

Listing 30.76 cvs up -d

$ cvs up -d
cvs update: Updating .
P Makefile
$

log

Wichtig bei der Arbeit mit CVS ist auch, dass man sich über die Änderungen, die am Quellcode vorgenommen werden, auf dem Laufenden hält. Dafür nutzt man den Befehl log und übergibt ihm die Namen der Dateien, zu denen man die Änderungsinformationen wünscht. Dabei erscheinen übrigens die Strings, die Sie bei einem commit-Befehl hinter dem -m-Parameter übergeben.

Listing 30.77 cvs log-Makefile

$ cvs commit -m 'Suffixregel f. c.o.'
cvs commit: Examining .
Checking in Makefile;
/home/swendzel/.cvs/projekt/Makefile,v <-- Makefile
new revision: 1.3; previous revision: 1.2
done
$ cvs log Makefile

RCS file: /home/swendzel/.cvs/projekt/Makefile,v
Working file: Makefile
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3; selected revisions: 3
description:
----------------------------
revision 1.3
date: 2005/06/26 17:12:58; author: swendzel; state:
Exp; lines: +2 –0
Suffixregel f. c.o.

----------------------------
revision 1.2
date: 2005/06/26 16:57:50; author: swendzel; state:
Exp; lines: +1 –0
*** empty log message ***
----------------------------
revision 1.1
date: 2005/06/26 16:56:05; author: swendzel; state:


Exp;
*** empty log message ***
=====================================================

Falls Sie weitere Informationen zu CVS suchen, empfehlen wir Ihnen [Bud05A].


Rheinwerk Computing - Zum Seitenanfang

30.13.2 SubversionZur nächsten ÜberschriftZur vorigen Überschrift

Die Weiterentwicklung des Concurrent Versions System nennt sich Subversion. Sie bietet gegenüber CVS einige Vorteile und hat im Grunde nur einen einzigen Nachteil: Subversion benötigt mehr Speicherplatz. Dies liegt daran, dass es von jeder veränderten Datei eine Kopie sichert. Zudem nutzt Subversion ein anderes Versionsschema als CVS.

Die Vorteile bestehen nun darin, dass es zusätzliche Befehle gibt und dass Dateien und Verzeichnisse umbenannt werden können. Bei CVS musste man diese noch löschen und unter einem neuen Namen anlegen, um sie »umzubenennen«. Verbessert wurde auch die Handhabung von Binärdateien. Außerdem kann über ein Modul für den Webserver Apache 2.x auf das Repository zugegriffen werden. Für CVS gibt es allerdings CVSweb, das unter der BSD-Lizenz erhältlich ist und Ähnliches ermöglicht. [Fn. Falls Sie sich CVSweb einmal ansehen möchten, sollten Sie die Adresse www.openbsd.org/ cgi-bin/cvsweb/ besuchen.] Die Befehle stimmen mit denen von CVS ungefähr überein; daher im Folgenden nur einige Beispiele für die wichtigsten Befehle.

Eigene Veränderungen können via svn commit auf den Server übertragen werden.

Listing 30.78 svn commit

$ svn commit -m 'Buffer Overflow Fix in recv.c'

Um die aktuelle Version vom Repository auf den eigenen Rechner zu übertragen, wird – wie bei CVS – der Befehl up verwendet.

Listing 30.79 svn up

$ svn up
Revision 755.

Der Befehl log zeigt die letzten Commits des Repositorys an. Im Folgenden sehen Sie einen Auszug der letzten Veränderungen im Subversion-Repository der Hardened Linux Distribution.

Listing 30.80 svn log

$ svn log
--------------------------------------------------------------------
r755 | cdpxe | 2007-04-11 23:57:39 +0200 (Mi, 11 Apr 2007) | 1 line

remove unneded old config archives+sign files
--------------------------------------------------------------------
r754 | cdpxe | 2007-04-11 23:44:08 +0200 (Mi, 11 Apr 2007) | 1 line

aaa_hl pkg update for 1.6.6
--------------------------------------------------------------------
r753 | cdpxe | 2007-04-11 23:42:51 +0200 (Mi, 11 Apr 2007) | 1 line

current internal dev version is 1.6.6 from now on *har har*
--------------------------------------------------------------------
r752 | cdpxe | 2007-04-11 23:38:21 +0200 (Mi, 11 Apr 2007) | 1 line

update for 1.6.5 (upload after the release, not now)
--------------------------------------------------------------------
r751 | cdpxe | 2007-04-11 21:12:32 +0200 (Mi, 11 Apr 2007) | 1 line

remove slackware/l/gd because we already have the package in
universe/l/gd
--------------------------------------------------------------------
...
...

Das Umbenennen von Dateien und ganzen Verzeichnissen ist in Subversion auch kein Problem.

Listing 30.81 svn rename

$ svn rename pakete packages

Lokale Veränderungen lassen sich mit dem stat-Befehl anzeigen. Dieser Befehl ist äußerst sinnvoll, wenn man sehen möchte, was man alles modifiziert hat, und anschließend die Veränderungen in mehrere einzelne Commits aufteilen möchte.

Das Hinzufügen von Dateien zum Repository geschieht mit svn add und das Löschen mit svn remove, worauf jeweils ein svn commit folgen sollte. Lokale Änderungen können mit svn revert rückgängig gemacht werden und Metainformationen zum ausgecheckten Repository erhält man durch svn info.

Listing 30.82 svn info für das WendzelNNTPd-Repository

$ svn info
Pfad: .
URL: https://wendzelnntpd.svn.sourceforge.net/svnroot/
wendzelnntpd
Basis des Projektarchivs: https://wendzelnntpd.svn.
sourceforge.net/svnroot/wendzelnntpd
UUID des Projektarchivs:
997a3042-3631-0410-9e25-ea9ec5d3c7cf
Revision: 524
Knotentyp: Verzeichnis
Plan: normal
Letzter Autor: cdpxe
Letzte geänderte Rev: 524
Letztes Änderungsdatum: 2011-03-01 23:01:44 +0100
(Di, 01. Mär 2011)

Rheinwerk Computing - Zum Seitenanfang

30.13.3 GitZur vorigen Überschrift

Ein weiteres, recht neues und zudem verteiltes System zur Quellcodeverwaltung nennt sich Git. Es wurde ursprünglich dafür entwickelt, bei der Kernelentwicklung von Linux zum Einsatz zu kommen, ist mittlerweile aber weit verbreitet. Bei Git werden alle Repository-Informationen inklusive aller Versionsunterschiede auf jedem, in die Entwicklung involvierten, System hinterlegt und jedes System kann sowohl die Rolle eines Clients als auch eines Servers übernehmen. Wie schon für Subversion möchten wir eine Übersicht der wichtigsten Befehle für Git am Beispiel des Hosters github.org und des Projekts openccd geben:

Zunächst soll ein Repository geklont werden, damit es von github auf den lokalen Rechner übertragen werden. Die entsprechende URL lässt sich auf der jeweiligen github-Projektseite unter dem Punkt »Source« finden.

Listing 30.83 git clone

$ git clone https://cdpxe@github.com/OpenCCD/OpenCCD.git
Initialized empty Git repository in /tmp/OpenCCD/.git/
Password:
remote: Counting objects: 152, done.
remote: Compressing objects: 100 % (105/105), done.
remote: Total 152 (delta 72), reused 121 (delta 41)
Receiving objects: 100 % (152/152), 46.17 KiB, done.
Resolving deltas: 100 % (72/72), done.

Änderungen können ähnlich, wie bei den bereits bekannten Systemen CVS und Subversion durchgeführt werden, müssen aber nach einem commit noch mit git push auf den Server übertragen werden. Um Änderungen eines entfernten Repositories auf den eigenen Rechner zu übernehmen muss hingegen git pull ausgeführt werden. Das Hinzufügen von Dateien funktioniert analog mit git add, das löschen von Dateien mit git rm.

Im Folgenden soll beispielhaft eine Änderung an einem Makefile vorgenommen werden. Nach Eingabe von git commit -a öffnet sich ein Editor zur Eingabe eines Kommentars (dies erfüllt denselben Zweck wie svn commit -m 'Kommentar'). Lokale Änderungen können über git diff angezeigt werden.

Listing 30.84 Weitere git-Befehle

$ cd OpenCCD
$ vim Makefile
...
$ git commit -a
[master 3743af7] Add trainling newline
Committer: Steffen Wendzel
<swendzel@steffenmobile.(none)>
Your name and email address were configured
automatically based on your username and hostname.
Please check that they are accurate.
You can suppress this message by setting
them explicitly:

git config --global user.name "Your Name"
git config --global user.email you@example.com

If the identity used for this commit is wrong, you
can fix it with:

git commit --amend
--author='Your Name <you@example.com>'

1 files changed, 2 insertions(+), 0 deletions(-)
$ git push
Password:
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100 % (3/3), done.
Writing objects: 100 % (3/3), 308 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To https://cdpxe@github.com/OpenCCD/OpenCCD.git
72c02e4..3743af7 master -> master
$ git pull
Password:
Already up-to-date.

Die Versions-History kann wie bei Subversion mit dem log-Befehl abgefragt und zur Erhöhung der Übersichtlichkeit dabei zusätzlich die Option --color hinzugefügt werden.

Listing 30.85 git log

$ git log
commit 3743af74ad2f855191e644bdcd7ecea2134f028d
Author: Steffen Wendzel <swendzel@steffenmobile.(none)>
Date: Mon Jun 20 11:43:35 2011 +0200

Add trainling newline

commit 72c02e4f10c11dd206d1f84a490f9e9429cb6241
Author: Steffen Wendzel <swendzel@swendzel-A880GU3.(none)>
Date: Sun Jun 19 18:09:20 2011 +0200

Add some develoment hints.

commit dc4692fc51649106356b361cfceeee1bc5f7e117
Author: Steffen Wendzel <swendzel@swendzel-A880GU3.(none)>
Date: Sun Jun 19 18:05:06 2011 +0200

Add explaining comments and implement the packet walktrough in
modbar.c.


Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux Handbuch






 Linux Handbuch


Zum Katalog: Linux Server






 Linux Server


Zum Katalog: Raspberry Pi






 Raspberry Pi


Zum Katalog: Ubuntu 14.04 LTS






 Ubuntu 14.04 LTS


Zum Katalog: Roboter bauen mit Arduino






 Roboter bauen
 mit Arduino


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2012
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de