Archiv der Kategorie: Computer

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…

Fritzbox und WLAN AP mit Heim- und Gastnetz

Ein kleiner Update der Netzwerkinfrastruktur stand an: man bekommt mittlerweile zu günstigen Preisen Dualbandfähige APs in diskretem Weiß mit PoE, z.B. den Mikrotik wAP ac. Der WAF ist also voll und ganz erfüllt.

Jetzt aber zur technischen Seite: die Fritzbox kann mit der Originolsoftware keine VLANs, aber genau solche braucht man, um Heim- und Gastnetz der Fritte auf ein Netzwerkkabel zum AP zu bringen. Also nimmt man von der Fritte zum Switch nicht nur ein Netzwerkkabel sondern zwei: 1 an Port 1-3, eins an Port 4 und dort eben das Gastnetz auf Port 4 legen. netzwerksetup

Das sieht dann so aus, die Port Nummern sind natürlich willkürlich wählbar beim Switch, aber ich lass die mal so stehen, dann ist der Rest auch verständlich.

Was wirklich hilfreich ist, ist, dazwischen immer mal mit dem Laptop an geeignete Stellen reinzugehen und schauen, obs noch pingt, man eine IP Adresse bekommt etc…

Nachfolgend meine Erkenntnisse auszugsweise, ich geh jetzt nicht drauf ein, wie man einen WLAN AP einrichtet etc. sondern nur das, woran es bei mir hing… auch sollten die Gerätemarken austauschbar sein, das Konzept bleibt gleich – wobei, wenn man eben als Router was anderes als ne Fritzbox im Einsatz hat, könnte es VLANs im Router geben und das Leben wäre leichter.

Switch Setup

Ich habe als Switch einen Zyxel GS1900-24E im Einsatz, aber das Schema sollte bei anderen Switches ähnlich sein.

Wichtig ist jetzt folgendes:  Es muss auf dem Switch zwei VLANs geben: VLAN ID 1 fürs Heimnetz, VLAN ID 2 fürs Gastnetz.

zyxel_vlan
Zyxel Switch VLAN Setup

Zum VLAN1 gehören alle Ports außer dem Port 17 (ich habe noch ein paar weitere Ports geschaltet, falls ich mal ne Gastdose belegen will).

zyxel_vlan2
Zyxel Switch VLAN 1 Setup

Zum VLAN2 gehören eben Port17 und die Gästeports ungetagged und die beiden Ports 23 und 24, wo die APs dranhängen getagged.

zyxel_vlan3
Zyxel Switch – VLAN 2 Setup

Jetzt kommt noch was ganz wichtiges: da der ganze Traffic von Port17 ja aufs VLAN2 soll, muss die entsprechende Port VLAN ID (PVID) entsprechend auf 2 eingestellt werden. Wenn man das vergisst, kommt nix auf dem Gastnetz an.

zyxel_vlan1
Zyxel Switch VLAN PVID setup

Accesspoint Setup

So, jetzt noch ein paar Feinheiten auf der Mikrotik Seite.

Als erstes ist ein VLAN einzurichten, das auf die VLAN ID2 hört. Fürs VLAN1 braucht man nix machen, das ist ja default…

Mikrotik Setup VLAN1
Mikrotik Setup VLAN1

Neben dem Setup der Wireless Interfaces – das Hauptinterface ist das Heimnetz, das Virtuelle ist das Gastnetz ist vor allem ganz wichtig, fürs Gastnetz eine Bridge anzulegen, in die die GastWLANs eingefügt werden.

Mikrotek Gastnetz Brücke
Mikrotek Gastnetz Brücke

Bei den Ports für die Brücken kann man dann die einzelnen Interfaces auswählen… das wars dann auch schon.

Mikrotek Interfaces in Brücken einfügen
Mikrotek Interfaces in Brücken einfügen

 

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.

Der Herr Moore

Immer, wenn ich mir ein neues Speichermedium kaufe, denke ich an meine erste Atari Festplatte mit 20MB und vergleiche das mit der jetzigen Grösse und denke „Holy shit“… bin aber meistens zu faul doch mal konkret auszurechnen, wie das so alles ist. Gestern hab ich in mein Handy eine 128GB µSD Karte eingesteckt… also hat das Teil jetzt insgesamt 144GB „Festplatte“. Das sind dezente 7200 mal so viel, wie der Atari hatte. Über Preis- und Gewichtsrelation mag ich mal gar nicht reden…

JahrMBPreis
1986201200 DM
198840
199080
1992160
1994320
1996640
19981280
20002560
20025120
200410240
200620480
200840960
201081920
2012163840
2014327680
2016655360~ 200 €

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.

MAMEKiosk – Update

Ein Nachtrag zum MAMEKIOSK:

Jetzt geht es darum das ganze auf RPI2 umzurüsten. Und ne USB Audio Karte reinzubauen. Zweiteres ganz einfach mit nem billig-USB-Dongle und dieser Anleitung.

Das aktuelle Image von piplay ist flugs gezogen, aber: pikeyd geht wohl nicht auf dem RPI2… also geschaut und da gibt es Retrogame was das gleiche machen sollte… sieht auch alles gut aus… aber irgendwas klappt da doch noch nicht ganz. Auf jeden Fall muss die obige Verdrahtung in retrogame.c so hardgecodet sein:


ioStandard[] = {
 { 7, KEY_LEFT }, // Joystick (4 pins) 
 { 9, KEY_RIGHT },
 { 10, KEY_DOWN },
 { 11, KEY_UP },
 { 17, KEY_LEFTCTRL }, // A/Fire/jump/primary 
 { 22, KEY_LEFTALT }, // B/Bomb/secondary 
 { 4, KEY_SPACE }, // C 
 { 8, KEY_5 }, // Credit
 { 15, KEY_1 }, // Start 1P 
 { 14, KEY_2 }, // Start 2P 
 { -1, -1 } }; // END OF LIST, DO NOT CHANGE 

Ob das nun funktioniert hat, kann man z.B. mit input-events 1 nachprüfen (aus dem input-utils paket).

Was ich noch nicht rausbekommen habe: welches das input mapping für die Bestätigung von safequit ist, also hab ich misc_safequit no in advmame.rc gesetzt. Ah, habs: [ui_select] isses… also doch safequit an.

BTW: ich hab doch das alte advmenu vom alten pimame genommen, das gefällt mir wesentlich besser als die ganzen vielen Emulatoren, ich will eh nur advmame.

Ergebnis vom Ganzen? Einiges gelernt, einiges gebastelt und: alles ist viel flüssiger und der Ton eiert nicht mehr rum, wenn die CPU unter Last kommt! Hat sich also gelohnt!

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.