Bits, Bytes and my 5 cents

Vorgestern und heute konnte ich mein erstes rpm-Paket erstellen. Da ich so was noch nie gemacht hatte, war es für mich eine gewisse Herausforderung.
Das Ergebnis sollte ein RPM-Paket sein, welches beim Installieren eine Ordnerstruktur anlegt, Files kopiert und danach ein Script ausführt. Beim Deinstallieren soll zuerst ein Script ausgeführt werden und dann die Kopierten Files wieder gelöscht werden.

Für jemand, der das schon ein paar mal gemacht hat, mag das einfach klingen, ich weiss – für mich war es aber alles andere als das

Jedoch, da ich auch schon mal für Windows paketiert habe, kann ich auch gleich einen Vergleich anstellen: Es ist viel unkomplizierter und einfacher unter Linux, wenn das SPEC-File mal steht… wenn

Doch nun zum Vorgehen!
Der Kern des Paketieren stellt das Programm rpmbuild und eine selbst erstellte SPEC-Datei dar.
Die SPEC-Datei kann man dabei wie eine Art Anleitung ansehen, wo aufgeschrieben wird, wann was getan werden soll. Anhand dieser Anleitung erstellt rpmbuild dann ein Paket.

Die allgemeine Funktionsweise habe ich mir aus dem Internet angeeignet. Besonders geholfen dabei hat mir diese Anleitung.

Das Problem aber, all diese Anleitungen basieren darauf, dass der Source aus dem Internet nachgeladen wird. Mein Paket musste aber alle Dateien lokal zur Verfügung haben.

Nun die erste Herausforderung: Wie mach ich das?
Nach viel probieren und testen hatte ich endlich eine Lösung… Unter dem Punkt %files werden die Dateien so aufgelistet, wie sie danach beim Zielsystem kopiert werden:

1
2
3
4
5
6

%files
/opt/itc/bin/soe-rootadd
/opt/itc/bin/soe-updatepubkeys
/opt/itc/prepost/install_post.sh
/opt/itc/prepost/remove_post.sh
/opt/itc/.sshsoe_id

Während dem Erstellen des Paketes mussten die Dateien aber im Ordner ~/rpmbuild/BUILDROOT/Paketname/opt/itc/../ liegen, damit es korrekt in das RPM integriert wird.

Die zweite Herausforderung war das Script: Unter %pre, wo ich auch alle Ordner erstellen liess, konnte ich das Script nicht starten, da zuerst %pre und danach erst %files abgearbeitet wird, wodurch das Script beim Starten noch gar nicht an seinem Platz ist.
Also habe ich es kurzerhand unter %install abgelegt. Doch aus welchem Grund auch immer – da wurde es nie gestartet…
Darauf habe ich ohne noch lange weiterzuprobieren, das Script unter %post abgelegt, welcher nach der Installation abgearbeitet wird.

Das die Dateien dann beim Deinstallieren wieder gelöscht werden, war ein kleines Problem. Einfach alles unter %preun eintragen und gut ist.

Mein SPEC-File sah am Schluss so aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

...
%pre
mkdir -p /opt/itc/bin/
mkdir -p /opt/itc/ssh/pubkeys/
mkdir -p /opt/itc/prepost/
 
%post
/opt/itc/bin/install_post.sh
 
%preun
/opt/itc/bin/remove_post.sh
rm -f /opt/itc/bin/soe-rootadd
rm -f /opt/itc/bin/soe-updatepubkeys
rm -f /opt/itc/bin/install_post.sh
rm -f /opt/itc/bin/remove_post.sh
rm -f /opt/itc/.sshsoe_id
 
%prep
%build
%install
%clean
rm -rf $RPM_BUILD_ROOT
 
%files
/opt/itc/bin/soe-rootadd
/opt/itc/bin/soe-updatepubkeys
/opt/itc/prepost/install_post.sh
/opt/itc/prepost/remove_post.sh
/opt/itc/.sshsoe_id

Beim erstellen des Paketes zeigt sich dann die Stärke von Linux. Auf dem 32Bit System, welches ich zur Erstellung verwendet habe, habe ich ohne Probleme mit dem Parameter –target x86_64 ein Paket für 64Bit Systeme erstellt.
Das Begeistert mich deshalb so, denn unter Windows konnte ich auf einem 32Bit-Host auch nur ein Paket für dessen Architektur machen.
Und da ich schon damit gerechnet hatte, für jede Architektur ein eigenes Hostsystem aufzusetzen, war ich umso erfreuter

