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

Frisch fröhlich habe ich mit der Installation des Paketes begonnen:

1

rpm -i ICAClient-11.0-1.i386.rpm

Dummerweise besteht ein Abhängigkeitsproblem, also gleich mal yum durchrennen lassen:

2

yum install ICAClient-11.0-1.i386.rpm

Doch dummerweise findet auch yum das benötigte Paket libXm.so.3 nicht…

Nach ein bisschen googeln habe ich dann herausgefunden, dass man unbedingt openmotif installieren muss. Doch auch das scheint nirgends in den Paketquellen vorhanden zu sein??
Also lade ich mir das Paket halt manuell herunter und installiere es:

3

yum localinstall --nogpgcheck openmotif-2.3.1-1.RHEL3.0.i386.rpm

Soweit so gut, also gleich nochmal versucht den Receiver zu installieren.

Doch noch immer scheint libXm.so.3 nicht vorhanden zu sein… Nach weiterer Suchzeit auf Google habe ich noch ein weiteres benötigtes Paket gefunden:

4

yum install libXaw

Doch damit wurde libXm.so.6 und nicht wie benötigt libXm.so.3 installiert. Also muss man noch ein bisschen bescheissen:

5

ln -s /usr/lib/libXm.so.6 /usr/lib/libXm.so.3

Auch bin ich oft über die Aussage gestolpert, dass möglichweise ein paar Fonts rumzicken könnten:

6
7
8

cd /usr/share/fonts/cjkuni-uming/
mv fonts.dir fonts.dir.disabled
mv fonts.scale fonts.scale.disabled

und dann war es endlich soweit:

9

yum install ICAClient-11.0-1.i386.rpm

Jetzt konnte ich den Receiver endlich installieren.
Doch damit noch nicht genug, man sollte die Applikation ja auch starten können… Und genau daran haperte es noch!
Als Ausgabe erhielt ich immer:

10

/usr/lib/ICAClient/wfcmgr: Zeile 197: Vereinbarung: Kommando nicht gefunden.

Doch nach ein bisschen Überlegen und Nachdenken war das ein kleineres Problem. Denn wenn man den Fehler so liest, so habe ich gleich an ein Problem mit der Eula gedacht. Also mal recherchieren, wie man das Anzeigen der Lizenz umgehen kann

11

touch ~/.ICAClient/.eula_accepted

Und von nun an kann ich auch unter Fedora alle Citrix Applikationen gebrauchen:

12

/usr/lib/ICAClient/wfcmgr -icaroot /usr/lib/ICAClient

Dabei handelt es sich um eine Groupware-Lösung ähnlich Microsoft Exchange, nur dass diese OpenSource ist.

Angepriesen wird das Projekt besonders als “günstige Alternative, welche für KMUs gut geeignet ist“.

Wikipedia beschreibt Open-Xchange wiefolgt:

Open-Xchange Server ist eine Kollaborationssoftware, die neben einer integrierten E-Mail-Benutzerschnittstelle, Termin-, Kontakt- und Aufgabenverwaltung auch weitergehende Funktionen wie Dokumentenspeicherung- und -austausch bietet.

Besonders interessant finde ich auch das hier:

In Vorbereitung befinden sich soziale Fähigkeiten der Anwendung, d. h. die Fähigkeit Daten zwischen Open-Xchange und auch Sozialen Netzwerken einfach und automatisiert auszutauschen. Dieser Austausch wird auf der Serverseite stattfinden, d. h. auch dann funktionieren, wenn der Benutzer gerade nicht aktiv ist.

Doch ganz so OpenSource ist das Projekt wohl doch nicht…

Will man nämlich das ganze nicht per Browser, sondern mittels Outlook verwenden, so muss man ein kostenpflichtiges Addon dazukaufen.

Doch nicht nur das, es gibt noch weitere Komponenten, welche nicht wirklich “frei” sind:

Seit August 2004 steht das Open-Xchange Server BackendGNU General Public License in der Version 2. Das unter der Open-Xchange Server Frontend steht unter Creative CommonsShare Alike, Non Commercial, Attribution-Lizenz. Diese Lizenzierung erlaubt die freie Verwendung auch in einer kommerziellen Umgebung und schränkt lediglich das Anbieten von gehosteten Angeboten ein (durch den Baustein Non Commercial in der Creative-Commons-Lizenz auf dem Frontend).

Ob das nun wirklich das Wahre ist, darüber kann man sich streiten. Auch kann ich noch nicht sagen, ob es wirklich eine brauchbare Alternative zu Exchange ist, das wird sich noch zeigen.

Als Host habe ich mich für einen Ubuntu Server 8.04 LTS entschieden.

Die Installation ist nicht wirklich schwierig, dafür sehr zeitaufwendig. Geholfen hat mir dieses Tutorial von Open-Xchange selbst.

Die Benutzeroberfläche, welche man nach einem Login zu Gesicht bekommt ist klar strukturiert. Man findet sich schnell und ohne Probleme zurecht, wie man es eigentlich auch von Exchange her kennt.

Wie es in Sachen Performance aussieht kann ich noch nicht sagen, da ich die Installation erst gestern durchgeführt habe. Dazu später dann mehr!

Das Skript muss man sich erst herunterladen,

wget http://registry.gimp.org/files/3DScreenshot.scm

und dann an den richtigen Ort verschieben

mv 3DScreenshot.scm /home/$USER/.gimp-2.6/scripts/

Nun nur noch die Plugins neu laden

Filter > Skript-Fu > Skripte aufffrischen

und schon kann man das Skript anwenden.

Filter > Script-Fu > 3D Screenshot

Vielen Dank an zefanja für den Tipp!

Das Spiel selbst ist recht amüsant, die Grafik klasse, die eigentliche Idee aber weder neu noch sehr einfallsreich.

Trotzdem mag ich das Game

Das Spiel ist frei im AppStore verfügbar!

ditaa ist ein Konsolenprogramm, womit man aus einem ACSII-File ein Bild mit “echten” Flowcharts erstellen. Alles was man zu tun hat, ist ein Textfile zu erstellen mti zum Bespiel folgendem Inhalt:

    +--------+   +-------+    +-------+
    |        | --+ ditaa +--> |       |
    |  Text  |   +-------+    |diagram|
    |Document|   |!magic!|    |       |
    |     {d}|   |       |    |       |
    +---+----+   +-------+    +-------+
        :                         ^
        |       Lots of work      |
        +-------------------------+

Nun lässt man ditaa drüberrasen und erhält folgendes Bild als Ausgabe:

Dazu verwendet man folgenden Befehl:
java -jar ditaa.jar inputfile outputfile.png

Mittels dem Parameter -h erhält man noch weitere und feinere Einstellungsmöglickeiten angezeigt.

Doch wieso der Aufwand? ditaa beantwortet die Frage gleich selbst:

BUT WHY? Does this thing have any real use?

There are several reasons why I did this:

1. Simply for hack value. I wanted to know if/how it could be done and how easily.
2. Aesthetic reasons and legacy formats: there are several old FAQs with ascii diagrams lying out there. At this time and age ascii diagrams make my eyes hurt due to their ugliness. ditaa can be used to convert them to something nicer. Although ditaa would not be able to convert all of them (due to differences in drawing ‘style’ in each case), it could prove useful in the effort of modernising some of those documents without too much effort. I also know a lot of people that can make an ascii diagram easily, but when it gets to using a diagram program, they don’t do very well. Maybe this utility could help them make good-looking diagrams easily/quickly.
3. Embedding diagrams to text-only formats: There is a number of formats that are text-based (html, docbook, LaTeX, programming language comments), but when rendered by other software (browsers, interpreters, the javadoc tool etc), they can contain images as part of their content. If ditaa was intergrated with those tools (and I’m planning to do the javadoc bit myself soon), then you would have readable/editable diagrams within the text format itself, something that would make things much easier. ditaa syntax can currently be embedded to HTML.
4. Reusability of “code”: Suppose you make a diagram in ascii art and you render it with version 0.6b of ditaa. You keep the ascii diagram, and then version 0.8 comes out, which features some new cool effects. You re-render your old diagram with the new version of ditaa, and it looks better, with zero effort! In that sense ditaa is a diagram markup language, with very loose syntax.

