Es war einmal ein kleines, süßes Mädchen, das immer ein Käppchen aus rotem Samt trug. Aufgrund dieses Attributes erhielt es ein Assign unter dem symbolischen Namen Rotkäppchen.

Eines Tages sprach die Mutter: Rotkäppchen, die Gesundheit deiner Großmutter hat einen Interupt bekommen. Wir müssen ein Pflegeprogramm entwickeln und zur Großmutter bringen, um das Problem zu lösen. Verirre dich jedoch nicht im Wald der alten Sprachen, sondern gehe nur strukturierte Wege. Nutze dabei immer eine Hochsprache der vierten Generation, dann geht es der Großmutter schnell wieder gut. Und achte darauf, dass dein Pflegeprogramm transaktioniert wird, damit es die Großmutter nicht noch mehr belastet.

Da der Weg zur Großmutter renetrant war, traf Rotkäppchen den Wolf. Er tat sehr benutzerfreundlich, hatte im Backround jedoch schon einen Abbruch programmiert. Während Rotkäppchen einen Go To ins Blumenfeld machte, ging der Wolf im Direktzugriff zur Großmutter und vereinnahmte Sie unverzüglich durch einen Delete. Ohne zu zögern gab er sich den Anschein kompatibel zu sein und nahm die logische Sicht der Großmutter an. Dann legte er sich in Ihren Speicherplatz.

Kurz danach lokalisierte auch Rotkäppchen die Adresse der Großmutter und trat in den Speicherraum.

Vor der Installation des Pflegeprogramms machte Rotkäppchen sicherheitshalber einen Verify und fragte:

Ei Großmutter, warum hast Du so große Augen?

Weil ich zufriedene Endbenutzer gesehen habe.

Ei, Großmutter warum hast Du so große Ohren?

Damit ich die Wünsche der User besser verstehen kann.

Ei, Großmutter warum hast du so ein entsetzlich großes Maul?

Damit ich dich besser Canceln kann!

Sprachs und nahm das arme Ding als Input. Nach ein Logoff begab sich der Wolf zur Ruhe, schlief ein und begann laut zu schnarchen.

Als der Jäger auf seinem Loop durch den Wald am Haus der Großmutter vorbeikam, sah er durch sein Window den Wolf im Bett liegen.

Finde ich dich hier du alter Sünder, sprach er, ich habe dich lange gesucht! Als Kenner der Szene analysierte er sofort, dass nach den Regeln der Booleschen Algebra die Großmutter nur im Bauch des Wolfes sein konnte. Er nahm sein Messer, teilte den Bauch des Wolfes in mehrere Sektoren und machte, welch Freude, die Großmutter und das Rotkäppchen wieder zu selbstständigen Modulen.

Als Input für den Bauch des Wolfes nahmen sie viele Kilobyte Steine und beendeten die Operation mit einem Close. Als der Wolf erwachte, verursachte ihm sein dermaßen aufgeblähter Hauptspeicher solche Schmerzen, dass er an einer Storage Violation jämmerlich zugrunde ging.

Da waren alle vergnügt.

Das Pflegeprogramm aktivierte die Großmutter. Rotkäppchen aber dachte: Du willst den Lebtag nie wieder einen Go To machen, sondern nur noch strukturierte Wege gehen, wie dirs die Mutter geboten hat.

Fortsetzung zu alea iacta est – Teil 1 und alea iacta est – Teil 2

So nun geht es in die dritte Runde!
Mein Bot ist fertig und hat bereits die ersten Testläufe absolviert. Begonnen habe ich auf dem offiziellen Server, doch dummerweise ist dieser mehr als nur langsam. So kann es da problemlos mal vorkommen, dass man 15 Minuten auf ein neues Spiel wartet.
Doch glücklicherweise hat ein findiger Mitstreiter eine in Ruby implementierte Serverkopie geschrieben und veröffentlicht. Damit können problemlos 10 Spiele pro Minute gespielt werden und ist somit für Tests viel besser geeignet.
Erreichbar ist dieser Server unter:

