ubuntuusers.de

🚧 Am Sonntag, 5. Mai, werden ab 16 Uhr die Server aktualisiert und eine neue Inyoka-Version veröffentlicht. Das Portal wird mehrmals nicht verfügbar sein.

6. Oktober 2011

Mit Roman gehts aufwärts. Einmal eine wirklich positive Info ist der Genesungszustand von Roman. Ich bin hoch erfreut zu hören, dass es Roman besser geht. Roman ist im Moment in einer Reha-Klinik und erholt sich von seiner Hirnblutung. Leider ist das eine wirklich sehr ernste Sache die einige Probleme mit sich bringt. Dirk hat dazu in seinem Podcast einen Beitrag zum Thema Balance im Leben gemacht. Hört mal rein, es lohnt sich.

Wie geht es nun weiter mit Roman ?

So wie es aussieht wird Roman nun sicherlich bis Ende Oktober in der Reha bleiben. Für die Rehabilitation braucht es immer wieder einen Input von Familienmitgliedern, Freunden, Verwandten und weiteren Personen. Im Moment läuft noch eine Phase mit engen Freunden im Sinne der Familie und Verwandten. Wir ubuntero’s kommen in einem 2. Schritt so etwa im November zum tragen. Bis dahin nützen Roman handschriftliche Glückwünsche via Brief-Post sehr viel. In diesem Sinne ist eine momentane Kontaktaufnahme mit Roman via Brief-Post eine gute Sache. Wenn ihr also Roman etwas gutes tun wollt, dann sendet eine Postkarte etc. an Romans Adresse.

Wer in der näheren Umgebung von Roman ist und ihn besuchen möchte, der kann das natürlich auch tun. Hier ist es wichtig, dass bei einem Besuch nicht zu verschiedene Personen-Gruppen anwesend sind. Damit das koordiniert werden kann, gibt es einen Doodle. Wenn ihr also einen Besuch abstatten möchtet, dann schaut in den Doodle und tragt euch dort ein.

Was können wir sonst noch tun ?

Es gibt noch viele Dinge die wir tun können. Wir rechnen damit, dass Roman etwa noch 6-12 Monate hier nicht mitmachen kann. Natürlich wollen wir alle Aufgaben die damit so anfallen weiter betreiben. In diesem Sinne wird als wichtigste Sache dieser Blog von mir weiter geführt. Auch weitere Internet-Auftritte müssen noch koordiniert und organisiert werden. Dazu werden wir alle technischen Massnahmen ergreiffen und die Systeme für Roman betreiben. Starken Rückhalt haben wir auch von Dirk. An dieser Stelle vielen Dank Dirk für alle Deine Bemühungen.

Fazit

Mit Roman gehts aufwärts. Wir unternehmen alles erdenkliche damit Roman so gut wie möglich wieder sein ganzes Leben in den Griff bekommt. Helft mit Roman zu unterstützen, denn ich bin mir sicher, dass es ihm wirklich sehr weit helfen wird. Danke für eure Mithilfe und euren Einsatz.

 

PDF-Datei dieses Artikels erzeugen

Ähnliche Artikel

  • Keine ähnlichen Artikel vorhanden

 

Ob nun 5 Minuten wirklich gebraucht werden ;-)

Asterisk Installation

Die Installation von Asterisk ist eine der Aufgaben die wirklich am einfachsten ist. Ich mache das ganze auf Debian, also hab ich auch die Debian Pakete genommen. apt-get la-le-lu und fertig. Welche Paket ich installiert habe? Diese:

ii  asterisk                            1:1.6.2.9-2+squeeze3         Open Source Private Branch Exchange (PBX)
ii  asterisk-config                     1:1.6.2.9-2+squeeze3         Configuration files for Asterisk
ii  asterisk-core-sounds-en-gsm         1.4.19-1                     asterisk PBX sound files - English/gsm
ii  asterisk-doc                        1:1.6.2.9-2+squeeze3         Source code documentation for Asterisk
ii  asterisk-h323                       1:1.6.2.9-2+squeeze3         H.323 protocol support for Asterisk
ii  asterisk-moh-opsound-g722           2.03-1                       asterisk extra sound files - English/g722
ii  asterisk-moh-opsound-gsm            2.03-1                       asterisk extra sound files - English/gsm
ii  asterisk-moh-opsound-wav            2.03-1                       asterisk extra sound files - English/wav
ii  asterisk-mp3                        1.6.2.1-1                    MP3 format support (format_mp3) for the Asterisk PBX
ii  asterisk-mysql                      1.6.2.1-1                    MySQL support for the Asterisk PBX (cdr mainly)
ii  libasterisk-agi-perl                1.01-2                       Collections of Perl modules to be used with Asterisk PBX AGI

Damit hat man bereits quasi alles was benötigt wird um den Asterisk Server zu starten.

In den Debian Repositories ist noch Asterisk 1.6 – und das ist auch gut so. Asterisk 1.8 gibt es zwar auch schon länger, allerdings ist diese Version noch recht Buggy. Im Internet wird auch noch oft von der 1.8 abgeraten und die meisten Dokus beziehen sich auf 1.6. Ich hatte bisher auch noch keine Probleme mit dem Dienst an sich.