Ich weiss jedoch nicht ob es daran liegt, dass ditaa noch in der Beta-Phase ist, oder ob ich einfach unfähig bin, aber bei mir wird das Bild immer ein bisschen zu schwarz, da wo eigentlich ein Pfeil sein sollte :

/---------------+    +---------------+
|               |    |               |
|    cRED       |    |    cPNK       |
|               |    |               |
|               |    |               |
+-------+-------/    +---------------/
    |                       ^
    |                       |
    +-----------------------+

ditaa muss man einfach ausprobiert haben

Update

Eine aktuelle JAVA-Version ist von grossem Vorteil

Da auch ich viel dokumentieren muss, war ich auf der Suche nach einem passenden Tool.

• Da ich privat mit Linux und geschäftlich mit Windows arbeite, sollte das Tool auch platformübergreifend sein.
• Weiter sollten die Dokumentationen leicht zugänglich von mehreren Computern sein.

Die Suche nach einem Tool, welche meine Anforderungen erfüllt, war nicht schwierig. Schon nach kurzer Zeit bin ich auf Dradis gestossen.

Dies ist nicht etwa das neuste Parfüm aus einem Frauenmagazin sondern ein auf Ruby basierendes Webtool.

Es ist speziell auf Notizen und Dokumentationen ausgerichtet. Da es ein Webtool ist, können auch mehrere Personen mit mehreren Betriebssystemen auf einmal auf die Daten zugreifen.

Die Webapplikation an sich ist sehr simpel gehalten. Die Daten werden in einem Tree mit beliebig vielen Kategorien und Unterkategorien organisiert. Um Daten hinzuzufügen reicht ein simples Klicken, sowas wie Speichern gibt es nicht.

Das ganze ist mehr oder weniger gut dokumentiert, ist aber auf jeden Fall einen zweiten Blick wert

Ein Easter Egg ist eine versteckte und nicht dokumentierte Funktion in einer Software, wie zum Beispiel der Flugsimulator in Google Earth.

Unser Easter Egg ist zwar keine solche versteckte Funktion aber trotzdem ein kleines Überraschungsei

Mittels WinRar unter Windows oder steghide unter Linux kann man problemlos eine beliebige Datei zb einem Bild anhängen. Nach aussen ist es immer noch ein simples Bild, welches man anschauen kann.

Unter Windows erstellt man zuerst ein .rar-Archiv von der geheimen Datei. Dann öffnet man eine Konsole und gibt folgenden Befehl ein:

copy /b bild.jpg + archiv.rar

Wenn man nun seine Datei wieder anschauen will, muss man das Bild nur mittels WinRar öffnen.

Unter Linux kann man steghide verwenden. Dies ist auf den Packetservern verfügbar.

Der Nachteil und vielleicht auch Vorteil von steghide ist, dass man nur kleine Dateien (bis 750 KB) anhängen darf. Dies ist insofern ein Vorteil, da ein Bild mit 10GB Grösse auffallen würde. Der Vorteil, dass mittels steghide die angehängte Datei verschlüsselt wird und nur mit einem Passwort gelesen werden kann.

Eine Datei verstecken kann man mit folgendem Befehl:

steghide embed -cf bild.jpg -ef datei.txt

Bild.jpg ist dabei das Bild, welches die Datei aufnimmt und datei.txt die geheime Datei, welche versteckt wird. Nach der Eingabe eines Passwortes haben wir ein vollfunktionsfähiges Bild mit einer geheimen Datei.