Die neue Version von Ubuntu 10.04 ist nun schon eine Zeit lang veröffentlicht worden, viele werden wohl auch schon mit der neuen Version arbeiten.
Auch ich habe kurz nach der Veröffentlichung ein Upgrade gewagt, leider jedoch ohne Erfolg.
Leider hat Compiz und der Nvidia-Treiber ein Problem mit der neuen Ubuntu-Version, weshalb ich dann mein System auch neu aufsetzen musste. Und ab da funktioniert auch alles wieder

Nun ist aber schon einige Zeit vergangen und es ist mal an der Zeit um eine Bilanz zu ziehen.
Wie sieht es denn bei euch so aus?

Und interessant wäre auch noch wieso?

Noch bevor LDAP oder Kerberos sich etablieren konnten, war ein Verzeichnisdienst mit dem Namen YP für Yellow Pages und später NIS für Network Information Service in aller Munde. Es war ein Produkt entwickelt von Sun, wodurch man Logininformationen über mehrere Computer hinweg verteilen konnte.

Auch wenn NIS als älter und unsicherer gilt als LDAP, hat es für mich ein klarer Vorteil: es ändert sich nicht immer komplett!
Wer schon mal ein LDAP auf einem Ubuntu Server 8.04 und 8.10 installiert hat, kann nachvollziehen was ich meine. So und damit genug, ich will hier nicht über LDAP herziehen, sondern NIS vorstellen

Ich habe mir also mit NIS und NFS innert wenigen Minuten eine zentrale Benutzerverwaltung mit zentralem Homeverzeichnis eingerichtet. Und wie das geht, folgt hier:

Ich habe mit dem NIS Server begonnen und dazu die Pakete für NFS und NIS aus den Paketquellen installiert.

1

apt-get install nfs-kernel-server nis

Während der Installation, nachdem man einen Namen für die Domäne eingegeben hat, versucht apt automatisch den NIS Daemon zu starten, was auf Grund mangelnden Einstellungen aber nie funktionieren wird. Also zurück lehnen, und auf den Fehler warten

Nun beginnt die Konfiguration. In der Datei /etc/default/nis wird die NIS-Installation von Client zum Server umgebogen:

1
2
3
4

# Are we a NIS server and if so what kind (values: false, slave, master)?
NISSERVER=true
# Are we a NIS client?
NISCLIENT=false

Dann geben wir in der Datei /etc/exports unser Homeverzeichnis frei:

1

/home	*(rw,async,no_subtree_check)

Wer es gern sicherer hat, kann den Stern durch einen Computernamen oder eine IP mit Subnet ersetzen, wodurch dann nur der Zugriff von diesen Maschinen aus gestattet ist.

Nun kann man den Daemon neu starten:

1

/etc/init.d/nis restart

Und zum Abschluss muss man noch die Maps generieren lassen. Dazu ruft man folgenden Befehl auf:

Weiterlesen »

Nein, Google versucht sich noch nicht als Käsehersteller!
Unter dem Codewort Jarlsberg führt die Google Code University ein Projekt zum Thema Schulung in Sicherheit für Webapplikationen.

This codelab shows how web application vulnerabilities can be exploited and how to defend against these attacks. The best way to learn things is by doing, so you’ll get a chance to do some real penetration testing, actually exploiting a real application.

Für alle die, welche dem Englisch nicht so mächtig sind: Jarlsberg ist eine Webapplikation von Google zum Thema Web Application Security. Basierend auf Python wird jedem Benutzer in einer eigenen Session eine Webseite präsentiert voll mit Sicherheitslücken von XSS über DOS bis hin zu XSRF und Path Traversal.

Neben dieser Webseite gibt es auch noch eine sehr ausführliche und gut erklärte Dokumentation zu jedem Exploit mit einer Erklärung wie man diesen auch beheben könnte (verfasst in Englisch).
Nachdem ich die Dokumentation nun mal komplett durchgearbeitet habe, muss ich sagen, es lohnt sich wirklich die 5 Seiten komplett zu lesen!
Jedoch muss ich auch sagen, in meinen Augen sind ein paar der vorgestellten Exploits ein wenig Realitätsfremd, da man z.B bei einem Pentest nur sehr wenig direkten Zugang zum Sourcecode hat.

Nichts desto trotz, wer es selbst mal ausprobieren will, und das kann ich wirklich jedem empfehlen, der klickt nun hier: