m4a Dateien in mp3 konvertieren mit ffmpeg unter Linux
Mit folgender Kommandozeile kann man mit ffmpeg m4a Sounddateien ins mp3 Format umwandeln:
find . -type f -name '*.m4a' -exec bash -c 'ffmpeg -i "$0" "${0/%m4a/mp3}"' '{}' \;
Mit find suchen wir uns erst mal alle m4a Dateien und für jede Datei wird eine neue Bash Shell gestartet. Diese startet ffmpeg, übergibt die gefundene Datei an ffmpeg als Input (-i). Dahinter wird die Zieldatei angegeben. Dabei ersetzen wir die Dateiendung m4a durch mp3.
Posted at 07:34nachm. Dez. 28, 2016 by cetixx in Tipps | Kommentare [0]
KDE Plasma Display Helligkeit (Display Brightness)
Wenn bei KDE Plasma mal wieder der Helligkeitsregler (Screen / Display brightness) versagt und genau nichts macht (was bei mir unter Archlinux ab und an passiert) und man auf das nächste Update wartet, kann man sich der weilen so behelfen, das man die Hintergrundbeleuchtung per Kommandozeile einstellt. Z.B.:
echo 700 > /sys/class/backlight/gmux_backlight/brightness
In meinem Fall steht hier gmux_backlight (MacBook Pro, der unter Linux läuft). Bei anderen muss man unter /sys/class/backlight/ einfach schauen, welche Backlights angezeigt werden (z.B. intel_backlight). Den aktuellen Wert kann man sich mit cat /sys/class/backlight/*/brightness ausgeben lassen. Für das gmux_backlight war der Wert bei mir bei 1023. Am Besten geht man in 100erter Schritten nach unten bis man die gewünschte Helligkeit eingestellt hat.
Posted at 08:44nachm. Nov. 07, 2016 by cetixx in Tipps | Kommentare [0]
Google Storage mit s3cmd und aws cli benutzen
Wenn man s3md mit Google Cloud Storage benutzen will, muss man in dessen Konfigurationsdatei .s3cfg Folgendes anpassen:
access_key = xxx
secret_key = xxx
host_base = storage.googleapis.com
host_bucket = %(bucket).storage.googleapis.com
xxx muss man natürlich durch seine entsprechenden Keys ersetzen, die man sich über die Google Console/UI (Storage -> Settings -> Interoperability) erstellen kann (nachdem man den interoperable access aktiviert hat natürlich). Diese Keys sind pro Projektmitglied und nicht pro Projekt (also jeder hat seinen eigenen Key).
Bei der AWS CLI (aws Kommando) konnte ich die Einstellungen in .aws/config irgendwie nicht nutzen. Hier half nur die Keys als Env. Variable zu setzen und den Endpoint zu ändern:
export AWS_ACCESS_KEY_ID=xxx
export AWS_SECRET_ACCESS_KEY=xxx
aws s3 --endpoint-url https://storage.googleapis.com ls
Auch hier natürlich xxx entsprechend ändern.
Posted at 09:59vorm. Okt. 20, 2016 by cetixx in Tipps | Kommentare [0]
Ersatz für KDE Quadkonsole
Bei KDE 4 hatte ich immer u.a. die KDE App Quadkonsole im Einsatz. Wird aber leider schon länger nicht mehr weiterentwickelt und unter Archlinux mit KDE Plasma 5 klappte das mit selber kompilieren auch nicht so wirklich. Als Ersatz habe ich Terminator gefunden, eine Konsole mit der man das Konsolenfenster in mehrere Teile splitten kann.
Posted at 01:25vorm. Sep. 08, 2015 by cetixx in Tipps | Kommentare [0]
Wo ist mein Speicherplatz hin?
cd /in/ein/verzeichnis
du -h . | grep -P '^[0-9\.]+G
Alternativ das Tool ncdu installieren...
Posted at 12:55vorm. Aug. 08, 2015 by cetixx in Tipps | Kommentare [0]
Gentoo - Alle installierten Pakete auflisten
equery list "*"
Posted at 12:55vorm. Aug. 08, 2015 by cetixx in Tipps | Kommentare [0]
Apache Mesos Testcluster für daheim
Was ist Mesos und Voraussetzungen
Ganz grob und einfach gesagt ist Apache Mesos ein "verteiltes Betriebssystem für Datenzentren", wenn man so will. Dabei spielt es keine Rolle, ob man Rechner, VMs oder beides hat und wo diese Rechner/VMs stehen. Man hat eine einheitliche Sicht auf alle Resourcen, auf welche man dann von Frameworks Tasks verteilt werden (u.a. auch Docker Container). Marathon und Chronos sind z.B. solche Frameworks und es gibt noch eine Reihe anderer und man kann selbst welche bauen. Alle Rechner, die in diesem Cluster-Verbund sind, stellen sich nach Außen als ein einzelner Pool an Resourcen dar. Das Ganze skaliert über einige zehntausend Nodes (soweit man sie denn hat ;-) ), ist ausfallsicher mit Hilfe von ZooKeeper, unterstützt Docker seit einiger Zeit, isoliert Tasks mit Hilfe von Linux Containern und bietet Java, Python, C++ und Go APIs, um direkt neue parallele Applikationen mit Mesos zu entwickeln.
Um Mesos einigermaßen realistisch zu testen (realistisch in dem Sinne, das man eine gewisse Anzahl von VMs hat und auch das HA-Setup mal testen kann), macht es Sinn, sich wie für den produktiven Betrieb auch, mindestens 3 Master-VMs (oder wer Rechner hat, dann 3 Rechner) und 2-3 Slaves (die dann die Tasks ausführen) zu installieren. Die Master-VMs benötigt man für ZooKeeper, der dafür sorgt, das immer ein Mesos-Service der sog. Master ist (die anderen sind soz. im Standby-Modus) und bei Ausfall des Masters, ein neuer Master bestimmt wird. Da der Master seine Aufgaben alle an die Slaves delegiert, hält sich die Belastung was CPU & Co. anbelangt bei ihm in Grenzen. Damit man ein Quorum hat, machen immer eine ungerade Anzahl von ZooKeeper-Instanzen Sinn (normalerweise 3 oder 5).
Für eine Testinstallation bietet es sich an, einige VMs zu installieren. Um VMs aufzusetzen, kann man z.B. Vagrant mit Virtualbox verwenden. Da ich libvirt drauf hab und in Vagrant nicht so tief drin bin, habe ich die 6 Ubuntu 14.04 LTS VMs mit virsh-install installiert. Wie das geht, habe ich prinzipiell hier beschrieben. Wenn man dann eine Ubuntu-VM installiert hat, kann man das fertige qcow2-File einfach kopieren (solange die VM nicht gestartet ist) und entsprechend dann in libvirt konfigurieren. Ich gehe darauf jetzt aber nicht weiter ein. Noch einfacher geht die Sache allerdings mit virt-builder (Teil des libguestfs Pakets ab Version 1.26, wenn ich mich nicht irre).
Wenn man dann die 6 VMs hat, kann man sich in der /etc/hosts noch Einträge machen, damit man die VMs per Namen und nicht per IP ansprechen kann. In meinem Fall:
192.168.122.252 me-master01
192.168.122.251 me-master02
192.168.122.250 me-master03
192.168.122.249 me-slave01
192.168.122.248 me-slave02
192.168.122.247 me-slave03
Der Netzbereich 192.168.122.0/24 ist bei mir die Default-Range, die bei libvirt vorgegeben war. Hab ich einfach übernommen. Ebenso die von libvirt erzeugte Bridge virbr0. Nicht schaden kann auch die Installation des ntp Pakets auf allen VMs, damit die Zeiten überall gleich sind.
Allgemein
Nachdem die VMs einsatzbereit sind, machen wir Ubuntu das Mesosphere Repository bekannt auf ALLEN VMs und updaten den Repo-Index:
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF
DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]')
CODENAME=$(lsb_release -cs)
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | sudo tee /etc/apt/sources.list.d/mesosphere.list
sudo apt-get -y update
Auf den Master-Hosts (und nur da) installieren wir das mesosphere-Metapaket das u.a. ZooKeeper, Mesos, Marathon (für langlaufende Tasks) und Chronos (für verteilte Cronjobs) enthält (das Metapaket hat aktuell ca. 330 MB):
sudo apt-get install mesosphere
Auf den Slave-Hosts installieren wir das mesos-Paket, das ist gut 100 MB kleiner und enthält u.a. ZooKeeper:
sudo apt-get install mesos
Als Nächstes konfigurieren wir ALLE VMs so, das sie alle die gleiche ZooKeeper Verbindungsinformation haben zu unseren ZooKeeper-Masterservern. Dazu editieren wir die Datei /etc/mesos/zk. Normalerweise finden wir dort den Eintrag zk://localhost:2181/mesos (der ist dafür gedacht, wenn man nur einen ZooKeeper hat), welchen wir ersetzen wollen. Statt localhost:2181 (2181 ist der ZooKeeoper Port) geben wir kommasepariert die IP's und Port unserer Master-ZooKeeper Server an. In meinem Fall sieht der Eintrag dann also so aus:
zk://192.168.122.252:2181,192.168.122.251:2181,192.168.122.250:2181/mesos
Master-Hosts/VMs (Mesos-Master)
Auf den Master-Hosts müssen wir nun jeder ZooKeeper-Instanz eine eindeutige ID verpassen. Dazu editieren wir /etc/zookeeper/conf/myid auf jedem Master. Die ID darf eine Zahl von 1-255 sein. In meinem Fall nehme ich das letzte Oktet von der IP der jeweiligen Master-VM also ID 252 für master01, 251 für master02 und 250 für master03.
Dann müssen wir der ID einen Host zuweisen. Dieses Mapping macht man in der Datei /etc/zookeeper/conf/zoo.cfg und sieht wie folgt aus:
server.252=192.168.122.252:2888:3888
server.251=192.168.122.251:2888:3888
server.250=192.168.122.250:2888:3888
Hinter server. steht also unsere ID, die wir oben vergeben haben und hinter dem "=" dann die IP des zugehörigen Hosts. Der erste Port 2888 wird verwendet, um mit dem Master zu kommunizieren. Der zweite Port 3888 wird verwendet, wenn ein neuer Master gewählt werden muss. Sollte man eine Firewall zwischen den Hosts haben, muss man die Ports natürlich freischalten! ZooKeeper ist damit soweit fertig.
Kümmern uns nun um die Mesos Master selber. Zuerst müssen wir das Quorum anpassen. Das Quorum legt fest, wie viele Nodes im Cluster noch funktionieren müssen, damit der Cluster noch als funktional eingestuft werden kann und Entscheidungen treffen kann. Über 50% des Clusters sollten noch funktionieren, damit Entscheidungen getroffen werden können. D.h. in unserem Fall von den drei Master-Hosts müssen mindestens zwei noch laufen. Wir setzen also auf ALLEN Master-VMs in /etc/mesos-master/quorum einen Wert von 2 (Default ist 1).
Dann schreiben wir auf ALLEN Master-VMs in /etc/mesos-master/ip die IP des jeweiligen Hosts, auf dem wir die Datei gerade editieren. Das Gleiche machen wir in/etc/mesos-master/hostname (alternativ kann man hier auch den Hostnamen rein schreiben, allerdings sollte man dann alle Hosts in der /etc/hosts stehen haben auf allen Mesos-Hosts/VMs, damit man nicht von einem DNS-Server abhängig ist - und falls der ausfällt, ist das eher ungünstig, zumindest wenn das Ganze produktiv wird ;-) ).
Master-Hosts/VMs (Marathon)
Als Nächstes ist dann die Marathon Konfiguration an der Reihe - die verteilte init System Implementierung, wenn man so will. Marathon startet u.a. lang laufende Prozesse. Marathon läuft auf allen Master-Hosts, aber nur der Leader kann Jobs ausführen. Die anderen Marathon Instanzen leiten die Requests transparent an den Leader weiter. Für jede Marathon Instanz müssen wir wie bei Mesos auch schon, wieder den Hostnamen festlegen. Hierzu können wir einfach /etc/mesos-master/hostname nach /etc/marathon/conf/hostname kopieren, müssen aber vorher noch das Verzeichnis auf jedem Master-Host anlegen (mkdir -p /etc/marathon/conf).
Dann müssen wir eine Liste von ZooKeeper Master für Marathon festlegen, die Marathon benötigt für den Informationsaustausch und Scheduling. Die Liste hat das gleiche Format wie wir es für Mesos in /etc/mesos/zk schon festgelegt haben. Auf ALLEN Master-Hosts kopieren wir also die Datei
sudo cp /etc/mesos/zk /etc/marathon/conf/master
Damit erlauben wir Marathon sich mit dem Mesos Cluster zu verbinden. Allerdings soll Marathon seine eigenen Informationen in ZooKeeper speichern können. Dafür nehmen wir wieder die gleiche Konfigurationsdatei und passen nur den Endpunkt (/marathon anstatt /mesos) an. Auf allen Master-Hosts kopieren wir
sudo cp /etc/marathon/conf/master /etc/marathon/conf/zk
Dann editieren wir /etc/marathon/conf/zk und tauschen, wie oben schon erwähnt, den Endpunkt /mesos durch /marathon aus. Dann sind wir mit Marathon soweit durch.
Auf den Master-Hosts sollen keine Slave-Prozesse laufen, deshalb beenden wir diese (soweit sie überhaupt laufen) und sorgen dafür, das sie beim Reboot nicht wieder starten:
sudo stop mesos-slave
echo manual | sudo tee /etc/init/mesos-slave.override
Nun soll dann auch endlich unser Konfiguration aktiv werden, an der wir schon die ganze Zeit rum basteln ;-)
sudo restart zookeeper
sudo start mesos-master
sudo start marathon
Wenn wir alles richtig gemacht haben, können wir uns auf einen der Master mal die GUI (Port 5050) anschauen z.B. http://192.168.122.251:5050/ . Man wird dann automatisch auf den Leader weitergeleitet, wenn man ihn nicht auf Anhieb erwischt. Bei Problemen kann man auf den Master-Hosts auch mal einen Blick in das ZooKeeper Log unter /var/log/zookeeper werfen. Da wir noch keine Slaves am Laufen haben, sieht die GUI noch nicht sehr spannend aus ;-)
Auf die Marathon-GUI können wir auch einen Blick werfen, welche unter Port 8080 läuft z.B. http://192.168.122.251:8080/ . Auch hier geht es nicht sonderlich spannend zu im Moment ;-)
Slave-Hosts/VMs
Da wir jetzt mit den Master-Hosts fertig sind, kümmern wir uns um die Slave-Hosts. Da wir hier keinen ZooKeeper und Mesos Master benötigen, fahren wir die Services runter (soweit sie laufen) und sorgen auch dafür, das diese Services beim Reboot nicht wieder starten. Auf ALLEN Slave-Hosts also:
sudo stop zookeeper
sudo echo manual | sudo tee /etc/init/zookeeper.override
sudo stop mesos-master
sudo echo manual | sudo tee /etc/init/mesos-master.override
Auch für die Slave-Hosts müssen wir wieder Hostname und IP festlegen diesmal im Verzeichnis /etc/mesos-slave. In unserem Fall sieht das für den ERSTEN Slave-Host dann so aus
echo "192.168.122.249" | sudo tee /etc/mesos-slave/ip
sudo cp /etc/mesos-slave/ip /etc/mesos-slave/hostname
Für die weiteren Slave-Hosts passt man die IP entsprechend an und führt die Kommandos dort aus. Dann können wir die Mesos Slaves auf ALLEN Slave-Hosts starten:
sudo service mesos-slave start
Wenn wir uns nun wieder auf eine der Mesos-Master GUIs einloggen (z.B. http://192.168.122.251:5050/), sollte auf der linken Seite irgendwo Slaves / Activated 3 stehen. Etwas weiter unten sieht man die Resourcen, die uns insgesamt im Cluster dann zur Verfügung stehen - also etwa die Anzahl der CPUs und RAM. Weitere Infos über die Slaves bekommt man, wenn man oben im Menü auf Slaves klickt.
Damit ist ZooKeeper, Mesos und Marathon soweit einsatzbereit. Über die Marathon-GUI (z.B. http://192.168.122.251:8080/) können wir dann oben links auf New Apps klicken und einen Task definieren. Zum Testen kann man einfach mal bei der ID Hello eingeben und beim Command
echo hello; sleep 10;
Man sieht dann, das alle 10 Sek. der Task auf einem Slave gestartet wird, nachdem er sich beendet hat.
Posted at 11:56nachm. Aug. 06, 2015 by cetixx in Tipps | Kommentare [0]
VM mit virsh-install installieren
Wenn man libvirtd (und die div. virsh*-Tools) installiert hat, kann man sich mit folgenden Kommando eine Ubuntu 14.04 VM erzeugen:
export VMNAME=vm_name
export VMRAM=1024
export VMCPU=3
virt-install \
--extra-args 'console=ttyS0,115200n8 serial'
vm_name ersetzt man durch den Namen, den die VM später haben soll und bei virsh list angezeigt wird. VMRAM gibt die RAM-Größe an und VMCPU die Anzahl der CPUs, die die VM nutzen darf. Wenn libvirtd gestartet ist, gibt es normalerweise auch ein Netzwerk-Interface virbr0. Sollte das br0 o.ä. heissen, muss man das entsprechend anpassen.
Posted at 12:12vorm. Aug. 05, 2015 by cetixx in Tipps | Kommentare [0]
Abhängigkeiten bei der Installation eines .deb Pakets auflösen
Wenn man ein .deb Paket direkt installieren will und auch die Abhängigkeiten aufgelöst werden sollen, dann kann man das mit
gdebi paketname.deb
machen.
Posted at 11:34nachm. Juli 23, 2015 by cetixx in Tipps | Kommentare [0]
Create a TV Show Tracker using AngularJS, Node.js and MongoDB
Ein unfangreiches Tutorial das die Technologien AngularJS, Node.js und MongoDB verwendet.
Posted at 11:30nachm. Juli 23, 2015 by cetixx in Tipps | Kommentare [0]
Archlinux - XBMC/Kodi, Lirc und Streamzap
Wer die Streamzap Fernbedienung unter Archlinux mit XBMC aka Kodi zum Laufen bringen möchte, dem hilft vielleicht diese kleine Anleitung:
*) Den Streamzap-Empfänger in den USB-Port stecken
*) Normalerweise müsste das streamzap-Modul dann selbstständig geladen werden (prüfen mit lsmod | grep streamzap). Ansonsten: modprobe streamzap und am Besten eine Datei anlegen, damit das Modul beim nächsten Start des Rechners mit geladen wird:
echo "streamzap" > /etc/modules-load.d/streamzap.conf
*) pacman -S lirc-utils
*) Im $HOME-Verzeichnis, mit dem XBMC aka Kodi dann laufen soll, ins Verzeichnis $HOME/.xbmc/userdata/ wechseln und eine Datei Lircmap.xml (man achte auf das große L) anlegen:
Download Lircmap.xml.gz
*) ln -s /usr/share/lirc/streamzap/lircd.conf.streamzap /etc/lirc/lircd.conf
*) Lircd-Service-Datei für Systemd anlegen: /usr/lib/systemd/system/lircd.service
Download lircd.service.gz
*) systemctl daemon-reload
*) systemctl start lircd
*) Mit dem Kommando irw kann man dann testen, ob man etwas empfängt, wenn man eine Taste auf der Fernbedienung drückt. Der Output sieht dann z.B. so aus:
00000000000028d0 00 KEY_UP Streamzap_PC_Remote
00000000000028d0 01 KEY_UP Streamzap_PC_Remote
00000000000028d4 00 KEY_DOWN Streamzap_PC_Remote
00000000000028d3 00 KEY_RIGHT Streamzap_PC_Remote
00000000000028d5 00 KEY_MENU Streamzap_PC_Remote
00000000000028d6 00 KEY_EXIT Streamzap_PC_Remote
Wenn was bei irw rein kommt, dann hat man gute Chancen, das es auch unter XBMC/Kodi klappt.
Posted at 03:40nachm. Dez. 07, 2014 by cetixx in Tipps | Kommentare [0]
Thunderbird: Mehrere E-Mail-Adressen in einer Identität verwalten
Da ich meine eigene Maildomain habe, richte ich mir immer eine neue E-Mail Adresse ein, wenn ich mich irgendwo anmelde. Sollte eine dieser Adressen irgendwo auf einer Spamliste landet, wird der Account einfach gelöscht (hat auch noch ein paar andere Vorteile). Der Nachteil ist, das man dann im Thunderbird für jede dieser Adressen eine eigene Identität sprich Konto anlegen muss. Das wird natürlich bald recht unübersichtlich ;-)
Aber Thunderbird kann mehrere E-Mail-Adressen in einer Identität bzw. Konto verwalten. Dazu geht man auf Edit -> Account Settings (sorry, hab die englischsprachige Version von Thunderbird...). Dann wählt man einen Account aus und klickt dann unten rechts auf den Button Manage Identities... (unterhalb vom Outgoing Server (SMTP)). Jetzt kann man hier die Email Adresse (das ist der FROM Header im SMTP-Protokoll) und auch Reply-to angeben (i.d.R. wird man in diesem Fall beides auf den gleichen Wert setzen).
Wenn man nun eine E-Mail verfasst, kann man oben bei From: diese - ich nenne es mal - virtuelle Identität auswählen. Wichtig ist nur, das der Mail-Server diese Mail-Adresse auch akzeptiert, sonst klappt das natürlich nicht. Aber ansonsten sieht dann der Empfänger der Mail als Absender diese "virtuelle" Identität. Es steht also dann nicht nur im Reply-to die gewünschte E-Mail-Adresse sondern auch im From: Feld und das ist das was wir haben wollen ;-) Die Default Mail-Adresse des Kontos taucht dann im Mailprotokoll nicht mehr auf.
Posted at 01:10vorm. Juni 05, 2014 by cetixx in Tipps | Kommentare [0]
cli53 - Amazon Route 53 DNS Kommandozeilentool
Wenn man eine DNS-Zone in AWS Route 53 verwaltet, leistet das kleine Tool cli53 ganz gute Dienste. Damit kann man z.B. eine Zone aus AWS heraus ins BIND-Format exportieren oder auch wieder importieren oder gezielt Einträge ändern. Es gibt zwar hierfür auch das aws Kommandozeilen Tool (pip install awscli), aber das hat einige Features von cli53 nicht.
Posted at 11:09nachm. Jan. 19, 2014 by cetixx in Tipps | Kommentare [0]
FTP: Verzeichnisse rekursiv herunterladen
Will wann einen FTP-Ordner und dessen Unterordner herunterladen, geht das recht gut mit wget:
wget -r "ftp://user:passwort@domain/verzeichnis"
Posted at 11:31nachm. März 25, 2013 by cetixx in Tipps | Kommentare [0]
Varnish Cache Objekt vor Ablauf der TTL erneuern
Der Varnish ist an sich ein toller Reverse-Proxy, hat nur vereinzelt ein paar Dinge, die manchmal etwas Kopfzerbrechen bereiten. Eine Sache davon ist, das Erneuern von gecachten Objekten. Ist die TTL eines Objekts abgelaufen und jemand frägt dieses Objekt ab, muss er warten, bis der Varnish es vom Backend neu gezogen hat. Fragen andere gleichzeitig dieses Objekt ab, bekommen sie es weiterhin aus dem Cache, soweit man eine Grace-Period definiert hat. Aber dieser eine o.g. User muss warten. Das kann man umgehen, in dem man sich für die wichtigsten Seiten einen Job schreibt, der das Objekt bereits vor Ablauf der TTL erneuert. In der Varnish-Konfiguration könnte das dann so aussehen:
acl refresh {
"localhost";
}
sub vcl_recv {
if (req.request == "REFRESH") {
if (client.ip !~ refresh) {
error 405 "Not allowed";
}
set req.hash_always_miss = true;
set req.request = "GET";
}
}
req.hash_always_miss funktioniert seit Varnish V 2.1.4. Während die User ja die Seiten mit der HTTP GET-Methode weiterhin aus dem Varnish-Cache bekommen, kommt unser Skript mit der REFRESH-Methode rein, setzt "req.hash_always_miss = true" und umgeht somit den Cache und zieht das entsprechende Objekt neu vom Backend. Anschließend wird es im Cache ersetzt und wir haben wieder ein "frisches" Objekt. Sehr praktisch :-)
Posted at 10:22nachm. Feb. 20, 2013 by cetixx in Tipps | Kommentare [0]