Archiv der Kategorie: Memo

Notizen zum build von LOS für Flo / Mako

Damit ich es nicht vergesse, was hier Schritt für Schritt abzuarbeiten ist bei der Erstellung von neuen Images für Flo und Mako:

## Note for Mako and Flo LOS builds
## Flo
## See https://wiki.lineageos.org/devices/flo/build
## repo init -u https://github.com/LineageOS/android.git -b cm-14.1
## Mako 
## https://wiki.lineageos.org/devices/mako/build
## repo init -u https://github.com/LineageOS/android.git -b lineage-15.1
##
## Keep buildenv up to date
## in this case in two sub-dirs in ~/android:
## ~/android/flo and ~/android/mako
##

cd ~/android/flo ; repo sync
# or
cd ~/android/mako ; repo sync

# if we run into problems with repo sync this might help:
# repo sync --force-broken --force-sync

##
## Source and export what we need for build
##

source build/envsetup.sh  

export LC_ALL=C
export USE_CCACHE=1
export ANDROID_JACK_VM_ARGS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4G"

##
## Start build process
##

breakfast flo
# or
breakfast mako

# change dir to pull in proprietary blobs from device
cd ~/android/flo/device/asus/flo
# or
cd ~/android/mako/device/lge/mako

# Connect device via USB
# Check your path: 
# ~/android/flo/device/asus/flo
# ~/android/mako/device/lge/mako
# Check that USB debugging is ON on device
# Can we see the device?

adb devices

# pull the proprietary blobs in
./extract-files.sh 

# prepare compile
ccache -M 50G
croot

# compile
brunch flo
# or
brunch mako

## 
## Install the image
##

cd $OUT
adb reboot sideload
adb sideload lineage [TAB]
# return to sideload mode
adb sideload addonsu [TAB]

Mit je einem Image ist hier der Ordner für Flo ca. 85G und der Ordner für Mako rund 122G groß.

getmyfreetraffic redirect

Wer, wie ich, ein wenig zu lang (in meinem Fall: 2 Tage) wartete, um das Update für Easy WP SMTP einzuspielen, deswegen gehackt wurde und nun vor lauter Redirects sein Blog nicht mehr sieht: hier mein Weg zu einer wieder funktionierenden Multiblog-Installation inklusive der Schilderung meiner Stolpersteine:

  1. Das Firefox Addon noscript verhinderte zuverlässig, dass ich bei der Begutachtung des eigenen Blogs dauernd von der eigenen Site weggeschubst wurde und im Orkus landete.
  2. Die eigentliche Reparatur erfolgte nach dieser Anleitung auf Stackoverflow. Ich wählte für meine Reparatur Option 2 – also den Weg über die functions.php im Theme-Ordner.
  3. Jedoch: Bei mir war ein Subblog gehackt worden, das das gleiche Theme verwendete wie das Hauptblog. Trägt man nun die geforderten Zeilen im Theme ein, muss man sich entscheiden, welches Blog man zuerst retten will, denn hieraus ergibt sich der einzutragende URL
    update_option( 'siteurl', 'https://bdjl.de' );
    update_option( 'home', 'https://bdjl.de' );

    Wie oben zu sehen, war das in meinem Fall die Hauptdomain (und das konkrete Theme: twentytwelve).

  4. Das beschriebenen Vorgehen über die functions.php von twentytwelve für das Hauptblog führte dazu, dass die Posts im Subblog mit dem gleichen Theme nicht mehr zu erreichen waren, weil für die nun die URLs des Hauptblogs galten … also lauter leere Seiten.
  5. Immerhin funktionierte ab diesem Punkt das Backend des Hauptblogs wieder. Hier stellte ich dann die Themes aller meiner Blogs in der Multisite Installation um auf twentyten. Nur das gehackte Subblog behielt twentytwelve.
  6. Jetzt wurde im Theme twentytwelve
    update_option( 'siteurl', 'https://bdjl.de/subblog' );
    update_option( 'home', 'https://bdjl.de/subblog' );

    die Haupt-URL des Subblogs eingetragen, die Seite einmal aktualisiert und: die Posts waren alle wieder da.

Dringend angeraten ist eine Passwortänderung für a) den Mail-Account und b) die Datenbank (MariaDB, MySQL). Weiter würde ich dazu raten, die Datenbank von WordPress nach der Reparatur zu dumpen und dann im Dump nach allen möglichen Strings zu suchen, die im Kontext dieses Überfalls irgendwie Sinn machen könnten. Weitere Schritte sind auch hier beschrieben:

https://codex.wordpress.org/FAQ_My_site_was_hacked

https://wordpress.org/support/plugin/easy-wp-smtp/

TC und EDS-Lite

Als Notiz für die, die es brauchen: Für EDS-Lite können TrueCrypt-Container (ja – auch VeraCrypt geht, aber das Schutzniveau muss ja nicht in und für jeden Fall so gesetzt werden) mit den Einstellungen oben schneller auf dem Rechner, als auf dem Tablet angelegt werden:

Encryption Algorithm: Twofish
Hash-Algorithm: SHA-512

Die Standardvorgaben von TrueCrypt scheinen für EDS-Lite nicht zu funktionieren.

Proxmox mit LXC bei Hetzner

Xen? KVM? LXC? Oder gar systemd-nspawn? In der Schule drehen wir uns bezüglich der Virtualisierungsbasis für unsere Cloud hübsch im Kreis. Aktuell neige ich LXC zu, musste aber bei meinen ersten Gehversuchen einige Schläge einstecken: Restricted Container zickten, Debian Jessie Container auf Ubuntu 16.04 als Wirt ebenfalls, das Netzwerk-Setup war fummelig und die Namensauflösung in den Containern selbst immer wieder „einfach weg“ …

Also das schlechte Wetter heute mal sinnvoll genutzt und einen ganz anderen Weg beschritten: nicht wie sonst per Shell gearbeitet, sondern heute mal per Oberfläche gefummelt und mir Proxmox näher angesehen. Geht flott und funktioniert zügig. Hier eine kurze Doku.

Im Hetzner installimage das aktuelle Debian auswählen – hier: Jessie. Setup durchführen, Updates installieren, neu booten und dann an die Arbeit.

Hinweis für die Partitionierung: Die LXC-VMs werden später unter /var – genauer: /var/lib/vz/images – liegen.

echo "deb http://download.proxmox.com/debian jessie pve-no-subscription" >> /etc/apt/sources.list
wget -O - http://download.proxmox.com/debian/key.asc | apt-key add -
apt-get update
apt-get upgrade
apt-get dist-upgrade
uname -a
reboot

Ich habe mir dann „die volle Packung Proxmox“ installiert:

apt-get install proxmox-ve ssh postfix ksm-control-daemon open-iscsi systemd-sysv mailutils

Nach einem erneuten Reboot zeigte ein uname -a nun

Linux hostname 4.4.59-1-pve #1 SMP PVE 4.4.59-87 (Tue, 25 Apr 2017 09:01:58 +0200) x86_64 GNU/Linux

Also frisch in Proxmox unter https://server.domain:8006 mit dem PAM Account für root angemeldet und dort eine neue VMBR0 angelegt, die erst einmal unkonfiguriert blieb.

Reboot. Proxmox übernimmt sonst die Änderungen nicht.

Dann das restlichen Netzwerk-Setup von Hand erledigt.

Die Basis-IP des Server war

78.78.78.82

Dazu kamen zwei über den Robot zusätzlich bestellte IPs

78.78.78.86
78.78.78.90

Es ergab sich damit für /etc/network/interfaces diese Konfiguration:

auto lo
iface lo inet loopback
iface lo inet6 loopback

# ETH0
auto eth0
iface eth0 inet static
  address 78.78.78.82 # Server Basis IP
  netmask 255.255.255.255 # Netzmaske neu gesetzt
  gateway  78.78.78.65 # wird von Hetzner mitgeteilt
  pointopoint 78.78.78.65 # PTP auf das Gateway

# VMBR0

auto vmbr0
iface vmbr0 inet static
  address 78.78.78.82 # Server Basis IP
  netmask 255.255.255.255 # Netzmaske neu gesetzt
  bridge_ports none
  bridge_stp off
  bridge_fd 0
    up ip route add 78.78.78.86/32 dev vmbr0 # erste VM mit erster Zusatz-IP
    up ip route add 78.78.78.90/32 dev vmbr0 # zweite VM mit zweiter Zusatz-IP

# IPv6 Config 

iface eth0 inet6 static
        address  121:121:121:121::2
        netmask  128
        gateway  fe80::1
        up ip -6 route add default via fe80::1 dev eth0
        up sysctl -p

iface vmbr0 inet6 static
        address 121:121:121:121::2
        netmask 64

Für jede weitere IP, die im vorliegenden Fall noch kommen mag, muss man für die VMBR0 eine Zeile ergänzen. Ich denke, das Schema ist nachvollziehbar. Die restliche IP-Konfiguration läuft über Proxmox direkt (siehe unten).

Es folgt die Anpassung von /etc/sysctl.conf

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
net.ipv6.conf.all.forwarding=1

Reboot.

Und ab jetzt geht es klickend in Proxmox weiter. Zuerst zieht man sich die benötigten Templates (hier: für Ubuntu und Debian). Dann legt ein Klick auf das entsprechende Icon die erste VM als LXC an. Der erste Container erhält als IP im hier vorliegenden Fall

78.78.78.86/32

und für seine Gateway-Adresse die Basis-IP des Servers:

78.78.78.82

Der Rest – also die Ressourcenzuteilung usw – war für die Testmaschinen dann eine Geschmacksfrage.

Die Verwaltung (Softwareinstallation etc.) der einzelnen VMs nahm ich lieber direkt auf dem Wirt vor. Da reagiert die Shell einfach zügiger als jedes Frontend. Ein

lxc-attach -n 100

bindet den zuerst erzeugten LXC an die Rootshell.

Ein internes Netzwerk, über das die VMs untereinander sprechen können, ist auch schnell eingerichtet: Auf dem Host oder auch über Proxmox in die /etc/network/interfaces

auto vmbr1
iface vmbr1 inet static
        address  10.16.1.0
        netmask  255.255.0.0
        bridge_ports none
        bridge_stp off
        bridge_fd 0

Reboot und in Proxmox dann der jeweiligen Maschine eine neue Netzwerkkarte (eth1) geben, die an die vmbr1 gebunden wird, passende IP und Netzmaske setzen – voila.

Erste Messungen mit iperf geben so um die 55 Gbit/sec.

Erstes Ergebnis:

  • Netzwerksetup, Einrichtung, Verwaltung laufen rund und zügig ab
  • Die Templates für Proxmox kommen ziemlich „dick“ mit Software ausgestattet daher. So würde ich diese ungern als Basis für eigene VMs nutzen

OMD auf Ubuntu 16.04 quick setup

Mein hausinterner Monitoring- und Nameserver wollte sich nicht ohne Zicken von 14.04 auf 16.04 schubsen lassen. Also setzte ich diesen neu auf und durfte dann OMD neu installieren. Meine Notizen:

wget https://mathias-kettner.de/support/1.2.8p15/check-mk-raw-1.2.8p15_0.xenial_amd64.deb
dpkg -i check-mk-raw-1.2.8p15_0.xenial_amd64.deb
apt-get install -f
service apache2 restart
omd create bdjlhome
su - bdjlhome

In /omd/sites/bdjlhome ist dessen Homeverzeichnis gelandet. Dort dann ausführen:

omd config
omd start
exit

Das OMD Config stellte ich auf Web GUI sowie Multisite und übernahm dort im Wesentlichen die vorhandenen Einstellungen:

Um den Monitoring-Server ebenfalls überwachen zu können folgte die Installation und Konfiguration (die dann auf allen zu überwachenden Clients ebenfalls durchgeführt werden muss):

apt-get install check-mk-agent xinetd nagios-plugins-basic
apt-get install -f

Die /etc/xinetd.d/check_mk sieht nach den nötigen Anpassungen wie folgt aus:

service check_mk
{
        type           = UNLISTED
        port           = 6556
        socket_type    = stream
        protocol       = tcp
        wait           = no
        user           = root
        server         = /usr/bin/check_mk_agent

        # If you use fully redundant monitoring and poll the client
        # from more then one monitoring servers in parallel you might
        # want to use the agent cache wrapper:
        # server         = /usr/bin/check_mk_caching_agent

        # configure the IP address(es) of your Nagios server here:
        only_from      = 127.0.0.1

        # Don't be too verbose. Don't log every check. This might be
        # commented out for debugging. If this option is commented out
        # the default options will be used for this service.
        log_on_success =

        disable        = no
}

Für die Clients muss dann bei only_from die IP des Monitoring-Servers eingetragen werden.

Weiter geht es für die mrpe.cfg:

mkdir /etc/check_mk
vi /etc/check_mk/mrpe.cfg

Hier schaltete ich APT und SSH Checks frei:

# APT Check
APT_CHECK /usr/lib/nagios/plugins/check_apt
# SSH Check
SSH_CHECK /usr/lib/nagios/plugins/check_ssh localhost

Fail2ban soll ebenfalls überwacht werden:

vi /opt/omd/sites/bdjlhome/local/share/check_mk/agents/plugins/fail2ban

In der Config für diesen Agent steht

#!/bin/sh
echo '<<<fail2ban>>>'
if [ -x /usr/bin/fail2ban-client ]; then
JAILS=`/usr/bin/fail2ban-client status | grep "Jail list" | tr -s [:blank:] | cut -f2- -d':' | sed -e 's/,/ /g'`
        echo "Detected jails: $JAILS"
        for jail in $JAILS
        do
                /usr/bin/fail2ban-client status $jail
        done
fi

und dann muss diese noch ausführbar sein:

chmod 755 /opt/omd/sites/bdjlhome/local/share/check_mk/agents/plugins/fail2ban

755 ist etwas arg dick aufgetragen, tut es aber für’s Heimnetz.

Dann den xinetd und den Apache neu starten:

service xinetd restart
service apache2 restart

Ob überhaupt Daten ankommen ist zu prüfen:

telnet localhost 6556

Die Anmeldung an OMD erfolgt im Browser an der lokalen IP (bei mir an dieser Stelle noch ohne Namensauflösung: https://10.16.X.X/bdjlhome) als omdadmin mit omd als Passwort, das nach dem ersten erfolgreichen Login geändert wird.

Im Main Menü unter Hosts wird dann der lokale Monitoring-Server eingerichtet. Rechts oben gibt es den Schalter New host. Diesem einen Namen und die passende IP (in diesem Fall 127.0.01) geben und über Save & go to Services speichern. Wenn alles klappt lässt sich hier gleich eine Service discovery durchführen und für diesen Host abspeichern.

Zurück im Main Menu: Wie üblich bei OMD müssen die Änderungen durch eine Reihe von Klicks auf farblich hervorgehobene Schalterchen erst aktiviert werden.

Ein Klick auf Hosts zeigt die Liste der schon eingetragenen Server an. Zur nachträglichen Service Discovery folgt der Klick auf das Icon „Notizbrett mit grünem Haken“ das im Overlay „Edit the services of this hosts, do a service discovery“ anzeigt.

… und nach ein wenig mehr Geklicke sind die lokalen Hosts eingetragen. Praktisch ist die Notification Funktion. Die warnt mich per Mail, wenn auf einem der Rechner etwas aus dem Lot gerät. In Ermangelung einer statischen IP verwende ich hierzu einen Postfix als Satellitensystem – aber das ist eine andere Geschichte.

Firefox 46 auf Kubuntu 14.04

kubuntu-gtk-options

Der Firefox-Dialog [Ziel speichern unter ,,,] ließ sich seit dem Update auf Firefox 46 unter Kubuntu 14.04 LTS nicht mehr richtig bedienen. Die Einträge in der linken Fensterhälfte unter Orte, Geräte und Lesezeichen reagierten nicht mehr auf Klicks und die Speichern bzw. Abbrechen Buttons reagierten zumindest komisch, mussten oft mehrfach angeklickt werden. Lediglich der Krümelpfad im Dialogfenster konnte noch zur Navigation in den Ordnern verwendet werden. Das könnte mit einem Bug im Zusammenhang stehen, der Firefox unter Ubuntu 12.04 im Moment komplett unbrauchbar macht.

Was hier geholfen hat, war, das Verzeichnis ~/.config/gtk-3.0/ zu löschen. In den KDE-Systemeinstellungen ist das GTK-3-Design danach auf Default zurückgestellt.

Firefox passt sich hiernach nicht mehr so hübsch in den Desktop ein. Die Fensterrahmen haben nun einen anderen graublauen Ton, als Firefox selbst.

gnupg 8192

Janis entdeckt (endlich wieder) Verschlüsselung. Enigmail will aber nicht funktionieren – deswegen muss gnupg direkt an die Arbeit.

Erstens eine Textdatei erstellen mit dem folgenden Inhalt:

Key-Type: RSA
Key-Length: 8192
Name-Real: Vorname Nachname
Name-Email: emailadresse@domain.tld
Expire-Date: 2y
Preferences: SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES TWOFISH CAST5 BZIP2 ZLIB ZIP Uncompressed

und dann den Key erzeugen lassen mit

gpg --gen-key --batch --enable-large-rsa <dateinamevonoben>

Das dauert ne kleine Ewigkeit (je nach Rechner und vorhandenem Zufall).

Da fehlt nun das Passwort. Also zuerst die Schlüssel-ID herausfinden:

gpg --list-keys

und dann den Schlüssel editieren:

gpg --edit-key <Schluessel-ID>
gpg> passwd
gpg> save

Der Schlüssel lässt sich dann in Enigmail importieren. Das Widerrufszertifikat kann dann dort erstellt werden, oder eben auch mit gnupg:

gpg --output widerrufszertifikat.asc --gen-revoke <Schluessel-ID>

gnupg stellt dann einige simple Fragen und alles wird gut. Das Widerrufszertifikat dann am einfachsten als Anhang in keepassx speichern.

Das Einzige, was mich stört, ist, dass Janis nun längere Schlüssel hat als ich 🙂

ownCloud Passwort

An der Zickigkeit von ownCloud auf Debian hat sich auch mit dem Upgrade auf die Version 6 wenig geändert. Während auf meinen Ubuntuservern das Upgrade schon immer einfach durchlief, maulte ownCloud mit der gleichen Berechenbarkeit am Ende eines jeden Upgrades auf einem Debian rum, dass das Passwort mindestens eines Benutzers nicht mehr funktioniere etc. pp. Meist lag es am Inhalt der .htaccess Dateien im ownCloud Ordner gepaart mit Firefox und seiner für mich schwer durchschaubaren Cache Verwaltung, die mir hier dazwischen kamen. Da half dann oft die Nutzung von Rekonq – oder eben Anpassungen der .htaccess Files. Heute wollte alles nicht helfen – der Bug saß wo anders (und ich weiß noch nicht wo). Also sah ich mich gezwungen, den Versuch eines Passwort Resets für den Benutzer admin auszuprobieren – was mit phpMyAdmin einfach umgesetzt werden kann.

ocusers

Die Tabelle oc_users auswählen und dort beim gewünschten Benutzer – hier: admin – auf „Edit“ klicken.

adminpw

SHA1 auswählen und das neue Passwort im Klartext eingeben. Durch Klick auf GO speichern. Das Passwort für den Benutzer liegt nun ungesalzen in der Datenbank! Deswegen folgt der nächste Schritt.

oc_personal

An ownCloud anmelden (was funktionieren wird) und nach Klick auf den Benutzernamen (rechts oben) zum Passwort-ändern Dialog von ownCloud navigieren. Dort das so eben gesetzte und ein neues Passwort eingeben.

Nur dieser letzte Schritt stellt sicher, dass das Passwort für diesen Benutzer auch gesalzen in der Datenbank landet, was eine kurze Kontrolle in phpMyAdmin auch bestätigt.