1

telnet littleforumpeople.com 3333

Mein Bot selbst hat sich eine bereits eine nicht allzuschlechte Statistik erarbeitet:

Gewonnen: 2258
Verloren: 1542
Spiele: 3800

Daraus ergibt sich eine Erfolgsquote von ganzen 59.4%, wodurch er problemlos mit den Besten mithalten kann

Der Bot selbst ist relativ einfach aufgebaut:

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

#!/bin/bash
#------------------------------------------------------------------------------
# Author:	Patrick Schmid
# Web:		http://blog.encodingit.ch
# Version:	1.1
# Changes:	- Grundversion (13.8.10)
#		- Script umgestellt auf NC-Version (16.8.10)
#------------------------------------------------------------------------------
 
# Umgebung festlegen
name="encodingit" # mein Name
active=0 # Nicht mein Zug
zaehler=0
 
function play { # Spielfunktion
 
	# Dies müsst ihr selbst machen ;)
 
}
 
while read command a1 a2 a3
do
	case $command in
		HELO)
			echo "AUTH $name Ich bin bereit!"
			;;
		TURN)
			play $a1 $a2
			;;
		THRW)
			if [ "$active" = "1" ] 
			then
				if [ "$a1" = "6" ]
				then
					active=0
				fi
			else
				if [ "$a1" = "6" ]
				then
					active=1
				fi
			fi
			;;
		WIN|DEF)
			echo "$command" >> log
			exit 0
			;;
		*)
			echo "AUTH $name Ich bin bereit!"
			;;
	esac
done

Ich denke ihr werdet verstehen, dass ich die Play-Funktion erst nach dem Abgabetermin veröffentliche.
Gestartet wird das Script via netcat oder ncat:

1

sudo ncat -v -e ./wettbewerb.sh littleforumpeople.com 3333

Ich wünsche euch viel Spass beim würfeln.

Fortsetzung zu alea iacta est – Teil 1

Mein Bot ist nun soweit geschrieben und mit Intelligenz gefüllt. Was ihm nun noch fehlt, sind ein paar Tests, danach werde ich (zumindest Auszüge daraus) auch hier veröffentlichen.

Doch noch ein paar Worte zu meinem Vorgehen:
Eigentlich wollte ich die Kommunikation von Script zu Server via dem virtuellen Device /dev/tcp abwickeln. Schon relativ früh zeigte sicher aber; das ist so nicht lösbar!
Das Problem dabei ist, dass sobald irgendetwas auf den Device umgeleitet wird, wird die TCP-Verbindung neu aufgebaut und nach dem Senden auch gleich wieder getrennt. Geplant ist aber, dass die Verbindung nur einmal hergestellt und dann natürlich auch gehalten wird…

Somit musste ich kurzerhand umdisponieren und bin auf eine andere Möglichkeit mittels Netcat ausgewichen. Dabei wird, wie hier schon zu lesen war, mittels der Option -e nach dem Verbinden ein Script gestartet. Die Kommunikation verläuft dabei über die Standard-Ein- und -Ausgabe. Jegliche Teile der Verbindung werden von Netcat geregelt, wodurch ich mich voll und ganz auf die KI konzentrieren kann.

Doch nun zum Wichtigsten: Die Strategie!
Ich habe in ein paar kurzen, manuellen Spielen ein paar Taktiken ausprobiert. Zur Zeit umgesetzt sind:

1. Liege ich im Rückstand, muss ich risikofreudiger werden.
2. Liege ich weit vorne, kann ich sicherer spielen.
3. Speichert mein Gegner selten, kann ich sicherer spielen

Doch irgendwie reicht mir das noch nicht aus für meinen Bot.
Wenn also jemand noch weitere Ideen hat, dann immer her damit Jeder Input ist willkommen!

