====== Projektübersicht ======
===== xRDP =====
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 [[http://c-nergy.be/blog/?p=5305|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 [[http://askubuntu.com/questions/133343/how-do-i-set-up-xrdp-session-that-reuses-an-existing-session|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
<
---
>
==== xrdp über ssh tunneln ====
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.
==== xrdp auf einem Debian 9 Stretch System ====
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
==== xrdp auf einem Debian 10 Buster System ====
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.
=== Authentication is required to Create Managed Color Device ===
In [[http://c-nergy.be/blog/?p=13641|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
=== Grüner Bildschirm bei xrdp-Zugriff auf Debian 9 - Mate System ===
Das Problem wird im [[https://debianforum.de/forum/viewtopic.php?t=165816|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
===== Linux Server als Backup System für Windows Desktops =====
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.
[[projects:windowsbackup|Backup für Windows Desktops]]
===== E-Mail Verschlüsselung =====
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 [[projects:emailverschluesselung|E-Mail Verschlüsselung]].
===== E-Mail Server zu Hause =====
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]]
===== jsTree =====
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}}
[[http://www.jstree.com/|jsTree Home]] \\
[[http://tkgospodinov.com/jstree-part-1-introduction/|jsTree Tutorial]]
jsTree: {{vakata-jstree-3.0.0-beta4-0-g1e2e7d9.zip}}
===== Linux Server =====
Quelle: http://www.pcwelt.de/ratgeber/Aktuelle_Linux-Distros_im_PC-WELT-Check-Linux-Distributionen-7971293.html\\
{{linuxwelt.jpg}}\\
Es sollen Server mit Linux - Betriebssystem eingerichtet werden. Die Systeme werden als [[projects:linuxserver#virtuelle Maschinen]] laufen. Die verschiedenen [[projects:linuxserver#Linux Distributionen]] sollen hinsichtlich
* [[projects:linuxserver#Stabilität]]
* [[projects:linuxserver#Wartbarkeit]]
* [[projects:linuxserver#Performance]]
* [[projects:linuxserver#Sicherheit]]
* [[projects:linuxserver#Marktentwicklung]]
untersucht werden. Die Untersuchung basiert auf dem Stand 01/2014.
===== Datenbank Wartung =====
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.
===== Einsatz von Xubuntu auf dem Desktop =====
https://sites.google.com/site/easylinuxtipsproject/xubuntu
==== Grundlagen ====
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.
==== Voraussetzungen ====
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.
==== Backup ====
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.
==== Nach der Basisinstallation ====
Als allgemeine Information kan die Seite [[https://sites.google.com/site/easylinuxtipsproject/first-xubuntu|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
==== Auf dem eeePC 701 4G ====
siehe [[http://forum.ubuntuusers.de/topic/xubuntu-12-04-auf-eeepc-4g/|Xubuntu 12.04 auf dem eeePC 4G]] \\
und [[http://blog.rootserverexperiment.de/2008/11/02/das-perfekte-netbook-setup-installation-ubuntu-xubuntu-810/|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 - Eine kleine Einführung =====
[[http://rogerdudler.github.io/git-guide/index.de.html|GIT Guide]]\\
[[http://think-like-a-git.net|Think like (a) GIT]]
==== Git über HTTP ====
Hier ist beschrieben, wie man einen einfachen git-Server installiert:
[[https://matthieu-moy.fr/spip/?Host-a-Git-repository-over-HTTP-S|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:
=== cgi ===
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/
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
# AllowOverride None
Require all granted
AllowOverride AuthConfig
=== /usr/lib/cgi-bin/.htaccess ===
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.
=== Erzeugen des git Clone ===
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!
==== Auschecken ====
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.
==== Synchronisieren ====
Bevor Änderungen an den Dateien durchgeführt werden muss die lokale Kopie des Projekts synchronisiert werden.
$ git pull
==== Einchecken ====
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.
==== Umgang mit Branches ====
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.
==== Merge Branches ====
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 [[http://think-like-a-git.net/sections/testing-out-merges.html|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.
===== DAViCal - Der Kalender-Server - und am Ende läuft er doch =====
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?
==== Installation der Version 1.1.1 ====
Wie so häufig, ist auch für DAViCal eine gute Installationsbeschreibung in [[http://wiki.ubuntuusers.de/DAViCal|Ubunutuusers]] zu finden. Die Schritte sind gut dokumentiert und funktionieren, ausser:
=== falscher PL-SQL Eintrag ===
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.
=== https ===
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.
==== Administration von DAViCal 1.1.1 ====
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.
=== Eingriff mittels SQL ===
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 :-(
==== Einbinden des Kalenders in Thunderbird / Lightning ====
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.
==== Aktuelle Version DAViCal 1.1.3.1 aus dem GIT beziehen ====
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.
==== ERFOLG ! ====
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.
===== Arch Linux im Einsatz =====
==== Installation ====
Mit der [[https://wiki.archlinux.de/title/Anleitung_f%C3%BCr_Einsteiger|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 [[projects:archinstall|Installation von Arch Linux]] sind einige Anmerkungen zu beachten.
=== dkms - Installation ===
=== Cups - Drucker ===
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.
=== Kennung root deaktiviert ===
Die Kennung root habe ich deaktiviert, da sudo installiert ist.
$ sudo usermod -L root
=== Network Manager ===
Der Networkmanager installiert von Haus aus nicht den Konfiguratoonsdialog und das Applet. Kann aber mit pacman nachinstalliert werden (nm-connection-editor network-manager-applet).
=== kein Papierkorb ===
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.
==== Linux Systemhärtung ====
Artikel im Netz: [[https://www.kuketz-blog.de/linux-systemhaertung-basis-linux-haerten-teil2/|Kuketz Blog]]
=== Lynis ===
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...
==== KVM, QEmu und Virt-Manager ====
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.
{{:projects:virtnetz.png?direct&400|}}
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.
{{:projects:statroute.png?direct&400|}}
Anschließend ist das virtuelle Subnetz und die VM transparent erreichbar. Bei Bedarf können auch statische [[projects:staticip|IP-Adressen per dhcp]] vergeben werden.
Viele Informationen zum Thema sind im [[https://jamielinux.com/docs/libvirt-networking-handbook/routed-network.html|libvirt Networking Handbook]] und im [[https://wiki.debian.org/KVM|Debian Wiki]]
=== Virt-Manager auf dem Server ===
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 [[https://wiki.debian.org/KVM#Installation|Debian Wiki]]. Für die vollständige Administration des fernen Systems ist ein root-Zugang per ssh erforderlich.
=== Permission Denied bei der Anlage einer neuen VM ===
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.
=== Zugriffsrechte auf den virt-manager per Remote ===
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
=== QXL - Treiber auf dem Gastsystem ===
virt-manager verwendet standardmäßig spice und qxl als Videosystem. Ohne Anpassung des Gastsystems kann damit nur eine Auflösung von max. SVGA (1024x768) erreicht werden. Auf einem Ubuntu - Gastsystem wird der QXL-Treiber mit
$ sudo apt install xserver-xorg-video-qxl spice-vdagent
installiert.
===== Lion - Mein Heimserver =====
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 [[Lion Konfiguration|Einrichtung]] findet man auf einer eigenen Seite.
===== Küchenprojekt =====
Das [[Küchenprojekt]] wird uns 2020 sehr beschäftigen.
===== GNUCash - Anpassungen wegen der PSD2-Umstellung 2019 =====
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 [[https://wiki.gnucash.org/wiki/De/HBCI|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 [[solutions:ueberblick#gnucash|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 [[https://wiki.gnucash.org/wiki/De/Flatpak|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 [[https://www.aquamaniac.de/rdm/projects/aqbanking/wiki/SetupPinTan|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.