Projektübersicht

Ein Linux-Rechner kann gut als Terminalserver genutzt werden. Um Windows-Standards einzuhalten ist dabei xRDP als TS-Software das Mittel der Wahl. xRDP ist im Ubuntu-Software-Repo enthalten und kann daher einfach installiert werden. Einziges Problem, die Konfiguration in Ubuntu ist sehr speziell, schwankt von Ubuntu Version zu Version und wird nicht in allen Fällen funktionieren.

Ein guter Ratgeber zur Installation ist in Griffon's IT Library zu finden.

Die Installation war damit erfolgreich. Folgende Probleme sind aber anzumerken:

• Unity als Window-Manager funktioniert seit Jahren nicht mit xRDP. Daher ist Xubuntu das Mittel der Wahl für den Terminalserver.
• Der Eintrag xfce4-session in der Datei ~/.xsession ist unbedingt erforderlich, sonst entsteht ein grauer Bildschirm
• Hi-Color Farbtiefe ist erforderlich, 256 Farben sorgen für den grauen Bildschirm
• Das alte Problem mit den „hängenden Session's“ ist nach wie vor vorhanden. Der Hack mit der Port-Nummer funktioniert aber super. Als PortNr muss der Port hinter 127.0.0.1 verwendet werden (59xx → xx = Terminalnr), dann klappt es. In Ask Ubuntu wurde das Thema auch behandelt, eine bessere Lösung scheint es aber nicht zu geben. In der Datei /etc/xrdp/xrdp.ini für [xrdp1] port=ask-1 eintragen, dann kann eine Portnummer eingetragen werden sofern bekannt.
• Ansonsten muss regelmäßig auf alte Sessions geprüft werden und/oder der TS-Service restartet werden. Dabei können die folgenden Kommandos helfen:

$ netstat -tulpn | grep vnc
$ ps -ef | grep Xvnc

• vagrant, virtuelle Maschinen und die Session war ein spannendes Thema! xRDP hat sich dabei ausgezeichnet geschlagen. Als Testsystem für eine heterogene Systemumgebung konnten die Entwickler neue Funktionen sofort ausprobieren ohne einen RollOut anstoßen zu müssen.
• /etc/xrdp/sesman.ini ist eine wichtige Verwaltungsdatei. Dort wird u. a. festgelegt, wie viele TS Sessions gleichzeitig arbeiten können (Default = 10). Auch die Einschränkung der User auf die group 'tsuser' kann Ursache für Probleme bei der Anmeldung sein. Näheres kann man mit $ man sesman.ini erfahren.
• Und dann ist da noch die Sache mit der TAB-Taste in xfce. Die funktioniert nämlich nicht, wenn man sich per xrdp anmeldet. Dafür gibt es Abhilfe:
  

you may find that this is a more general issue with interception of the Tab key under remote XFCE4 sessions, rather than a problem with bash completion itself.
I had a similar issue running XFCE4 over VNC and the workaround for me was to edit the ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml file to unset the following mapping

<       <property name="&lt;Super&gt;Tab" type="string" value="switch_window_key"/>
---
>       <property name="&lt;Super&gt;Tab" type="string" value="empty"/>

Bei einem Zugriff auf einen Rechner aus dem Internet via rdp ist die Sicherheit nicht gewährleistet. Der rdp-Port 3389 ist ein zusätzliches Einfallstor für Hacker. Ein sicherer Zugriff sollte immer durch ssh geschützt werden. Es ist möglich, den Zugriff auf xrdp durch einen ssh-Tunnel abzusichern.

Erzeugung des ssh-Tunnel auf dem lokalen Rechner und Remotezugriff auf 192.168.178.n:

$ ssh -L 33389:localhost:3389 192.168.178.n -N &
$ rdesktop localhost:33389

Alternativ die Erzeugung des ssh-Tunnel auf einem vServer 192.168.178.x und Remotezugriff auf 192.168.178.n:

$ ssh -L 192.168.178.x:33389:localhost:3389 192.168.178.n -N &

Remmina kann diese Tunnel proprietär erzeugen, bei einem Zugriff aus dem Internet ist der Schalter Tunnel über loopback-Adresse notwendig, da ist originäre IP-Adresse des Servers nicht erreichbar ist.