Doch wenn man das nicht weiss, kommt es wie folgt heraus:

Ich wusste, dass sich mittels der Option -e in Netcat nach erfolgreichem Verbinden sogleich ein Script ausführen lässt.
Doch auf mir unerklärliche Art und Weise wollte mein netcat aus den Paketquellen einfach keine Option -e kennen!
Beim googeln dann bin ich über GNU Netcat gestossen. Jedoch war dies nur Version 0.7.1.1 und ich hatte aus den Paketquellen Version 1.84 installiert. Dass es nicht das selbe Tool ist, war mir zu der Zeit immer noch nicht bewusst, wodurch ich zuerst weitersuchte.
Die Lösung fand ich schlussendlich, ja man glaubt es kaum, auf Wikipedia Da wurde ich erstmals damit konfrontiert, dass netcat eben doch nicht unbedingt gleich netcat ist.

Wer also ein ähnliches Problem hat, der soll doch einfach mal GNU Netcat ausprobieren:

Die Vorgaben dabei sind ganz einfach; der Bot muss schlussendlich mit einem Make-File gestartet werden können und auf einem Ubuntu 10.04 Rechner laufen. Insofern kann die Programmiersprache also fast frei gewählt werden. Der Spielablauf wird dabei vom Server wettbewerb.linux-magazin.de über ein für menschen-lesbares TCP-Protokoll gesteuert.

Das ganze Spiel an sich ist relativ einfach gehalten. Ein Bot kann solange Würfeln, wie er keine 6 wirft oder das Spiel nicht speichert. Alle Punkte werden dabei immer zusammengezählt.
Sobald jedoch eine 6 geworfen wird, so werden alle Punkte bis zum letzten Save wieder abgezogen, und der Spielzug ist beendet.
Es gilt also, seinem Bot soviel Intelligenz einzuhauchen, damit dieser das optimale Mittelmass zwischen “Roll” (würfeln) und “Save” (speichern) findet.

Meinen Bot habe ich in Bash-Script begonnen und bin bislang damit ganz gut gefahren, da es sich über ein virtuelles Device ohne viel Programmieraufwand problemlos via TCP mit einem beliebigen Server kommunizieren lässt:

1

echo "alea iacta est" > /dev/tcp/$server/$port

Wer es noch einfacher will, und sich überhaupt nicht um jegliche Kommunikation zwischen Server und Bot bemühen will, der kann sein Script via Netcat starten und alle Kommandos über die Standard-Ein- und Ausgabe verwalten:

1

nc -e bot.sh wettbewerb.linux-magazin.de 3333

Auch wer auf etwas komplexeres Zurückgreifen will, der findet auf der offiziellen Webseite bereits Beispiele in PHP und Ruby, welche man nur noch mit Intelligenz füllen muss.

Ein weiteres sehr gutes PHP-Beispiel gibt es auch auf blog.oncode.info, dank welcher Seite ich überhaupt auf den Wettbewerb aufmerksam geworden bin.

Noch bis zum 12. September ist das Spiel für jedermann und jedefrau geöffnet! Mögen die Würfel entscheiden

OpenVZ ist eine Virtualisierungstechnik für Linux. Damit lassen sich mehrere so genannte Virtual Private Server einrichten, die alle den Kernel und die Hardware des Host-Systems nutzen. Das Konzept ähnelt also anderen Techniken wie FreeBSD Jails und Solaris Zones. Auch als Gastsystem unterstützt OpenVZ ausschließlich Linux. Durch eine detaillierte Ressourcenaufteilung soll es möglich sein, sehr viele virtuelle Maschinen parallel auf einem physischen Computer zu betreiben, die alle streng voneinander isoliert sind. [golem.de]

Installieren kann man OpenVZ auf viele Linux basierten Betriebssysteme direkt aus den Paketquellen; im folgenden habe ich als Beispiel ein Debian (32bit) auf meinem DL380 G3 verwendet.

Zuerst müssen die passenden Kernel und Pakete installiert werden:

1

apt-get install linux-image-openvz-686 vzctl vzquota cstream

Leider ist das Tool vzdump nicht mehr in den Paketquellen enthalten, ist aber essentiell um eine virtuelle Maschine im laufenden Betrieb zu sichern:

1
2
3

cd /tmp/
wget http://download.openvz.org/contrib/utils/vzdump/vzdump_1.2-4_all.deb
dpkg -i vzdump_1.2-4_all.deb

Danach müssen in der Datei /etc/sysctl.conf folgende Punkte ergänzt werden:

1
2
3
4
5

net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.default.forwarding=1
kernel.sysrq = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.eth0.proxy_arp=1

Nach dieser Anpassung darf nicht vergessen worden, die Konfiguration neu einzulesen:

1

sysctl -p

Nun muss der Server neugestartet werden, damit der OpenVZ-Kernel auch verwendet wird.

Nun ist OpenVZ soweit eingerichtet und die ersten “virtuellen” Maschinen können eingerichtet werden.
Hier zeigt sich aber auch schon die erste Schwäche von dieser Virtualisierungslösung, denn entgegen anderen Methoden lassen sich mit OpenVZ nur genau das Betriebssystem mit dem Kernel für Guests verwenden, welcher auch der Host benutzt.

Nun da alles eingerichtet ist, können die ersten Templates heruntergeladen werden.
Dazu müssen zuerst die Paketquellen angepasst werden:

1

echo "deb http://download.openvz.org/debian-systs lenny openvz" >> /etc/apt/sources.list

Das der neue Eintrag problemlos funktioniert, muss noch der passende Schlüssel nachgeladen werden:

1
2

wget -q http://download.openvz.org/debian-systs/dso_archiv_signing_key.asc -O- | apt-key add -
apt-get update

Nun sollten auch die passenden Templates in den Paketquellen gelistet werden:

1

apt-cache search openvz | grep vzctl

Damit ein Guest mit diesem Template eingerichtet werden kann, muss er vorher natürlich noch heruntergeladen und installiert werden:

1

apt-get install vzctl-ostmpl-debian-4.0-i386-minimal vzctl-ostmpl-debian-5.0-i386-minimal

Nun kann auch schon mit dem Einrichten des ersten Guests begonnen werden.

Die dazu zur Verfügung stehenden Templates sind unter /var/lib/vz/template/cache/ gelistet.
Hier zeigt sich nun ein Vorteil von OpenVZ gegenüber den alternativen Virtualisierungslösungen. Das einrichten eines neuen Guest dauert hier gerade mal ein paar Sekunden, während bei ESX oder Xen normalerweise stets die gesamte Installation durchlaufen werden muss. Das eintippen eines einfachen Befehls reicht schon aus:

1

vzctl create 1 --ostemplate debian-5.0-i386-minimal --config vps.basic

Erhält man danach eine Ausgabe, wie die folgende, so war die Aktion erfolgreich:

1
2
3

Creating VE private area (debian-5.0-i386-minimal)
Performing postcreate actions
VE private area was created

Nun hat man die Möglichkeit direkt Einstellungen für einen Guest vorzunehmen:

1
2
3
4
5
6
7
8
9
10
11

#Beim Booten aufstarten
vzctl set 1 --onboot yes --save
 
#Hostname setzen
vzctl set 1 --hostname tux1.linux.ch --save
 
#IP Adresse setzen
vzctl set 1 --ipadd 192.168.0.1 --save
 
#DNS Server setzen
vzctl set 1 --nameserver 145.253.2.75 --nameserver 213.191.92.86 --save

Alle nun gemachten Einstellungen werden in der Datei /etc/vz/conf/1.conf gespeichert.

Nun kann der Guest das erste mal gestartet und gleichzeitig auch noch das Rootpasswort angepasst werden:

1
2

vzctl start 1
vzctl exec 1 passwd

Will man den Guest direkt auf der Kommandozeile ansprechen, so kann dies entweder per SSH oder direkt über den Host passieren. Dazu kann folgendes Kommando verwendet werden:

1

vzctl enter 1

Eine List mit allen virtuellen Maschinen erhält man mit dem Befehl vzlist:

1

vzlist -a

Weitere Informationen bekommt man durch die Manpages:

1

man vzctl

oder dem offiziellen Wiki

Was ich bisher noch nicht finden konnte ist eine Möglichkeit mit vzctl set 1 … den Guest zu einer dynamischen IP Adresse zu zwingen.

Insgesamt ist es eine gute Möglichkeit um schnell und unkompliziert zu virtualisieren, jedoch wer viele Ansprüche hat und nicht immer das selbe Betriebssystem / die selbe Distribution verwendet, wird nie seinen Spass an OpenVZ haben.

Natürlich lässt sich alles problemlos auch auf andere Distributionen und Architekturen portieren, wobei die Namen, besonders für die Templates, angepasst werden müssen.

1
2
3

Erreichte Punkte: 620
Erforderliche Punktzahl: 500
Status: Pass

Diese Prüfung habe ich, im Vergleich zu LPI 101, als viel einfacher empfunden.
In 102 geht es Hauptsächlich um Shell-Scripting, Cron und X11, wobei das Hauptgewicht in meiner Prüfung klar auf Scripting lag:

1
2
3
4
5
6

80% Shells, Scripting and Data Management
80% User Interfaces and Desktops
50% Administrative Tasks
80% Essential System Services
78% Networking Fundamentals
66% Security

Vorbereitet habe ich mich neben dem offiziellen Script auch noch mit dem Buch LPIC-1 von Harald Maassen aus dem Galileo Computing Verlag.
Für LPIC 101 habe ich zwar noch ein anderes Buch verwendet, aber wenn ich heute einen Vergleich machen und eines der beiden Bücher empfehlen müsste, so würde ich mich klar für LPIC-1 entscheiden, da es in meinen Augen den Stoff besser abdeckt und realistischere Testfragen vorweisen kann.
Die Testfragen waren sogar teils so realistisch, das sie mit exakt dem Wortlaut an der Zertifizierungsprüfung vorkamen

Mit bestandener LPIC-1 Zertifizierung konnte ich auch gleich das Novell CLA beantragen, da Novell vor etwa einem Jahr gemerkt hat, dass sich die Prüfungsinhalte von CLA mit denen von LPIC-1 überschneiden, und seither jeder mit bestandenem LPIC-1 das Novell CLA geschenkt bekommt.

Nun bleibt nicht mehr viel übrig, als auf meine Zertifikate zu warten und dann auf zu LPIC-2. Und natürlich auch meinem Mitstreiter zu gratulieren

Dieses Blog habe ich vor zwei Jahren gegründet, um über tägliche Probleme und Situationen aus meine täglichen Leben als Informatiker zu berichten. Zu Beginn waren meine Beiträge noch hauptsächlich über Windows und haben sich dann immer mehr und mehr zu den Themen Linux und OpenSource entwickelt. Und besonders seid ich auch auf der Arbeit dem Linux / Unix-Team unterstellt bin, werden Windows-Probleme immer rarer, was ich aber nicht als besonders schlimm befinde

Nun bleibt mir nicht mehr viel übrig als euch für eure Treue und Unterstützung zu danken und mich auf viele weitere erfolgreiche Jahre mit euch zu freuen!!

Nun das ist so meine Geschichte.

Und nun zu euch!
Folgend kannst du die Distributionen auswählen, die du regelmässig verwendest. Interessant wäre auch noch, wieso ausgerechnet diese?

Sollte ich eine vergessen habe, sorry

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