Archiv der Kategorie: Linux

GSM Gateway mit Asterisk und FreePBX auf Raspberry Pi

Nachdem ich erst versucht habe, das ganze zu Fuß auf Raspian zu bauen, hab ich nach gefühlten zwei Tagen aufgegeben und http://www.raspberry-asterisk.org genommen. Das hat den Riesenvorteil, dass man auch einen einigermaßen aktuellen Asterisk bekommt, auf dem der chan_dongle trotzdem geht.

Bei der Konfiguration hat vor allem:

Installing a FreePBX with FritzBox as trunk on a Raspberry Pi

geholfen. Es hat trotzdem alles nicht auf Anhieb geklappt. Irgendwann bin ich dann dazu übergegangen, alles, was nach ID und Passwort klang, gleich zu nennen, jetzt gehts 🙂 Ob das jetzt sicherheitstechnisch schlimm ist, kann ich schwer sagen (ok, stimmt nicht :-), ist alles im Intranet, da können mich die Leute auch schädigen, wenn sie einfach das Telefon in die Hand nehmen.

Vorher habe ich den UMTS Stick (Huawei E160) direkt an der Fritte betrieben, aber seit 6.83 ging das plötzlich nicht mehr. Aber da man dort eh die ausgehende Rufnummer nicht unterdrücken kann, ist mir das so eh viel lieber. Der RPi braucht übrigens mit dem Dongle ca. 3 Watt.

Im Prinzip sollte das auch immer noch mit dem UMTS Dongle an der Fritte gehen. Aber AVM gibt leider keine Liste mit unterstützten Sticks heraus und Rufnummernunterdrückung geht mit dieser Methode auch nicht… meine Handynummer soll ja nicht unbedingt bei einem Anruf von zuhause angezeigt werden.

Alexa, mach die Glotze aus

Da sitzt man auf dem Sofa, der Film fängt gleich an und daneben leuchtet der Rechner die Welt voll.

Jetzt könnte man natürlich aufstehen und das Ding einfach locken oder den Bildschirm ausschalten oder was immer, aber warum hat man sich denn dieses kleine Laberdöschen in die Bude gestellt. Also flux ein Script zusammengestohlen:

#!/usr/bin/python
import sys, os
from flask import Flask, jsonify

app = Flask(__name__)
app.config.update(
# DEBUG=True,
)

command = 'gnome-screensaver-command --lock'

@app.route('/lockscreen', methods=['GET'])
def get_tasks():
 os.system(command)
 return ""

if __name__ == '__main__':
 app.run('0.0.0.0',5000 )

Das Ding jetzt als Startprogramm eintragen.

Die Alexa steuert bei mir zuhause eh schon ziemlich viel dank der genialen HA Bridge. Dieser muss man natürlich noch erklären, dass sie z.B. das Device „Monitor“ mit dem GET Befehl: http://meinlaptop.fritz.box/lockscreen ausschalten muss. Fertig.

Irgendwelche Security Bedenken?

Neben dem ganzen Amazon- und Cloud-Rotz und eigentlich recht wenige: ich nehme nicht noch nen weiteren Internet Service wie IFTT rein, sondern der Dot steuert das Dingens über die HA Bridge direkt (weil Amazon da halt ne zwei Klassen Gesellschaft hat). Der Flask Server oben ist glaub ich recht überschaubar… vielleicht fallen mir ja noch ein paar Ideen ein, was man machen könnte: Laptop Lautstärke wäre auch noch schick…

Debian Repository per ssh auf ein chroot

Für eigene Zwecke will man immer mal ein Repository haben, auf das andere nicht zugreifen können, aber das man auch an Bekannte oder Testgruppen oder wen auch immer weitergeben kann. ftp mit Passwort und http mit Passwort sind so ne Sache, ein wenig sicherer könnte das schon sein.

Debian Repositories können auch via ssh eingebunden werden, eine entsprechende Zeile in der sources list sieht dann so aus:

deb ssh://repouser@example.com/packages/ jessie main

Auf dem Server muss man einen entsprechenden Nutzer einrichten und die packages enthalten eben das Debian Repository. Authentisierung erfolg per ssh key, d.h. auf Clientseite wird ein ssh-Key erzeugt, der auf Serverseite im ~/.ssh/authorized_keys des repouser liegt. Soweit so straightforward.

Der Nachteil dieser Variante ist, dass der repouser nun einen ssh login auf dem Server hat, was ihn natürlich auch lesenden Zugriff auf andere Ressourcen gibt, was man eher nicht unbedingt will. Kann sein, dass man dies auch noch besser absichern kann, die beste Absicherung ist auf jeden Fall, diesen Benutzer in ein chroot environment zu sperren.

Dieses fahre ich über die sftp chroot variante des sshd, in der sshd_config steht dazu:

Subsystem sftp internal-sftp

Match Group sftp
ChrootDirectory %h
AllowTcpForwarding no

Nun muss der repouser noch zur Gruppe sftp dazu und jetzt kommt das eigentliche Problem: die chroot Umgebung mit den richtigen Dateien und Rechten auszustatten, d.h. alles dort einzurichten, was nötig ist, um auf Clientseite apt-get … aufzurufen. Und da war das Problem: Was braucht apt-get via ssh auf der Serverseite? Letzendlich hab ich es nur raus bekommen, in dem ich mir die Sourcen von apt-get angeschaut habe. Und da waren vor allem find und dd die Hänger… die drauf und es ging. Wie man herausbekommt, welche libs nötig sind, sagt ldd find und ldd dd und gut ist.

Das ganze ist hier in einem schmutzigen Script, das so unter Ubuntu 14.04 läuft, Achtung: die Libs werden so für andere Distris nicht passen, aber ldd ist dein Freund, der Rest stimmt.

#!/bin/bash
echo "This script should be started as root on the machine, which hosts the repo"
REPOUSER="repouser"
REPOHOME="ssdhome/$REPOUSER"
echo "Generating chroot environment for $REPOUSER in $REPOHOME"</code>

adduser --disabled-password --ingroup sftp --home /$REPOHOME $REPOUSER
mkdir -p /$REPOHOME
chown root:root /$REPOHOME
cd /$REPOHOME
mkdir -p bin dev etc home lib usr var tmp usr/bin vat/tmplib/x86_64-linux-gnu usr/lib/x86_64-linux-gnu $REPOHOME lib/x86_64-linux-gnu lib64
cp /bin/ls bin/
cp /bin/dash bin/sh
cp /bin/bash bin/
cp /usr/bin/scp usr/bin/
cp /bin/dd bin/
cp /usr/bin/find usr/bin/
cp /usr/bin/whoami usr/bin/
cp /lib/x86_64-linux-gnu/libtinfo.so.5 lib/x86_64-linux-gnu/
cp /lib/x86_64-linux-gnu/libdl.so.2 lib/x86_64-linux-gnu/
cp /lib/x86_64-linux-gnu/libc.so.6 lib/x86_64-linux-gnu/
cp /lib64/ld-linux-x86-64.so.2 lib64/
cp /lib/x86_64-linux-gnu/libselinux.so.1 lib/x86_64-linux-gnu/
cp /lib/x86_64-linux-gnu/libacl.so.1 lib/x86_64-linux-gnu/
cp /lib/x86_64-linux-gnu/libpcre.so.3 lib/x86_64-linux-gnu/
cp /lib/x86_64-linux-gnu/libattr.so.1 lib/x86_64-linux-gnu/
cp /lib/x86_64-linux-gnu/libnss_compat* lib/x86_64-linux-gnu/
cp /lib/x86_64-linux-gnu/libm.so.6 lib/x86_64-linux-gnu/
mknod dev/null c 1 3
mknod dev/zero c 1 5
chmod 666 dev/*
chmod 1777 tmp
grep $REPOUSER /etc/passwd &gt;&gt; etc/passwd
echo "now, cp the repository beginning with the packages dir to ssdhome/$REPOUSER"
echo "do not forget to add the public key to ssdhome/$REPOUSER/.ssh/authorized_keys"
echo "and add a line like: deb ssh://$REPOUSER@example.com/packages/ jessie main"

 

Redmine in Sub-URI und https

Boah, diese ganze gelayerte Webappgrütze bringt einem um, wenn man das nicht regelmässig macht und die ganzen Fehlermeldungen der einzelnen Layer sofort versteht…

Ok, ich habe weder Zeit noch Lust, meine Erkenntnisse von 5 Tage rumprobieren hier komplett aufgeräumt wieder zu geben, aber wenigstens das Ergebnis könnte helfen…

Also neben dem „normalen“ redmine aufsetzen hab ich das Dingens via thin und socket gegen einen nginx in einer suburi gebunden. Hier die Konfigurationen, die evtl. helfen könnten…

zuerst mal /etc/thin/redmine.yml:

---
chdir: "/space/redmine/latest"
environment: production
timeout: 30
log: "/var/log/thin/redmine.log"
pid: "/space/redmine/latest/tmp/redmine.pid"
max_conns: 1024
max_persistent_conns: 100
require: []
wait: 30
threadpool_size: 20
socket: "/space/redmine/latest/tmp/thin.sock"
daemonize: true
user: www-data
group: www-data
servers: 1
prefix: "/redmine"

nun die /etc/init.d/thin

#!/bin/bash
DAEMON=/usr/local/rvm/gems/ruby-2.2.3/bin/thin
SCRIPT_NAME=/etc/init.d/thin
CONFIG_PATH=/etc/thin
export GEM_PATH=/usr/local/rvm/gems/ruby-2.2.3:/usr/local/rvm/gems/ruby-2.2.3@global
export RUBY_VERSION=ruby-2.2.3
export MY_RUBY_HOME=/usr/local/rvm/rubies/ruby-2.2.3
export XDG_SESSION_COOKIE=xxxxxx
export IRBRC=/usr/local/rvm/rubies/ruby-2.2.3/.irbrc

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

source /usr/local/rvm/scripts/rvm

case "$1" in
  start)
	$DAEMON start --all $CONFIG_PATH
	;;
  stop)
	$DAEMON stop --all $CONFIG_PATH
	;;
  restart)
	$DAEMON restart --all $CONFIG_PATH
	;;
  *)
	echo "Usage: $SCRIPT_NAME {start|stop|restart}" >&2
	exit 3
	;;
esac

last not least der passende ausschnitt aus der /etc/nginx/sites-enabled/ssl

location ~ ^/redmine(/.*|$) {
        alias   /space/redmine/latest/public$1;
#location /redmine {
            proxy_set_header        Host $host;
            proxy_set_header        X-Real-IP $remote_addr;
            proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header        X-Forwarded-Proto $scheme;
            proxy_redirect          http:// https://;
            proxy_pass              http://unix:/space/redmine/latest/tmp/thin.0.sock;
    }

Wie ich es geschafft habe, das ruby 2.2.3. zu installieren, hab ich vergessen… ich vermute mit dem „bundler install“ aus dem redmine verzeichnis…

Über kurz oder lang werde ich wohl eher auf docker und einen reverse proxy umsteigen, damit sollte das in ner SubURI wohl auch gehen. Ob mein Serverlein für solche Sachen aber dann noch genug Speicher hat? Wer weiss…

laptopbackup

Uiuiui, am 31.3. war  Worldbackupday, da bin ich doch schon wieder 2 Tage zu spät mit meinem script…  aber immerhin, endlich bin ich mal soweit.

Was machts? naja, im Prinzip ists nur ein wrapper um einen rsync Einzeiler. Er schaut nach, ob der letzte Backup länger als 604800 (7 Tage) zurückliegt, ob der Rechner im ethernet ist und der server gepingt werden kann.  Wenn das alles zutrifft, wird rsync gestartet und ab gehts.  Ein wenig notifications und mail, wenns nicht klappt. Fertig ist die Laube.

Klar, das script muss per crontab nach Geschmack wiederholt werden. Ich mach das alle 10 minuten, aber das ist Geschmacksache. Hier nun das Script. Macht draus, was ihr wollt 🙂

Achja: der Trick, dass das überhaupt aus dem cron geht, ist, ein ssh-key ohne passwort zu verwenden und den auf der anderen Seite zu den authorized keys zu tun, aber das wisst ihr ja sicher.

#!/bin/bash
cd /home/foobar
SERVER=192.168.1.2
SCRIPTNAME=`basename $0`
last=0
if [ -f .laptopbackup ]
then
    last=`cat .laptopbackup`
fi
curr=`date '+%s'`

diff=$(($curr-$last))
echo diff: $diff
if [ $diff -gt 604800 ]; then 
    IP=$(/sbin/ip route | awk '/default/ { print $3 }')
    IF=$(/sbin/ip route | awk '/default/ { print $5 }')
    if [ $IP="192.168.1.1" ] && [ $IF="eth0" ]; then

	ping -q -c 1 $SERVER
	if [ $? -eq  0 ]
	then
	    /usr/bin/notify-send $SCRIPTNAME "Starting backup to $SERVER" --icon=dialog-information
	    /usr/bin/rsync -e '/usr/bin/ssh -i /home/foobar/.ssh/foobar_home' -av --delete --exclude-from=stevebackup.exclude . foobar@192.168.1.2:laptopbackup/ > .laptopbackup.log
	    if [ $? -eq  0 ]
	    then
		/usr/bin/notify-send $SCRIPTNAME "Backup to $SERVER finished" --icon=dialog-information
		echo "$curr" &> .laptopbackup
	    else
		/usr/bin/notify-send $SCRIPTNAME "Backup to $SERVER failed" --icon=dialog-information
		mail -s "laptopbackup: Error" skrodzki@stevekist.de < .laptopbackup.log
	    fi
	else
	    /usr/bin/notify-send $SCRIPTNAME "Server $SERVER not reachable" --icon=dialog-information  
	fi
    fi
fi

Party machen… aka Playlists erstellen.

So, bevor ich es vergesse, schreib ich hier mal auf, wie man eine Playliste für eine Party unter Linux erstellt und dann quer über seine Systeme verteilt…

Also so ne Standard-Playliste heisst ja foo.m3u und besteht eigentlich nur aus Dateinamen mit ihren Pfaden. Mehr geht auch, siehe z.B. hier.  Playlisten kann wohl auch mehr oder minder jeder Player und weil eben unter Linux auch m3u, weils offen ist, trotzdem hat mir quodlibet am besten gefallen, da man da Songs einfach mit der rechten Maustaste zu jeweiligen Listen hinzufügen kann und mit einem Haken auch sieht, ob der Song schon drin ist. Ausserdem kann quodlibet die playlists auch mit relativem Pfad speichern. So geht sie eigentlich mit jedem Player und auch mit den mit kopierten Stücken, wenn die Pfade bleiben.

Weil man für die Party evtl. ein schwächeres Gerät hat, welches nicht genug Speicher für die komplette Musiksammlung hat. Kann man diese ja anhand der playlisten kopieren. Hierzu kopiere ich die auf meinem Serverlein vom Verzeichnis „music“ in ein Verzeichnis „playlistmusic“ mittels folgendem Befehl:

sed "s/#.*//g" < party.m3u | sed "/^$/d" | while read line; do cp --parents "${line}" '../playlistmusic/'; done