Auf dem Zielserver wird mittels Firewall ausschließlich der Port 22 freigeschaltet. Ein direkter Zugang mit xrdp auf dem Port 3389 ist damit ausgeschlossen. Um den Zugang noch mehr zu sichern sollte der ssh - Zugang ausschließlich per Public-Key-Verfahren zugelassen werden. Dafür muss in der Datei /etc/ssh/sshd_config„ der Eintrag

PasswordAuthentication no

gesetzt werden.

Das ssh-Portforwarding kann auch für die Anbindung einer Mysql/Mariadb Datenbank verwendet werden.

$ ssh -L 33066:localhost:3306 192.168.178.n -N &

erzeugt einen lokalen Port 33066 auf dem die Datenbank erreicht werden kann.

Wichtig ist, dass die Mysql-Direktive „skip-name-resolve“ ausgeschaltet ist, da sonst ein Zugang ausschließlich per localhost und nicht auch per 172.0.0.1 möglich ist.

Auf einem Debian 9 System kann xrdp einfach mittels sudo apt install xrdp installiert werden.

Allerdings muss eine Änderung durchgeführt werden, damit der Zugriff dann auch funktioniert.

Die Datei /etc/X11/Xwrapper.config muss wie folgt angepasst werden, sonst kommt nur ein grüner Bildschirm:

#allowed_users=console
allowed_users=anybody

Auf einem Debian 10 System kann xrdp ebenfalls mittels sudo apt install xrdp installiert werden.

Wenn Xorg als session-Manager verwendet wird erscheint der Mauszeiger als dicker schwarzer Block. Das Verhalten kann beeinflusst werden, wenn auf dem Zielsystem

sudo sed -e 's/^new_cursors=true/new_cursors=false/g' \
           -i /etc/xrdp/xrdp.ini

eingetragen wird.

Wenn Gnome 3 als Window-Manager zum Einsatz kommt kommt es zu einem Problem mit dem File-Manager Nautilus. Im rdesktop muss „Copy+Paste“ abgeschaltet werden, da der Nautilus sonst klemmt. Der Aufruf lautet daher

$ rdesktop -g 80% -r clipboard:off 192.168.122.11

Um den Aufruf zu vereinfachen, habe ich /usr/local/bin/xdebian10 angelegt.

Und dann ist da noch das Problem mit den Polkit-Popups.

In Griffon's IT Library sind dazu mehrere Artikel entstanden, die erläutern warum das Problem entsteht und was man dagegen tun kann.

Es handelt sich um das Verhalten der System Policies bei einem Remote Zugriff. Um hier Abhilfe zu schaffen muss eine Datei erzeugt werden:

root@debian10:/etc/polkit-1/localauthority/50-local.d# cat 45-allow-colord.pkla 
[Allow Colord all Users]
Identity=unix-user:*
Action=org.freedesktop.color-manager.create-device;org.freedesktop.color-manager.create-profile;org.freedesktop.color-manager.delete-device;org.freedesktop.color-manager.delete-profile;org.freedesktop.color-manager.modify-device;org.freedesktop.color-manager.modify-profile
ResultAny=no
ResultInactive=no
ResultActive=yes

[Allow Package Management all Users]
Identity=unix-user:*
Action=org.debian.apt.*;io.snapcraft.*;org.freedesktop.packagekit.*;com.ubuntu.update-notifier.*
ResultAny=no
ResultInactive=no
ResultActive=yes

Das Problem wird im Debian Forum diskutiert. Die Lösung liegt in der Zugriffsbeschränkung auf das X11 System.

In der Datei “/etc/X11/Xwrapper.config„ die „allowed_users“ auf „anybody“ stellen:

 
#allowed_users=console
allowed_users=anybody

In Debian 11 wird die rdp-Verbindung nicht richtig aufgebaut, es erscheint ein weißer Bildschirm. Hintergrund ist, dass eine ssl-Verbindung aufgebaut werden soll und daher auf dem Server der Zugriff auf ssl ermöglicht werden muss.

Add XRDP user to SSL-Cert group aus Linux Shout

$ sudo adduser xrdp ssl-cert
$ sudo systemctl restart xrdp

Ansonsten funktioniert xrdp problemlos…

In den Medien wird zunehmend über die Gefahr von Trojanern auf Windows Computern berichtet. Hierbei sind vor Allem die sogenannten Verschlüsselungstrojaner gefährlich, denn Daten können sehr wertvoll sein und die Erpressung durch die Versender der Trojaner ist ein einträgliches Geschäft.

Für Stefans Windows Workstation habe ich daher vor, alle wichtigen Daten auf einem Linux Server zu sichern. Als System kommt dabei sein alter Desktop Rechner in Frage. Mit 2 GB RAM nicht sehr groß, aber für den Zweck bestimmt ausreichend.

Backup für Windows Desktops

Die Verschlüsselung von eMails bekommt eine größere Bedeutung seitdem die flächendeckende Überwachung des Internets durch NSA und anderen Geheimdiensten aufgedeckt wurde.
Grundsätzlich gilt weiterhin, eMails sind wie Postkarten zu behandeln, das heißt Informationen, die man auch auf eine Postkarte schreiben würde sollten auch weiterhin unverschlüsselt versendet werden. Alles andere stellt einen unnötigen zusätzlichen Arbeitsaufwand dar.
Dieses Projekt beschreibt Erkenntnisse beim Einstieg in die E-Mail Verschlüsselung.

Es kann spannend sein, zu Hause einen E-Mail Server einzurichten. Dabei existiert ein Router, der den Zugang zum nternet ermöglicht und per DynDNS einen DNS-Namen besitzt. Da durch DynDNS ständig andere IP-Ardessen verwendet werden macht es Sinn, die E-Mails zunächst bei einem Provider zu speichern und per fetchmail auf den lokalen Mails-Server zu übernehmen. Postfix bildet den eigentlichen MTA und dovecut ermöglicht den Zugriff von E-Mail Clients per IMAP und SMTP.

Eine umfassende Anleitung steht in http://mein.homelinux.com/wiki/mailserver/mailserver

28.01.2014: Für die enadCo habe ich eine Darstellung von Daten mit Hilfe einer Baumstruktur erstellt. Grundlage ist eine mysql-Datenbank, aus der mit Hilfe von php Daten ausgelesen und durch javaskript navigierbar werden.

Source: katalog.tgz

jsTree Home
jsTree Tutorial

jsTree: vakata-jstree-3.0.0-beta4-0-g1e2e7d9.zip

Quelle: http://www.pcwelt.de/ratgeber/Aktuelle_Linux-Distros_im_PC-WELT-Check-Linux-Distributionen-7971293.html

Es sollen Server mit Linux - Betriebssystem eingerichtet werden. Die Systeme werden als virtuelle Maschinen laufen. Die verschiedenen Linux Distributionen sollen hinsichtlich

• Stabilität
• Wartbarkeit
• Performance
• Sicherheit
• Marktentwicklung

untersucht werden. Die Untersuchung basiert auf dem Stand 01/2014.

Erste Aspekte zum Thema Datenbankwartung enthält die Seite http://www.wisegeek.org/what-is-database-maintenance.htm.

Ziele der Datenbankwartung sind:

• Backup und Restore
• Suche nach Fehlern und Problemen
• Index Rebuild
• Entfernen von Duplikaten und Waisen
• Aufzeigen von Abnormalitäten
• Daten-Management

Primär ist das Thema für mich auf mySql-Datenbanken ausgerichtet. Es gibt aber auch einen CouchDB-Server, was ein völlig anderes Datenbank-Konzept ist und dementsprechend andere Wartungserfordernisse mitbringt.

https://sites.google.com/site/easylinuxtipsproject/xubuntu

Durch das Ende von Windows XP und die neue LTS Xubuntu Version 14.04 derzeit die Gelegenheit neue Anwender für den Einsatz von Xubuntu zu gewinnen. Es gibt noch immer Anwendungsfälle, wo ein Windows Rechner erforderlich ist, aber es werden immer weniger. Die meisten Firmen bieten Softwarelösungen inzwischen auch für Linux an oder es gibt eine Web-basierte Lösung, die ohnehin auf jedem Betriebssystem läuft.

Der PC sollte jünger als 10 Jahre sein, 1 GB RAM sind Minimum. Ansonsten läuft speziell auch alte Hardware problemlos mit Xubuntu. Für die Installation ist ein Internet-Anschluss erforderlich, hier ist ein lokales Netzwerk mit DSL-Router zu empfehlen. Die direkte Anbindung des PC an ein DSL-Modem ist aufwendig zu konfigurieren.

Die Anwender-Daten des PC müssen gesichert werden. Eine parallele Installation von Xubuntu ist möglich, dann kann auch nachträglich noch auf die Daten zugegriffen werden. Allerdings existiert das unsichere Windows XP damit weiter.

Als allgemeine Information kan die Seite Do this first in Xubuntu verwendet werden. Nicht alle Tipps müssen befolgt werden, aber eine Prüfung ist allemal gut. Auf der Seite gibt es auch eine Checkliste, die abgearbeitet werden kann. Weiter Themen sind:

• ssh Server einrichten
• Unteres Dock einrichten
• Samba/smbclient einrichten
• backup / rsnapshot einrichten
• Standard Schrift in Libre Office definieren
• asunder als CD-Ripper einrichten
• Drucker / Scanner einrichten
• Brasero installieren als BrennSoftware
• Dauer bis Sperre / StandBy einrichten, ggf. disable LightLocker
• ntp installieren
• seahorse installieren
• Einfach- oder Doppeklick

siehe Xubuntu 12.04 auf dem eeePC 4G
und Das perfekte Netbook

17.05.2015: noch offene Themen…

• Drucker
• Video - Fehler
• Disable Upgrade Button in Software & Updates
• Disable Touchpad to 1 sec
• Check 3D Compiz
• sudo apt-get purge apt-xapian-index
• Einfach- oder Doppelklick???
• neues Passwort!!!
• (Seahorse)
• (ZRam)
• (sudo apt-get install xfce4-whiskermenu-plugin)

GIT Guide
Think like (a) GIT

Hier ist beschrieben, wie man einen einfachen git-Server installiert: Git über HTTP

Leider ist diese Beschreibung an ein paar Stellen veraltet. Mir ist es trotzdem gelungen, ein git-Repository per http auf einem ansonsten ungenutzten apache-Server erreichbar zu machen.

Kommando: $ git clone http://pleione/cgi-bin/git.cgi/ufw.git

Folgende Hinweise:

Per default ist das Verzeichnis /usr/lib/cgi-bin für cgi-Skripte vorgesehen. Die Einstellungen sind in /etc/apache2/conf-enable/serve-cgi-bin.conf. Folgende Änderungen wurden gemacht:

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
		<Directory "/usr/lib/cgi-bin">
			Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
			# AllowOverride None
			Require all granted
			AllowOverride AuthConfig
		</Directory>

AuthUserFile /usr/lib/cgi-bin/.htpasswd
AuthType Basic
AuthName "Git Private"
Require valid-user

# SetEnv GIT_PROJECT_ROOT /usr/lib/cgi-bin/git-repos
# SetEnv GIT_HTTP_EXPORT_ALL

Die Umbelegung von GIT_PROJECT_ROOT hat nicht funktioniert, daher liegen die git-Repo's in /var/www/html. .htpasswd muss mit htpasswd -c .htpasswd erzeugt werden.

In /var/www/html wird als www-data ein Clone des Original git Repository angelegt. www-data muss entsprechende Rechte besitzen. Durch den Schalter –bare werden nur die git-Dateien erzeugt, die Daten bleiben im Original. Die Datei git-daemon-export-ok ermöglicht den Zugriff per Web.

www-data:/var/www/html$ git clone --bare /home/sonoxo/ufw ufw.git
www-data:/var/www/html$ touch ufw.git/git-daemon-export-ok

VORSICHT!: Der Clone ist ein unabhängiges Original. Änderungen per git push werden nur innerhalb der über http zugreifenden git-Clones ausgetauscht. Also am Besten ganz auf http umstellen, oder keine Änderungen in den fernen Repos durchführen!

Für das enadco billing project wurde ein neues Repository database-recources erzeugt.

Erzeugung des lokalen Clone:

$ git clone https://koecher_a@stash.enadco.net/scm/bm/database-resources.git
$ cd database-resources

Nun können die Dateien verändert oder gelöscht oder auch neue Dateien hinzugefügt werden.

Bevor Änderungen an den Dateien durchgeführt werden muss die lokale Kopie des Projekts synchronisiert werden.

$ git pull

Zum Einchecken eines neuen Stands muss zunächst ein commit erzeugt und das Ergebnis dann an den GIT-Server übertragen werden.

$ git add .
$ git commit -m "Info zum neuen Stand"
$ git push
$ # oder mit Angabe des Branch
$ git push origin master

Der GIT-Server darf nicht auf master eingecheckt sein, sonst können keine push durchgefpührt werden.

Veränderungen werden durch Jira und Stash initiiert.

1. Jira Ticket erstellen und die Veränderung beschreiben.
2. Mit „Branch erstellen“ einen neuen Branch in Stash erzeugen, alternativ kann der branch auch auf der Shell erzeugt werden.

$ git branch neu_branch
$ git checkout neu_branch

3. Der neue Branch kann nun in das lokale Dateiverzeichnis übernommen und darin weitergearbeitet werden:

$ git pull
$ git checkout neu_branch
$ git pull

Beim Einchecken wird der Code nun auf den neuen Branch geschrieben.

Zurück zum Master

$ git checkout master

4. Wenn alles fertig ist, wird der Branch in Stash mittels „Pull Request“ zum Review freigegeben und kann dann nach dem Check mittel „Merge“ wieder zum Master hinzugefügt werden.

Branches sind eine gute Sache um verschiedene Handlungszweige zu erstellen und um Restorepoints zu ermöglichen. Dabei kann es immer sein, dass man den Handlungszweig zurück zum Ursprung führen möchte. Mit einem Merge kann das erreicht werden.

In Testing out Merges sind verschiedene Ansätze für einen sicheren Merge beschrieben. Die Scout-Version erscheint dabei die meiste Sicherheit zu bieten.

Beispiel: Die Branch neue_funktion soll in master übernommen werden.

1. In die Zielbranch wechseln mit $ git checkout master. Mit $ git status prüfen, ob alles ok ist.

2. Neue Branch mit $ git branch mergetest erstellen und mit git checkout mergetest hinein wechseln.

3. Merge durchführen mit $ git merge neue_funktion und testen. Geht es schief setzt $ git reset –hard den Merge zurück.

4a. Alles ist ok. In master wechseln mit $ git checkout master, den Merge übernehmen mit $ git checkout mergetest

4b. Der Merge hat nicht funktioniert. In master wechseln mit $ git checkout master, die Branch löschen mit $ git branch -D mergetest. Alles ist wieder auf dem alten Stand.

Mein erster Test für einen unabhängigen Kalender-Server war mal wieder ein Open-Source Alptraum. DAViCal macht einen guten Eindruck und kann auch von den Ubuntu-Repo's installiert werden. Allerdings war diese Installation nicht zu gebrauchen. Was ist geschehen?

Wie so häufig, ist auch für DAViCal eine gute Installationsbeschreibung in Ubunutuusers zu finden. Die Schritte sind gut dokumentiert und funktionieren, ausser:

Das DB-Installationsskript wirft Fehler, weil Funktionen nicht erstellt werden können. Der Grund ist ein falscher Eintrag in dem Skript für das PL-SQL. Richtig ist LANGUAGE plpgsql, in der neueun Version scheint dieser Fehler behoben zu sein, allerdings habe ich keine Neuinstallation getestet.

Es gibt Hinweise und ich habe auch eine Seite gefunden, wo das Vorgehen für eine verschlüsselte Übertragung beschrieben ist. Zum Testen erstmal weggelassen, für den Betrieb aber unbedingt erforderlich, um die Passwörter zu schützen.

Scheinbar alles ok, aber

• Es wird keine Default-Sammlung für einen neuen Prinzipal angelegt
• Der Prinzipal kann keine Sammlungen einrichten.
• In eine Sammlung können keine Daten importiert werden.

Das Kommando

update collection set parent_container = '/andreas/', dav_name = '/andreas/calendar/' where collection_id = 1008;

hat eine Sammlung des admin in die richtige Konvention für andreas geändert, trotzdem kein Erfolg

Mit der URL:

http://192.168.31.240/davical/caldav.php/andreas/calendar

leicht möglich, aber in der Version 1.1.1 keine Chance, etwas Brauchbares zu erhalten.

Die Seite http://davical.dhits.nl/index.php/Downloading beschreibt, wo die aktuelle Version liegt.

 
$ git clone https://gitlab.com/davical-project/awl.git
$ git clone https://gitlab.com/davical-project/davical.git

Anschließend müssen durch make release in den neuen Verzeichnissen tarballs erzeugt werden. Diese können von root in /usr/share installiert und in awl bzw. davical umbenannt werden. Symbolische Links gehen auch.

Nach der Installation habe ich die Anweisung aus http://wiki.davical.org/w/Update-davical-database befolgt und mit dem Kommando

$ sudo -u postgres /usr/share/davical/dba/update-davical-database --dbuser=postgres

die Datenbank aktualisiert.

Jetzt konnte admin eine kleinen Musterkalender importieren (.ics-File). Das Einbinden in Thunderbird ging ohne Probleme und ein Termin wurde erfolgreich erzeugt.

Strike!

Bleibt zu klären, wie die Version 1.1.3 ohne die Version 1.1.1 installiert werden kann und ob die Administration nun in Summe richtig funktioniert. Jedenfalls ist der Kalender jetzt funktionsfähig.

Mit der Anleitung für Einsteiger kann Arch installiert werden. In einer virtuellen Maschine (Virtualbox) entstehen dabei kaum Schwierigkeiten. Einzig die dkms Installation für die Vbox - Videotreiber war nicht beschrieben.

Bei der weiteren Installation von Arch Linux sind einige Anmerkungen zu beachten.

Da HP Drucker installiert werden sollen ist hplip zu installieren. Allerdings wurde der Drucker nach der Installation nicht im Auswahlmenü angezeigt. Der Ausdruck einer Testseite über http://localhost:631 war aber ohne Probleme möglich.

Abhilfe hat die Installation von

$ sudo pacman -S gtk3-print-backends

gebracht.

Die Kennung root habe ich deaktiviert, da sudo installiert ist.

$ sudo usermod -L root

Der Networkmanager installiert von Haus aus nicht den Konfiguratoonsdialog und das Applet. Kann aber mit pacman nachinstalliert werden (nm-connection-editor network-manager-applet).

In xfce wird kein Papierkorb angezeigt. Der Grund dafür ist, dass gvfs nicht automatisch installiert wird. gvfs und die erforderlichen Backends installieren und alles ist ok.

Artikel im Netz: Kuketz Blog

Lynis ist ein Audit Tool um Schwachstellen in Linux Systemen aufzuzeigen. In Arch kann Lynis mit

$ sudo pacman -S lynis

installiert werden.

Das Arch-Linux in der virtullen Maschine erreicht 67% Systemhärtung auf Anhieb. Gut sind etwa 80% - also es ist noch etwas zu tun…

Neben der Virtualisierungslösung VirtualBox von Oracle gibt es auch die Linux eigene Lösung QEmu und Virt-Manager. Die Kernel-Virtualisierung mittels KVM kann auch in VirtuaBox genutzt werden. Ein wesentlicher Unterschied zwischen den Lösungen besteht in der Netzwerkanbindung.

QEmu und der Virt-Manager verwenden reguläre Schnittstellen im Linux System, VirtualBox errichtet eine eigene Netzwerkinfrastruktur, die im Host nicht weiter sichtbar ist. Eine Bridge kann mit dem Virt-Manager nur auf einem Kabel NIC eingerichtet werden, WLAN NIC's verbieten den Bridge-Modus im Allgemeinen.

Um dennoch eine VM mit Virt-Manager einzurichten braucht man ein virtuelles Netzwerk. Das Netzwerk „default“ ist dabei eine NAT-Lösung, wodurch die VM im Hostnetz unsichtbar bleibt. Wenn ein Zugriff auf die VM aus dem Hosts-Netz gebraucht wird, muss ein eigenes virtuelles Netz als „Route zu wlan0“ konfiguriert und der VM zugewiesen werden.

Damit das Routing aus dem neuen virtuellen Netz in das Hostnetz und das Internet funktioniert braucht es dann noch eine statische Route in der übergeordneten FritzBox.

Anschließend ist das virtuelle Subnetz und die VM transparent erreichbar. Bei Bedarf können auch statische IP-Adressen per dhcp vergeben werden.

Viele Informationen zum Thema sind im libvirt Networking Handbook und im Debian Wiki

Auf einem Server ist nicht unbedingt eine grafische Oberfläche installiert. Die Administration des Virt-Manager wird über die GUI aber wesentlich vereinfacht. Es ist nicht erforderlich, dass die GUI auf allen Wirtsystemen installiert ist, denn der Virt-Manager ermöglicht die Administration der VM's auch durch das Netz.

Für einen Server ohne grafische Oberfläche wird QEmu/KVM und Virt-Manager wie folgt installiert:

Für Debian Jessie, Ubuntu 16.04 und ältere OS:

# apt-get install qemu-kvm libvirt-bin

Ab Debian Stretch und (vermutlich) neuere Ubuntu Versionen:

# apt install qemu-kvm libvirt-clients libvirt-daemon-system

Hinweise hierzu findet man im Debian Wiki. Für die vollständige Administration des fernen Systems ist ein root-Zugang per ssh erforderlich.

Nach der Installation des virt-manager auf einem Debian 9 - Rechner konnte zunächst keine neue VM eingerichtet werden. Die Installation brach mit „Permission Denied“ ab. Ursache ist der notwendige Zugriff auf /dev/kvm, deren User auf rw-rw– root:kvm eingestellt sind. virt-manager verwendet den User libvirt-qemu als Systemuser, daher die fehlenden Rechte.

Abhilfe:

$ sudo adduser libvirt-qemu kvm

Nach einem Reboot konnten neue VM's angelegt werden.

Für den Zugriff auf einen Server mittels virt-manager per ssh muss die ssh-Kennung in der Gruppe libvirt zugelassen sein.

$ sudo adduser $USER libvirt

virt-manager verwendet standardmäßig spice und qxl als Videosystem. Ohne Anpassung des Gastsystems kann damit nur eine Auflösung von max. SVGA (1024×768) erreicht werden. Auf einem Ubuntu - Gastsystem wird der QXL-Treiber mit

$ sudo apt install xserver-xorg-video-qxl spice-vdagent

installiert.

Nach langer Überlegung habe ich nun doch einen Heimserver angeschafft. Es handelt sich um einen HP Proliant MicroServer Gen8 G1610T mit Debian 9 als Betriebssystem.

Alles weitere zur Einrichtung findet man auf einer eigenen Seite.

Das Küchenprojekt wird uns 2020 sehr beschäftigen.

In den Repositories von Ubuntu und Debian werden GNUCash 2.6 und aqbanking 3.5 angeboten. Durch die umfangreichen Änderungen der deutschen Banken aufgrund der EU-Richtlinien PSD2 kann damit nicht mehr online auf die Konten zugegriffen werden.

PSD2 erfordert die Aqbanking 6 Bibliotheken und somit ein Gnucash neuer als 3.7.

Auf den WIKI Seiten von GNUCash ist beschrieben, wie man GNUCash als Flatpak installiert und damit Zugriff auf eine aktuelle Version erhält.

Mit Ubuntu 20.04 ist die GnuCash Version 3.8b+ (AqBanking 6.0.1.2) mit dem Stand 2019-12-29 in den Repository's enthalten. Damit ist der Zugang prinzipiell wieder möglich, allerdings funktioniert der Zugriff auf die Postbank weiterhin noch nicht.

Ein Fehler bei der Kontenzuordnung konnte mit der Mailingliste geklärt werden, der Abruf der SEPA-Informationen hat den Umsatzabruf bei der Volksbank ermöglicht.

Schließlich habe ich mich entschieden, die Flatpak Installation auf einer VM auszuprobieren. Hierfür habe ich eine Debian 10 - VM (coonie auf tiger) verwendet, da Flatpak erst ab Debian 10 in den Standard Repositories enthalten ist.