Auf die absoluten Basics (bspw. wie nun einen SIP/Account einrichten) möchte ich hier eigentlich – wie immer – nicht eingehen. Ich möchte mehr die Fallstricke beschreiben die ich auf meinem Weg beiseite räumen musste und ein Tipps geben. Eine gute Quelle ist das Asterisk Buch online ( http://www.das-asterisk-buch.de/2.1/ ). Dort werden gerade die Basics recht gut beschrieben.

Ein paar Konfighints

Konfiguration über Scripte erweitern

Datei: /etc/asterisk/asterisk.conf

Parameter: execincludes = yes ; support #exec in config files

Dadurch wird es möglich innerhalb von Konfigurationsdateien mit Hilfe von “#exec” externe Scripte auszuführen. Der Output eines solchen Scriptes muss im Format der Konfigurationsdatei sein.

Konfigurationen (Accounts & Voicemail) aus der Datenbank

Das ganze läuft unter dem Namen “realtime”. Der Name ist durchaus verständlich, da durch Änderungen an der Datenbank der Asterisk Prozess nicht neu geladen werden muss. Ändert man in den Dateien (sip.conf, voicemail.conf, etc.) muss der Dialplan oder teilweise der asterisk Prozess neu geladen werden.

Datei: /etc/asterisk/extconfig.conf

Parameter:

[settings]
voicemail => mysql,general,voicemail
sipusers => mysql,general,sip_devices
sippeers => mysql,general,sip_devices

Diese Einstellungen bewirken, dass Asterisk nach den SIP Accounts (quasi der /etc/asterisk/sip.conf) auch in der Datenbank schaut. Das gleiche gilt für die /etc/asterisk/voicemail.conf.

Damit das ganze funktioniert müssen noch die Daten für den Connect auf die Datenbank eingerichtet werden.

Datei: /etc/asterisk/res_mysql.conf

Parameter:

[general]
;dbhost = 127.0.0.1
dbname = asterisk_db
dbuser = root
dbpass = test
dbport = 3306
dbsock = /var/run/mysqld/mysqld.sock
requirements=warn ; or createclose or createchar

Diese Einstellungen machen dem System die Datenbank bekannt. Man sieht nun auch, dass der Verweis aus der extconfig.conf “general” auf diese Verbindung zeigt und hier seine Referenz hat. Dem entsprechend können also auch mehrere Datenbanken genutzt werden.

Die Datenbanktabellen müssen noch erstellt werden. Dafür möchte ich gerne auf eine externe Seite verweisen -> http://www.voip-info.org/wiki/view/Asterisk+RealTime+Sip

Mit einem reload oder restart sollte dann die Konfiguration in der Datenbank berücksichtigt werden – falls vorhanden. Die Felder in der Datenbank sind analog zu denen in den Konfigdateien. Es gibt einige Spalten die in den jeweiligen Tabellen vorhanden sein müssen, die meisten können jedoch auch einfach gelöscht werden. Auch zusätzliche Spalten sind kein Problem – sie werden von Asterisk einfach ignoriert.

 Dateirechte

Mir ist es häufig passiert, dass ich Änderungen vorgenommen habe die vom System nicht angenommen wurden. Das ganze ohne irgendeine Fehlermeldung (wenigstens in den “normalen” logs). Das passiert, wenn die Rechte einer Konfigurationsdatei nicht stimmen. Die Dateien sollten alle asterisk gehören.

Erster Test

Einen ersten Test kann man ganz einfach mit Hilfe eines Headsets und (bspw.) Ekiga oder Jitsi – also Softphones – machen. Ich habe dazu Voicemail konfiguriert und als Test die Mailbox angerufen.

 

 

 

 

 

 

 

5. Oktober 2011

    Schuppentier als Maskottchen

    Mark Shuttleworth hat heute bekanntgegeben, dass der Codename für Ubuntu 12.04 LTS Precise Pangolin lauten wird. Zu deutsch bedeutet das etwa „gewissenhaftes Schuppentier“.

    Gemäß der Tradition wurde ein Adjektiv gefolgt von einem Tier gewählt, wobei es sich um eine Alliteration handelt, und die Anfangsbuchstaben bei jeder Version fortlaufend ist. Auf das O folgt das P und aus allen Einsendungen für Namensvorschläge wurde nun der oben genannte Schuppentier ausgesucht.

    Das Adjektiv soll im Übrigen auf die Zuverlässigkeit von Ubuntu anspielen, deren Anspruch erneut an diese Ubuntuversion gestellt wird. Leider wurde diese einmalige Chance nicht genutzt, um das Linuxmaskottchen Tux ins Spiel zu bringen: Penguin.

     

    Mark Shuttleworth hat soeben in seinem Blog den Namen des nächsten LTE Ubuntu Releases verraten.
    Ubuntu 12.04 wird den Namen Precise Pangolin haben. Auf Deutsch: Präzises/akkurates Schuppentier

    Auf den Namen ist er wohl gekommen, da er vor kurzer Zeit selber einem Schuppentier auf der Spur war und bestätigen kann, dass diese sehr präzise seien zumindest hinsichtlich des Auffindens von Ameisennestern.

    Da im Ubuntu Alphabet das P an der Reihe war, ist es etwas schade das man für das "große" LTE Release keinen simplen Namen wie z.B. P***** Penguin nimmt.


    Schuppentiere (engl. Pangolin) sind die einzig bekannten Säugetiere, die mit großen Hornschuppen ausgestattet sind.


    Mehr Infos zum Tier gibt es auf Wikipedia.

    Den Orginalpost von Mark Shuttleworth gibt es hier.

    Nur noch neun Tage, dann startet die Ubucon 2011 in Leipzig. Es ist noch nicht zu spät für die Anmeldung. Das Programm kann sich meiner Ansicht nach sehen lassen. Ich möchte noch einmal explizit darauf hinweisen, dass man eine Förderung in Anspruch nehmen kann, falls die Teilnahme an der Veranstaltung eine zu grosse finanzielle Herausforderung darstellt. Wer eine Mitfahrgelegenheit sucht oder bietet, möge sich bitte auf dieser Wiki-Seite eintragen.

    Ich freue mich darauf, Euch zu treffen!

    4. Oktober 2011

    Wuala war für mich einige Zeit eine ernsthafte Alternative zur Dropbox. Leider war für mich der Upload bei Wuala noch nie besonders schnell. Da ich aber nie große Dateien hochgeladen hatte fand ich das nicht schlimm.

    Nun hat sich Wuala aber von einer Funktion verabschiedet, die der Speicheranbieter Dropbox voraus hatte. Man konnte eigenen Festplatten-Speicher freigeben und ihn gegen zusätzlichen Speicherplatz in der Cloud eintauschen. Diese Funktion gibt es bei Wuala nun nicht mehr – eigentlich schade.

    Damit verabschiedet sich Wuala für mich aus dem Rennen der Online-Speicher. Was passiert nun mit dem bereits durch das Tauschen ‘verdienten‘ Speicherplatz? Dieser bleibt den Nutzern für 12 Monate erhalten, danach muss man ihn kaufen. Wuala bietet hierfür laut Forum einen Rabatt an. Man muss also jetzt nicht panisch sofort bei Wuala seine Koffer packen und die Daten in Sicherheit bringen – immerhin.

    In der neuen Wuala-Version, die heute über die Paketquellen auf mein System kam, war die Tausch-Funktion bereits verschwunden. Damit verschwindet Wuala nun allerdings auch von meiner Festplatte.

    3. Oktober 2011


    Weiter geht es in meiner Serie zu SparkleShare. Hier noch einmal eine Übersicht über die (geplanten) Themen der Serie:

    Heute also der zweite Teil – es geht um die Einrichtung und den Betrieb eines eigenen Servers für SparkleShare

    Installation des Servers

    Da SparkleShare keine eigene Server-Software, sondern stattdessen nur ein GIT-Repository benötigt, ist die Installation des Servers sehr einfach – und was die Voraussetzungen angeht auch sehr anspruchslos.

    Wenn ihr einen eigenen Root-Server o.ä. gemietet habt, wäre es natürlich praktisch das GIT-Repository dort einzurichten. Aber mir fällt da noch ein zweites Szenario ein: wer ein NAS sein eigen nennt, kann ggfs. auch dort das Repository platzieren und so ein automatisches Synchronisieren auf den NAS realisieren.

    Bei meinem Synology NAS würde das jedenfalls funktionieren. Man muss zuvor den Paketmanager IPKG darauf zum laufen bringen (wie das funktioniert, habe ich hier schon einmal geschrieben). Darüber kann dann GIT installiert werden. Ich habe das selbst aber noch nicht probiert und ich werde hier auch nicht näher darauf eingehen.

    Pakete installieren

    Zunächst einmal muss man dafür sorgen, dass die benötigte Software auf dem Server vorhanden ist: GIT und OpenSSH. Sofern es sich um einen Ubuntu-Server handelt, kann das folgendermaßen bewerkstelligt werden:

    sudo apt-get install git-core openssh-server

    GIT-Repository erstellen

    Bei einem GIT-Repository handelt es sich an sich nur um ein Datenverzeichnis, das zusätzlich ein paar Verzeichnisse und Dateien zur GIT-Steuerung beinhaltet. D.h. man kann sich frei aussuchen, wo man denn sein Repository bzw. seine Repositories auf dem Server unterbringen möchte. Ich schlage dafür /var/sparkleshare vor (spielt aber wirklich keine Rolle, wenn ihr das lieber irgendwo anders haben woll). Legt also euer Basisverzeichnis an:

    mkdir /var/sparkleshare

    Dann legt ihr euch ein Repository-Verzeichnis unterhalb des Basisverzeichnisses an (auch dieser Name ist natürlich frei wählbar):

    cd /var/sparkleshare
    mkdir meinrep

    Und schließlich müsst ihr aus diesem Verzeichnis ein GIT-Repository machen:

    cd /var/sparkleshare/meinrep
    git --bare init

    Zugriff per SSH-Key ermöglichen

    Als nächstes braucht ihr ein SSH-Keypair, dessen Public-Key ihr auf dem Server platzieren müsst. SparkleShare benutzt dann den lokal gespeicherten Private-Key für die Authentifizierung am Server. Aber zunächst: falls ihr mit dieser Thematik nicht vertraut seid, möchte ich euch dringend die Wikiseite bei ubuntuusers.de an Herz legen.

    Mit folgendem Kommando könnt ihr ein Keypair generieren:

    ssh-keygen -t rsa

    Falls ihr schon einen Key für den Zugriff auf euren Server besitzt, könnt ihr diesen Schritt natürlich überspringen und den vorhandenen Key auch für SparkleShare benutzen. Seid euch aber in beiden Fällen darüber bewusst, dass eine bei der Generierung angegebene Passphrase natürlich auch jeweils nach jedem System-Neustart einmal eingegeben werden muss (immer dann, wenn sich SparkleShare das erste Mal mit dem Server verbindet). Wenn ihr keine Passphrase eingebt, bleibt euch das erspart – aber das bedeutet dann auch, dass jeder, der in Besitz eures Private-Keys kommt, auch Zugriff auf euren Server erhält!

    Ihr findet nun euren Public-Key in der Datei ~/.ssh/id_rsa.pub und euren Private-Key in ~/.ssh/id_rsa.

    Kopiert nun den Public-Key auf den Server, indem ihr folgendes eingebt (wobei ihr meinuser durch den Benutzer ersetzt, den ihr auf dem ebenfalls zu ersetzenden Server meinserver benutzen wollt):

    ssh-copy-id meinuser@meinserver

    Beachtet an dieser Stelle auch, dass euer Repository-Verzeichnis für den hier angegebenen User natürlich les- und schreibbar sein muss. Sonst kann es natürlich nicht funktionieren.

    Ihr könnt nun prüfen, ob der Zugriff per SSH unter Benutzung des Keys funktioniert:

    ssh -l meinuser meinserver

    Anstatt des User-Kennworts müsst ihr nun die Passphrase eures Keys eingeben – falls ihr keine Passphrase angegeben habt, solltet ihr sofort angemeldet sein.

    Client konfigurieren

    Beispielkonfiguration im SparkleShare-Client

    Wählt im Menü des SparkleShare-Clients den Punkt Remote-Ordner hinzufügen... und gebt in der folgenden Maske eure Daten (User- und Servername und Repository-Verzeichnis) an.

    Wählt die Option Auf meinem eigenen Server aus und gebt in das Eingabefeld dahinter eure Serveradresse ein. Wenn euer lokaler Benutzer einen anderen Namen hat, als der Benutzer auf dem Server, müsst ihr dem Servernamen außerdem den Server-Benutzer voranstellen – nach dem Schema: user@server.

    In dem unteren Eingabefeld Verzeichnisname gebt ihr dann den vollständigen Pfad zu eurem GIT-Repository an.

    Für die o.g. Beispiel-Konfiguration würde das so aussehen, wie in dem auf der Seite gezeigten Screenshot.

    Wenn ihr dann auf Synchronisation klickt, startet die Erst-Sychronisation. D.h. es werden alle Dateien vom Server abgeholt, falls das Repository dort schon befüllt ist – falls nicht wird einfach ein lokales Repository-Verzeichnis erzeugt.

    Dieses lokale Repository-Verzeichnis findet ihr dann als Unterverzeichnis unterhalb von ~/SparkleShare. Alles was ihr dort hinein kopiert, wird auf den Server übertragen.

    Mehr…

    An dieser Stelle möchte ich noch einmal auf die Serie hinweisen. Lest also auch den ersten Artikel und seid gespannt auf die noch folgenden. Eine Übersicht über die bereits erschienenen und noch geplanten Artikel findet ihr ganz oben.

    pssst, weitersagen!

    Ich geb’s ja zu! Ich habe bisher höchstens manuelle Backups gemacht. Wiederkehrende Erfahrungen mit kaputten Festplatten, versehentlich gelöschten Daten oder verschlimmbesserten Konfigurationsdateien haben mich dann aber doch motiviert, mich etwas intensiver mit der Thematik zu befassen. Und es kann tatsächlich so einfach sein: In meinem Fall heißt die Antwort rsnapshot – ein kleines Shelltool, mit dem man regelmäßige Backups machen kann.

    Vorausgehende Fragen (und Antworten)

    Wer sich mit Backups beschäftigt, sollte einige Fragen vorausschicken, damit ein sinnvolles Backupsystem entsteht:

    Wohin sollen meine Daten gespeichert werden?
    Hier bietet sich natürlich an, eine logisch und physikalisch vom normalen System getrennte Festplatte zu wählen. Mit rsnapshot ist aber beispielsweise auch ein Backup per SSH auf einem entfernten Server möglich.

    Was will ich backupen? In meinem Fall:

    • /home-Verzeichnis
    • /etc und /var für die Einstellungen
    • /usr für lokal installierte Programme
    • /boot für die Bootinformationen

    Wie oft will ich meine Daten backupen?
    Ich habe dazu ein Script geschrieben (dazu unten mehr), welches als Cronjob täglich und monatlich aufgerufen wird. Außerdem habe ich rsnapshot so eingestellt, dass nach 5 Tagen bzw. 3 Monaten die Daten wieder überschrieben werden.

    Besonders wichtig: Wie werden die Daten später wiederhergestellt?
    Im Falle von rsnapshot kann man sie einfach aus dem Backupverzeichnis kopieren.

    Warum rsnapshot?

    Auf der Suche nach einem unkomplizierten und möglichst schlanken Backuptool, bin ich auf rsnapshot gestoßen. Wie viele Backuptools, verwendet Rsnapshot das altbewährte rsync für Backups. Eine Besonderheit von rsnapshot ist, dass nur beim ersten Mal eine komplette Kopie der Daten erfolgt. Anschließend werden nur noch diejenigen Dateien kopiert, die sich geändert haben, für alle Anderen werden Hardlinks zum ersten Backup gesetzt. Das spart natürlich Platz und wirkt sich auch deutlich positiv auf die Laufzeit der nachfolgenden Backups aus.
    Die Dateien werden unkomprimiert in der selben Verzeichnisstruktur wie auf dem eigentlichen System abgelegt, was die Wiederherstellung einzelner Dateien natürlich erleichtert.
    Ich denke auf Desktopsystemen reicht es auch, eine Kopie der aktuellen Datei zu haben,  auf Serversystemen, auf denen Datensicherheit besonders wichtig ist, muss man sich natürlich überlegen, ob man nicht lieber zu einem Tool greifen möchte, das jedes Mal “komplette” Backups anlegt.

    Rsnapshot konfigurieren

    Die Konfigurationsdatei (Standard: /etc/rsnapshot.conf) ist gut kommentiert und schnell angepasst. Im Wesentlichen müssen hier nur ein Zielverzeichnis (snapshot_root), die Backuppoints (Verzeichnisse, die gespeichert werden sollen) und eventuelle Ausnahmen (exclude-Anweisungen) festgelegt werden. Außerdem sollte man auswählen, welche in Zeiträumen (und wie lange) die Daten gesichert werden sollen. Danach kann das Backup schon mittels z.B. rsnapshot -t daily getestet und mit rsnapshot -v daily durchgeführt werden!

    Rsnapshot Backupscript (Backup auf gesonderte Platte)

    Ich habe mir ein kleines Script geschrieben, damit meine Backuppartition (die ich zuvor in /etc/fstab eingetragen habe) automatisch gemountet wird und ich entsprechende Notifications über das Backup in Gnome bekomme. Außerdem erstellt das Script anschließen immer eine Liste der installierten Pakete (Pacman / Archlinux). Ich habe dieses Script unter /etc/cron.daily sowie (in angepasster Form) nach /etc/cron.monthly gepackt, damit regelmäßige Backups abgelegt werden können. Falls Fehler beim Backup auftreten, werden diese auf der Backupplatte in einer errors.log gespeichert und es erscheint passende Benachrichtigung auf dem Desktop.

     

     

    Wer Interesse hat, darf das Script natürlich nach Belieben an die eigenen Bedürfnisse anpassen.. Garantie, dass das Script funktioniert, gibt’s natürlich nicht – Verbesserungsvorschläge sind immer willkommen! ;)

    Ich geb’s ja zu! Ich habe bisher höchstens manuelle Backups gemacht. Wiederkehrende Erfahrungen mit kaputten Festplatten, versehentlich gelöschten Daten oder verschlimmbesserten Konfigurationsdateien haben mich dann aber doch motiviert, mich etwas intensiver mit der Thematik zu befassen. Und es kann tatsächlich so einfach sein: In meinem Fall heißt die Antwort rsnapshot - ein kleines Shelltool, mit dem man regelmäßige Backups machen kann.

    Vorausgehende Fragen (und Antworten)

    Wer sich mit Backups beschäftigt, sollte einige Fragen vorausschicken, damit ein sinnvolles Backupsystem entsteht:

    Wohin sollen meine Daten gespeichert werden?

    Hier bietet sich natürlich an, eine logisch und physikalisch vom normalen System getrennte Festplatte zu wählen. Mit rsnapshot ist aber beispielsweise auch ein Backup per SSH auf einem entfernten Server möglich.

    Was will ich backupen?

    In meinem Fall:

    • /home-Verzeichnis
    • /etc und /var für die Einstellungen
    • /usr für lokal installierte Programme
    • /boot für die Bootinformationen

    Wie oft will ich meine Daten backupen?

    Ich habe dazu ein Script geschrieben (dazu unten mehr), welches als Cronjob täglich und monatlich aufgerufen wird. Außerdem habe ich rsnapshot so eingestellt, dass nach 5 Tagen bzw. 3 Monaten die Daten wieder überschrieben werden.

    Besonders wichtig: Wie werden die Daten später wiederhergestellt?

    Im Falle von rsnapshot kann man sie einfach aus dem Backupverzeichnis kopieren.

    Warum rsnapshot?

    Auf der Suche nach einem unkomplizierten und möglichst schlanken Backuptool, bin ich auf rsnapshot gestoßen. Wie viele Backuptools, verwendet Rsnapshot das altbewährte rsync für Backups. Eine Besonderheit von rsnapshot ist, dass nur beim ersten Mal eine komplette Kopie der Daten erfolgt. Anschließend werden nur noch diejenigen Dateien kopiert, die sich geändert haben, für alle Anderen werden Hardlinks zum ersten Backup gesetzt. Das spart natürlich Platz und wirkt sich auch deutlich positiv auf die Laufzeit der nachfolgenden Backups aus. Die Dateien werden unkomprimiert in der selben Verzeichnisstruktur wie auf dem eigentlichen System abgelegt, was die Wiederherstellung einzelner Dateien natürlich erleichtert. Ich denke auf Desktopsystemen reicht es auch, eine Kopie der aktuellen Datei zu haben,  auf Serversystemen, auf denen Datensicherheit besonders wichtig ist, muss man sich natürlich überlegen, ob man nicht lieber zu einem Tool greifen möchte, das jedes Mal “komplette” Backups anlegt.

    Rsnapshot konfigurieren

    Die Konfigurationsdatei (Standard: /etc/rsnapshot.conf) ist gut kommentiert und schnell angepasst. Im Wesentlichen müssen hier nur ein Zielverzeichnis (snapshot_root), die Backuppoints (Verzeichnisse, die gespeichert werden sollen) und eventuelle Ausnahmen (exclude-Anweisungen) festgelegt werden. Außerdem sollte man auswählen, welche in Zeiträumen (und wie lange) die Daten gesichert werden sollen. Danach kann das Backup schon mittels z.B. rsnapshot -t daily getestet und mit rsnapshot -v daily durchgeführt werden!

    Rsnapshot Backupscript (Backup auf gesonderte Platte)

    Ich habe mir ein kleines Script geschrieben, damit meine Backuppartition (die ich zuvor in /etc/fstab eingetragen habe) automatisch gemountet wird und ich entsprechende Notifications über das Backup in Gnome bekomme. Außerdem erstellt das Script anschließen immer eine Liste der installierten Pakete (Pacman / Archlinux). Ich habe dieses Script unter /etc/cron.daily sowie (in angepasster Form) nach /etc/cron.monthly gepackt, damit regelmäßige Backups abgelegt werden können. Falls Fehler beim Backup auftreten, werden diese auf der Backupplatte in einer errors.log gespeichert und es erscheint passende Benachrichtigung auf dem Desktop.

    Wer Interesse hat, darf das Script natürlich nach Belieben an die eigenen Bedürfnisse anpassen:

    Garantie, dass das Script immer funktioniert, gibt’s natürlich nicht - Verbesserungsvorschläge sind immer willkommen! ;)

    2. Oktober 2011

    Immer mal wieder reizt mich die Programmiersprache für Statistiken R. Um diesen Reiz dann auszuleben hab ich vor ein paar Monaten angefangen kleine Graphen für den zufallsbasierten Simulator ZRE zu bauen. Das Spiel “läuft” einfach 24/7 und schreibt für jedes geschehene Event Einträge in die Datenbank. Diese Einträge werte ich dann mit Hilfe von R aus.

    Dazu gibt es ein Skript. Nämlich zre.R (Ob das die Konvention bei R-Skriptnamen ist, kann ich nicht sagen ;) )

    #!/usr/bin/env Rscript
    
    ### General R-Script
    # MySQL
    library(RMySQL)
    con <- dbConnect(MySQL(), user="", password="", host="", client.flag=CLIENT_MULTI_RESULTS)
    # Style
    zre_colors <- colors()[grep("green",colors())]
    zre_mint <- colors()[c(48,86,50)]

    Im Klartext wird aus dem CRAN Library Verzeichnis die Library RMySQL includiert und die Verbindung in der Variable con abgelegt. Ähnlich wie bei PHP. Für alle Debian / Ubuntu Benutzer empfiehlt sich aber, die Library einfach über das Paketsystem nachzuinstallieren.

    $ aptitude install r-cran-rmysql

    Standardmäßig sehen Graphen die mit R erstellt werden ziemlich mau aus. Die weiteren Variablen unter Style habe ich gewählt um mir die Colorierung der Graphen etwas zu erleichtern. Diese werden später einfach als Attribute in den Plots/Barplots gesetzt und ausgewertet. Ich fange einfach mal der Reihe nach an:

    Die Abfolge ist immer ziemlich ähnlich. Zu aller Erst wird der Query für die Datenbank an die Variable sql übergeben. Diese Variable wiederrum wird zusammen mit der Connection an die Funktion dbGetQuery übergeben und das Ergebnis dessen schliesslich in zre_wins gespeichert. Anschliessend ein paar kleine Informationen an das Dateiformat übergeben und den Graphen bauen.

    Die Funktion par lässt sich erstmal als eine Art Environment Funktion für Graphen verstehen. Hier werden Eigenschaften wie Schriftfarbe, Hintergrund, Axenfarbe, und Liniendicke definiert. Danach kommt (wie ich finde) der schwierigste Teil. Bauen des Graphen. Je nach Art des Graphen (Balken, Linien, Torte u.ä.) werden logischerweise verschiedene Parameter erwartet. Die Daten werden hierbei jetzt als Matrix an ein Balkendiagram übergeben. Weitere Informationen wie die Überschrift (main) und die Beschreibung der Balken (names.arg) werden einfach angefügt.

    # Graph: Wins

    sql <- paste("SELECT COUNT(id) AS sum, side FROM zombies.zre_wins GROUP BY side;")
    zre_wins <- dbGetQuery(con, sql)
    png(file="wins.png", width=400, height=400)
    par(col="white", bg="transparent", col.axis="white", col.lab="white", col.main="white", lwd=2)
    barplot(as.matrix(zre_wins$sum), main="Game Summary", names.arg=c(zre_wins$side), beside=TRUE, col=zre_mint)

    Selbes Spiel wieder, nur mit mehr Balken und anderem Use-Case. Diesmal werden die 25 Konflikte mit den meisten Opfern visualisiert.

    # Graph: Highest Kills

    sql <- paste("SELECT id, kills FROM zombies.zre_kills ORDER BY kills DESC LIMIT 25;")
    zre_matches_highest <- dbGetQuery(con,sql)
    png(file="highestkills.png", width = 400, height = 400, bg="transparent")
    par(col="white", bg="transparent", col.axis="white", col.lab="white", col.main="white", lwd=4)
    barplot(zre_matches_highest$kills, zre_matches_highest$id, main="25 Highest Kills", beside = TRUE, ylab="Kills", col=zre_colors)

    Aber da Balkendiagramme auch irgendwann Langweilig werden geht das natürlich auch anders. Die 25 letzten Konflikte werden im “Opferverlauf” wie folgt dargestellt:

    # Graph: Kills

    sql <- paste("SELECT kills FROM zombies.zre_kills ORDER BY id DESC limit 25;")
    zre_kills <- dbGetQuery(con,sql)
    yrange <- range(zre_kills$kills)
    xrange <- length(zre_kills$kills)
    png(file="kills.png", width=400, height=400, bg="transparent")
    par(col="white", bg="transparent", col.axis="white", col.lab="white", col.main="white", lwd=4)
    plot(zre_kills$kills, xlab="Games", type="b", ylab="Kills", main="Kills from last 25 Attacks", col=zre_mint)

    Damit es nicht immer nur um Tote geht, auch mal was erfreuliches. Die Geburtenrate in ZRE steigt! :)

    # Graph: BirthRate

    sql <- paste("SELECT Month(date) AS month, count(id) AS born FROM (SELECT *, Month(date) AS M FROM zombies.zre_born) t Group by M; ")
    zre_birthrate <- dbGetQuery(con,sql)
    png(file="birthrate.png", width=400, height=400)
    par(col="white", bg="transparent", col.axis="white", col.lab="white", col.main="white", lwd=3)
    barplot(zre_birthrate$born, xlab="Month", ylab="Born Humans/Zombies", names.arg=c(zre_birthrate$month),main="BirthRate per Month", col=zre_colors)

    Und auch das Wetter soll bei der ganzen Sache nicht zu kurz kommen. Hierbei bitte besonderes Augenmerk auf die Legende rechts oben. Eine direkte Zuordnung der Werte und Farben ist nicht nötig, da die Farben in der selben Reihenfolge von zre_colors befüllt werden wie die Balken. Die erschreckend hohe Zahl an Naturkatastrophen erklärt das aber trotzdem nicht :)

    # Graph: Weather
    sql <- paste("SELECT COUNT(id) AS count, weather FROM zombies.zre_weather GROUP BY weather ORDER BY count DESC;")
    zre_weather <- dbGetQuery(con,sql)
    png(file="weather.png", width=400, height=400)
    par(col="white", bg="transparent", col.axis="white", col.lab="white", col.main="white", lwd=2)
    barplot(zre_weather[,1], main="Weather in ZRE", beside = TRUE, col=zre_colors)
    legend( 5, 40000, zre_weather$weather, cex=0.9, fill=zre_colors, col="white")

    Das volle zre.R Skript befindet sich wie das meiste auf Github: https://gist.github.com/1031260

    Ich selbst habe seit heute GNOME 3.2 (Arch machts möglich) auf meinem Desktop. Aktuell spiele ich etwas mit der neu eingeführten Integration von Webapplikationen.

    Was mir allerdings dabei nicht gefällt ist der kleine Ausschnitt welcher als Icon für den Starter verwendet wird. Genau gesagt finde ich den richtig hässlich, den oft ist in der oberen linken Ecke nur selten etwas aussagekräftiges versteckt. Auf der anderen Seite habe ich für Starter generell lieber Tango Icons, es soll ja alles schön einheitlich sein.

    Über das Menü kann man das Icon dieser Starter aber nicht verändern, daher folgender weg:

    1. Mit cd ~/.gnome2/epiphany/ in das Konfigurationsverzeichnis von Epiphany wechseln.
    2. Dann mal (z.B. mit ls) schauen welchen Ordner Epiphany für eine bestimmte Webapplikation verwendet hat, in der Regel ist es der Name des Starters klein geschrieben und dann noch eine Art Hash am Ende des Dateinamens.
    3. cd ordnername wechselt nun in den Ordner dieses starters.
    4. Und zum Schluss kann mit ln -f -s /pfad/zum/icon.png app-icon.png das Icon gegen das gewünschte ausgetauscht werden.
    Ich verwende bewusst nur einen Link für das Icon, wer möchte kann natürlich auch einfach eine Kopie vom Icon erzeugen.

    Das Icon muss im PNG Format vorliegen, und sollte eine Größe von 128x128 Pixeln haben. Wenn man das Icon getauscht hat muss man noch die GNOME Shell neu starten, das geht ganz einfach mit ALT-F2 und dem Befehl restart.

    Nachtrag: Man kann das Icon auch in der .desktop Datei im jeweiligen Ordner ändern, das erzielt den gleichen Effekt.

    Ich selbst habe seit heute GNOME 3.2 (Arch machts möglich) auf meinem Desktop. Aktuell spiele ich etwas mit der neu eingeführten Integration von Webapplikationen.

    Was mir allerdings dabei nicht gefällt ist der kleine Ausschnitt welcher als Icon für den Starter verwendet wird. Genau gesagt finde ich den richtig hässlich, den oft ist in der oberen linken Ecke nur selten etwas aussagekräftiges versteckt. Auf der anderen Seite habe ich für Starter generell lieber Tango Icons, es soll ja alles schön einheitlich sein.

    Über das Menü kann man das Icon dieser Starter aber nicht verändern, daher folgender weg:

    1. Mit cd ~/.gnome2/epiphany/ in das Konfigurationsverzeichnis von Epiphany wechseln.
    2. Dann mal (z.B. mit ls) schauen welchen Ordner Epiphany für eine bestimmte Webapplikation verwendet hat, in der Regel ist es der Name des Starters klein geschrieben und dann noch eine Art Hash am Ende des Dateinamens.
    3. cd ordnername wechselt nun in den Ordner dieses starters.
    4. Und zum Schluss kann mit ln -f -s /pfad/zum/icon.png app-icon.png das Icon gegen das gewünschte ausgetauscht werden.
    Ich verwende bewusst nur einen Link für das Icon, wer möchte kann natürlich auch einfach eine Kopie vom Icon erzeugen.

    Das Icon muss im PNG Format vorliegen, und sollte eine Größe von 128x128 Pixeln haben. Wenn man das Icon getauscht hat muss man noch die GNOME Shell neu starten, das geht ganz einfach mit ALT-F2 und dem Befehl restart.

    Nachtrag: Man kann das Icon auch in der .desktop Datei im jeweiligen Ordner ändern, das erzielt den gleichen Effekt.

    Man glaubt es kaum, aber es gibt einige Sachen, die unter Ubuntu nicht perfekt implementiert sind. Manchmal sind andere Systeme besser ;-) . Die parallele Unterstützung von Prozessor-Architekturen auf einem System zum Beispiel. Einige Architekturen, wie x86_64, sind in der Lage, über einen Kompatibilitätsmodus alte x86-Programme auszuführen, ohne das eine Neuübersetzung erforderlich wäre. Andere, wie Itanium, schaffen das zumindest durch Hardware-Emulation.

    Jedoch muss auch das Betriebssystem dieses Feature unterstützen. Windows kann es, Mac OS X kann es, und Ubuntu kann es eigentlich auch. Allerdings war es unter Ubuntu (und unter Debian, allgemein mit dpkg) bisher nicht sehr einfach, ein für x86 gedachtes Paket einfach so unter x86_64 zu installieren. Nun, wenn es nur *ein* Paket war, dann konnte man es mit der Option –force-architecture trotzdem installieren. Aber normalerweise hängen Pakete von anderen Paketen ab (z.B shared libraries), und ein 32-Bit-Programm benötigt natürlich 32-Bit-Bibliotheken. Die restlichen 64-Bit-Programme benötigt aber 64-Bit-Bibliotheken, womit man von einigen Bibliotheken beide Varianten installieren müsste. Dies gibt sowohl auf der Ebene des Dateisystems als auch auf der des Paketmanagers Probleme.

    In der Vergangenheit gab es mehrere Hacks, um dieses Problem zu umgehen. Manche richteten sich ein 32-Bit-chroot ein und ließen ihre 32-Bit Software darin laufen. Die Maintainer paketierten 32-Bit-Bibliotheken für 64-Bit-Systeme, etwa in dem Sammelpaket ia32-libs (oder einzelne lib32*-Pakete), die an andere Orte wie /lib32 und /usr/lib32 installiert wurden. Die – meist proprietären – 32-Bit-Anwendungen wurden dann ebenfalls neu paketiert, um diese Bibliotheken nutzen zu können. Für Browser-Plugins wie Flash wurden Wrapper geschrieben, um 32-Bit-Plugins in einem 64-Bit-Browser benutzen zu können. Aber eine richtige Lösung war das nicht.

    Unter Windows war es noch nie ein Problem, 32-Bit-Anwendungen unter 64-Bit-Windows zu installieren. Das ist sogar eher die Regel als die Ausnahme, Software-Hersteller beschäftigen sich nur mit 64-Bit, wenn es signifikante Vorteile bringt, ansonsten wäre es nur sinnlose Ressourcen-Verschwendung, die Anwendung läuft auch als 32-Bit-Binary unter 64-Bit. Man installiert die Anwendung einfach, ohne sich um die Architektur zu kümmern. Und Apple? Die haben schon mehrere Architekturwechsel hinter sich, von 68k auf PowerPC, x86 und schließlich x86_64. Durch Emulation (getauft Rosetta) konnte man die alten Anwendungen auf der neuen Architektur weiterverwenden, sogar Code für mehrere Architekturen in einer Datei verpacken.

    Unter Debian und Ubuntu wird all das jetzt mit dem neuen Multiarch-Support möglich. Ab Ubuntu Oneiric und Debian Wheezy wird er mit dabei sein. Multiarch ermöglicht es, Anwendungen und Bibliotheken zu installieren, die für eine Architektur gebaut wurden, die entweder als Fallback von der eigenen Architektur oder von einem Emulator (wie QEMU) unterstützt wird.

    Auf Dateisystem-Ebene bedeutet das: Bibliotheken werden nicht mehr einfach nach /lib bzw. /usr/lib installiert, sondern mit architekturspezifischen Präfixen, etwa /lib/i386-linux-gnu oder /usr/lib/x86_64-linux-gnu – gleiches gilt für Header-Dateien. Dadurch kommen sich die Bibliotheken nicht mehr in Konflikt und können parallel existieren. /lib/32, /usr/lib32, /lib64 und /usr/lib64 fallen weg. Anwendungen, Build-Systeme und Compiler müssen natürlich diese Features unterstützen.

    Auch der Paketmanager muss gleichzeitig Pakete mehrerer Architekturen verwalten können. Im Augenblick kann in der Datei /etc/dpkg/dpkg-cfg.d/multiarch eingestellt werden, welche Architekturen neben der Nativen berücksichtet werden sollen. Synaptic zeigt dann die fremden Pakete nach dem Schema <paketname>:<architekturname>, also zum Beispiel adobe-flashplugin:i386 an. Das Software-Center von Ubuntu zeigt jedes Programm nur einmal an und nimmt die native Variante wenn möglich, ansonsten eben das architekturfremde Paket.

    In den Meta-Daten der Pakete kann über die Option Multi-Arch angegeben werden, wie es sich auf fremden Architekturen verhalten soll.

    • same bedeutet, dass es mit Multiarch kompatibel ist und parallel zum nativen Paket installiert werden kann (z.B Bibliotheken),
    • foreign heißt, dass das Paket nicht parallel installiert werden kann (z.B Systemdienste oder auch ausführbare Programme)
    • und allowed meint, dass ein architekturfremdes Paket davon abhängen darf.

    Aber die ganze Sache hat auch Nachteile. Zum einen ist der Multiarch-Support noch nicht standardisiert und eine reine Debian/Ubuntu-Geschichte. Ob andere Distributionen mitmachen, die mitunter schon eigene Lösungen haben, bleibt abzuwarten. Zum anderen fördert die Multiarch-Unterstützung das Verharren auf alten Architekturen, wie man das unter Windows beobachten kann. Viele Software gibt es nur als 32-Bit, weil das ja auch auf 64-Bit läuft. Damit muss man letztendlich noch ein halbes 32-Bit-System mitinstallieren und im Arbeitspeicher halten, mit reinen 64-Bit-Anwendungen entfällt dieser Schritt komplett.

    Außerdem ist das Thema langsam gegessen. Denn die Nicht-Verfügbarkeit von 32-Bit-Software unter 64-Bit hat dazu beigetragen, dass fast jedes Linux-Programm auch als 64-Bit verfügbar ist. Bei Open-Source-Programmen sowieso; den Firefox zum Beispiel gab es lange für 64-Bit-Linux, schon bevor Mozilla vor kurzem angefangen hat, selbst 64-Bit-Binaries bereitzustellen. Proprietäre Anwendungen gibt es auch nur noch wenige, die nicht für 64-Bit verfügbar sind, wie etwa Flash. Aber auch hier hat Adobe vor, mit Version 11 64-Bit Support einzuführen.

    Den Vorteil von Multiarch sehe ich in Cross-Compilation in Kombination mit QEMU. So wird etwa das Erstellen von Binaries für ARM unter einem leistungsfähigen x86_64 -System transparent und out-of-the-box möglich sein, anschließend ließe sich das Kompilat mittels QEMU gleich ausprobieren.

    Und was ändert sich für den normalen Nutzer? Nur, dass er keine Fehlermeldung mehr kriegt, wenn er versucht, ein 32-Bit-Programm unter seinem 64-Bit-System zu installieren – es funktioniert einfach.

    Bis es soweit ist, muss noch ein weiter Weg gegangen werden – schließlich bedeutet Multiarch eine radikale Umstellung des Dateisystems und die Konvertierung von vielen Paketen, sowie möglicherweise Kompatibilitätsprobleme mit älteren Distributionsversionen und anderen Distributionen.


    Da sind sie nun – fast überall. Die SMP Systeme (Multicore Systeme). Und zu ihnen gesellen sich auch immer mehr Programme, die mehrere CPUs nutzen können … also Multithreaded sind. Und ein altbekanntes Problem.

    Lang her

    Wenn “damals” ein Prozess ein wenig “überschwenglich” war und durch ein Problem (z.B.) die ganze Leistung des Systems an sich gezogen hat, dann waren das so 100% und die Kiste war tot. Je nach dem.

    nicht sooo lang her

    Dann kamen die Multicore Systeme und unser Prozess konnte nicht mehr das ganze System lamlegen – Juhuuu. Man konnte sich also wenigstens noch anmelden und den Prozess killen.

    Heute

    Tja, heute sind wir wieder bei damals. Die Multicoresysteme werden von Multithreaded Prozessen an die Wand gefahren. Toll. Ein Prozess mit 400% CPU usage ;-)

    Kann man da was tun?

    Aber sicher doch. So viel man sich freut, dass das ein oder andere Programm nun mehrere Cores nutzt, so wenig brauchen viele der Programme das. Oder sagen wir mal so: Die meisten kommen auch mit 3 von 4 CPUs aus. Was mache ich also wenn ich einen Prozess habe, der so manches Mal die Kiste herunterzieht? Ich weise ihm einfach nur noch 3 der 4 CPUs zu und kann somit noch mit einer meine Anmeldung vollziehen.

    Unser Freund zur Umsetzung dieses gewieften Planes heißt “taskset” (man taskset).

    Grundsätzlich benötigt man lediglich 2 Informationen:

    • Anzahl CPUs im System
    • Anzahl CPUs die man zuweisen möchte
    • ProzessID (PID) (bei einem vorhanden Prozess, ansonsten kann ein Prozess auch mit taskset gestartet werden)

    CPUs

    Die CPUs werden mit Hilfe einer Bitmask definiert.

    CPU1 -> 0x00000001
    CPU2 -> 0x00000002
    CPU3 -> 0x00000004
    CPU4 -> 0x00000008
    ...

    Möchte man eine CPU zuweisen (CPU MASK), so wird einfach die 2 für die CPU2 genommen.

    xCPUs

    Möchte man mehrere CPUs zuweisen, so werden diese einfach addiert (HEX!). Alle 4 CPUs wären somit “f”. CPU2 und CPU3 wäre “6″ und so weiter …

    Nägel mit Köpfen

    Um die CPU “Affinity” eines vorhandenen Prozesses zu setzen, nutzt man folgenden Befehl:

    taskset -p <CPU MASK> <PID>

    Bei Programmaufruf:

    taskset <CPU MASK> <CMD>

     

     

     

    1. Oktober 2011

    In der letzten Folge von mobileMacs bin ich auf Sublime Text 2 aufmerksam geworden, einen wirklich schönen (den Ruf haben crossplatform Programme ja meist nicht…) und sehr konfigurierbaren Texteditor. Bisher hatte ich für die Entwicklung meiner webOS-Apps immer Komodo Edit im Einsatz, doch es war an der Zeit, mal einen neuen Editor auszuprobieren. Bisher habe ich den Wechsel nicht bereut, im Gegenteil: die Arbeit macht mit diesem schicken Editor viel Freude!

    Installiert habe ich Sublime Text 2 über folgendes PPA:

    sudo add-apt-repository ppa:webupd8team/sublime-text-2
    sudo apt-get update
    sudo apt-get install sublime-text-2

    Sublime Text bringt von Haus aus keine Code-Validation für Javascript mit, allerdings gibt es ein Plugin, womit sich dieses Feature nachrüsten lässt. Dazu muss man allerdings zuerst noch eine Erweiterung installieren: Sublime Package Control. Ist dieser Schritt getan, kann man nun das Plugin bequem über die Sublime Paketverwaltung installieren. Dazu öffnet man die Command Palette (STRG+SHIFT+P) und wählt den Eintrag: ”Package Control: Install Package”. Im nächsten Schritt kann man nun SublimeLinter (“sublimelint”) installieren.

    Achtung: Damit Sublime Linter auch funktioniert, muss node.js installiert sein!

    Für mein derzeitiges webOS-Projekt (BibleZ HD) habe ich ein kleines Script geschrieben, welches das Plugin compiliert (BibleZ HD is eine Hybrid-App) und anschließend “palm-run” aufruft, womit die App auf das Gerät/Emulator gepackt wird und automatisch die Logs ausgegeben werden. Sublime Text 2 besitzt sogenannte Build-Systems, d.h. man kann für bestimmte Dateitypen oder Projekte kleine Scripte angeben, welche dann das Projekt compilieren oder einzelne Dateien übersetzen (Coffee-Script o.ä.).

    Über Tools → Build System → New Build System… kann man nun sein Script angeben. Hier ein Beispiel, wie ich mein Shell-Script eingebunden habe (das Skript habe ich vorher ausführbar gemacht):

    { "cmd": ["/path/to/my/File.sh"], "path": "/usr/bin:/usr/local/bin:/bin" }

    Nun kann man bequem mit STRG+B bzw. F7 das Skript starten und den Logs in einer kleinen Console am Bildschirmrand folgen!

    Ich finde Sublime Text 2 sehr gelungen und werde es definitiv noch weiter einsetzen!

    2 Kommentare

    Führt man in den Ubuntu-Natty-Quellen ein Update von Firefox aus, wird standardmäßig auf meinem System keine deutsche Sprachdatei mitgeliefert und ich erhalte einen englischen Firefox in (momentan) Version 7.0.1. Dieses Problem existiert schon seit maverick, obwohl ich das Paket firefox-locale-de installiert habe.

    Die Sprachdatei liegt jedoch als .xpi-Datei (Firefox-Erweiterung) auf den ftp-Servern von Mozilla und lässt sich mit ein paar Klicks nachinstallieren. Dazu reicht es aus, den Link https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest-7.0/linux-i686/xpi/de.xpi (32bit) bzw. https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest-7.0/linux-x86_64/xpi/ (64bit) aufzurufen und die erscheinende Sicherheitsabfrage (siehe Screenshot) mit “Allow” zu bestätigen.Nach einem Neustart ist die Sprachdatei installiert.

    Hinweis: Analog zu Firefox lässt sich auch Thunderbird über diesen Weg “eindeutschen”. Der Pfad zur deutschen Sprachdatei lautet für die aktuelle Version der 7er-Reihe https://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/latest-7.0/linux-i686/xpi/de.xpi (32bit) bzw. https://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/latest-7.0/linux-x86_64/xpi/de.xpi (64bit). Hierbei ist jedoch zu beachten, dass man die Sprachdatei erst herunterladen muss und per “Install Add-on from file” im Thunderbird-Menü die Erweiterung installieren muss.

    30. September 2011

    Ich habe ja schon einige male einen Browser-Test im Blog beschrieben, und jetzt habe ich einen der letzten Tests durchgeführt.

    Der Firefox mit der Version 7 ist in den letzten Tagen für mein Ubuntu 11.04 heraus gekommen. Wie immer habe ich vor dem Update aber noch den Paecekeeper Test mit dem Firefox 6 gemacht, damit ich einen Vergleich habe. Peacekeeper hat sich nun auch einen neuen Speedtest angelegt und den habe ich auch ausprobiert. Der Speedtest geht etwa gleich lang wie vorher. Die Bilder und inhaltlichen Tests sind etwas erweitert worden.

    Für mich eigentlich nicht verwunderlich ist die Tatsache, dass sich beim Feuerfuchs im Sinne der Geschwindigkeit nichts getan hat. Ich hatte ja schon in den früheren Test immer den Eindruck, dass der Chromium immer schneller war als der Feuerfuchs und ich denke das hat sich mit dem neuen Peacekeeper Test auch wieder bewahrheitet. Für mich ist das weiter nicht so schlimm, denn ich benutze den Feuerfuchs nur als Backup Browser und damit fällt mir die Geschwindigkeit nicht so auf. Zu bemerken ist noch, dass der neue Peacekeeper Test eine Beta ist.

    Fazit

    Ich bleibe bei meinem Chromium Browser was die Geschwindigkeit betrifft. Wer weiss, vielleicht zündet der Feuerfuchs ja doch einmal den Turbo.

     

     

    PDF-Datei dieses Artikels erzeugen

    Ähnliche Artikel

    • Keine ähnlichen Artikel vorhanden

    Nachdem ich schon wieder darauf angesprochen wurde wie man eine Bildschirmleiste, für einen zweiten Monitor, inklusive Fensterleiste anlegt, hab ich mich entschlossen eine Anleitung dazu zu schreiben. Das ganze ist nicht weiter kompliziert, man muss eben nur mal wieder wissen wie es geht.


     
    Um ein neue Bildschirmleiste (Panel) anzulegen, klickt man mit der rechten Maustaste auf das vorhandene Panel und wählt “Panel anlegen” aus. Nun erscheint am rechten Bildschirmrand ein neues Panel, das wir ebenso mit der rechten Maustaste anklicken und “Eigenschaften” auswählen. Im folgenden Fenster nehmen wir folgende Änderungen vor:
    - “Ausrichtung” auf “Unten” stellen, dies sorgt dafür, dass die Leiste am unteren Bildschirmrand positioniert wird.
    - Der Haken des Punktes “Ausdehnen” wird entfernt, da sich das Panel sonst nicht verschieben lässt.
    - Alternativ lässt sich die Leite auch auch mit + verschieben (Danke an Christoph für den Tipp)
     

     
    Das verkleinerte Panel kann jetzt per Drag & Drop auf den 2. Bildschirm gezogen werden. Anschließend klicken wir mit der rechten Maustaste auf das Panel, gehen erneut auf “Eigenschaften” und setzen den Haken bei “Ausdehnen” wieder. Nach dem Schließen haben wir jetzt das Panel über die komplette Bildschirmbreite.
     
    Nun fehlt nur noch die Fensterliste, damit geöffnete Fenster auch in der Leiste angezeigt werden. Hierzu klicken wir mit der rechten Maustaste wieder auf das Panel und wählen “Zum Panel hinzufügen …” aus. Im folgenden Fenster wählen wir den Menüpunkt “Fensterliste” aus und gehen auf “Hinzufügen”.
     

     
    Als letzten Punkt muss nur noch die “Fensterliste” per Drag & Drop an die gewünschte Position verschoben werden.
     
    Anleitung wurde unter Ubuntu 10.04 mit Gnome 2.30.2 erstellt
     
    Fazit: Mit dieser kurzen Anleitungen, lassen sich beliebig viele Panels oder Objekte zum Panel hinzufügen.
     
    Klar soweit?
    Euer RSB

    Ups, eine Hardware-Kleinigkeit hab ich doch glatt vergessen :-( Wir möchten doch auch Mobil telefonieren!

    WLAN oder DECT?

    Zuerst einmal muss man sich entscheiden welche Technologie man einsetzen möchte. Es gibt WLAN Mobiltelefone – mittlerweile sogar von AVM – welche dann direkt per WLAN mit dem Asterisk kommunizieren und sich registrieren. Auf der anderen Seite gibt es auch DECT für VoIP. Wo liegt nun der Unterschied bzw. Nachteile und Vorteile??

    Mit WLAN wird jeder so seine Erfahrungen gemacht haben. WLAN ist nur relativ zuverlässig was die Geschwindigkeit und auch den Empfang angeht. Je weniger Empfangsstärke man hat, desto weiter geht die Übertragungsrate runter. Das ist ein Problem dabei. Das könnte man natürlich durch einen Haufen Sender in den Griff bekommen. Das andere Problem ist die Latenz. WLAN ist nicht für Echtzeitkommunikation gedacht und dem entsprechend bringt das auch Probleme beim VoIP Betrieb mit sich. Ein weiterer Aspekt: Die Geräte sind zur Zeit noch relativ teuer.

    DECT ist seit vielen Jahren der Standard für Mobile Analogtelefone. Die Reichweite einer einzelnen Basisstation ist gut und man bekommt viele verschiedene Telefone von vielen Herstellern. Die Telefone sind auch von der Benutzung her fast jedem bekannt und müssen nicht groß erklärt werden. (Ich weiß gerade nicht so recht was ich noch zu DECT schreiben soll !?!)

    Da WLAN für uns aus oben genannten Gründen und auch aus Erfahrungsberichten heraus nicht zur Diskussion stand, haben wir und für DECT entschieden.

    Auch da gibt es was von Ratiopharm

    Naja, nicht ganz ;-) Wie bildet man eine Schnittstelle zu Mobilteilen von der Asterisk Anlage ab?

    Die LowCost Lösung wäre einfach ein ganz normales Mobiltelefon an einen analogen Port an eines der Patton Gateways anzuschließen. Das ist auch in Ordnung, wenn man nur ein paar Mobilteile hat und auch von der größe des Gebäudes auf Roaming (wenn die Reichweite einer Basisstation nicht das ganze Gebäude abdeckt) verzichten kann.

    Muss man jedoch ein größeres Gebäude versorgen, so macht das mit den Pattons keinen Sinn. Erstens zu teuer und zweitens benötigt man dann die Roaming Funktionalität. Man kommt also um eine professionelle Lösung nicht herum. Ich habe mich bei einer solchen Basisstation für die “Aastra RFP L32IP” entschieden. Jede Basisstation kann bis zu 8 SIP Gespräche gleichzeitig handeln, bis zu 4096 Telefone verwalten ( :D ) und Cluster mit weiteren Basisstationen dieser Art bilden. Durch die Clusterbildung kann man große Gebäude in jeder Ecke ohne Probleme ausleuchten. Die Konfiguration der Geräte ist einerseits total kompliziert (wenn man nicht weiß wie diese Dinger ticken), andererseits jedoch vollkommen lapidar. Darauf werde ich in dieser Reihe definitiv noch eingehen!!

    Fazit: Wir nutzen auch für DECT quasi Gateways, die für uns VoIP in DECT umwandeln und uns so in die Lage versetzen ganz normale Mobilteile an der Asterisk zu nutzen.

    29. September 2011

    Nach langer Zeit komme ich mal wieder dazu was zu schreiben. Diesmal stand bei mir ein größerer Umbau an meinem Fileserver an.

    Und zwar wollte ich aus meinem Raid5 mit 3 Platten ein Raid10 mit 4 Platten machen (wegen der höheren Geschwindigkeit) und meine Raid Partition verschlüsseln.

    Das Verschlüsseln bzw. eigentlich das entschlüsseln stellte die größte Herausforderung dar, da mein Server jeden Tag an und ausgeschalten wird. Das heißt ich müsste normalerweise Bildschirm und Tastatur anschließen und jedes mal am Server das Passwort zum Entschlüsseln eingeben – das ist viel zu umständlich.

    Ich habe mir ein kleines Script geschrieben, das ich auf alle Clienten verteilt und dort in den Autostart nach dem Anmelden gelegt habe.

    Und hier ist das Script:


    #!/bin/sh
    # Decrypting NFS Partition
    if [ -z "$(ssh -t server_sudoers@server 'if mount|grep -q "on /crypto type"; then echo mounted; fi')" ]
    then
    ssh -t server_sudoers@server "echo $(zenity --entry --hide-text --text 'Bitte Passwort zum Entschlüsseln eingeben')|sudo cryptsetup luksOpen /dev/md0 crypto && sudo mount /dev/mapper/crypto /crypto && sudo mount --bind /crypto /nfsexports/crypto;"
    fi
    # Mounts
    sudo mount -t nfs4 server:/crypto/multimedia /home/multimedia

    Der Benutzer server_sudoers ist auf dem Server ein extra Benutzer, mit dem man sich per ssh Schlüsseldatei anmelden kann (also ohne Passworteingabe). Die Schlüssel wurden auf alle Clienten verteilt. Dann kann dieser Benutzer per sudo die mount und cryptsetup Befehle ohne Passwort ausführen (editieren der /etc/sudoers).

    In der ersten Zeile wird eine ssh Verbindung zum Server aufgebaut und geschaut, ob die verschlüsselte Partition schon entschlüsselt und gemountet wurde (also ein anderer Client das schon getan hat). Ist dies der Fall wird einfach nur noch das im System gemountet, was der Benutzer auf dem Fileserver benötigt.

    Ist die Platte noch nicht entschlüsselt, wird eine grafische Passwortabfrage ausgeführt (Zenity muss auf allen Clienten installiert sein, was mit Ubuntu im Normalfall schon in der Standardinstallation der Fall ist) und diese direkt an das Programm cryptsetup übergeben.

    War das Entschlüsseln erfolgreich, wird das entschlüsselte Laufwerk gemountet. Der nächste Mount Befehl sorgt dafür, dass die entschlüsselte Partition in die NFS 4 Freigaben gemountet wird.

    Als letztes werden dann auch hier die gewünschten Ordner auf dem Client per NFS gemountet.

    Wie ich finde erheblich komfortabler als alle Lösungen, die ich bisher im Internet gefunden habe (nur EIN Passwort muss eingegeben werden, grafische Abfrage des Passwortes und auch nur dann, wenn entschlüsselt werden muss). Und die verschlüsselte Partition ist sicher (keine Schlüsseldatei auf einem USB Stick oä).

    Merkwürdig. Ohne mir ersichtlichen Grund war plötzlich kein Sound mehr da. Es ist eine ganz normale Debian Squeeze Installation, ohne extra Quellen.

    Kernel: vmlinuz-2.6.32-5-amd64

    Audio device:

    ATI Technologies Inc SBx00 Azalia (Intel HDA) (rev 40)

    nVidia Corporation GF104 High Definition Audio Controller (rev a1)

    mit aplay -l wurde nur eins angezeigt. (gerade nicht verfügbar)

    Die module waren:

    snd_hda_codec_via      47887  1 
    snd_hda_intel          20035  1 
    snd_hda_codec          54244  2 snd_hda_codec_via,snd_hda_intel
    snd_hwdep               5380  1 snd_hda_codec
    snd_pcm                60503  2 snd_hda_intel,snd_hda_codec
    snd_seq                42881  0 
    snd_timer              15582  2 snd_pcm,snd_seq
    snd_seq_device          4493  1 snd_seq
    snd                    46526  10
    snd_hda_codec_via,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_seq,snd_timer,snd_seq_device
    soundcore               4598  1 snd

    Sind das nicht ein wenig mehr als üblich?

    Ich habe eine Weile mit den Optionen von Alsactl rumgespielt, ohne Erfolg. Dann habe ich pulseaudio nachinstalliert, was aber keine Verbesserung gebracht hat.

    Doch dann fand ich die Einstellung "Virtuelles Ausgabegerät zur simultanen Wiedergabe auf allen Soundkarten zur Verfügung stellen". Nun geht es wieder.

    Irgendwie merkwürdig, habe ich wirklich zwei Audio Devices? muss ich wohl noch mal genauer mein Mainboard ansehen und forschen, aber ich weiß momentan nicht mal, was für eins ich habe.

    Eine Minecraftkarte hat schon einige Vorteile wenn man größere Gebäude oder ähnliches bauen möchte. Eine schöne Anwendung dazu ist der Minecraft Overviewer, welcher auch auf einem Ubuntu Server läuft.

    Im ersten Schritt sollte man sich den Minecraft Overviewer mittels:

    git clone https://github.com/overviewer/Minecraft-Overviewer.git

    auf den Server holen. Nun installieren wir einige Abhängigkeiten um das c_overviewer Modul zu kompilieren. Dies geschieht mittels:

    apt-get install build-essential python2.6 python2.6-dev python-imaging python-numpy

    und

    cs Minecraft-Overviewer
    python setup.py build

    Der Minecraft Overviewer benötigt eine terrain.png Datei. Diese kann aus der minecraft.jar extrahiert (z.B. mittels 7-Zip) werden und sollte in den Minecraft-Overviewer Ordner kopiert werden. Nun kann man eine Karte erzeugen:

    ./overviewer.py ../world/ ../mcmap/

    Schöner ist es natürlich wenn das ein Skript macht, welches die ganzen Dateien auch noch auf einen FTP Server hochlädt. Dazu installieren wir lftp:

    apt-get install lftp

    Nun erstellen wir noch eine Datei namens updatemap.sh mit folgendem Inhalt:

    #!/bin/bash
    
    #Karte erstellen
    cd Minecraft-Overviewer
    ./overviewer.py ../world/ ../mcmap/
    cd ..
    
    #Daten hochladen
    lftp -e "mirror -R mcmap /" -u nutzer,password example.com

    Dieses Skript muss nur regelmäßig angestartet werden und schon bleibt die Karte aktuell :)

    Weitere Informationen gibt es unter:
    https://github.com/overviewer/Minecraft-Overviewer/wiki/Running-Overviewer-on-a-Server
    http://www.wulkau.de/2011/04/09/howto-minecraft-overviewer-karte-erstellen/
    https://github.com/overviewer/Minecraft-Overviewer/wiki/Missing-terrain.png
    https://github.com/overviewer/Minecraft-Overviewer/wiki/Map-examples

    28. September 2011

    Ich wollte wissen wieviel Speicher (RAM) und belegte Slots ich in meinem Rechner habe und war zu faul den Rechner extra aufzuschrauben. Und Linux wäre nicht Linux, wenn es nicht dafür auch wieder ein kleines Tool namens dmidecode gibt.

    Ein beherztes dmidecode –help bewirkt folgende Ausgabe

    
    Usage: dmidecode [OPTIONS]
    Options are:
     -d, --dev-mem FILE     Read memory from device FILE (default: /dev/mem)
     -h, --help             Display this help text and exit
     -q, --quiet            Less verbose output
     -s, --string KEYWORD   Only display the value of the given DMI string
     -t, --type TYPE        Only display the entries of given type
     -u, --dump             Do not decode the entries
     -V, --version          Display the version and exit

    Wichtig für mich ist der Parameter -t. Denn als Typ versteht dmidecode:

      bios
      system
      baseboard
      chassis
      processor
      memory
      cache
      connector
      slot

    Und mit sudo dmidecode -t memory bekam ich dann die Info, dass ich ein 2GB Modul im 1. Steckplatz habe, dass der 2. Steckplatz leer ist und dass der Memory Controler maximal 8GB verwalten kann. Zusammengefasst (Ausgabe gekürzt) sieht das dann so aus:

    Memory Controller Information
            Supported Interleave: One-way Interleave
            Current Interleave: One-way Interleave
            Maximum Memory Module Size: 4096 MB
            Maximum Total Memory Size: 8192 MB
    
    Memory Device
            Size: 2048 MB
            Form Factor: SODIMM
            Locator: DIMM 1
            Bank Locator: Bank 0/1
            Type: DDR2
            Type Detail: Synchronous
            Speed: 667 MHz (1.5 ns)
    
    Memory Device
            Size: No Module Installed
            Form Factor: SODIMM
            Locator: DIMM 2
            Bank Locator: Bank 2/3
            Type: DDR2
            Type Detail: Synchronous
            Speed: 667 MHz (1.5 ns)
    

    Ich wollte wissen wieviel Speicher (RAM) und belegte Slots ich in meinem Rechner habe und war zu faul den Rechner extra aufzuschrauben. Und Linux wäre nicht Linux, wenn es nicht dafür auch wieder ein kleines Tool namens dmidecode gibt.

    Ein beherztes dmidecode –help bewirkt folgende Ausgabe

    
    Usage: dmidecode [OPTIONS]
    Options are:
     -d, --dev-mem FILE     Read memory from device FILE (default: /dev/mem)
     -h, --help             Display this help text and exit
     -q, --quiet            Less verbose output
     -s, --string KEYWORD   Only display the value of the given DMI string
     -t, --type TYPE        Only display the entries of given type
     -u, --dump             Do not decode the entries
     -V, --version          Display the version and exit

    Wichtig für mich ist der Parameter -t. Denn als Typ versteht dmidecode:

      bios
      system
      baseboard
      chassis
      processor
      memory
      cache
      connector
      slot

    Und mit sudo dmidecode -t memory bekam ich dann die Info, dass ich ein 2GB Modul im 1. Steckplatz habe, dass der 2. Steckplatz leer ist und dass der Memory Controler maximal 8GB verwalten kann. Zusammengefasst (Ausgabe gekürzt) sieht das dann so aus:

    Memory Controller Information
            Supported Interleave: One-way Interleave
            Current Interleave: One-way Interleave
            Maximum Memory Module Size: 4096 MB
            Maximum Total Memory Size: 8192 MB
    
    Memory Device
            Size: 2048 MB
            Form Factor: SODIMM
            Locator: DIMM 1
            Bank Locator: Bank 0/1
            Type: DDR2
            Type Detail: Synchronous
            Speed: 667 MHz (1.5 ns)
    
    Memory Device
            Size: No Module Installed
            Form Factor: SODIMM
            Locator: DIMM 2
            Bank Locator: Bank 2/3
    
    n        Type: DDR2
            Type Detail: Synchronous
            Speed: 667 MHz (1.5 ns)
    

    Ich wollte wissen wieviel Speicher (RAM) und belegte Slots ich in meinem Rechner habe und war zu faul den Rechner extra aufzuschrauben. Und Linux wäre nicht Linux, wenn es nicht dafür auch wieder ein kleines Tool namens dmidecode gibt.

    Ein beherztes dmidecode –help bewirkt folgende Ausgabe

    
    Usage: dmidecode [OPTIONS]
    Options are:
     -d, --dev-mem FILE     Read memory from device FILE (default: /dev/mem)
     -h, --help             Display this help text and exit
     -q, --quiet            Less verbose output
     -s, --string KEYWORD   Only display the value of the given DMI string
     -t, --type TYPE        Only display the entries of given type
     -u, --dump             Do not decode the entries
     -V, --version          Display the version and exit

    Wichtig für mich ist der Parameter -t. Denn als Typ versteht dmidecode:

      bios
      system
      baseboard
      chassis
      processor
      memory
      cache
      connector
      slot

    Und mit sudo dmidecode -t memory bekam ich dann die Info, dass ich ein 2GB Modul im 1. Steckplatz habe, dass der 2. Steckplatz leer ist und dass der Memory Controler maximal 8GB verwalten kann. Zusammengefasst (Ausgabe gekürzt) sieht das dann so aus:

    Memory Controller Information
            Supported Interleave: One-way Interleave
            Current Interleave: One-way Interleave
            Maximum Memory Module Size: 4096 MB
            Maximum Total Memory Size: 8192 MB
    
    Memory Device
            Size: 2048 MB
            Form Factor: SODIMM
            Locator: DIMM 1
            Bank Locator: Bank 0/1
            Type: DDR2
            Type Detail: Synchronous
            Speed: 667 MHz (1.5 ns)
    
    Memory Device
            Size: No Module Installed
            Form Factor: SODIMM
            Locator: DIMM 2
            Bank Locator: Bank 2/3
    
    n        Type: DDR2
            Type Detail: Synchronous
            Speed: 667 MHz (1.5 ns)