Für mehrere Playlisten macht man das für jede Playliste hintereinander. Jetzt noch die playlisten auch in das playlistmusic verzeichnis kopieren. Fertig. Dieses Verzeichnis ist nun komplett eigenständig funktionsfähig und die Musikstücke sind in der gleichen Ordnerstruktur wie im Ausgang vorhanden…

So, jetzt noch die Mucke aufs Android Device, z.B. mit rsync backup. Da muss man keine Kabel anschliessen und es ist eigentlich schnell genug und einmal konfiguriert geht es.
Jetzt noch Playlist Backup nehmen, um die m3u dem Android bekannt zu machen, und gut ist. Als Party Player wird wohl Cross DJ eingesetzt werden, mal schauen, ob ich dann korrigieren muss, dass das alles nicht läuft. Aber wenn nicht, kommt die Mucke auf nen alten Laptop und ich nehme Mixxx.

Ubuntu Linux aufdem MEDION AKOYA E6416

Auf dem MEDION AKOYA E6416 läuft Ubuntu (hier ein 15.10) mehr oder minder reibungslos. Für den Preis ein schicker Laptop, FullHD, i5 irgendwas, gutes Gewicht. Da kann man die klapprige Tastatur schon in kauf nehmen. Eine SSD und mehr Speicher ist aber auf jeden Fall nötig, aber geht ja alles problemlos einzubauen.