Auf dem GnuCash Wiki gibt es eine Installationsanleitung. Allerdings ist am 03.05.2029 in der GnuCash Version 3.10-1 (AqBanking 6.1.4.0) ein weiterer Fehler, der den Account-Abruf bei der Postbank über die GUI unmöglich macht.

Die Seite SetupPinTan beschreibt die Einrichtung per Kommandozeile, damit konnten die Postbank-Konten eingerichtet und ein Umsatzabruf durchgeführt werden.

Um die Kommadozeile zu verwenden, muss man per

$ flatpak run --command=sh org.gnucash.GnuCash

in die Flatpak Umgebung wechseln. Dort stehen die AqBanking Kommandos zur Verfügung.

Hier ist mein Vorgehen zur Anzeige der Photo-TAN von ComDirect in AqBanking

OS: Debian 9
GnuCash 3.10
AqBanking 6.1.4
installiert via Flatpak

Bei der Einrichtung des Kontenzugriffs für GnuCash in AqBanking muss bei der Comdirect eine TAN angegeben werden, die als Photo-TAN in einem „PNG“ Format übermittelt wird. Dieses Bild muss angezeigt werden, damit es von der photoTAN-App gelesen und die darin verschlüsselte TAN dekodiert werden kann.

AqBanking ermöglicht es, hierfür bei der Abfrage einen Schalter anzugeben, der auf ein Bildanzeigeprogramm zeigt. Allerdings stehen in der Flatpak-Sandbox keine Grafik-Bibliotheken zur Verfügung, weshalb es dort auch keine Anzeigeprogramme gibt. Das Sandbox Prinzip schließt die Nutzung der Anzeigeprogramme des übrigen Computers aus.

In GnuCash ist ein internes Anzeigeprogramm implementiert, weshalb die weitere Verwendung der Photo-TAN nach der Konteneinrichtung ohne Probleme auch in der Flatpak Installation funktioniert.

Als Anzeigeprogramm in der Flatpak Umgebung kann „viu“ verwendet werden. „viu“ ist eine Bildanzeige, die ausschließlich auf den Darstellungsmöglichkeiten des Terminals basiert und daher keine grafische Ablaufumgebung benötigt.

Die Bildauflösung ist dementsprechend äußerst eingeschränkt, hat aber bei mir zur Erkennung der TAN ausgereicht. Und nach Einrichtung der Kontoverbindung ist ohnehin alles ok.

Die Lösung im Einzelnen:

wichtige Internet Links

Installation von GnuCash in Flatpak: https://wiki.gnucash.org/wiki/De/Flatpak Auf dieser Seite gibt es auch einen Hinweis zu Optischen TANs, der aber bei der Konteneinrichtung nicht ausreichend ist.

Kontoeinrichtung mit AqBanking auf der Kommandozeile: https://www.aquamaniac.de/rdm/projects/aqbanking/wiki/SetupPinTan

Kommandos

1. viu installieren

Das Binary von viu kann von der Seite
https://github.com/atanunq/viu/releases/tag/v1.0
heruntergeladen werden, z. B. nach /home/mein/pfad. Anschließend muss die Datei mit

$ chmod u+x /home/mein/pfad/viu

ausführbar gemacht werden und kann dann direkt mit

$ /home/mein/pfad/viu testbild.png

ausprobiert werden.

2. Wechsel in die Sandbox und verlassen der Sandbox

$ flatpak run –command=sh org.gnucash.GnuCash
[📦 org.gnucash.GnuCash ~]$ aqbanking-cli versions
Versions:
AqBanking-CLI: 6.1.4
Gwenhywfar : 5.2.0.0
AqBanking : 6.1.4.0
[📦 org.gnucash.GnuCash ~]$ exit
$

3. Abruf der Kontenliste mit viu

[📦 org.gnucash.GnuCash ~]$ aqhbci-tool4 –opticaltan=/home/mein/pfad/viu getaccounts -u 123

Um Bestsign bei der Postbank zu verwenden, muss die TAN_MEDIA_KENNUNG gesetzt werden. Beispiel für HHG:

$ aqhbci-tool4 setTanMediumId -u 124 -m „SO:Andi iPhone SE“