Um die angehängte Datei wieder zu extrahieren verwendet man folgenden Befehl:

steghide extract -sf bild.jpg

So und nun viel Spass beim anmalen der Eier und frohe Ostern

Als erstes bin ich auf PHProject gestossen. Damit habe ich dann auch eine Zeit lang gearbeitet, doch leider haben mich kleine Fehler, das schlichte Design und die ein bisschen überfüllte und unübersichtliche Übersicht immer gestört.

Mit der Zeit habe ich die Groupware immer weniger benutzt und das Projekt ist mehr oder weniger in Vergessenheit geraten.

Doch dann bin ich über ein Artikel im Planet gestolpert. Dabei wurden mehrere Groupwares angesprochen. Diese habe ich auch gleich ausprobiert.

Leider aber wollten die meisten der Groupwares nicht meinen ansprüchen genügen oder sich nicht mit PHP und MySQL begnügen. Bis auf eines: OpenGoo!

Obwohl es ein bisschen langsam ist und sehr sehr oft einen Error liefert (was aber auch am Server liegen kann) bin ich sehr zufrieden damit, da es sehr übersichtlich ist und meine geforderten Funktionen erfüllt.

Dadurch will ich es hier kurz vorstellen:

Die Anforderungen sind sehr simpel: PHP und MySQL.

Die ganzen Aufgaben, Task, Notes etc sind in sogenannte Workspaces organisiert. So kann man z.B. eine Workspace für Privat und eine für die Arbeit erstellen. Wenn man eine Workspace anwählt, werden auch nur diese Aufgaben angezeigt. Weiter hat man auch die Möglichkeit einzelne User für Workspaces zu berechtigen.

Ein weiteres gutes Feature ist auch, dass man für Task einen Zeitbutton hat, welcher automatisch die gearbeitete Zeit misst.

Sehr nützlich ist auch die Versionskontrolle für hochgeladene Files. Man hat die Möglichkeit jedes Update eines Files mit einem Kommentar zu versehen, so dass man später genau nachvollziehen kann, wann was geändert wurde.

Alles in allem trifft es meine Vorstellungen sehr genau

Doch irgendwie habe ich es wieder ins Auge gefasst, da einem Kollegen von mir der PC mit Viren versucht ist. Also habe ich mich auf die Suche nach einem geeigneten Script oder Tool gemacht. Jedoch, da ich meine Daten auf eine externe HD speichern will, wollte ich zuerst ein Script machen, welches bei jedem einstecken ein Backup macht. Jedoch, da ich extrem faul bin und dem Shell-Scripting nicht wirklich mächtig bin, habe ich mich mal auf die Suche nach einem geeigneten Tool gemacht.

Wie so oft einmal wurde ich im Wiki von uu.de fündig: sBackup heisst die Lösung all meiner Probleme Naja, bleiben wir mal auf dem Boden!

Das installieren geht total einfach über die Shell mit folgendem Befehl:

sudo apt-get install sbackup

Danach findet man das Tool unter System >> Systemverwaltung >> Simple Backup Config / Restore. Über diese beiden Menueinträge managed man die ganze Software. Ich werde hier nur auf die Config, nicht aber auf das Restoren eingehen, da ich es selbst noch nie gebraucht habe und es hoffentlich auch nicht brauchen werden. Das selbe wünsche ich dir natürlich auch!

Nun kann man diverse Einstellungen vornehmen. Es sind seit der Installation ein paar Standardeinstellungen wie das includen der wichtigsten Pfaden oder das excluden von Musik und iso Files. Nun kann man noch die Zeit einstellen, wie oft das Backup durchgeführt werden muss. Weiter kann man bestimmen, wann ein Backup gelöscht werden soll.

Die für mich wichtigste Funktion ist Abort backup if destination directory not exist. Somit kann ich problemlos auf eine HDD sichern. Ist diese nicht vorhanden, so wird nichts gesichert.