Auch wenn Chef Ruby einsetzt unterstützt es leider doch nicht alles. Ich wollte eine nette Regex direkt im Cookbook ausführen lassen. In Ruby wunderbar funktioniert, beim Chef run wurde die Regex nicht korrekt ausgeführt. Ich habe sogar zwei verschiedene ausprobiert (wobei die erste nicht ganz korrekt ist, aber auch funktioniert), aber leider Erfolglos. sed funktioniert eben einfach immer :)

Regex: Kommentiere eine Zeile, wenn ubuntu.com oder canonical.com enthalten ist und nicht mit einer Raute anfängt.

 ruby_block 'modify /etc/apt/sources.list' do
  block do
    File.write( f = "/etc/apt/sources.list",
      #File.read(f).gsub(/(?!^#)(.*)(?:ubuntu\.com|canonical\.com)(.*)/) { "# #{$&}" }
      File.read(f).gsub(/^[^!#]*(?:ubuntu\.com|canonical\.com)/m) { "# #{$&}" }
    )
  end
end
 

Lösung:

execute 'modify /etc/apt/sources.list with sed' do
  command "sed -i -e '/ubuntu\.com/s/^#*/#/' -e '/canonical\.com/s/^#*/#/' /etc/apt/sources.list"
end

In dem Cloudera Manager kann man sich schon verschiedene Grafen der einzelnen Komponenten anschauen, wenn man jedoch auch Grafana benutzt will man nicht wirklich immer umschalten.
Es ist jedoch möglich ein Plugin für Grafana zu schreiben um die Daten direkt aus dem CDH zu ziehen. Amir Pakdel hatte ein Plugin für Grafana 1.x geschrieben, welches ich für Grafana 2.x umgeschrieben habe.

Download: Grafana CDH Datasource Plugin

Installation

Damit wir in kein Problem mit XSS kommen müssen wir unsere anfragen an das CDH mit einem kleinen Proxy über den Server von Grafana abfertigen. Dafür muss folgende Apache Konfiguration angelegt werden:

    ProxyPass http://$CLOUDERAMANAGER:7180/api/v9
    ProxyPassReverse http://$CLOUDERAMANAGER:7180/api/v9
    RequestHeader set Authorization "Basic <base64>"
    Header set Access-Control-Allow-Origin "*"

Das $CLOUDERAMANAGER muss mit dem Hostnamen von dem CDH Manager ersetzt werden und in dem RequestHeader der Benutzername:Passwort (in base64) von dem Benutzer der mit der API von CDH reden darf. Anschließend noch ein paar Module aktivieren:

# a2enconf cdh
# a2enmod proxy_http proxy request headers
# service apache2 restart

Anschließend können wir das Modul installieren und Grafana neu starten. Vor dem Neustart, muss jedoch noch die $GRAFANAURL in der datasource.js angepasst werden.

 # tar -xzf cdh.tar.gz -C /usr/share/grafana/public/app/plugins/datasource/ 
# service grafana-server restart

Jetzt kann man schon beginnen eine neue Datasource zu erstellen und fleißig Graphen bauen. Wie baut man die Graphen? Man muss die SQL Statements aus dem CDH in Grafana übertragen. Die Statements bekommt man aus den vorhanden Graphen:

In dem JSON befindet sich das Query, welches einfach in die Row im Grafana eingetragen werden muss. Fertig.

Wenn man momentan auf Owncloud 8.0 upgraded erhalten viele Benutzer nur noch eine weiße Seite und nichts passiert. In den Logdateien kann man auch keine Fehler finden.
Das Problem liegt an ein paar Plugins die noch nicht für 8.0 aktualisiert worden. Diese muss man deaktivieren:

# cd /zur/deiner/owncloud
# sudo -u www-data php occ app:disable calendar
# sudo -u www-data php occ app:disable contacts

Gehen wir mal davon aus das wir einen SSH Benutzer in einer Jail eingesperrt haben. Dieser möchte aber unbedingt einen SSH Tunnel  zu einem anderen Server aufbauen. Normalerweise will man das nicht und verbietet dieses in der sshd_config Konfiguration mittels AllowTcpForwarding no.

Ich wollte das trotzdem einmal habe und konnte einfach nicht finden warum es nicht möglich war. Meine Fehlermeldung:

# ssh -N -L 1337:127.0.0.1:3306 user@$remoteserver -vv

debug1: Connection to port 1337 forwarding to 127.0.0.1 port 3306
requested.
debug2: fd 7 setting TCP_NODELAY
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: administratively prohibited: open failed
debug2: channel 2: zombie
debug2: channel 2: garbage collecting
debug1: channel 2: free: direct-tcpip: listening port 1337 for
127.0.0.1 port 3306, connect from ::1 port 58509, nchannels 3

Ein kleiner Test:

# telnet localhost 1337
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

Hat leider nichts geholfen und wenn die Fehlermeldung schon sagt das es $irgendwas nicht öffnen kann, muss man sich das einmal genauer mit strace anschauen:

# strace -p $pid -ff
Process $pid attached - interrupt to quit
select(8, [3 7], [], NULL, NULL)        = 1 (in [3])
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
read(3,
"\354O-\1\374O\215\5\4G\323\226\371\207V\325s\37\277-\350\207$)\261}\235\241\320\306\302M"...,
16384) = 96
socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4
connect(4, {sa_family=AF_FILE, path="/dev/log"}, 110) = -1 ENOENT (No such file or directory)
close(4)                                = 0
select(8, [3 7], [3], NULL, NULL)       = 1 (out [3])
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(3,
"\374\231G-+\2,\365\255\312\240Y\20\217YL\350\3t193O\35\323\224\237\3728\260\233\223"...,
64) = 64
select(8, [3 7], [], NULL, NULL

In der Jail hat kein /dev/log existiert und ohne ein bisschen herumzuloggen möchte SSH anscheinend auch keinen Tunnel aufbauen. Kurzerhand das Device angelegt und schon ging es.

root@server:/var/jail/user/dev# ls -al log
srw-rw-rw- 1 root root 0 Mar  3 16:08 log
root@server:/var/jail/user/dev# grep -E '^\$' /etc/rsyslog.d/jail.conf
$AddUnixListenSocket /var/jail/user/dev/log
root@server:/var/jail/user/dev#

Manchmal fügt man eine Regel zu Spät in die .gitignore Liste ein und man hat hunderte von Dateien in dem Repository die man eigentlich nicht will. Einfach zu lösen:

git rm -r --cached .
git add .
git commit -m "fixed untracked files"

Ich benutze kein Gitlab oder Github für private Repositories sondern greife auf diese normal per ssh zu. Wenn man das alleine auf einem Server macht ist das kein Problem. Was aber wenn jemand da zustößt und will auch an das Repository? Dieser sich aber auch sonst nicht auf dem Server einloggen und am System zu schaffen machen.

Zum Glück kann man pro SSH Pubkey erlauben welche Programme ausgeführt werden dürfen. Ein Feature was meines Erachtens viel zu wenig angewendet wird. Dafür brauchen wir erst einmal ein kleines Script, welches der Key ausführen darf und somit unserer Limitierung ist. Das platzieren wir in dem Home Verzeichnis des Benutzers:

# cat ~/gitserve && chmod g+x ~/gitserve

#!/bin/sh
exec git-shell -c "$SSH_ORIGINAL_COMMAND"

Dem SSH Key müssen wir dieses jetzt nur noch bei bringen:

command="./gitserve",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty
ssh-rsa AAAAB.....

Der Benutzer kann jetzt nur noch mit der git-shell interagieren.

Ich habe mir einen Etikettendrucker zugelegt und habe mich bin dabei für de QL-570 von Brother entschieden. Den gab es gerade günstig bei Amazon zu kaufen und kommt mit Einzeletiketten und Endlospapier klar.

Bei Brother kann man sich die Treiber herunterladen. Ich habe mich für deb entschieden. Entpacken muss man sie so oder so:

# ar xv ql570cupswrapper-1.0.1-0.i386.deb
# ar xv ql570lpr-1.0.1-0.i386.deb

Den Inhalt von der data.tar.gz kann man dann nach “/” kopieren. Anschließend muss man nur noch einen Befehl ausführen damit der Treiber auch im cups konfiguriert wird:

# /opt/brother/PTouch/ql570/cupswrapper/cupswrapperql570pt1

Leider hat das bei mir nicht ganz gereicht. Ich musste die größe des Papiers noch mit angeben. Das mitgelieferte Papier hat eine Breite von 62mm. Den Befehl bastelt man am besten mit der Ausgabe von dem cupswrapper Befehl (wegen der Seriennumber):

# lpadmin -p QL-570 -E -v usb://Brother/QL-570?serial=<SERIAL> -P /usr/share/cups/model/Brother/brother_ql570_printer_en.ppd -o PageSize=62x29

Anschließend kann man in der angegebenen Größe mittels gLabels auch direkt losdrucken :) Die passenden Optionen kann man sich einfach anzeigen lassen:

# lpoptions -pQL-570 -l

Das Munin Paket hat leider noch eine alte VHost Konfiguration und ist nicht ganz mit Apache 2.4 kompatibel. So geht es jedoch:

Nachdem im ersten Teil das Projekt mit Mopidy und Icecast fehlgeschlagen ist, musste eine neue Lösung her. Entschlossen wurde sich dann für die Squeezebox von Logitech. Die hat ein relativ offenes System mit Servern und Clients. Die lässt sich auch ohne deren Hardware betreiben. Es gibt ein Third-Party Modul mit dem man seinen Soundcloud Account einbinden kann und das war für mich das wichtigste. Der andere wichtige Teil ist, dass alle Clients auch Synchron sind und die Lieder nicht von verschiedenen Stellen abspielt. Auch daran hat Logitech gedacht und ins Protokoll eingebaut. Also eigentlich eine viel umfangreichere Lösung als mit Mopidy.

Als erstes müssen wir ein paar Abhängigkeiten installieren:

# apt-get install libjpeg8 libpng12-0 libgif4 libexif12 libswscale2 libavcodec53

Auf dem Raspberry Pi werde ich Server und Client betreiben und als erstes beginnen wir mit dem Server:

# wget http://downloads.slimdevices.com/LogitechMediaServer_v7.8.0/logitechmediaserver_7.8.0_all.deb
# dpkg -i logitechmediaserver_7.8.0_all.deb
# service logitechmediaserver stop

Das sollte ohne Probleme durchlaufen. Wir muessen jedoch noch ein paar Libs und Symlinks anlegen, die der Server benoetigt. Dabei greife ich auf das Fantastische Howto von All Things Pi zurück:

# wget http://itbert.de/pub/lms-rpi-raspbian.tar.gz
# tar -xzf lms-rpi-raspbian.tar.gz

In dem LMS Howto sind noch ein paar Schritte mehr beschrieben, die waren jetzt bei v7.8.0 nicht nötig:

# mv libmediascan.so.0.0.0 libfaad.so.2.0.0 /usr/local/lib
# mv /usr/share/squeezeboxserver/Bin/arm-linux/faad /usr/share/squeezeboxserver/Bin/arm-linux/faad.old
# mv faad /usr/share/squeezeboxserver/Bin/arm-linux
# ln -s /usr/local/lib/libmediascan.so.0.0.0 /usr/local/lib/libmediascan.so
# ln -s /usr/local/lib/libmediascan.so.0.0.0 /usr/local/lib/libmediascan.so.0
# ln -s /usr/local/lib/libfaad.so.2.0.0 /usr/local/lib/libfaad.so
# ln -s /usr/local/lib/libfaad.so.2.0.0 /usr/local/lib/libfaad.so.2
# ldconfig
# chown -R squeezeboxserver:nogroup /usr/share/squeezeboxserver/

Anschließend kann man den Dienst wieder starten:

# service logitechmediaserver start

Auf dem RaspberryPi dauert das Starten bei mir ungefähr 20 Sekunden und erst dann kann man auf das Webinterface http://DEINSERVER:9000/ zugreifen.
Der Server läuft und wer will kann sich noch das SqueezeCloud Modul aktivieren. Den erstellten API Key aus Teil 1 kann man ruhig weiterverwenden.

Wir wollen jedoch auch Musik hören und nicht nur abspielen. Als Client benutze ich den SqueezeLite und habe bis jetzt keine Probleme gehabt. Zum Glück gibt es auch Binaries und man muss nichts weiter auf dem RasPi kompilieren:

# wget http://squeezelite-downloads.googlecode.com/git/squeezelite-armv6
# chmod +x squeezelite-armv6

Der Client hat selber viele Einstellungen, aber auf dem Server selber kann man ihn ohne Optionen starten. Nach ein paar Sekunden sollte der Client in dem Webinterface von dem Server angezeigt werden und man kann Musik abspielen.

Mein Setup umfasst momentan, den Server und einen Client auf dem Raspi und einen weiteren Client auf dem Computer. Beide laufen ohne Probleme und ich kann endlich in der ganzen Wohnung Soundcloud streamen und das auch noch Synchron :) Demnächst kommt noch ein zweiter RasPi dazu und ich bin mal gespannt.
Auf dem Android benutze ich die Squeeze Controller App. Damit kann man den Server steuern. Leider kann es nicht direkt auf das Soundcloud Modul zugreifen, sondern nur auf die Lieder die momentan in der Playlist sind. Funktioniert jedoch auch super. Soweit bin ich sehr zufrieden und man hat ein paar Hundert Euro gespart die man ansonsten mit Sonos oder Raumfeld ausgegeben hätte.

Ein kleines Projekt um das Heim ein bisschen mehr Musikalisch zu machen. Das Ziel ist es in jedem Raum und auf der Dachterrasse ein paar Boxen zu haben die die gleiche Musik spielen. Eigentlich ganz einfach mit DLNA zu realisieren. Das Problem ist nur, dass ich auch unbedingt Soundcloud hören möchte.

Nach ein bisschen Recherche bin ich auf Mopidy gestoßen. Das ist ein Musikserver der auch von Soundcloud, Spotify und Streams Musik abspielen kann. Wenn man dazu noch Icecast benutzt kann man es sogar in das Netzwerk streamen. Hört sich super an – also installieren. Eine andere Anforderung ist noch das es auf einem RasperryPi laufen muss. Das Projekt sagt sogar das es auf dem laufen soll, also weiter installieren. SPOILER ALERT: Mopidy als Musikdaemon läuft auch einwandfrei und kann ich empfehlen. Wer jedoch auch noch Icecast benutzen will kann dieses leider vergessen, weil der kleine Pi einfach nicht mit dem decodieren der Lieder mitkommt und somit die CPU total überlastet und die Streams nur hackelig ankommen. Es ist also nicht zu empfehlen das folgende Howto auf einem RasperryPi zu installieren sondern auf einem Rechner mit mehr CPU Power zum dekodieren.

Die Installationanleitung von docs.mopidy.com kann man eigentlich getrosst folgen. Man sollte nur gleich seine Plugins mit installieren:

# apt-get install mopidy mopidy-alsamixer mopidy-soundcloud

Es werden alle möglichen python Abhängigkeiten installiert und kann schon ein paar Minütchen dauern auf dem Pi. Unter Debian liegt die Konfiguration unter /etc/mopidy/ und sollte auch dort angepasst werden, wenn man die init script benutzen will. Die Konfiguration kann man eigentlich minimal belassen und man muss nur noch folgendes hinzufügen um den HTTP Server, MPD Server und Soundcloud Anbindung zu aktivieren:

[http]
enabled = true
hostname = ::
port = 6680
static_dir = /var/www/Mopidy-MusicBox-Webclient/webclient
zeroconf = Mopidy HTTP server on $hostname

[mpd]
enabled = true
hostname = ::
port = 6600
password =
max_connections = 20
connection_timeout = 60
zeroconf = Mopidy MPD server on $hostname

[soundcloud]
enabled = true
explore_songs = 100
auth_token = <DEIN-KEY>

[alsamixer]
enabled = true
card = 1
control = PCM

Bevor wir den Dienst starten sollten, brauchen wir noch den API Key für Soundcloud und die Dateien für das Webfrontend.

# cd /var/www/
# git clone https://github.com/woutervanwijk/Mopidy-MusicBox-Webclient.git

Anschließend nur noch Mopidy starten:

# service mopidy start

Jetzt ist es möglich sich mit dem Webfrontend zu verbinden: http://<DEINSERVER>:6680

Die Konfiguration für Mopidy ist jetzt eigentlich abgeschlossen und man kann auf dem Computer auf dem Mopidy läuft (falls nicht: modprobe snd_bcm2835) Musik hören. Wir wollen jedoch Streamen! Also muss erst einmal Icecast2 installiert werden:

# apt-get install icecast2
# sed -i s/false/true/ /etc/default/icecast2

Damit Mopidy einen eigenen Mountpoint bekommt, müssen wie die Konfiguration von Icecast in /etc/icecast2/icecast.xml anpassen bzw. hinzufügen:

<mount>
<mount-name>/mopidy</mount-name>
<fallback-mount>/silence.mp3</fallback-mount>
<fallback-override>1</fallback-override>
</mount>

Woher kommt die silence.mp3 und was macht diese? Es gibt leider noch einen Bug mit Mopidy und Icecast, dass bei einem Songwechsel Icecast die Verbindung verliert. Deswegen muss man den Workaround einbauen und eine leere Datei abspielen. Diese muss im webroot von Icecast liegen und kann folgendermaßen erstellt werden:

# ffmpeg -f lavfi -i aevalsrc=0 -t 5 silence.mp3
# mv silence.mp3 /usr/share/icecast2/web/

Damit Icecast von Mopidy benutzt werden kann, müssen wir den output channel von Mopidy anpassen:

mixer = software
mixer_volume = 100
# output = autoaudiosink
output = lame ! shout2send mount=mopidy ip=<DEINSERVER> port=8000 password=askme
# output = audioresample ! audioconvert ! vorbisenc ! oggmux ! shout2send mount=mopidy ip=<DEINSERVER> port=8000 password=askme
visualizer =

Anschließend muss man Icecast starten und Mopidy neu starten. Bitte beachten, Icecast muss immer vor Mopidy gestartet werden. Wenn alles korrekt konfiguriert ist muss man in Mopidy ein Lied startet und man kann im Icecast Webinterface einen aktiven /mopidy Mountpunkt sehen. Und schon kann man überall Musik hören:

# mplayer http://DEINSERVER:8000/mopidy

Seit ein paar Tagen bin ich in irgend einer Liste für XML-RPC Brute Force Attacken gelandet und die müllen meine limitierten Apache Slots zu. Lösung:

#!/bin/bash
# script: block xmlrpc attacks
# author: Steffen Wirth <s.wirth@itbert.de>
 
LOGFILE="/var/log/apache2/access.log"
LASTLINES="20"
MAXCOUNT="5"
 
LIST=$(tail -n$LASTLINES $LOGFILE |grep "xmlrpc.php" | awk '{print $1}' | sort -n | uniq -c)
 
if [ -n "$LIST" ]; then
        while read -r count ip ; do
                if [ $count -ge $MAXCOUNT ]; then
                        iptables -A INPUT -s $ip -j DROP
                        logger -t "XMLRPC" "blocked ip $ip"
                fi
        done <<< "$LIST"
fi

wie immer auch im gist.github.com

Wie Sebastian korrekt darauf hinwies, wenn man fail2ban installiert hat ist es viel einfacher:

# grep -v "^#" /etc/fail2ban/filter.d/apache-xmlrpc.conf 

[INCLUDES]

before = apache-common.conf

[Definition]

failregex = ^ .*POST .*xmlrpc\.php.*

ignoreregex = 
# grep apache-xmlrpc /etc/fail2ban/jail.conf -A3
[apache-xmlrpc]
enabled = true
port    = http,https
filter  = apache-xmlrpc
logpath = /var/log/apache*/*access.log
maxretry = 5