Was aber nicht ab Werk geht sind ein paar Multimedia-Tasten: vor allem Vol+ und Vol- und Mute nerven, da sie hängen bleiben.

Abhilfe schafft folgende Datei (als root):

/etc/udev/hwdb.d/70-keyboard.hwdb

evdev:atkbd:dmi:bvn*:bvr*:bd*:svnMedion:pn*:pvr*
KEYBOARD_KEY_b0=!volumeup
KEYBOARD_KEY_ae=!volumedown
KEYBOARD_KEY_a0=!mute
KEYBOARD_KEY_19=!p
KEYBOARD_KEY_df=sleep

danach noch ein

udevadm hwdb --update

und ein reboot tut auch gut.

Die pn oben in der hwdb datei könnte man wohl noch genauer angeben, aber ich war zu doof, die passende zu finden.

Fanless Home Server

Das Ziel war es, ein lüfterloses Serverlein zu bauen, das wenig Platz weg nimmt, Strom sparend ist und trotzdem leistungsfähig genug ist, als universeller Server eingesetzt zu werden.

Als Board kommt ein J1800 (siehe Bilder) zum Einsatz, das ist schick, hat leider aber nur zwei SATA Ports. Der dritte für die Systemplatte (eine 30 Gig SSD) wurde über einen USB3 Adapter gebaut. Das System hat keinerlei Lüfter. Die 2,5 Platten werden kaum warm, der Prozessor mit 11 Watt auch nicht, das Netzteil ist extern.

Einen (evtl. auch aktualisierten) Link zur gh Einkaufsliste gibt es hier.

Auf dem System läuft ein normales Ubuntu LTS. Services, die u.a. bereitgestellt werden:

  • ssh z.B. für rsync (Backup von Android phones)
  • samba
  • seafile als personal cloud fileserver
  • SoGO als Kalender und Adressbuch-Server
  • Kodi –  Das Ding ist ja leise, warum sollte es also nicht auch die TV Settop Box spielen? Ah, dafür wurde noch ein IR Empfänger für den LIRC reingefräst.
  • … der Fantasie sind keine Grenzen gesetzt.