Diesmal stand ich vor einem interessanten Problem: Die hinterlegten Verbindungen unter “Mit Server verbinden” wollte ich löschen. Allerdings gibt es in diesem Fenster keine Möglichkeit diese “History” zu leeren. Aber es ist ja nicht Linux wenn es nicht doch eine Lösung geben würde….

/home/username/.config/nautilus/servers

in dieser Datei im XML Format sind die benutzten Verbindungen hinterlegt. Und hier kann man diese auch entfernen.
In dieser Datei müssen die Werte zwischen (bzw. inklusiv) Bookmark entfernt werden.

Die Linux-Distribution Pop!_OS ist von Ubuntu abgeleitet und wird von der amerikanischen Firma system76 entwickelt. Diese Firma verkauft Notebooks, auf denen standardmäßig Pop!_OS installiert ist. Im Vergleich zu anderen Distributionen ist Pop!_OS besonders gut für Notebooks mit NVIDIA-Grafik optimiert.

Ursprünglich dachte ich, Pop!_OS sei nur ein weiterer Ubuntu-Klon mit modifizierten Gnome-Desktop und integrierten NVIDIA-Treibern. Seit ich die Distribution auf mein neues Lenovo-P1-Notebook installiert habe, weiß ich, dass Pop!_OS weit mehr Eigenheiten hat.

Varianten

Pop!_OS steht aktuell in den Versionen 18.04 LTS und 18.10 sowie in jeweils zwei Varianten zur Auswahl. Diese beiden Varianten unterscheiden sich darin, ob die NVIDIA-Treiber bereits inkludiert sind oder nicht. Ich habe für meinen Tests Pop!_OS 18.10 in der NVIDIA-Variante verwendet.

Notebook-spezifische Vorbereitungsarbeiten

Vor der Installation von Pop!_OS auf meinem Lenovo P1 habe ich das auf einer zweite SSD befindliche Windows aktualisiert und dann ein BIOS-Update durchgeführt (siehe auch diesen heise-Artikel).

Des Weiteren habe ich zwei BIOS-Optionen verändert:

• UEFI Secure Boot = No

• F1-F12 as Primary Keys = Enabled

Die erste Option ist zwingend erforderlich, weil Secure Boot in Kombination mit den nicht GPL-kompatiblen NVIDIA-Treibern unmöglich ist.

Die zweite Option entspricht meinen Gewohnheiten. Ich will die Funktionstasten als solche verwenden (F1 bis F12). In meiner Emacs-Konfiguration sind diese Tasten alle mit häufig verwendeten Funktionen verbunden.

Für die Installation von Pop!_OS ist es hingegen nicht erforderlich, Veränderungen am Grafiksystem durchzuführen. Ich habe die Einstellung Graphics Device = Hybrid Graphics also belassen und nicht auf Discrete umgestellt.

Installation

Bei der Installation lautet das Motto von Pop!_OS: Alles oder nichts. Es gibt nur zwei Installationsvarianten:

• Clean Install verwendet die gesamte Festplatte. (Wenn es mehrere Festplatten/SSDs gibt, können Sie das gewünschte Gerät auswählen.) Diese Variante eignet sich nur, wenn Sie keine Rücksicht auf vorhandene Betriebssysteme nehmen müssen. Sie haben keine Wahlmöglichkeiten bei der Partitionierung. Standardmäßig richtet Pop!_OS eine relativ große Swap-Partition, eine EFI- oder eine boot-Partition sowie eine Datenpartition ein, die die restliche Festplatte/SSD ausfüllt (ext4-Dateisystem). Immerhin können Sie zum Schluss entscheiden, ob das Dateisystem verschlüsselt werden soll oder nicht.

• Custom (Advanced): Hinter dieser Option verbirgt sich das andere Extrem. Wenn Sie sich dafür entscheiden, müssen Sie sich um die Partitionierung selbst kümmern. Das Pop!_OS-Installationsprogramm öffnet dazu GParted, Sie können aber natürlich auch in einem Terminal mit parted arbeiten. Auf jeden Fall erhalten Sie keine Unterstützung durch das Installationsprogramm, das keinen Partitionseditor hat. Stattdessen zeigt es die mit GParted oder parted erzeugten Partitionen nur an. Sie können nun über kleine Dialoge entscheiden, wie Sie die Partitionen für die Installation nützen möchten.

Selbstredend habe ich mich für die zweite Variante entschieden. Mein Ziel war, auf der SSD Platz für weitere Linux-Installationen zu lassen. Das Problem besteht nun darin, dass Pop!_OS bei der Custom-Variante keine Verschlüsselungsoption anbietet. Vielmehr müssen Sie die Datenpartition mit crypt_setup selbst vorbereiten.

Ich habe daher in einem Terminal die notwendigen Vorbereitungsarbeiten selbst durchgeführt. Zuerst habe ich auf der SSD eine GPT-Partitionstabelle eingerichtet. (Vorsicht! Alle auf der SSD befindlichen Daten gehen dabei verloren.)

parted /dev/nvme0n1
>   mklabel gpt

Immer noch in parted habe ich eine EFI-Partition eingerichtet:

> mkpart EFI 1mib 1024mib
> set 1 hidden
> set 1 esp

Und schließlich die Datenpartition, wobei die letzten 250 GiB der SSD frei bleiben sollten:

> mkpart encryptedpop 1025mib -250gib
> exit

Die EFI-Partition benötigt ein VFAT-Dateisystem:

mkpart encryptedpop 1025mib -250gib

Die Datenpartition wird mit crypt_setup verschlüsselt. (Dabei müssen Sie zweimal das gewünschte Passwort angeben.) Damit entsteht die neue Device-Datei /dev/mapper/cryptlvm:

cryptsetup luksFormat --type luks2 /dev/nvme0n1p2
ls /dev/mapper/cryptlvm 
    /dev/mapper/cryptlvm

Diese Device-Datei soll nun als Physical Volume für ein Volume Group für LVM dienen. In der Volume Group habe ich mit lvcreate ein Logical Volume eingerichtet.

pvcreate /dev/mapper/cryptlvm
vgcreate popvg /dev/mapper/cryptlvm
lvcreate -L 1500G popvg -n poproot

Auf eine Swap-Partition habe ich angesichts 32 GByte RAM verzichtet. Damit ist der Terminal-Voodoo beendet. Das Pop!_OS-Installationsprogramm erkennt sowohl die EFI-Partition als auch die verschlüsselte Partition und das darin enthaltene LVM-Setup.

Recovery-Partition: Wenn Sie möchten, dass Ihnen nach der Installation auf der Festplatte/SSD ein Recovery-System zur Verfügung steht, müssen Sie eine weitere 4 GByte große Partition vorsehen (VFAT, unverschlüsselt, außerhalb von LVM) und dieser im Installationsprogramm das Verzeichnis /recovery zuweisen. Das Recovery-System ist einfach ein Pop!_OS-Live-System.

Die weitere Installation erfolgt dann ohne weitere Rückfragen und innerhalb weniger Minuten. Nach dem Neustart muss noch ein Benutzer eingerichtet werden — das war’s.

Hinweis: Wenn Sie Pop!_OS in VirtualBox ausprobieren, passt sich die Auflösung der virtuellen Maschine nicht automatisch an die Fenstergröße an. Standardmäßig stehen u.U. nur 800×600 Pixel zur Verfügung. Abhilfe: Öffnen Sie in der virtuellen Maschine die Gnome-Einstellungen, öffnen Sie das Dialogblatt *Devices/Displays* und wählen Sie dort die gewünschte Auflösung aus.

Desktop

Nach dem ersten Login offenbart sich der Pop!_OS-Desktop als ziemlich gewöhnliches Gnome-System mit wenigen Modifikationen, die durch Shell Extensions, eigene Fonts und Themes realisiert sind.

NVIDIA-Unterstützung

Das Alleinstellungsmerkmal von Pop!_OS ist sicherlich die gute NVIDIA-Unterstützung out of the box, also ohne irgendwelche Konfigurationsarbeiten. Pop!_OS verfolgt dabei einen sehr pragmatischen Ansatz: Über zwei in das Gnome-Systemmenü eingebauten Kommandos kann zwischen der NVIDIA- und der Intel-GPU gewechselt werden. Jeder Wechsel erfordert einen Neustart. Das ist weniger bequem als unter Windows, aber es funktioniert (zumindest bei meinen Tests) zuverlässig.

Der GPU-Wechsel kann auch durch Kommandos initiiert werden, wobei auch diese Änderungen erst nach einem Reboot wirksam werden.

sudo system76-power graphics nvidia
sudo system76-power graphics intel

Hinter den Kulissen erzeugt system76-power eine neue Initrd-Datei. Anschließend werden die Dateien in /boot/efi/EFI/Pop_OS-xxx erneuert. Neugierig wie ich bin, habe ich die Initrd-Images ausgepackt (unmkinitramfs) und verglichen (diff -rq). Das Ergebnis: Die Initrd-Datei für NVIDIA enthält erwartungsgemäß die NVIDIA-Kernelmodule (nvidia-drm.ko, nvidia-modset.ko). Dafür enthält die Intel-Variante die folgende Datei:

# Datei /etc/modprobe.d/system76-power.conf 
blacklist nouveau
blacklist nvidia
blacklist nvidia-drm
blacklist nvidia-modeset
alias nouveau off
alias nvidia off
alias nvidia-drm off
alias nvidia-modeset off

Sowohl das system76-power als auch die dazugehörige Gnome-Erweiterung sind Open-Source-Projekte auf GitHub zu finden. Als Programmiersprache wurde Rust verwendet.

• https://github.com/pop-os/system76-power
• https://github.com/pop-os/gnome-shell-extension-system76-power

Als Grafiksystem kommt in Pop!_OS Xorg zum Einsatz. Diverse Wayland-Pakete sind zwar installiert, beim Login gibt es aber keine Möglichkeit, Wayland zu aktivieren. Das ist insofern konsequent, als die NVIDIA-Treiber ja inkompatibel zu Wayland sind).

Energieverwaltung

Mit system76-power und den dazugehörige Gnome Extension können Sie auch zwischen drei Nutzungsprofilen umschalten:

sudo system76-power profile battery 
sudo system76-power profile balanced
sudo system76-power profile performance

Ich habe keine schlüssige Dokumentation gefunden, was die obigen Kommandos exakt tun.

Sicher ist, dass das Battery-Profil die Hintergrundbeleuchtung des Bildschirms stark reduziert. (Die Helligkeit kann per Tastatur natürlich wieder angehoben werden.) Außerdem wird im Battery-Profil der Turbo-Modus der CPU deaktiviert:

cat /sys/devices/system/cpu/intel_pstate/no_turbo
  0

In den beiden anderen Modi lautet das Ergebnis jeweils 1, d.h. bei Bedarf taktet die CPU höher. Der CPU-Governor bleibt bei allen drei Profilen auf powersave:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | uniq
  powersave

Kurzum, der Unterschied zwischen Balanced und Performance ist unklar geblieben. Ich habe keine wesentliche Änderung des CPU-Verhaltens feststellen können. Benchmarks mit Geekbench ergaben jeweils (im Rahmen der üblichen Schwankungen) dieselben Ergebnisse.

Hintergrundinformationen:

https://github.com/pop-os/system76-power/wiki
https://wiki.archlinux.org/index.php/CPU_frequency_scaling

Paketverwaltung

Pop!_OS verwendet zusätzlich zu den Ubuntu-Paketquellen eine eigene Paketquelle:

http://ppa.launchpad.net/system76/pop/ubuntu

Mit meinem im Blogbeitrag Die LTS-Frage vorgestellten Script habe ich ermittelt, wie viele Pakete aus der Pop!_OS-eigenen Paketquelle stammen. Das Ergebnis ist verblüffend. Es sind über 100 Pakete!

accountsservice appstream-data-pop appstream-data-pop-icons
com.github.donadigo.eddy curl dmeventd dmsetup gdm3 geary
gir1.2-accountsservice-1.0 gir1.2-gdm-1.0:amd64
gir1.2-gnomedesktop-3.0:amd64 gnome-control-center
gnome-control-center-data gnome-control-center-faces
gnome-desktop3-data gnome-online-accounts
gnome-shell-extension-alt-tab-raise-first-window
gnome-shell-extension-always-show-workspaces
gnome-shell-extension-do-not-disturb
gnome-shell-extension-pop-battery-icon-fix
gnome-shell-extension-pop-shop-details
gnome-shell-extension-pop-suspend-button
gnome-shell-extension-system76-power hidpi-daemon initramfs-tools
initramfs-tools-bin initramfs-tools-core kernelstub
libaccountsservice0:amd64 libc-bin libc-dev-bin libc6:amd64 libc6:i386
libc6-dev:amd64 libcurl3-gnutls:amd64 libcurl4:amd64
libdevmapper-event1.02.1:amd64 libdevmapper1.02.1:amd64
libegl-mesa0:amd64 libegl1-mesa:amd64 libgbm1:amd64 libgdm1
libgl1-mesa-dri:amd64 libgl1-mesa-dri:i386 libglapi-mesa:amd64
libglapi-mesa:i386 libglx-mesa0:amd64 libglx-mesa0:i386
libgnome-desktop-3-17:amd64 libgoa-1.0-0b:amd64 libgoa-1.0-common
libgoa-backend-1.0-1:amd64 libgranite-common libgranite5:amd64
liblvm2app2.2:amd64 liblvm2cmd2.02:amd64 libnvidia-cfg1-418:amd64
libnvidia-common-418 libnvidia-compute-418:amd64
libnvidia-compute-418:i386 libnvidia-decode-418:amd64
libnvidia-decode-418:i386 libnvidia-encode-418:amd64
libnvidia-encode-418:i386 libnvidia-fbc1-418:amd64
libnvidia-fbc1-418:i386 libnvidia-gl-418:amd64 libnvidia-gl-418:i386
libnvidia-ifr1-418:amd64 libnvidia-ifr1-418:i386 libxatracker2:amd64
linux-generic linux-headers-4.18.0-16 linux-headers-4.18.0-16-generic
linux-headers-generic linux-image-4.18.0-16-generic
linux-image-generic linux-libc-dev:amd64
linux-modules-4.18.0-16-generic linux-modules-extra-4.18.0-16-generic
linux-signed-generic locales lvm2 mesa-va-drivers:amd64
mesa-vdpau-drivers:amd64 mesa-vulkan-drivers:amd64 multiarch-support
nvidia-compute-utils-418 nvidia-dkms-418 nvidia-driver-410
nvidia-driver-418 nvidia-kernel-common-418 nvidia-kernel-source-418
nvidia-utils-418 plymouth-theme-pop-basic pop-default-settings
pop-desktop pop-fonts pop-gnome-initial-setup pop-gnome-shell-theme
pop-gtk-theme pop-icon-theme pop-session pop-shop pop-theme
pop-wallpapers popsicle popsicle-gtk repoman system76-dkms
system76-io-dkms system76-power xserver-xorg-video-nvidia-418

Das macht, offen gesagt, ein wenig skeptisch: Ein modifizierter Kernel, diverse modifizierte Gnome-Pakete (inklusive des eigenen Paketmanagers pop-shop, der natürlich auf Gnome Software basiert und ebenso schlecht wie dieses Programm funktioniert) etc. Ist system76 wirklich in der Lage, all diese Pakete langfristig solide zu warten? Gerade mit modifizierten Gnome-Paketen ist selbst Canonical gescheitert und letztlich zurück in das Mainstream-Lager gewechselt.

Standardmäßig sind keine Snap-Pakete installiert. Selbst auf die Installation des Snap-Dämons hat system76 verzichtet. (Sie können das mit apt install snapd beheben, wenn Sie wirklich wollen.)

systemd-boot statt GRUB

Technisch gesehen die größte Überraschung ist, dass Pop!_OS auf Rechnern oder virtuellen Maschinen mit EFI nicht GRUB verwendet, sondern die systemd-Komponente systemd_boot. (Wenn Sie Pop!_OS hingegen in VirtualBox installieren, wo standardmäßig ein traditionelles BIOS aktiv ist, kommt GRUB zum Einsatz.)

Pop!_OS mit systemd-boot benötigt richtig viel Platz in der EFI-Partition. Auf meinem Notebook ohne Recovery-System sind es ca. 160 MByte:

cd /boot/efi/EFI/
du -h 
  155M  ./Pop_OS-e16cb407-87e1-4333-90b3-e3a05f8e80f7
  92K   ./systemd
  92K   ./BOOT
  155M  .

Bei der Clean Install-Variante beträgt der Platzbedarf sogar 200 MByte, weil ein weiteres Image zum Start des Recovery-Systems eingerichtet wird.

Noch ein paar Anmerkungen zur EFI-Partition: Hier speichern alle auf einem Rechner installierten Betriebssysteme (also Windows sowie alle Linux-Distributionen) ihren Bootloader. Üblicherweise beanspruchen die Dateien ca. 10 bis 20 MByte pro Betriebssystem. Bei Pop!_OS ist der Platzbedarf deswegen so viel größer, weil die Boot-Dateien auch den Kernel und das Initrd-Image mit einschließen. Das ist insofern praktisch, als keine unverschlüsselte Boot-Partition erforderlich ist. Alle für den Boot-Vorgang erforderlichen Dateien sind direkt in der EFI-Partition.

Auf Notebooks mit vorinstalliertem Windows ist die EFI-Partition zumeist 256 MByte groß. Mit Windows und Pop_OS! ist die EFI-Partition dann so gut wie voll. Eine Vergrößerung mit einem Partitions-Manager scheitert zumeist daran, dass sich oft unmittelbar hinter der EFI-Partition eine 16 MByte große reserved windows Partition befindet (siehe z.B. superuser.com).

Weil ich Probleme bei zukünftigen Linux-Installationen ausschließen wollte, habe ich während der Installation eine zweite EFI-Partition eingerichtet. Der EFI-Standard sieht dies vor (nochmals superuser.com), Windows ist aber anscheinend nicht immer glücklich damit. In meinem Fall gab es aber keine Probleme, Windows lässt sich weiter starten und liest die Boot-Dateien aus ’seiner‘ EFI-Partition, während Pop!_OS die zweite EFI-Partition nutzt.

Im Betrieb bleibt systemd-boot normalerweise komplett unsichtbar. Nur wenn Sie exakt zum richtigen Zeitpunkt die Leertaste drücken, erscheint ein Menü mit den zur Auswahl stehenden Systemen. Im Prinzip handelt es sich dabei um Pop!_OS mit dem aktuellen Kernel, Pop!_OS mit dem vorigen Kernel sowie gegebenenfalls ein Recovery-System.

Die Menüeinträge wählen Sie mit den Cursortasten aus. Bei Bedarf gelangen Sie mit [E] in einen Editor, in dem Sie die Kernelparameter verändern können. Weitere interaktive Funktionen gibt es nicht.

Die Konfiguration von systemd-boot erfolgt durch die Datei /boot/efi/loader/loader.conf. Dort können Sie unter anderem mit timeout n die Zeit in Sekunden einstellen, während der das systemd-boot-Menü angezeigt wird. (Die Defaulteinstellung lautet 0.) Standardmäßig enthält loader.conf nur die Zeile default osname, die auf eine der Menüdateien im loader-Verzeichnis verweist. Mehr Details zu den (spärlichen) Konfigurationsmöglichkeiten finden Sie im archlinuxwiki.

Ist systemd-boot nun besser oder schlechter als GRUB? Das ist schwer zu sagen. An sich gefällt der minimalistische Ansatz im Vergleich zu dem mit Funktionen überladenen GRUB. Sollten allerdings Boot-Probleme auftreten, ist eine allfällige Reparatur vermutlich schwieriger als bei GRUB — schon alleine deswegen, weil systemd-boot wenig verbreitet ist. Im Web sind nur wenige Anleitungen und eine dürftige offizielle Dokumentation und zu finden:

• https://wiki.archlinux.org/index.php/systemd-boot
• https://www.freedesktop.org/software/systemd/man/systemd-boot.html
• https://blog.system76.com/post/170539007243/distinst-updates-boot-sequence-optimization
• https://support.system76.com/articles/pop-recovery/

Recovery-System

Nach Wochen der Bastelei habe ich es endlich geschafft ein Snap-Paket für die AusweisApp2 zu bauen, welches auch mit dem Confinement funktioniert. Die einzige Einschränkung, die aktuell noch existiert, ist das man nach der Installation einmalig die benötigten Interfaces des Snap-Pakets „connecten“ muss. Danach funktioniert die Anwendung ohne weitere Einschränkungen:

sudo snap install ausweisapp2-ce

sudo snap connect ausweisapp2-ce:raw-usb :raw-usb
sudo snap connect ausweisapp2-ce:hardware-observe :hardware-observe
sudo snap connect ausweisapp2-ce:network-manager :network-manager
sudo snap connect ausweisapp2-ce:network-observe :network-observe

sudo systemctl restart snap.ausweisapp2-ce.pcscd.service

Letzterer Befehl ist notwendig, damit der Card-Daemon noch vor dem ersten Start der Anwendung die passenden Rechte besitzt.

Ich habe im Snap-Store einen Request zum Auto-Connecten gestellt. Falls dieser genehmigt wird, kann man die Anwendung auch ohne explizites „connecten“ installieren.

Update

Ich hatte im Text vergessen zu erwähnen, dass das Snap-Paket den Card-Daemon mitbringt. Das Distributionsspezifische Paket ist somit nicht mehr notwendig. Unter Ubuntu kann dieses mit „sudo apt purge pcscd“ deinstalliert werden.

Am Wochenende fanden die 21. Chemnitzer Linux-Tage an der TU Chemnitz statt. Für mich war es nun schon der dritte Besuch nach 2015 und 2018.

Zu Vorträgen aus dem Vortragsprogramm kann ich nicht sehr viel sagen. Wie es sich bei mir mittlerweile Standard ist, bin ich mehr in Gesprächen mit den zahlreichen Freunden „verwickelt“ gewesen und weniger in Vorträgen gewesen. Am Samstag habe ich es immerhin geschafft den einzigen Vortrag für mich an diesem Tag zu besuchen: „Python asyncio in der Praxis“.

Am Sonntag habe ich es ebenfalls nur zu einem Talk geschafft. Allerdings war ich da der Speaker und musste (viel) reden. Wie auch bei der letzten OpenRheinRuhr erzählte ich über „How To Commit: Nachvollziehbare Git-Historien“. In diesem Vortrag erzählte ich über die Art und Weise wie Commits auszusehen haben sollten, damit diese auch im Nachhinein nachvollziehbar sind. Der Talk war auch als Diskussion ausgerichtet, weshalb einige Informationen und Wortmeldungen entsprechend nicht in den „Folien“ enthalten sind. Eine Aufzeichnung des Talks gab es hingegen und wird hoffentlich zeitnah auf der Webseite vom CLT veröffentlicht.

Die Folien finden sich auf meinem Speakerdeck Account oder eingebettet (via JavaScript) auch hier:

Das Thema des Talks wird für mich im Umgang mit Git immer wichtiger, sodass es in der kommenden zweiten Auflage meines Git Buches ein eigenständiges Kapitel gewidmet bekommen wird.

Unabhängig von meinem Talk lohnt sich ein Besuch der Chemnitzer Linux-Tage auch weiterhin. Eine schöne nette Community die sich da trifft. Für mich auch die Open-Source-Konferenz, die ich am besten mag. Und das liegt nicht nur an der guten Organisation… :)

Auch in diesem Jahr haben die Chemnitzer Linux Tage wieder in das zentrale Hörsaal- und Seminar-Gebäude der Technischen Universität Chemnitz eingeladen. Das Motto lautete diesmal „Natürlich intelligent“ und so wundert es nicht, dass sich eine Vielzahl von Vorträgen den Themen Künstliche Intelligenz und Maschinelles Lernen widmeten. Darüber hinaus gab es interessante Vorträge zu den Themen IoT, Container, Sicherheit, Einsteiger, Datacenter, usw. Alles in allem wurde wie im letzten Jahr ein vielseitiges Programm geboten.

Anreise am Freitag

Wie im vergangenen Jahr bin ich auch dieses Mal wieder mit dem Auto angereist, denn 4,5 Std. Fahrt sind mir doch lieber, als 6-7 Std. Reisezeit mit der Bahn (laut Fahrplan). So kam ich Freitag Abend rechtzeitig an, um das Social Event im Turmbrauhaus zu besuchen. Es war ein schöner Abend mit freundlichen Menschen bei interessanten Gesprächen und natürlich 1..n Hopfenkaltschalen.

Ich habe mich gefreut, bekannte Gesichter von ubuntuusers.de wieder zu sehen und neue Gesichter hinter einigen Blogs kennen zu lernen, die ich regelmäßig lese.

Auftakt am Samstag

Punkt 7.00 Uhr Frühstück im Hotel, 8.00 Uhr Einlass bei den Chemnitzer Linux Tagen und ab 9.00 Uhr öffnete die Ausstellerfläche und das Vortragsprogramm startete. Ich selbst lernte an diesem Tag etwas über Präsentationen mit XeLaTeX (Beamer), NVMe, NVMe over Fabrics und erfuhr die ein und andere Neuigkeit im persönlichen Gespräch mit alten und neuen Bekannten. Mein persönliches Zitat des Tages stammt von D. Menzel und lautet: „NVMe over Fabric ist wie iSCSI auf Steroiden.“ :-D

Ausklang am Sonntag

Auch der Sonntag begann früh mit dem Frühstück um 7.00 Uhr. Um 9.00 Uhr war bereits alles für die Abreise gepackt und die Chemnitzer Linux Tage öffneten ihre Halle für den zweiten Veranstaltungstag. Dieser startete für mich mit einigen Standbesuchen, um Informationen über mögliche Schulungsangebote und Tipps für den Einsatz von Ansible einzusammeln, bevor es dann um 10.00 Uhr in den ersten Vortrag, den Samba Status Report, ging.

Laut dem zuvor genannten Vortrag tritt SMB2 an, um NFS zu töten. Naja, ich persönlich glaube, Totgesagte leben länger.

Der Storage Track endete mit einem Vortrag von Kai Wagner, welcher über die Neuigkeiten im neuen Ceph Release Nautilus berichtete. In hohem Tempo führte Kai durch eine Folienschlacht, um keine coole Neuerung zu vergessen. Bei den vielen lang erwarteten Neuerung kann ich gut verstehen, dass Kai keine davon unterschlagen wollte. Dennoch hat Kai hier einen tollen und unterhaltsamen Talk gehalten. Danke hierfür.

Der letzte Vortag für mich an diesem Tage war Open Source und Medizin, welcher einen interessanten Einblick in die Forschung mit Medizindaten bot.

Im Anschluss wurden die Vorträge noch in kleinen Gruppen diskutiert, bevor ich mich verabschiedete, um mich auf den Heimweg zu machen.

Es war mal wieder ein schönes Wochenende und tolle Chemnitzer Linux Tage 2019. Bis zum nächsten Jahr.

Wurde in einem Wiki, das auf die Software MediaWiki setzt, das Passwort von einem Benutzer vergessen? Wenn das Wiki korrekt konfiguriert wurde und der Nutzer eine E-Mail-Adresse hinterlegt hat, kein Problem, da es hierfür die Funktion "Passwort vergessen" gibt, die unter dem Login-Formular abgerufen werden kann.

Ist ein solches Zurücksetzen allerdings nicht möglich, da z.B. der Mailtransport nicht aktiviert ist, muss das Passwort anderweitig erneuert werden. Wer sich schon auf den Weg in die Datenbank (Tabelle "user", Spalte "user_password", i.d.R. BLOB) macht, kann aufatmen, denn bei Zugriff auf die PHP-CLI schafft eines der MediaWiki-Wartungsscripte Abhilfe.

changePassword.php im maintenance-Verzeichnis ist für Passwort-Änderungen auf Kommandozeilenebene zuständig. Benötigt wird Zugriff auf das interne Verzeichnis, am besten per SSH. Dann per

cd /pfad/zur/installation/maintenance

in das maintenance-Verzeichnis der MW-Installation schalten und dort

php changePassword.php --user=Benutzername --password=NeuesPasswort

ausführen.

Die Optionsparameter müssen durch den zurückzusetzenden MW-Benutzernamen sowie das neu zu vergebende Passwort ersetzt werden. Das neue Passwort sollte grundlegende Passwortstandards (mehr als 8 Zeichen, etc.) erfüllen, damit eine Änderung möglich ist.

Tipp: alternativ bietet sich auch das gleiche Kommando mit vorangestelltem sudo an:

sudo -u www-data php changePassword.php --user=Benutzername --password=NeuesPasswort

Hier wird das Kommando unter dem Benutzer www-data, dem unter Debian für Apache2 üblichen Benutzer, ausgeführt. Bei anderen Paketen, Konfigurationen oder Distributionen muss dieser Wert natürlich enstprechend des dort eingestellten Webserver-Benutzers geändert werden.

KDE verfolgt bereits seit vielen Jahren mobile Pläne, herausgekommen ist dabei bisher nicht viel. Außer einem Framework namens Kirigami mit dem man klassische Desktopapplikationen mobil-tauglich machen möchte und damit das Benutzererlebnis auf dem Desktop ruiniert.

Wenn ich für irgendwas auf dem Linux Desktop Enthusiasmus entwickeln konnte, dann war dies immer KDE. Dank KDE bin ich erst richtig warm mit Linux geworden und habe dem Desktop über zwei große Versionssprünge die Treue gehalten. Zuletzt zunehmend frustriert (siehe auch die Serie ab: KDE Plasma 5 Teil I: Käfer und Schuldzuweisungen) aber ein Wechsel kam nie in Betracht. Seit einigen Jahren nutze ich nun auf dem Desktop macOS (siehe: Ein Apfel in der Antarktis - Teilwechsel auf macOS) und die virtuellen Maschinen laufen mit MATE.

KDE Plasma hat sich bei einigen Migrationsvorhaben allerdings immer wieder als sehr guter Desktop für Windows-Umsteiger erwiesen (siehe: openSUSE Leap im wartungsfreien Einsatz). Daher komme ich damit immer noch in Berührung. Nun habe ich mir mal den Entwicklungsstand von openSUSE Leap 15.1 angeguckt, da im Sommer einige Systeme darauf migriert werden sollen.

Vielleicht muss man erst mal Abstand zu einem Desktop gewinnen um den Entwicklern laut zuzurufen: Lasst das!

KDE Plasma ist nach wie vor ein toller Desktop und inzwischen auch hinreichend ressourcenschonend (siehe auch: Mythen V: KDE benötigt viele Ressourcen) und stabil. Das gilt sogar für notorische Problemkinder wie die Kontact-Suite, die hier im Produktiveinsatz keine nennenswerten Probleme macht. Von wirklichen Softwareperlen wie Dolphin mal ganz zu schweigen - der vielleicht beste Dateimanager unter allen Betriebssystemen und Desktopumgebungen, die ich je verwenden durfte.

Die Kirigami-basierten Anwendungen wie Discover und die neuen Systemeinstellungen sind jedoch furchtbar. Die Benutzerführung ist ganz offensichtlich an mobile Endgeräte angepasst, die Programme sind reaktionslangsam, es gibt Grafikfehler und bei Fenstervergrößerung/-verkleinerungen hängt alles.

Natürlich ist die Hardware nicht die Neueste. Ein Haswell i5 mit entsprechender Onboard-Grafikkarte liegt bei Linux aber im gesunden Mittelfeld, das hat die Ubuntu-Telemetriedatenerhebung ergeben.

Es ist schön, dass die Entwickler von Plasma Mobile am Ball bleiben. Die Zukunft liegt im mobilen Bereich und Linux darf sie nicht komplett verschlafen. Es gibt aber nach all den Jahren noch kein einziges mobiles Gerät auf dem Plasma Mobile läuft und keine Distribution einer lauffähigen Umgebung. Das wird sich vielleicht mit dem Librem 5 ändern, aber das kommt auch erst nächstes Jahr - frühestens!

Hört also auf die Desktopanwender in Geiselhaft für ein mobiles Unterfangen zu nehmen, das noch gar nicht existiert. Macht nicht das Desktoperlebnis für eure mobilen Träume kaputt. Sonst habt ihr am Ende nichts, keinen Desktop und kein mobiles System.

Bilder:

Einleitungs- und Beitragsbild von ElisaRiva via pixabay

Im zweiten Teil haben wir unserer Electron-App einen zum jeweiligen Betriebssystem passenden Look verpasst. Dabei haben wir je nach Plattform ein passendes Stylesheet verwendet, damit sich die Anwendung gut einpasst.

In diesem Teil werden wir nun das Menü der gtk3-demo-application nachbauen. Dazu werden wir als Erstes das App-Menü der Anwendung bauen. Dieses definieren wir beim Start der App. Als zweiten Schritt werden wir ein Kontext-Menü erstellen, dass zur Laufzeit der Anwendung komponiert wird. Damit unterscheidet es sich in der Art und Weise der Definition vom App-Menü.

Abschließend werden wir noch ein paar Optimierungen für Mac OS vornehmen. Das App-Menü auf einem Mac unterscheidet sich grundlegend von den Menüs unter Windows und Linux.

App-Menü

Das App-Menü erstellen wir in der Datei src/index.js. Dort wird es während des Starts der App geladen. Als Template für das Menü verwenden wir einen Javascript-Array, der Javascript-Objekte enthält. Die Javascript Objekte entsprechen einem Menüpunkt.

Das Menü-Template hat folgende Struktur:

[
  {
    label: 'NAME',
    submenu: [
      { role: 'NAME' },
      {
        label: 'NAME',
        click () { ... }
      }
    ]
  }
]

Jeder Menüpunkt kann wiederum eigene Untermenüs enthalten. Der sich so ergebende Baum stellt das App-Menü da.

Mit der Methode buildFromTemplate erstellen wir dann das Menü-Objekt.

Zusätzlich ergänzen wir src/index.js noch um eine Funktion showMessage, die uns als Dummy-Callback dient.

import { app, BrowserWindow, Menu, dialog } from 'electron';
...
  mainWindow = null;
  });

   const showMessage = message => dialog.showMessageBox({
    type: 'info',
    message: `You activated action: "${message}"`,
    buttons: ['Close'],
  });

   const menu = Menu.buildFromTemplate([
    {
      label: 'Preferences',
      submenu: [
        {
          label: 'Prefer Dark Theme',
          type: 'checkbox',
        },
        {
          label: 'Hide Titlebar when maximized',
          type: 'checkbox',
        },
        {
          label: 'Color',
          submenu: [
            {
              label: 'Red',
              type: 'radio',
              accelerator: 'CmdOrCtrl+R',
              click: () => showMessage('Red'),
            },
            {
              label: 'Green',
              type: 'radio',
              accelerator: 'CmdOrCtrl+G',
              click: () => showMessage('Green'),
            },
            {
              label: 'Blue',
              type: 'radio',
              accelerator: 'CmdOrCtrl+B',
              click: () => showMessage('Blue'),
            },
          ],
        },
        {
          label: 'Shape',
          submenu: [
            {
              label: 'Square',
              type: 'radio',
              accelerator: 'CmdOrCtrl+S',
              click: () => showMessage('Square'),
            },
            {
              label: 'Rectangle',
              type: 'radio',
              accelerator: 'CmdOrCtrl+R',
              click: () => showMessage('Rectangle'),
            },
            {
              label: 'Oval',
              type: 'radio',
              accelerator: 'CmdOrCtrl+O',
              click: () => showMessage('Oval'),
            },
          ],
        },
        {
          label: 'Bold',
          type: 'checkbox',
          accelerator: 'CmdOrCtrl+Shift+B',
          click: () => showMessage('Bold'),
        },
      ],
    },
    {
      label: 'Help',
      submenu: [
        {
          label: 'About',
          accelerator: 'CmdOrCtrl+A',
          click: () => dialog.showMessageBox({
            type: 'info',
            title: 'about',
            message: `GTK+ Code Demos
3.22.30
Running against GTK+ 3.22.30
Program to demonstrate GTK+ functions.
(C) 1997-2013 The GTK+ Team
This program comes with absolutely no warranty.
See the GNU Lesser General Public License, 
version 2.1 or later for details.`,
            buttons: ['Close'],
          }),
        },
      ],
    },
  ]);
  Menu.setApplicationMenu(menu);
...

Anschließend sollte das Menü zu sehen sein. Das Development-Menü wird nicht mehr angezeigt. Für ein größeres Projekt könnte es sinnvoll sein, ein Development-Menü zu erhalten, dass im Entwicklungsmodus angezeigt wird und bei Auslieferung ausgeschaltet wird.

Kontext-Menu

Die Demo-App besitzt auch ein Kontextmenü zur Textbearbeitung. Um dieses nachzubauen, gehen wir etwas anders vor. Wir erstellen es nicht mehr aus einem Template, sondern komponieren es zur Laufzeit.

Dementsprechend ergänzen wir unseren Code auch nicht mehr in der src/index.js, sondern in src/app.jsx.

Als Erstes definieren wir das Menü im Konstruktor unsere App-Komponente. Weil die Menu-Klasse nur im Hauptprozess zur Verfügung steht, müssen wir auf sie über das Remote-Objekt zugreifen.

Das Menü selbst ist sehr viel einfacher als das App-Menü gehalten. Wir fügen nur ein paar Standardfunktionen und einen Trenner in das Kontext-Menü ein. Wir machen dabei ausgiebig Gebrauch von der role-Option. Diese erlaubt uns, von Electron vordefinierte Standardmenüs zu verwenden.

    const menu = new remote.Menu();
    menu.append(new remote.MenuItem({ role: 'cut' }));
    menu.append(new remote.MenuItem({ role: 'copy' }));
    menu.append(new remote.MenuItem({ role: 'paste' }));
    menu.append(new remote.MenuItem({ role: 'delete' }));
    menu.append(new remote.MenuItem({ type: 'separator' }));
    menu.append(new remote.MenuItem({ role: 'selectall' }));
    this.menu = menu;
...
    this.onContextMenu = this.onContextMenu.bind(this);

Damit wir auf das Kontext-Menü zugreifen können, definieren wir einen onContextMenu-Handler für die Textarea. Dieser macht nichts anderes, als einfach das Kontextmenü zu öffnen und mit dem Hauptfenster zu verbinden.

  onContextMenu(event) {
    event.preventDefault();
    this.menu.popup({ window: remote.getCurrentWindow() });
  }
...
    <textarea id="TextField" onKeyDown={this.onInput} onContextMenu={this.onContextMenu} />

Jetzt kann man über der Textarea mit der rechten Maustaste ein Kontext-Menü aufrufen.

Mac-Menü

Das App-Menü unter Mac OS unterscheidet sich deutlich von den App-Menüs unter Windows und Linux.

In Mac OS gibt es 3 Standard Menüs, die jeder Anwendung bereitstellen sollte:

• window
• help
• services

Zu diesem Zweck stellt Electron unter Mac OS einige Standard-Menüs über Rollen bereit. Diese helfen beim Aufbau des Menüs.

Als Erstes speichern wir in src/index.js das Template für das App-Menü in einer eigenen Variablen.

Dann passen wir die Rolle unsere Hilfe-Menüs an.

Als Nächstes fügen wir die beiden anderen Unter-Menüs in unserem App-Menü ein, falls wir uns auf einem Mac befinden. Dazu verwenden wir Standard-JavaScript-Methoden, um unser Template-Array zu erweitern.

Wenn wir nun unsere Beispielanwendung auf einem Mac starten, wird das Menü im globalen Menü von Mac OS angezeigt.

Du findest den Source-Code für dieses Tutorial auf Github: https://github.com/rockiger/electron-react-example

Im letzten Teil werden wir uns um die Paketierung mit electron-forge kümmern.

Created with Dictandu

The post Cross-plattform Apps mit Electron und React Teil 3 appeared first on Rockiger.

Mozillas kostenloser und die Privatsphäre respektierender Filesharing-Dienst Firefox Send hat die Betaphase verlassen und erweitert nun offiziell das Produkt-Portfolio von Mozilla. Eine Android-App folgt in Kürze.

Bereits 2017 hat Mozilla Firefox Send im Rahmen von Test Pilot gestartet. Mit dem heutigen Tag verlässt Firefox Send die Beta-Phase und startet mit neuem Logo und neuer Webseite durch.

Dateien privat und sicher teilen mit Firefox Send

Firefox Send ist ein Dienst zum temporären Bereitstellen von Dateien. Die Nutzung von Firefox Send ist kostenlos und erfolgt durch eine Ende-zu-Ende-Verschlüsselung sicher. Durch die Festlegung einer Maximal-Dauer sowie einer Maximal-Anzahl an Downloads löschen sich die Dateien nach kurzer Zeit wieder von selbst vom Mozilla-Server.

Dauerhaft können Dateien nicht bei Firefox Send gelagert werden, denn es ist ein wesentlicher Teil des Konzeptes von Firefox Send, dass sich Nutzer nicht sorgen müssen, dass ihre Dateien für immer in der Cloud herumliegen. Optional kann außerdem auch noch ein Passwort festgelegt werden, ohne welches die Dateien nicht heruntergeladen werden können.

Firefox Send funktioniert mit jedem Browser, also nicht nur mit Firefox. Ein Firefox Account ist weder für das Hochladen noch für das Herunterladen von Dateien notwendig. Firefox Send ist also für jeden geeignet.

Ohne Anmeldung liegt das Limit bei 1 GB pro Datei. Wer sich mit seinem Firefox Account anmeldet, kann Dateien mit einer Größe von bis zu 2,5 GB hochladen.

Die Verwendung des Firefox Accounts hat außerdem den Vorteil, dass hochgeladene Dateien von jedem Gerät aus verwaltet werden können und nicht nur von dem Gerät, von welchem sie hochgeladen worden sind.

Außerdem ist ein höheres Limit als ein Download, nämlich bis zu 100 Downloads, sowie eine Maximal-Dauer von sieben Tagen nur mit Firefox Account möglich.

Zusätzlich soll schon bald, voraussichtlich sogar noch in dieser Woche, die erste Beta-Version einer Android-App von Firefox Send veröffentlicht werden.

Der Beitrag Mozillas Filesharing-Dienst Firefox Send startet offiziell erschien zuerst auf soeren-hentzschel.at.

Aktive Festplatten benötigen Energie, erzeugen Wärme, lassen den Lüfter laufen, verbrauchen dadurch noch mehr Energie und das meist völlig sinnlos, weil sie die meiste Zeit sowieso nicht benötigt werden. Daher sollte man Festplatten nach Möglichkeit bei Nichtgebrauch in den Standby schicken.

In heutigen NAS-Systemen arbeiten oft 2 und mehr große HDDs. Proprietäre Lösungen wie Synology oder QNAP haben daher längst Standby-Lösungen integriert. Ein normales Linux-Betriebssystem lässt die Festplatten allerdings 24/7 rotieren und erzeugt dadurch sinnlosen Energiebedarf. Nicht benötigte Festplatten sollten daher abgeschaltet werden

Voraussetzung ist dass das eigentliche System nicht auf einer der Festplatten liegt, da diese dann beständig wieder aufgeweckt werden würde und die Festplatte dadurch unnötigen Belastungen ausgesetzt wäre. Je nach Hardware kann man das eigentliche System z. B. auf eine kleine SSD installieren oder auch auf einen USB 3-Stick, der immer angeschlossen ist.

Grundsätzlich kann Linux mittels hdparm Festplatten bei Nicht-gebrauch in den Standby-Modus schicken. Hierzu ist lediglich eine Anpassung der Konfigurationsdatei /etc/hdparm.conf notwendig. Leider haben viele Distributoren die Situation verschlimmbessert indem sie die hdparm.conf ignorieren oder mit Skripten umgehen. Ubuntu und openSUSE sind hier unrühmliche Beispiele.

Eine einfache Möglichkeit das Problem zu beheben besteht in der Nutzung von TLP. Eigentlich handelt es sich dabei um eine Lösung zum Energiesparen auf Notebooks (ursprünglich sogar nur Thinkpads). Es lässt sich aber auch hervorragend auf Server- und Desktopsystemen nutzen.

Die Installation erfolgt bei vielen Distributionen direkt aus den Paketquellen. Bei openSUSE beispielsweise via:

# zypper in tlp

Anschließend muss die Konfiguration angepasst werden. Dies geschieht über die Datei /etc/default/tlp.

Folgender Abschnitt ist dabei von Interesse:

# Disk devices; separate multiple devices with spaces (default: sda).
# Devices can be specified by disk ID also (lookup with: tlp diskid).
DISK_DEVICES="sda"

# Disk advanced power management level: 1..254, 255 (max saving, min, off).
# Levels 1..127 may spin down the disk; 255 allowable on most drives.
# Separate values for multiple disks with spaces. Use the special value 'keep'
# to keep the hardware default for the particular disk.
DISK_APM_LEVEL_ON_AC="128"
DISK_APM_LEVEL_ON_BAT="128"

# Hard disk spin down timeout:
#   0:        spin down disabled
#   1..240:   timeouts from 5s to 20min (in units of 5s)
#   241..251: timeouts from 30min to 5.5 hours (in units of 30min)
# See 'man hdparm' for details.
# Separate values for multiple disks with spaces. Use the special value 'keep'
# to keep the hardware default for the particular disk.
DISK_SPINDOWN_TIMEOUT_ON_AC="120"
DISK_SPINDOWN_TIMEOUT_ON_BAT="120"

Unter DISK_DEVICES legt man fest welche Festplatten betroffen sein sollten. Im obigen Beispiel lediglich sda. Man könnte hier aber auch mehre Festplatten mit Leerzeichen getrennt angegeben.

Im zweiten Abschnitt legt man den APM-Level fest. Bei mehr als einer angegebenen Festplatte müssen die Werte nun ebenfalls für jede Platte angegeben und mit Leerzeichen getrennt werden. Viele Distributionen nehmen hier 254, was aber ein Abschalten verhindert. Hier muss man ein bisschen experimentieren, da das Verhalten je nach Festplatten-Modell unterschiedlich sein kann. Bei 128 (was oft auch für Notebooks verwendet wird) habe ich bei meinen WD Red Modellen gute Erfahrungen gemacht.

Der dritte Abschnitte steuert die Zeit, nach der die Festplatte ohne Zugriffe abgeschaltet werden. Die im Beispiel aufgeführten 120 bedeutet 10 Minuten. Der Wert ist ebenfalls für jede Platte anzugeben.

Abschließend aktiviert und startet man den Dienst:

# systemctl enable tlp

# systemctl start tlp

Mittels des folgenden Kommandos kann man überprüfen ob die Festplatte wie gewünscht in den Standby geht.

# hdparm -C /dev/sda

Folgende Ausgabe erscheint wenn die Festplatte korrekt in den Standby geht:

/dev/sda:
 drive state is:  standby

Kommt hingegen folgende Ausgabe ist die Festplatte aktiv:

/dev/sda:
 drive state is:  active/id

Bilder:

Einleitungs- und Beitragsbild von FreePhotosART via pixabay

Es muss nicht immer gleich der Red Hat Sattelite Server sein, um einen lokalen Spiegelserver für die Installation von RPM-Paketen bereitzustellen.

Auf GitHub habe ich im Repository „Poor man’s RHEL mirror“ eine kleine Sammlung von Bash-Skripten zusammengestellt, mit denen sich ein Spiegelserver für RHEL-Repositories aufbauen lässt. Mit diesem können RHEL-Repositories, für welche man eine gültige Subskription besitzt, auf einen Host im lokalen Netzwerk synchronisiert und deren Pakete anderen RHEL-Servern im LAN zur Verfügung gestellt werden.

Neben der reinen Spiegelung können mit den auf GitHub bereitgestellten Skripten weitere lokale Stage-Repositories eingerichtet werden, mit denen sich die Verfügbarkeit von Paketen für einzelne Stages steuern lässt. Zusätzlich bietet das Projekt Skripte, um eigene YUM-Repositories zu erstellen, um zum Beispiel eigene Pakete darüber bereitstellen zu können. Des Weiteren wurde die Möglichkeit berücksichtigt, die Red Hat Errata Informationen in die lokalen RHEL-Repositories zu integrieren, um die --advisory Option für YUM auch auf Systemen nutzen zu können, die über keine eigene Verbindung zum Internet verfügen.

Warum ist dieses Projekt nützlich?

• Es schont die eigene Internetverbindung, da Pakete nur einmal aus dem Internet heruntergeladen und anschließend im LAN zur Verfügung gestellt werden.
• Es unterstützt bei der Erstellung eines YUM-Repositories zur Bereitstellung von RPM-Paketen.
• Es unterstützt das Staging-Konzept, in dem es die Möglichkeit bietet, stage-spezifische Repositories bereitzustellen.
• Es implementiert die Red Hat Errata Informationen in die gespiegelten RHEL-Repos, so dass diese von angebundenen Servern genutzt werden können, die über keine eigene Internetverbindung verfügen.
• Es entstehen keine Zusatzkosten, da alle notwendigen Werkzeuge in den Repos einer RHEL-Standard-Subskription enthalten sind.

Wer kann dieses Projekt nutzen?

Das Projekt selbst steht unter der MIT-Lizenz und kann unter deren Bedingungen frei genutzt, modifiziert und weiter verteilt werden.

Für den Betrieb des Spiegelservers ist der Besitz einer gültigen RHEL-Subskription Voraussetzung. Denn es können nur jene Repos gespiegelt werden, für die eine gültige Subskription vorhanden ist. Auch alle an den Spiegelserver angeschlossenen Systeme müssen über eine entsprechende und gültige Subskription verfügen.

Bei Fragen zu Subskriptionen helfen die folgenden Seiten weiter:

• Red Hat subscription model FAQ
• Red Hat subscription service overview

Um mit diesem Projekt einen Spiegelserver aufsetzen und betreiben zu können, sind gewisse Kenntnisse erforderlich. Zu diesen zählen die Installation eine RHEL-Systems inkl. Registrierung, das Hinzufügen von Subskriptionen und die Installation von Paketen. Informationen hierzu bietet die Product Documentation for Red Hat Enterprise Linux 7.

Wie ist das GitHub-Repository zu diesem Projekt aufgebaut?

Das GitHub-Repository beinhaltet ein README, welches einen Überblick über das Projekt und eine Kurzbeschreibung der einzelnen Skripte in englischer Sprache beinhaltet. Im Master-Branch befindet sich die letzte stabile Version des Projekts. Weiterentwicklungen und Fehlerkorrekturen werden im Dev-Branch gepflegt und nach einer Testphase in den Master-Branch übernommen.

Sorgen, Nöte und Anträge sowie gefundene Fehler dürfen gern über die Issue-Funktion oder in den Kommentaren zu diesem Beitrag gemeldet werden.

An dieser Stelle folgt eine Beschreibung in deutscher Sprache, wie ein Spiegelserver mit diesem Projekt aufgebaut werden kann. Dabei handelt es sich um keine Schritt-für-Schritt-Anleitung und es werden grundlegende Kenntnisse über den Betrieb eines RHEL-Servers und die Installation sowie Konfiguration von Paketen vorausgesetzt.

Einrichtung eines Spiegelservers für arme Sysadmins

Um das Projekt nutzen zu können, benötigt man eine RHEL-Installation mit gültiger Subskription, auf welcher mindestens die folgenden Pakete installiert sein müssen:

• reposync und createrepo, um RHEL-Repos synchronisieren und eigene Repos erstellen zu können
• git zum Klonen des hier beschriebenen Projekts
• Die Gruppe Basic Web Server oder einen anderen Webserver eurer Wahl, um die gespiegelten Repos über HTTP im LAN bereitstellen zu können

Zu Beginn sind die Dateien aus dem oben genannten GitHub-Repository in einem Verzeichnis auf dem lokalen Host bereitzustellen. Anschließend ist das Projekt zu konfigurieren. Die dazu notwendigen Schritte werden in den folgenden Abschnitten erläutert.

CONFIG.SAMPLE

Hierbei handelt es sich um die Hauptkonfigurationsdatei. Diese ist in CONFIG umzubenennen bzw. zu kopieren und zu editieren. In dieser Datei werden die Variablen gesetzt, die von den verschiedenen Shell-Skripten verwendet werden. Darunter sind z.B. Angaben, welche Repos gespiegelt werden und wo die Dateien gespeichert werden sollen.

Die Datei ist mit Kommentaren versehen und sollte weitgehend selbsterklärend sein (was für alle weiteren Dateien gilt).

create_yum_repo.sh

Dieses Skript kann genutzt werden, um ein eigenes YUM-Repository zu erstellen, über welches RPM-Pakete bereitgestellt werden können. Der Name des zu erstellenden Repos kann dem Skript als Parameter übergeben werden.

do_reposync.sh

Dies ist das Herzstück des Projekts. Es kümmert sich um die Spiegelung der RHEL-Repos. Die notwendigen Parameter werden in der Datei CONFIG konfiguriert.

Das Skript lädt nur die aktuellen Pakete aus den Repos herunter, löscht aus den Upstream-Repos entfernte Pakete jedoch nicht automatisch auf dem lokalen Host. Dies ist meinen persönlichen Anforderungen geschuldet. Es ist nicht ausgeschlossen, dass ich diese Parameter in Zukunft ebenfalls konfigurierbar gestalte.

Einen Überblick über den Speicherbedarf ausgewählter RHEL-Repos findet ihr hier: How much disk space do I need for reposync?

Um die heruntergeladenen Pakete im LAN zur Verfügung zu stellen, muss das BASEDIR (siehe CONFIG) über einen Webserver zugreifbar gemacht werden.

refresh_repo.sh

Werden einem Repo neue RPM-Dateien hinzugefügt, muss die Metadaten-Datenbank aktualisiert werden, damit Klienten die neuen Pakete auch finden können. Um diese Aktualisierung kümmert sich eben dieses Skript.

rsync_repo.sh

Mit diesem Skript lassen sich Repos auf dem lokalen System synchronisieren. Dabei werden die Dateien jedoch nicht 1:1 kopiert, sondern Hardlinks erstellt. Dies spart bei der Verwendung mehrerer Repos für unterschiedliche Stages Speicherplatz.

Neben dem kompletten Sync eines Repos ist es auch möglich, dem Skript eine Datei zu übergeben, welche die Namen der Pakete enthält, welche in ein weiteres Repo „transportiert“ werden sollen.

Wrapper-Scripts

In meiner Umgebung arbeiten wir mit bis zu vier verschiedenen Stages (E, I, Q und P). Für jede dieser Stages wird ein eigenes Stage-Repo des Upstream rhel-7-server-rpms erzeugt. Um diese Stage-Repos zu aktualisieren, werden die folgenden Skripte verwendet:

• update_rhel-e-stage.sh
• update_rhel-i-stage.sh
• update_rhel-q-stage.sh
• update_rhel-p-stage.sh

Jede Stage wird mit den Paketen aus der vorhergehenden aktualisiert. So ruft z.B. update_rhel-e-stage.sh das Skript rsync_repo.sh, um die Pakete aus dem lokalen Spiegel des Upstreams rhel-7-server-rpms zu importieren. update_rhel-i-stage.sh verwendet dementsprechend die rhel-e-stage als Quelle usw.

Diese Konfiguration ist für meinen Anwendungsfall optimiert. Die Verwendung der Skripte ist optional. Der Spiegelserver funktioniert auch ohne diese Wrapper-Scripts.

update_mirror_packages_and_erratas.sh

Dieses Skript aktualisiert die Pakete in den Repos des lokalen Spiegelservers inkl. der Red Hat Errata Informationen. Letztere ermöglichen es, die Erratas (RHSA, RHBA und RHEA) auch Systemen verfügbar zu machen, welche über keine Verbindung zum Internet verfügen.

Das Skript ist in der Standardeinstellung auf meinen Anwendungsfall optimiert und aktualisiert am Ende alle vorhandenen RHEL-Stage-Repos. Wer diese Funktion nicht benötigt, kann sie durch Auskommentieren der Zeilen 45 und 46 im Skript deaktivieren.

Anschließend kann ein Cronjob erstellt werden, welcher das Skript ausführt, um den Spiegelserver regelmäßig gemäß der eigenen Anforderungen zu aktualisieren.

Die gespiegelten Repos verfügbar machen

Hat man die Repos seiner Wahl gespiegelt, ergibt sich je nach Konfiguration eine Verzeichnisstruktur ähnlich der folgenden.

$ tree -L 2
.
├──  rhel-7-test-mirror
│   ├── rhel-7-server-extras-rpms
│   ├── rhel-7-server-optional-rpms
│   ├── rhel-7-server-rpms
│   ├── rhel-7-server-supplementary-rpms
│   ├── rhel-e-stage
│   ├── rhel-e-stage.repo
│   ├── rhel-i-stage
│   ├── rhel-p-stage
│   ├── rhel-q-stage
│   └── rhel-server-rhscl-7-rpms

Das Verzeichnis rhel-7-test-mirror aus obigen Beispiel enthält die gespiegelten Repos als Unterverzeichnisse. Dieses Verzeichnis sollte über einen Webserver zugreifbar gemacht werden, um die Pakete den Clients im lokalen Netzwerk verfügbar zu machen.

Im obigen Listing ist eine Datei namens rhel-e-stage.repo zu sehen. Dabei handelt es sich um eine Repo-Datei, welche heruntergeladen und im Verzeichnis /etc/yum.repos.d/ platziert werden kann, um wie in diesem Beispiel das Repo rhel-e-stage zu aktivieren.

Aufbau einer Repo-Datei

Das folgende Listing zeigt die kommentierte Repo-Datei aus dem vorstehenden Abschnitt. Sie kann als Muster für weitere eigene Repo-Dateien dienen.

[rhel-e-stage] # Repo ID
baseurl = http://example.com/rhel-7-test-mirror/rhel-e-stage/
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
name = Repo for rhel-7-server-rpms (Test)

Fragen, Sorgen, Nöte und Anträge

Das Projekt und die enthaltene Software werden so wie sie sind unter der angegebenen Lizenz zur Verfügung gestellt.

Fragen, Sorgen, Nöte und Anträge können sowohl hier in den Kommentaren zum Artikel, als auch auf Github hinterlassen werden.

Ich hoffe, dass dieses Projekt euch (weiterhin) nützlich ist und freue mich über Rückmeldungen, wie es euch gefällt.

Vor ca. einem Jahr habe ich beschrieben, wie man mit einem Raspberry Pi und einem Feinstaubsensor die Luftqualität messen kann. Das Setup setzen wir so seit einigen Jahren bei uns in der Schule bzw. auch privat ein. Einen Nachteil hat dieses Projekt allerdings: es ist nicht mobil, sondern abhängig von einem WLAN-Netz bzw. einer Netzwerkverbindung. Wenn der Raspberry Pi und das Smartphone / ein Rechner nicht im gleichen Netz sind, kann man nicht auf die Messdaten zugreifen. Deshalb haben wir vor einiger Zeit den Raspberry Pi um einen kleinen Bildschirm ergänzt, sodass man die Werte direkt am Gerät ablesen kann. Wie man diesen Bildschirm für unser mobiles Feinstaubmessgerät einrichtet und welche zusätzlichen Konfigurationen notwendig sind, möchte ich in diesem Artikel kurz vorstellen.

Bildschirm für den Raspberry Pi einrichten

Auf Amazon oder AliExpress gibt es verschiedene Displays für den Raspberry Pi. Diese reichen von ePaper-Screens bis hin zu LCDs mit Touchfunktion. Wir haben uns für einen 3,5″ LCD mit Touch entschieden, welcher eine Auflösung von 320×480 Pixel hat (Modell MPI3501). Man kann diesen Bildschirm einfach auf die GPIO Pins stecken. Dazu kostet er gerade mal 10-15€. Schön ist auch, dass er mit 3,5″ genauso groß wie ein Raspberry Pi ist.

Wenn man den Bildschirm aufsteckt und den Raspberry Pi startet, bleibt der Bildschirm weiß. Man muss zuerst noch die passenden Treiber für das Display installieren. Dazu meldet man sich per SSH an und führt folgende Befehle aus:

$ rm -rf LCD-show
$ git clone https://github.com/goodtft/LCD-show.git
$ chmod -R 755 LCD-show
$ cd LCD-show/

Je nach Bildschirmmodell muss man nun den passenden Befehl ausführen um die Treiber zu installieren. In unserem Fall (für das Modell MPI3501):

$ sudo ./LCD35-show

Dieser Befehl installiert die entsprechenden Treiber und startet den Raspberry Pi anschließend neu.

Pixel-Desktop installieren und Autostart einrichten

Damit wir die Website mit den Messwerten direkt beim Start auf dem Bildschirm angezeigt bekommen sind noch einige Schritte notwendig. Zuerst muss man die Pixel-Desktopumgebung installieren (falls man bisher Raspian Lite verwendet hat) mit

$ sudo apt install raspberrypi-ui-mods

Dann fehlt noch der Chromium-Browser, um die Website anzuzeigen:

$ sudo apt install chromium-browser

Standardmäßig ist der Autologin für das Benutzer „pi“ nicht eingerichtet. Dies ist aber notwendig, damit die Messwerte direkt nach dem Start angezeigt werden können, ansonsten begrüßt einen nur der Anmeldebildschirm. Den Autologin kann man über das raspi-config Programm einrichten:

sudo raspi-config

Im Menü wählt man dann 3 Boot Options → B1 Desktop / CLI → B4 Desktop Autologin.

Zu guter Letzt fehlt noch die Einrichtung des Autostarts, damit Chromium nach dem Booten automatisch mit der AQI-Seite gestartet wird. Dazu legt man den Ordner /home/pi/.config/lxsession/LXDE-pi/ an:

$  mkdir -p /home/pi/config/lxsession/LXDE-pi/

Anschließend erstellt man in diesem Ordner die Datei autostart

$ nano /home/pi/.config/lxsession/LXDE-pi/autostart

und fügt diesen Inhalt ein:

#@unclutter
@xset s off
@xset -dpms
@xset s noblank

# Chromium im Vollbild beim Start öffnen
@chromium-browser --incognito --kiosk http://localhost

Möchte man noch den Mauszeiger ausblenden, muss man noch das Paket unclutter installieren und am Anfang der autostart das Kommentarzeichen entfernen:

$ sudo apt install unclutter

Da ich im letzten Jahr ein paar kleine Änderungen am Code vorgenommen habe, empfiehlt es sich das Skript und die Dateien der AQI-Website neu herunterzuladen (wie das geht, steht im Originalartikel).

Fazit

Durch das Display hat man nun ein mobiles Feinstaubmessgerät. Wir setzen sie an unserer Schule ein um z.B. die Qualität der Luft in den Klassenzimmern zu überprüfen oder um Vergleichsmessungen durchzuführen. Mit diesem Setup ist man nicht mehr auf eine Netzwerkverbindung oder WLAN angewiesen, sondern kann die kleine Messstation überall einsetzen – mit einer Powerbank sogar noch unabhängig vom Stromnetz.

Kommentar hinzufügen

Der Beitrag Wie man ein mobiles Feinstaubmessgerät bauen kann erschien zuerst auf .:zefanjas:..

Vor vielen Jahren habe ich Windows auf meinem Desktop durch Linux ersetzt und mittlerweile einige Distributionen im Einsatz gehabt. Immer habe ich die schnelle und einfache Installation von Software über die Paketmanager als einen der größten Vorteile gegenüber Windows gesehen. Besonders die Möglichkeit zum Einbinden von Drittquellen fand ich immer toll. Damit war die Möglichkeit geboten, Updates an einer einzigen Stelle (dem Paketmanager) durchzuführen, ohne dass man auf den “Store” der Distribution angewiesen ist.

Ja, die Sicherheitsproblematik bei Drittquellen ist mir bewusst, dieses Problem habe ich aber in noch größerem Maße beim Download von Software über irgendwelche Webseiten. Daher hoffe ich, auch in Zeiten von Flatpaks, Snaps und Appimages, dass uns die Paketmanager noch lange erhalten bleiben.

Sicherlich ist die Aufgabe, die Paketmanager zu bewältigen haben, gewaltig. Programme bringen Abhängigkeiten mit, die wiederum Abhängigkeiten haben, die wiederum…

Bei der Installation zeigen einem die Paketmanager an, welche Software durch Abhängigkeiten zusätzlich zum gewünschten Programm installiert wird. Leider zeigen sie nicht an, welches Paket welche Abhängigkeit auslöst.

Dies kann man sehr schön mit dem Programm debtree visualisieren

Debtree – Installation und Funktion

In der Debian/Ubuntu/Mint-Familie lässt sich debtree direkt aus den Paketquellen installieren. Zusätzlich wird graphviz benötigt, um aus den von debtree erzeugten DOT-Files ein Bild zu erstellen.

Anschließend kann die erste Grafik erzeugt werden. Zum testen eignet sich ein Paket, das relativ wenige Abhängigkeiten mitbringt. Beispielsweise nano oder openssl.

Wie man sieht, hat debtree zuerst die Abhängigkeiten eingelesen, davon allerdings auch welche übersprungen. In diesem Fall die libc6.
Debtree hat in der Datei /etc/debtree/skiplist einige Abhängigkeiten definiert, die standardmäßig ignoriert werden. Es handelt sich dabei um Abhängigkeiten, die so gewöhnlich sind, dass sie in einem Großteil der Grafiken auftauchen würden und diese unnötig aufblasen. Die Liste kann man nach den eigenen Wünschen anpassen.

Mit der Option –no-skip soll sich das Anwenden dieser Liste deaktivieren lassen. Leider hat dies bei mir nicht funktioniert. Das Anwenden von –no-skip hatte keinerlei Auswirkungen. Alternativ kann man die skiplist anpassen, oder mit der Option –show-all alle Abhängigkeiten anzeigen lassen. Diese Möglichkeit hat funktioniert, führt aber bei Paketen mit vielen Abhängigkeiten schnell zu einer riesigen Datei.

Zusätzlich gibt es unter /etc/debtree/endlist eine Liste mit Paketen, deren Abhängigkeiten nicht weiter verfolgt werden. Im Gegensatz zu den Paketen in der Skiplist, die gar nicht in der Grafik auftauchen, werden die Pakete in der endlist in der Grafik angezeigt. Allerdings endet die Linie mit Abhängigkeiten nach diesem Paket.

Nach dem Ausführen des Befehls erhält man folgende Grafik.

Bei Paketen mit vielen Anhängigkeiten wird die Grafik schnell sehr riesig und unübersichtlich. Dies sieht man beispielsweise, wenn man sich die Abhängigkeiten des Webservers NGINX, ohne das setzen zusätzlicher Optionen, anzeigen lässt. Dabei handelt es sich auch bei NGINX noch um ein Paket mit relativ wenigen Abhängigkeiten. Möchte man die Abhängigkeiten des Pakets gnome-shell anzeigen, kapituliert dot mit folgender Meldung “dot: graph is too large for cairo-renderer bitmaps. Scaling by 0.533022 to fit” Auch angepasste Image ist anschließend noch knapp 55 MB groß.

Debtree Optionen

Um zu vermeiden, dass man riesige und damit unbrauchbare Grafiken erhält, bietet Debtree einige Optionen um die Ausgabe zu beeinflussen.

Natürlich finden sich in der Manpage noch eine Vielzahl weiterer Optionen, mit denen sich die Ausgabe beeinflussen lässt. Hierbei handelt es sich meiner Meinung nach um die wichtigsten.

Debtree Grafiken interpretieren

Die verschiedenen Pfeile, Farben und Formen haben folgende Bedeutungen.

Paketmanager haben ja im Normalfall die tolle Eigenschaft, wie durch Magie die benötigten Abhängigkeiten bereit zu stellen. Mit debtree lässt sich schön darstellen, wie diese Magie funktioniert, wie komplex die Abläufe sind und mit welchen Entscheidungen ein Paketmanager unter Umständen zu kämpfen hat.

Abhängigkeiten von Paketen mit debtree visualisieren ist ein Beitrag von techgrube.de.

Wenn ein Kommando auf der Linux-Konsole mit vorangestellten sudo ausgeführt wird, wie z.B.

sudo apt install mc

wird das Kommando in Normalfall mit den Rechten und im Kontext des Nutzers root ausgeführt. Manchmal soll eine solche Operation jedoch mit einem anderen Nutzer durchgeführt werden. Dazu dient die sudo-Option -u:

sudo -u www-data crontab -e

Nach der Option muss der Nutzer angegeben werden, in dessen Kontext gewechselt werden soll. In diesem Beispiel würde die Crontab-Datei des Nutzers www-data geöffnet.

In privaten Fenstern sind Erweiterungen ab Firefox 67 standardmäßig deaktiviert. Nutzer können aber alle – oder auch einzelne Erweiterungen – in privaten Fenstern aktivieren und erhalten so mehr Kontrolle als bisher.

Ab Firefox 67 werden private Fenster noch ein Stück privater, denn ab dann sind Erweiterungen in privaten Fenstern standardmäßig nicht länger aktiviert und können so nicht länger Aktivitäten ausführen, welche in Widerspruch mit dem Konzept privater Fenster stehen. Firefox weist nach dem Update beim ersten Start eines privaten Fensters in Form eines Dialogs darauf hin.

Dies betrifft jedoch lediglich neu installierte Erweiterungen. Damit sich Nutzer nicht über plötzlich nicht mehr funktionierende Erweiterungen wundern, erhalten alle bereits installierten Erweiterungen automatisch die Berechtigung, auch in privaten Fenstern aktiv zu sein. Für bestehende Nutzer ändert sich also erst einmal nichts, bis die nächste Erweiterung installiert wird.

Im Add-on Manager markiert Firefox sämtliche Erweiterungen, welche die Berechtigung erhalten haben, auch in privaten Fenstern aktiv zu sein. Oberhalb der Erweiterungen steht eine Erklärung mit Link auf eine Hilfe-Seite von Mozilla.

In der Detail-Ansicht des Add-on Managers kann für jedes Add-on individuell eingestellt werden, ob dieses in privaten Fenstern aktiv sein soll oder nicht.

Bisher waren Add-ons immer sowohl in regulären als auch in privaten Fenstern aktiv. Mit dieser neuen Option kann der Nutzer selbst entscheiden, bestimmte Erweiterungen auch in privaten Fenstern zu nutzen, andere jedoch nicht. Damit ist diese Neuerung ein Mehrgewinn für die Nutzer, ungeachtet dessen, wie man zur Standard-Einstellung steht, weil so jeder das bekommt, was er respektive sie will.

Der Beitrag Firefox 67: Nutzer entscheidet, welche Erweiterungen in privaten Fenstern aktiv sind erschien zuerst auf soeren-hentzschel.at.

Um eine Fotocollage zu erstellen existieren viele Wege. So kann die Collage mit dem Bildbearbeitungsprogramm der Wahl, wie z.B. GIMP, erstellt werden. Mit zunehmender Anzahl von Fotos kann sich dieser Prozess allerdings in die Länge ziehen.

Eine mittels PhotoCollage erstellte Collage

Eine Alternative zu diesem manuellen Prozess kann die Anwendung PhotoCollage, welche über das Paket photocollage installiert werden kann, darstellen:

sudo apt install photocollage

Die Anwendung verfügt über ein simples Interface, in welchem die Bildgröße und die Farbe der Ränder eingestellt werden. Anschließend können die Bilder hinzugefügt werden und unterschiedliche Anordnungen ausprobiert werden. Anschließend kann die Collage exportiert werden. Im Gegensatz zu vielen Webdiensten, welche ähnliches leisten, ist PhotoCollage nicht auf bestimmte Größen beschränkt. Damit sind auch Collagen im Format DIN-A2 und größer möglich. Der Quelltext des Projektes ist auf GitHub zu finden. Lizenziert ist PhotoCollage unter der GPL in der Version 2 und damit freie Software.

Firefox Lockbox ist ein Passwort-Manager von Mozilla für Apple iOS, der in Kürze außerdem für Android sowie für den Desktop-Firefox erscheinen wird. Dieser Artikel gibt eine Vorschau, was von Lockbox für den Desktop-Firefox zu erwarten ist.

Im Juli 2018 hat Mozilla die erste Version von Firefox Lockbox für Apple iOS veröffentlicht, einen Passwort-Manager mit 256-Bit-Verschlüsselung und Synchronisation, der seit dem auch schon einige Updates erhalten hat.

Download Firefox Lockbox für Apple iOS

Doch nicht nur auf Apple iOS ist Firefox Lockbox ein Thema. In Kürze wird Mozillas Passwort-Manager ebenso für Android erscheinen und die bevorzugte Passwort-Lösung für den kommenden Fenix-Browser sein, im Sommer wird Lockbox außerdem als Erweiterung für den Desktop-Firefox erscheinen. Mockups geben einen Ausblick, was von der Firefox-Erweiterung zu erwarten ist.

Wie immer bei Mockups sei auch hier angemerkt, dass diese nicht zwangsläufig das finale Produkt repräsentieren müssen – weder, was das Design betrifft, noch funktional.

Die Mockups zeigen eine Toolbar-Schaltfläche, über welche ein Login ausgewählt werden kann. Benutzername und Passwort lassen sich darüber betrachten und kopieren.

Die Passwort-Verwaltung selbst wirkt sehr aufgeräumt und bietet im Wesentlichen die gleichen Funktionen wie die Toolbar-Schaltfläche. Hierüber können bestehende Logins außerdem bearbeitet und neu angelegt werden – etwas, was in der bestehenden Passwort-Verwaltung von Firefox nicht möglich ist.

Erkennt Firefox Lockbox, dass ein Login kompromittiert sein könnte, wird darauf in Form eines roten Banners hingewiesen. Dabei handelt es sich um eine Integration von Firefox Monitor, einem Dienst, den Mozilla im September 2018 gestartet hat und Nutzer überprüfen lässt, ob diese in der Vergangenheit Opfer eines Datendiebstahls waren. Dafür arbeitet Mozilla mit HaveIBeenPwned.com zusammen.

Die Mockups zeigen außerdem einen eigenständigen Monitor-Tab, wo es zu bekannten Datendiebstählen ausführliche Informationen über Zeitpunkt und Art des Diebstahls gibt. Außerdem wird der Nutzer animiert, sein Passwort zu ändern.

Auch mit dem dunklen Theme von Firefox soll Firefox Lockbox harmonieren, wie das folgende Mockup zeigt.

Ob der Monitor-Service ebenso Teil des kostenlosen Angebots sein wird, lässt sich anhand der Mockups nicht ableiten. Denn während die Grundfunktionalität kostenlos ist, plant Mozilla, ab dem dritten Quartal mit Premium-Features für Firefox Lockbox und Firefox Monitor zu experimentieren. Mit Premium-Angeboten möchte Mozilla unabhängiger von Suchmaschinen-Verträgen werden. Bislang erhält Mozilla einen Großteil seines Geldes von Google. Im Oktober 2018 hat Mozilla in den USA mit einem VPN sein erstes Premium-Angebot testweise gestartet.

Der Beitrag Vorschau auf Mozillas neuen Passwort-Manager für Firefox erschien zuerst auf soeren-hentzschel.at.

Schulnetzwerke werden mit wachsenden Anforderungen komplexer. Ein Schulserver, schulweites WLAN, Einsatz von Tablets und Laptops im Unterricht, eine Schulcloud, einheitliche Logins für alle Dienste – die Anforderungen an einen Netzwerkbetreuer oder Dienstleister in der Schule sind vielfältig. Wenn alles funktioniert, ist meist auch alles gut. Aber was ist, wenn der Server, die Firewall oder ein Switch ausfällt? Die Konsequenzen können sehr unterschiedlich sein. Wie schnell kann der Normalbetrieb wiederhergestellt werden? Wie wichtig ist Hochverfügbarkeit in einem Schulnetzwerk?

Hochverfügbarkeit

Laut Wikipedia definiert sich Hochverfügbarkeit folgendermaßen

Hochverfügbarkeit (englisch high availability, HA) bezeichnet die Fähigkeit eines Systems, trotz Ausfalls einer seiner Komponenten mit einer hohen Wahrscheinlichkeit (oft 99,99 % oder besser) den Betrieb zu gewährleisten.

Es geht also darum, dass ein System („das Schulnetzwerk“) einsatzfähig bleibt, auch wenn eine oder mehrere Komponenten einmal ausfallen sollten. Dabei kann es durchaus zu Unterbrechungen kommen. Je nachdem wie lang so eine Unterbrechung ist, teilt man die Hochverfügbarkeit in verschiedene Klassen ein. Ein Schulnetzwerk muss vor allem an Schultagen einsatzfähig sein (ca. 180-200 Tage pro Jahr). Auch wenn eine 99,999% Verfügbarkeit in den wenigsten Schulen absolut notwendig ist, ist der reibungslose Betrieb für den Unterrichtsalltag sehr wichtig.

Single Point of Failures

Um Hochverfügbarkeit herzustellen, müssen sogenannte „Single Point of Failures“ reduziert werden. Es handelt sich dabei um Komponenten bei deren Ausfall das ganze Schulnetzwerk still stehen würde. Was können solche „Single Point of Failures“ sein?

• Firewall → fällt sie aus, gibt es kein Zugang mehr zum Internet, je nach Konfiguration funktioniert auch das interne Netz nicht mehr
• Switche (v.a. Hauptswitch) → siehe Firewall, Komplettausfall
• Server → fällt er aus, sind viele Anwendungen nicht mehr zu erreichen, d.h. keine Anmeldung mehr im internen Logins, Webanwendungen, Schulcloud, …
• Internetanschlüsse → fällt der einzige Zugang aus, ist man offline.
• …

Kurze Geschichte am Rande:

Letzte Woche ist unsere Firewall ausgefallen (aufgrund des Atom C2000 Bugs). Das Netzwerk lag still, wir waren offline. Ein erster Versuch die Firewall zu virtualisieren scheiterte, sodass wir auf einen kleinen Minicomputer mit 2 Netzwerkkarten ausgewichen sind. Es waren ein paar zusätzliche Konfigurationen an unserem Hauptswitch nötig um alle WANs und VLANs auf zwei Netzwerkkarten aufzuteilen. Nach einigen Stunden lief das Netzwerk dann wieder (wir konnten das Backup der Konfiguration mit wenig Änderungen problemlos wiederherstellen).

Wie kann man die Ausfallsicherheit erhöhen?

Es gibt mehrere Möglichkeiten, wie man die Ausfallsicherheit erhöhen und das System „Schulnetzwerk“ besser gegen Ausfälle schützen kann. Allgemein geht es darum, dass man möglichst wenige (am besten keine) „Single Point of Failures“ hat und kritische Komponenten bei einem Ausfall fehlertolerant sind. Wie bereits oben erwähnt, hängen die Anforderungen an ein hochverfügbares Schulnetzwerk sehr von den Gegebenheiten und Wünschen des Schulträgers ab. Zum einen ist es eine Frage des Geldbeutels, zum anderen muss auch nicht jedes Netzwerk innerhalb weniger Minuten wieder verfügbar sein.

Hier einige Ideen, wie man die Ausfallsicherheit erhöhen kann:

• qualitative Hardware → gute Hardware kostet zwar mehr, aber sie läuft oft stabiler
• Backups, Backups → Konfigurationen, Daten, Virtuelle Maschinen, Container – an Backups führt kein Weg dran vorbei (Backups unbedingt auch testen!)
• Monitoring → ein gutes Monitoring kann in manchen Fälle Fehler früh erkennen bzw. gibt einen Überblick, wo es im Netzwerk gerade Probleme gibt. So kann man schneller reagieren und ist nicht auf die Hinweise der Benutzer im Netzwerk angewiesen („Das Internet geht nicht mehr“, „Der Drucker ist kaputt“, …)
• Fehlertoleranz erhöhen → auch „Failover“ genannt, d.h. zwei Netzteile im Server, mehrere Internetanschlüsse („Multi-WAN), zwei Firewalls, RAID, zwei Server, …
• Ersatzteile vorhalten → Festplatten, Ersatzswitch, …
• UPS/USW → Hardware bei Stromschwankungen schützen und Weiterbetrieb auch bei einem Stromausfall gewährleisten (für begrenzte Zeit)
• „personelle Redundanz“ → besser zwei oder mehrere Administratoren bzw. Dienstleister (bei Abwesenheit durch Krankheit, Urlaub, …)
• vorbeugende Wartungen
• …

Fazit

Ein Schulnetzwerk ist sicher kein hochkritisches System, aber mit der fortschreitenden Digitalisierung der Schulen wird es immer wichtiger, dass die IT-Infrastruktur möglichst ohne Ausfälle erreichbar bleibt. An manchen Schulen wiegt ein Ausfall des Internets so schwer, dass kaum weiter gearbeitet werden kann (Onlinesysteme zur Verwaltung, Schulclouds, Online-Lernsysteme, Student Information Systems). Um die Ausfallsicherheit zu erhöhen, muss man nicht immer viel Geld in die Hand nehmen. Viel wichtiger ist, dass man auf einen Ausfall vorbereitet ist (v.a. bei den Single Point of Failures).

3 Kommentare

Der Beitrag Wie wichtig ist Hochverfügbarkeit in einem Schulnetzwerk? erschien zuerst auf .:zefanjas:..

Anfang des Jahres habe ich einer Kundin die Epikur-Praxisverwaltung auf ihrem Ubuntu-Laptop installiert. Meine Kundin hat sich zum Jahresanfang mit einem halben Kassensitz selbstständig gemacht. Zur Abrechnung mit den gesetzlichen Krankenkassen benötigte sie den Anschluss an ein Lesegerät für Krankenkassenkarten.

Die Einrichtung der Telematikinfrastruktur spielte noch keine Rolle. Sie wird erst Mitte des Jahres vorgenommen. Da zum jetzigen Zeitpunkt noch nicht genug erforderliche Gerätschaften zur Verfügung stehen.

Im Folgenden möchte ich meine Erfahrungen und die meiner Kundin mit Epikur und Ubuntu beschreiben. Starten werde ich mit der Installation von Server und Client. Danach werde ich auf die Einrichtung des Kartelesegeräts und auf die Benutzung von Epikur eingehen.

Wer noch weitere Fragen zum Thema Epikur und Ubuntu hat, kann mich gerne unter marco@rockiger.com erreichen.

Warum Epikur und Ubuntu?

Auf meinen Rat hin verwendet die Kundin schon seit einiger Zeit Ubuntu. Zum Zeitpunkt der Installation von Epikur war für meine Kundin der Umstieg auf Windows kein Thema mehr.

Die Vorteile von Ubuntu gegenüber Windows liegen auf der Hand:

• geringerer Ressourcenverbrauch
• höhere Systemsicherheit
• bessere Usability (zumindest aus Sicht meiner Kundin)
• niedrigere Kosten

Die Unterstützung von Ubuntu war der ausschlaggebende Punkt für die Nutzung von Epikur. Epikur ist die einzige Praxisverwaltungssoftware, die Ubuntu unterstützt. Die Konkurrenten Elephant und Psyprax schieden wegen der fehlenden Ubuntu Unterstützung aus.

Installation von Epikur auf Ubuntu Linux

Weil eine Nutzung der Praxisverwaltungssoftware mit einem Tablet sichergestellt werden sollte, haben wir uns für die Server-Variante von Epikur entschieden. Die Epikur-Clients entsprechen der Einzelplatzvariante, nur dass sie sich eben beim Start mit einem Server verbinden.

Mit einem Epikur-Server können sich mehrere Clients verbinden. Mit einem Zusatzmodul ist es darüber hinaus möglich, ein HTML-Frontend zu betreiben. Es erlaubt, einen reduzierten Funktionsumfang von Epikur als Website zu nutzen – hierfür reicht der Browser des Tablets aus.

Ziel ist es, das Dokumentationen schon während der Therapie im Tablet eingegeben werden können, ohne die Notizen von Papier in die Praxisverwaltungssoftware zu übertragen. Alternativ einen Laptop während der Therapie zu benutzen, war für meine Kundin keine Option.

Es empfiehlt sich, im Vorfeld den Epikur-Server sowie den Client herunterzuladen. Beide sind ganz schöne Brocken, die circa 1 GB groß sind.

Installation des Epikur-Servers

Vorbereitend benötigt der Epikur-Server eine Java-Laufzeitumgebung. Auf der Website empfiehlt Epikur das Oracle Java 8 JDK 64 Bit. Ich habe aber das openjdk-8-jdk installiert. 

Nach mehr als 2 Monaten Nutzung gab es bisher noch keine Probleme mit dem Server und dem openjdk-8. Die freie Java-Variante passt sich meiner Erfahrung nach besser in Ubuntu ein und kann direkt aus den Paketquellen installiert werden:

sudo apt install openjdk-8-jdk

Danach wird der heruntergeladene Server installiert:

sudo apt install ./PFAD/ZUR/epikur4Server-x-all.deb 

apt sollte dabei die folgenden Abhängigkeiten installieren:

dependencies libbonobo2-0 libbonobo2-common libgnome-2-0 libgnome2-0 libgnome2-bin libgnome2-common libgnomevfs2-0  libgnomevfs2-common liborbit-2-0

Alternativ kann man den Epikur-Server auch mit Ubuntu Software installieren.

Nun kann man den Server mit epikur4Server starten. Der Start des Servers dauert circa 1 – 2 Minuten.

Nun kann man den Epikur-Server testen. Die genaue Konfiguration wurde von einem Service-Mitarbeiter von Epikur per Teamviewer vorgenommen.

Installation des Epikur-Clients

Für die Installation des Clients fordert Epikur laut Website die folgenden Abhängigkeiten: 

libxi6:i386 libxtst6:i386 libxrender1:i386 libgnome2-0:i386 libusb-0.1-4:i386 lib32stdc++6 libgtk2.0-0:i386 libxxf86vm1:i386 libgl1-mesa-glx:i386

Für was diese Bibliotheken notwendig sind, ist mir nicht klar. Der Client startet auch ohne sie.

Ich empfehle noch, den ttf-mscorefonts-installer zu installieren, damit die Arial-Schriftart installiert ist. Sie wird für manche Grafikanzeigen im Client benötigt.

Um alle Abhängigkeiten nutzt man am besten wieder die Kommandozeile:

sudo apt install libxi6:i386 libxtst6:i386 libxrender1:i386 libgnome2-0:i386 libusb-0.1-4:i386 lib32stdc++6 libgtk2.0-0:i386 libxxf86vm1:i386 libgl1-mesa-glx:i386 ttf-mscorefonts-installer

Den heruntergeladenen Epikur-Client installiert man mit:

sudo apt install ./PFAD/ZUR/epikur4Server-x-all.deb 

Oder man nutzt wieder Ubuntu Software. Um den Epikur-Client zu starten, benutzt man den Befehl epikur4Client. Es wird ein laufender Epikur-Server benötigt, damit der Epikur-Client starten kann. Sonst bricht der Start mit einer Fehlermeldung ab.

Die exakte Konfiguration wurde auch hier vom Service-Mitarbeiter per Fernwartung durchgeführt.

Erfahrungen in der Praxis

Kartenlesegerät SCM eHealth500 unter Ubuntu

Bis zur Einrichtung der Telematikinfrastruktur benötigt meine Kundin noch eine Möglichkeit, Versicherungskarten einzulesen. Die Auswahl an Karten, die mit Ubuntu funktionieren, ist deutlich geringer als Geräte, die mit Windows funktionieren.

Das Kartenlesegerät SCM eHealth500 ist ein ausgelaufenes Produkt, das uns unter Ubuntu anfangs ein wenig Kopfzerbrechen bereitet hat. Anfangs war es uns nicht möglich, das Gerät zum Laufen zu bringen. Auch mithilfe des Service-Mitarbeiters nicht.

Nach Anfrage bei SCM wurde mir mitgeteilt, dass keine Weiterentwicklung der Treiber für Ubuntu 18.04 geplant ist.

Nach kurzer Zeit wurde uns aber glücklicherweise ein extra Treiberpaket von Epikur zur Verfügung gestellt, mit dem wir eingelesene Kartendaten auf den Epikur-Client übertragen konnten.

Beim Einlesen werden die Kartendaten erst mal auf dem kabellosen Kartenlesegerät zwischengespeichert. Bei Bedarf werden die Daten dann im Epikur-Client eingelesen.

Synchronisation der Kalenderdaten mit Google Calendar

Die einzige Funktion, die wir bis jetzt nicht zum Laufen bekommen haben, ist die Google-Calender-Synchronisation. Diese speichert Patienten-Termine anonymisiert in Google Calender. Damit hat der Therapeut seine Termine auch von unterwegs im Griff.

Nach mehreren Teamviewer-Sitzungen konnte das Problem noch nicht gelöst werden. Mittlerweile gab es aber Kontakt mit dem Entwickler des Google-Calendar-Moduls. Dieser arbeitet an einer Lösung des Problems. 

The post Epikur und Ubuntu-Linux appeared first on Rockiger.

Time Machine ist die universelle Backuplösung für macOS und Vorbild für Linux-Lösungen wie Back In Time oder Deja-Dup. Mit Time Machine lassen sich Systemeinstellungen, installierte Programme und Benutzerdaten auf externe Speichermedien sichern. Hierfür eignet sich von der externen Festplatte bis zum Netzwerkspeicher jedes mögliche Speichermedium.

Lange Zeit waren AFP-Freigaben dafür notwendig (siehe z. B. Time Machine Backups auf einen Linux Server sichern), was bei Linux die Netatalk-Implementierung erforderlich machte. Inzwischen wendet sich Apple von solchen Insellösungen ab und vollzieht einen Schwenk zu SMB. MacOS 10.14 "Mojave" stellt hier einen Zwischenschritt dar (siehe auch: Time Machine auf einem Linux Server - Stand macOS 10.14 "Mojave"), bei dem beide Implementierungen für Time Machine funktionieren. Wer also ein funktionsfähiges AFP-Backupziel hat braucht nicht zu wechseln, wer Probleme hat oder eine neue Sicherung einrichtet sollte gleich zukunftsfest auf SMB setzen.

Problematisch ist gegenwärtig immer noch, dass Apple einige spezifische Erweiterungen für SMB voraussetzt, damit dieses als Sicherungsziel für Time Machine geeignet ist. Proprietäre NAS-Anbieter wie beispielsweise Synology haben diese sehr schnell implementiert, die Open Source Community brauchte leider mal wieder erheblich länger. Die im März vergangenen Jahres veröffentlichte Version Samba 4.8 enthält nun aber alle benötigten Funktionen. Das Veröffentlichungsdatum zeigt jedoch schon, dass keine ernstzunehmende LTS-Distribution diese Version gegenwärtig ausliefert. Der Linux-Standard ist momentan Samba 4.7 oder älter. Das gilt leider auch für openSUSE Leap 15.0.

Wenn man also auf Leap 15.0 eine Time Machine-taugliche SMB-Freigabe einrichten will, muss man zuerst die Samba-Version aktualisieren. Dank des hervorragenden OBS ist dies zum Glück kein Problem. Dazu muss lediglich folgendes Repository hinzugefügt werden:

http://download.opensuse.org/repositories/network:/samba:/STABLE/openSUSE_Leap_15.0/

Anschließend aktualisiert man die installierte Samba-Version auf die dort gegenwärtig ausgelieferte Variante. Sofern nicht bereits installiert benötigt man zusätzlich noch Avahi:

# zypper in avahi

Nun richtet man eine Freigabe für Time Machine ein. Dazu sind, wie bereits erwähnt, einige Besonderheiten zu berücksichtigen. Folgendes sollte in der /etc/samba/smb.conf stehen: 

[TimeMachine]
	comment = Time Maschine Backuport
	path = /media/Daten/tmb
	browseable = yes
	writeable = yes
	vfs objects = catia fruit streams_xattr
	fruit:aapl = yes
	fruit:time machine = yes

Hierdurch wird das Speicherziel /media/Daten/tmb genutzt. Diesen Pfad muss man ggf. anpassen.

Als Benutzer empfiehlt es sicher immer für Time Machine einen eigenen Benutzer anzulegen. Bei openSUSE kann man das im entsprechenden YaST-Modul erledigen. Anschließend muss der Benutzer noch als Samba-User angelegt werden:

# smbpasswd -a <user>

Der Benutzer ist zudem noch als Eigentümer des Sicherungsordners einzutragen

# chown <user> /media/Daten/tmb

Abschließend aktiviert und startet man die Dienste für Samba und Avahi:

# systemctl enable smb.service

# systemctl start smb.service

# systemctl enable avahi-daemon.service

# systemctl start avahi-daemon.service

Die SMB-Freigabe lässt sich nun in macOS als Sicherungsziel einrichten.

Bilder:

Einleitungs- und Beitragsbild von FreePhotosART via pixabay

Im letzten Teil haben wir eine Electron-Anwendung geschrieben, die auf der GTK-Demo-App basiert. Wir haben die grundsätzliche Struktur der Anwendung erstellt und die Funktionalität, die die Anwendung bereitstellt hinzugefügt.

In diesem Teil möchten wir nur nun die Optik der Anwendung entsprechend anpassen. Dazu werden wir als Erstes herausfinden, auf welchem Betriebssystem und mit welchem Fenstermanager die Anwendung läuft.

Ausgestattet mit dieser Information werden wir dann das jeweilige passende Stylesheet laden, um die Anwendung nativ aussehen zu lassen.

Das Ziel ist es nicht, dass die Anwendung 100 % so aussieht, wie eine Anwendung, die mit dem Window-Toolkit des Betriebssystems geschrieben ist. Unser Ziel ist es, dass die Anwendung mit vertretbarem Aufwand so aussieht, dass sie nicht als Fremdkörper wahrgenommen wird.

In welcher Umgebung läuft die App?

Und herauszufinden, in welcher Umgebung die App läuft, müssen wir eine kleine Javascript-Abfrage beim Start der Anwendung einbauen. Mit dieser Laden wird dann, damit wir ein spezifisches Stylesheet laden können.

Dazu öffnen wir die index.html-Datei, laden style.css für plattformunabhängige Styles und fügen folgendes Javascript ein.

<link rel="stylesheet" type="text/css" href="./styles/style.css">
  <script type="text/javascript"> 
    let cssUrl = '';
    if (process.platform === 'linux') {
      const execSync = require('child_process').execSync;
      const theme = execSync('gsettings get org.gnome.desktop.interface gtk-theme').toString().toLowerCase()
      
      if (theme.includes('adwaita')) {
        cssUrl = 'adwaita.css'
      } else if (theme.includes('arc')) {
        cssUrl = 'arc.css'
      } else if (theme.includes('OSC') || theme.includes('mac')) {
        cssUrl = 'mac.css';
      } else if (theme.includes('win')) {
        cssUrl = 'win.css';
      }
      
    } else if (process.platform === 'darwin') {
        cssUrl = 'mac.css';
    } else if (process.platform === 'win32') {
        cssUrl = 'win.css';
    }
    if (cssUrl) {
        document.write('<link rel="stylesheet" type="text/css" href="./styles/'+ cssUrl +'">');
        }
  </script>

Dabei nutzen wir die process-Bibliothek von NodeJS und schauen als Erstes auf welchem Betriebssystem wir uns befinden. Befinden wir uns auf einem Mac- oder einem Windows-Rechner, nutzen wir die CSS-Datei mac.css oder win.css.

Für den Fall, dass wir uns auf einem Linux Rechner befinden haben wir noch eine kleine Besonderheit eingebaut: Wir führen mit NodeJS eine Kommandozeilen-Abfrage durch, die uns den Namen des aktuellen Themes zurückgibt. Dementsprechend verwenden wir nun die passende CSS-Datei.

Die Auswahl des Themes lässt sich beliebig erweitern, da ich persönlich das Arc-Theme verwende, werden wir uns auf dieses konzentrieren. An dieser Stelle muss jeder selbst entscheiden, mit wie viel Aufwand er Linux-User zu unterstützen möchte. Ich könnte mir vorstellen, dass ein Theme für Ubuntu-Nutzer auch noch sinnvoll wäre. Dies könnte eine gute Übung sein.

Cross-platfform Styling

Um nun ein plattform-gerechtes Styling der Einzelkomponenten zu kreieren, müssen wir diverse CSS-Dateien anlegen. Dazu erstellen wir den Ordner styles im src-Verzeichnis. Für jede angegebene CSS-Dateien müssen wir nun eine anlegen.

Als Erstes entfernen wir jegliche Inline-Styles aus unseren Komponenten. Sonst können wir diese nur mühsam überschreiben.

Im neu geschaffenen styles-Verzeichnis legen wir nun die Datei style.css an. In diese Datei kommen alle Style-Informationen, die wir vorher inline eingefügt hatten. Für die Farben legen wir CSS-Variablen fest. 

:root{
    --fg_color: #5c7080;
    --text_color: #182026;
    --bg_color: rgb(245, 248, 250);
    --borders: rgb(206, 217, 224)
}

#Layout {
    display: flex;
    flex-direction: column;
    height: 100vh;
}

.bp3-button { cursor: default; }

#TextField {
    height: 100%;
    flex-grow: 1;
    overflow: auto;
    border: none;
    resize: none;
    outline: none;
}

#StatusBar {
    background-color: var(--bg_color); 
    border-top: 1px solid var(--borders);
    color: var(--text_color);
    height: 50px;
    padding: 12px;
}

Das hat den Vorteil, dass man nur durch den Austausch der Farben schon unterschiedliche Themes erstellen kann. Soweit so gut. 

Um nun das Arc-Theme nachzubauen, benötigt man nur wenige Zeilen CSS. Zumindest für unsere Beispielanwendung.

Als Erstes überschreiben wir die CSS-Variablen für die verwendeten Farben. Dann passen wir noch Details der einzelnen Komponenten an.

:root {
    --window_bg: #e7e8eb;
    --window_fg: hsla(222, 18%, 39%, 0.8);
    --button_hover_bg: #fdfdfd;
    --button_hover_border: #D1D3DA;
    --selected_bg_color: #5294e2;
    --selected_fg_color: #ffffff;
}

.bp3-navbar {
    background-color: var(--window_bg);
    padding: 0 5px;
    height: 40px;
}
.bp3-navbar-group {
    height: 40px;
}
.bp3-button .bp3-icon {
    color: var(--window_fg)
}
.bp3-button {
    min-width: 35px;
    min-height: 30px;
}
.bp3-button.bp3-minimal:hover {
    background-color: var(--button_hover_bg);
    border: 1px solid var(--button_hover_border);
}
.bp3-menu-item { padding: 1px 7px; }
.bp3-menu-item:hover, .bp3-button.bp3-minimal:active, .bp3-button.bp3-minimal.bp3-active  { 
    background-color: var(--selected_bg_color); 
    color: var(--selected_fg_color);
}
:focus {
    outline: none;
}

#StatusBar {
    max-height: 38px;
    padding: 10px;
}

Das Ergebnis sieht wie folgt aus:

Das Gleiche machen wir noch für das MacOS- und für das Windows-Theme. Wir brauchen dafür jeweils nur wenige Zeilen CSS.

:root {
    --window_bg: #e7e8eb;
    --window_fg: hsla(222, 18%, 39%, 0.8);
    --button_hover_bg: #fdfdfd;
    --button_hover_border: #D1D3DA;
    --selected_bg_color: #5294e2;
    --selected_fg_color: #ffffff;
}

.bp3-navbar {
    background-color: var(--window_bg);
    padding: 0 5px;
    height: 40px;
}
.bp3-navbar-group {
    height: 40px;
}
.bp3-button .bp3-icon {
    color: var(--window_fg)
}
.bp3-button {
    min-width: 35px;
    min-height: 30px;
}
.bp3-button.bp3-minimal:hover {
    background-color: var(--button_hover_bg);
    border: 1px solid var(--button_hover_border);
}
.bp3-menu-item { padding: 1px 7px; }
.bp3-menu-item:hover, .bp3-button.bp3-minimal:active, .bp3-button.bp3-minimal.bp3-active  { 
    background-color: var(--selected_bg_color); 
    color: var(--selected_fg_color);
}
:focus {
    outline: none;
}

#StatusBar {
    max-height: 38px;
    padding: 10px;
}

:root {
    --window_bg: #fffff;
    --window_fg: #000000;
    --button_hover_bg: #cce8ff;
    --button_hover_border: #0078d7;
    --selected_bg_color: #cce8ff;
    --selected_fg_color: #000000;
    --bg_color: #ffffff;
    --borders: rgba(16, 22, 26, 0.1);
}

.bp3-navbar {
    background-color: var(--window_bg);
    padding: 0 10px;
    height: 40px;
    box-shadow: 0 0 0 1px var(--borders);
}
.bp3-navbar-group {
    height: 40px;
}
.bp3-button .bp3-icon {
    color: var(--window_fg)
}
.bp3-button {
    min-width: 35px;
    min-height: 30px;
    border-radius: 0;
}
.bp3-button.bp3-minimal:hover, .bp3-button.bp3-minimal:active, .bp3-button.bp3-minimal.bp3-active  {
    background-color: var(--button_hover_bg);
    border: 1px solid var(--button_hover_border);
}
.bp3-menu-item { padding: 1px 7px; }
.bp3-menu-item:hover, .bp3-button.bp3-minimal:active, .bp3-button.bp3-minimal.bp3-active  { 
    background-color: var(--selected_bg_color); 
    color: var(--selected_fg_color);
}
:focus {
    outline: none;
}

#StatusBar {
    max-height: 45px;
    padding: 15px;
}

Fairerweise muss man dazu sagen, dass alle drei Theme ohne Gradienten auskommen und somit nur wenig Änderungen brauchen. Das Gnome Standard-Theme Adwaita nachzubauen, wäre deutlich aufwendiger.

Du findest den Source-Code für dieses Tutorial auf Github: https://github.com/rockiger/electron-react-example

Im nächsten Teil werden wir das Menü der gtk3-demo-application nachbauen und noch ein wenig Feinschliff betreiben.

Created with Dictandu

The post Cross-plattform Apps mit Electron und React Teil 2 appeared first on Rockiger.

Nur selbst betriebene Dienste bieten wirkliche Sicherheit für die eigenen Daten. In kaum einer Frage sind sich die meisten Experten derart einig. Das Softwareanagebot um eine solche Lösung zu betreiben ist vielfältig und die finanziellen Kosten überschaubar (siehe auch: Cloud in Eigenregie Teil I: Vorbemerkungen). Allerdings kommt man bei vollständiger Umsetzung letztlich nicht um den Betrieb eines Servers, der direkt aus dem Internet aufrufbar ist, herum.

Die meisten normalen Anwender sind mit der Pflege ihrer Endgeräte bereits vollkommen überfordert. Menschen, die in Supportforen mit vollständig veralteten Betriebssystem-Versionen jenseits jedweder Supportperiode auftauchen sind keine Seltenheit sondern repräsentieren eine große Gruppe von Anwendern. Lediglich die extrem langen Supporzeiträume von Windows-Versionen bewahren uns hier vor schlimmeren. Im mobilen Bereich ist die Verwendung nicht mehr unterstützter Betriebssysteme sogar die Regel - leider nicht nur bei Android. Die Ursache ist eine Mischung aus Hilflosigkeit, Unkenntnis, falscher Risikoabschätzung und der furchtbar falsch verstandenen Redewendung "never change a running system".

Die positive Nachricht ist, dass das Problem dennoch überschaubar ist. Massive Angriffswellen auf Android-Smartphones im Stil früherer Angriffe auf Windows-Rechner sind bisher zum Glück ausgeblieben, aber immmer wieder aufkommende Wellen von Schadsoftware, zuletzt in Form von Crypto-Schädlingen, zeigen das immense Problempotenzial. Zum Glück befinden sich viele der schlecht gewarteten Systeme hinter einem Router, dessen Firewall das schlimmste verhindert. 

Ganz anders bei einem Home Server, den man per DynDNS und Portweiterleitung aus dem Internet erreichbar macht. Schlecht konfigurierte Software oder ein Betriebssystem jenseits jeglicher Supportzeiträume entfaltet hier ein ganz anderes Gefährdungspotenzial. Mal abgesehen davon, dass ein Server voller Sicherheitslücken mit direkter Erreichbarkeit aus dem Netz alles möglich ist, nur kein wirksames Mittel für mehr Datenschutz.

Den meisten Anwendern kann man daher den Betrieb eines eigenen Servers kaum empfehlen. Sie bleiben auf die bestehenden Angebote von Dienstleistern angewiesen und können keinen wirksamen Datenschutz betreiben. Umso wichtiger ist hier natürlich die Existenz vertrauenswürdiger Anbieter, die ihren Kunden ein hohes Datenschutz-Niveau bieten.

Ansonsten entsteht eine Zwei-Klassen-Gesellschaft beim Datenschutz. Auf der einen Seite jene, die durch Ausbildung oder viel Zeit, sowie dem nötigen Interesse sich Kenntnisse angeeignet haben um eine eigene Infrastruktur zu betreiben und auf der anderen Seite solche Personen, denen das unerreichbar bleibt und für die kein wirksamer Datenschutz möglich ist.

Bilder:
Einleitungs- und Beitragsbild von Tumisu via pixaybay

Jolla bzw. das Betriebssystem Sailfish OS war mal die große Hoffnung auf ein funktionsfähiges, freies Mobilbetriebssystem ohne Google-Anbindung (siehe auch der damalige Test: Sailfish OS auf dem Nexus 4 ausprobiert). Trotz mannigfaltiger Schwierigkeiten gibt es Jolla und Sailfish OS immer noch, aber das kommerzielle Überleben hat seinen Preis.

Jolla wurde von ehemaligen Nokia-Mitarbeitern entwickelt, die den eingeschlagenen Entwicklungsweg des N9 und MeeGo weitergehen wollten. Sie hatten damit nicht unrecht. Die Kooperation zwischen Microsoft und Nokia, sowie die anschließende Übernahme der Handysparte von Nokia durch den Redmonder Konzern endete im Fiasko. Heute baut Microsoft keine Smartphones mehr und hat jüngst sein Mobilbetriebssystem beerdigt (siehe auch: Kommentar: Microsoft wird Windows aufgeben), Nokia ist als Lizenzmarke von HMG Global nun wieder auf dem Smartphone-Markt zurück - mit Android. Jolla gibt es immer noch und jüngst veröffentlichte man Sailfish OS 3.

Doch auch Jollas Weg war nicht einfach. Anfänglich versuchte man sich auf die integrierte Entwicklung von Betriebssystem und Hardware, verhob sich dann aber mit der Entwicklung eines Tablets. Man fokussierte sich daraufhin auf die Weiterentwicklung des Systems und Lizensierung an Partner. Zudem arbeitet man mit Sony zusammen, weshalb es für einige Sony Xperia Geräte Sailfish X als offizielle Variante gibt.

Obwohl Sailfish OS als Open Source Hoffnung galt und sich in dieser Szene auch überproportionaler Beliebtheit erfreut ist das Betriebssystem nicht komplett quelloffen. Die Basis aus Linux Kernel und Mer ist zwar Open Source, die Oberfläche und einige Apps allerdings proprietär. Der Vorteil liegt also eher in der Unabhängigkeit von Google, Apple & Co und weniger in einer vollkommen transparenten Software.

Diese Unabhängigkeit hat leider ihren Preis. Um der Insolvenz zu entgehen versuchte man das Betriebssystem stärker in Schwellenländern zu etablieren, wo Android und iOS möglicherweise noch nicht so gefestigt sind. Vor allem die Verbindungen nach Russland sind in den letzten Jahren gewachsen. Die russische Firma Open Mobile Platform Ltd. gehört nicht nur zu den wichtigsten Mittelgebern Jollas, sondern lizensiert das Betriebssystem auch für die den russischen Markt.

Inzwischen ist der russische Staat über den Staatskonzern Rostelecom, der 75% der Anteile von Open Mobile Platform Ltd. hält, direkt an Jolla beteiligt. Rein theoretisch soll ein angepasstes Sailfish OS, das als Aurora OS firmiert, zukünftig als Betriebssystem für alle Mobiltelefone von Staatsbeamten genutzt werden. Inwiefern hier gesetzgeberische Theorie und gelebte Verwaltungspraxis auseinander gehen kann man natürlich von Deutschland aus nicht beurteilen.

Es stellt sich aber schon die Frage, ob ein System, auf dessen Entwicklung mittelbar ein Staat Einfluss hat dessen politisches System nur sehr wenige als lupenreine Demokratie bezeichnen, wirklich noch die Open Source Hoffnung am Smartphone-Markt sein kann.

Bilder:
Einleitungs- und Beitragsbild von Pexels via pixabay

Text-, Sprach- und Videonachrichten werden heutzutage nicht mehr über standardisierte Formate, sondern über Dienste in Firmenhand ausgetauscht. Damit einher geht ein riesiger Datenpool, denn selbst bei verschlüsselten Inhalten bleiben die wertvollen Metadaten ungeschützt. Abhilfe könne hier nur freie Dienste schaffen, aber das Angebot ist unübersichtlich und nicht konkurrenzfähig.

Wie prekär die Situation ist, zeigte sich kürzlich wieder anlässlich der geplanten Integration der drei Facebookdienste WhatsApp, Instagram und Facebook Messenger (siehe auch: Kommentar: Facebook - Einfach weiter wie bisher). Facebook legt damit potenziell eine Datenbank an, die für sehr viele Weltregionen beinhaltet wer, wann mit wem kommuniziert hat.

Facebook und seinen Tochterunternehmen spielt dabei in die Hände, dass sich die anderen großen IT-Firmen vollkommen verzettelt haben. Weder haben Google, Microsoft und Apple es hingekriegt einen Dienst als Gegengewicht aufzubauen, noch konnten die Telekommunikationsunternehmen ihre halbgaren Lösungen etablieren. Bei ersteren fehlt es definitiv am Willen zur Zusammenarbeit, bei letzteren an Marktmacht und fähigen Entwicklern.

Es bleiben somit nur freie Lösungen, die von der Community oder kleinen Firmen entwickelt und gepflegt werden.

Früher trennt man die Bereiche in Text-, Sprach und Videokommunikation. Heute können die meisten Apps mehrere oder gar alle dieser Funktionen gleichzeitig. Die ehemaligen Lösungen zur Videkommunikation haben Textlösungen implementiert und ehemalige Instant Messenger lassen nun auch Videokommunikation zu. Dateiaustausch bietet fast jede Lösung an.

Die folgende Auflistung behandelt nur komplett freie Angebote und keine halbfreien Pseudolösungen wie beispielsweise Telegram mit seinem proprietären Server.

Freie Kommunikationslösungen

Dezentrale Ansätze

Die beiden dezentralen Angebote basieren auf den Fortentwicklungen relativ alter Standards und dem Versuch diese den Gegebenheiten der Gegenwart anzupassen. Herausforderungen sind hier neben der Vielzahl der Endgeräte und ihrer mobilen Nutzung auch die staatliche Überwachung und das Bedürfnis nach starker Verschlüsselung.

IRC

IRC (Instant Relay Chat) ist vermutlich die älteste Lösung und kommt noch aus den Anfängen des öffentlichen Internets. War es anfänglich als Möglichkeit zum textbasierten Gruppenchat weit verbreitet, nutzt heute vor allem die Open Source Szene noch stark das System. Die Stärke des Systems ist sein dezentraler Ansatz und die Vielzahl an Clients, die das System auf allen denkbaren Betriebssystemen ermöglicht.

Das System hat aber auch zahlreiche Schwächen. IRC ist kein homogener Messenger sondern gespalten in unterschiedliche Netzwerk mit regionalen Schwerpunkten. Der Anwender muss sich mit einem solchen Netz (bspw. freenode) verbinden und kann sich dann nur innerhalb des verbundenen Netzes Nachrichten austauschen. Die Nachrichtenübertragung erfolgt standardmäßig unverschlüsselt, was in letzter Zeit lediglich mit den Transportverschlüsselung kompensiert wurde. Clientseitige Verschlüsselung hat sich weder für Gruppen- noch Privatnachrichten durchgesetzt. Dadurch ist IRC so sicher wie eine herkömmliche E-Mail.

XMPP

Das Extensible Messaging and Presence Protocol (kurz XMPP), früher auch als Jabber bekannt, ist etwas jünger als IRC und seit 2004 durch die IETF als Standard anerkannt. Jeder an das Internet angebundene XMPP-Server kann mit anderen Servern kommunizieren, wodurch XMPP ähnlich dezentral aufgebaut ist wie die E-Mail. Dadurch kann jeder Inhaber eines XMPP-Accounts alle anderen Anwender kontaktieren.

Der dezentrale Ansatz ist jedoch auch das größte Hindernis bei der Entwicklung. Verbindungen zwischen zwei Clients werden immer über mindestens einen Server aufgebaut. Sind die Anwender bei unterschiedlichen Servern angemeldet, müssen besagte Server miteinander kommunizieren. Das erfolgte ursprünglich mal alles unverschlüsselt, inzwischen haben die meisten Anbieter eine Transportverschlüsselung eingerichtet. Eine Verschlüsselung der Inhalte zwischen den Endgeräten (Ende-zu-Ende) ist zwar theoretisch mittels OTR bzw. OMEMO möglich, aber viele Clients haben das immer noch nicht implementiert. Audio- und Videokommunikatin ist bis dato noch fast immer unverschlüsselt.

Einige Zeit lang sah es so aus, als ob XMPP als Messenger eine vergleichbare Bedeutung wie die E-Mail erreichen könnte. Die Unterstützung durch Google und viele andere große Anbieter sollte es möglich machen. In den letzten Jahren beendeten jedoch viele Firmen ihr Engagement und XMPP ist tendenziell auf dem Rückzug. In Open Source Kreisen hofft man regelmäßig, dass XMPP sich doch noch durchsetzen kann (so wie bei Linux), aber das ist unwahrscheinlich. Die Bedeutung des Standards liegt heute vor allem darin, dass er die Basis für die vielen proprietären Lösungen von WhatsApp bis iMessage bildet.

Matrix/Riot

Matrix ist einer der neuesten Akteure auf dem Markt der dezentralen Angebote. Matrix möchte simplifiziert ausgedrückt die Schwächen von XMPP überwinden und ein zeitgemäßes Protokoll für die Text-, Sprach und Videokommunikation über das Internet anbieten.

Mit Synapse und dem mit Abstand wichtigste Client Riot - der sowohl für Desktop, wie Mobilbetriebssysteme zur Verfügung steht - gibt es quasi Referenzimplementierungen. Hierdurch vermeidet man zumindest vorerst die starke Zersplitterung von XMPP mit all ihren Nachteilen. Grundsätzlich erlaubt man allerdings eine Föderalisierung.

Der Fokus liegt dem Zeitgeist folgend stark auf Gruppenkommunikation wie sie das proprietäre Slack massentauglich gemacht hat.

Silence

Bei Silence (ehemals SMSSecure) handelt es sich im Prinzip um einen Aufsatz für SMS/MMS, der eine Verschlüsselung dieser Kommunikation gewährleistet. Das macht zentrale Server überflüssig, setzt aber eine Mobilfunknummer, sowie einen Tarif voraus. Zudem existiert Silence nur für Android und ist daher eine Insellösung.

Zentralisierte Messenger

Einige Entwickler haben sich den Erfolg von WhatsApp zum Vorbild genommen und konzeptionell ähnliche Angebote entwickelt, die jedoch sicherer sein sollen oder dem Anwender mehr Freiheiten lassen.

Signal

Signal ist sicherlich das Flaggschiff der sicheren Messenger. Seit 2015 firmieren die Kommunikationslösungen von Open Whisper Systems einheitlich unter der Marke Signal und lösen damit die Vorgänger TextSecure für Android ab. Finanziert wird das ganze durch Spenden und sonstige Einnahmen. Strukturell ähnelt Signal modernen Angeboten wie WhatsApp. Die Kommunikation erfolgt über Apps für Mobilbetriebssysteme und wird über zentrale Server abgewickelt. Zwar kann theoretisch jeder einen eigenen Signal-Server betreiben, allerdings würde man sich dann vom restlichen Signal-Netzwerk loslösen. Eine Dezentralisierung lehnen die Entwickler ab, da man genau jene Entwicklungshemmnisse fürchten in die XMPP und IRC geraten sind.

Die Verschlüsselungslösung von Signal, das vormals so genannte Axolotl-Protokoll, gilt als absolut sicher und findet auch in den konkurrierenden Lösungen WhatsApp und Wire Verwendung. Signal versucht zudem seit längerem die anfallenden Metadaten und Informationen zum Kontaktabgleich zu minimieren. Der Zugriff auf das Adressbuch ist sowieso optional. Verschlüsselung ist hier nur nicht ein Placebo für die besorgte Anwenderseele.

Wire

Wire funktioniert oberflächlich ähnlich wie Signal und bearbeitet damit die gleiche Nische. Es gibt Apps die über einen zentralen Server miteinander verschlüsselt kommunizieren. Das Verfahren wurde erfolgreich einem Audit unterzogen und ist somit vertrauenswürdig. Die Entwicklung betreibt maßgeblich die Schweizer Firma Wire Swiss GmbH aber Apps und Server sind Open Source.

Peer-to-Peer Lösungen

Es gibt auch Lösungen, die ohne einen oder mehrere zentrale Server auskommen und die Verbindung direkt zwischen den Clients aufbauen.

Ring/Jami

Kaum eine Lösung hat sich so oft umbenannt, wie das was aktuell als Jami firmiert. Man kennt es möglicherweise auch unter den früheren Namen GNU Ring und SFLPhone. Insbesondere letzterer zeigt den ursprünglichen Fokus des Projekts auf eine SIP-basierende Lösung für Sprachkommunikation.

Jami ist quelloffen und benötigt keinen zentralen Server. Es steht Apps für alle verbreiteten Desktopsysteme, sowie für Android und iOS zur Verfügung.

Briar

Die ausschließlich für Android verfügbare Lösung Briar ist ein Sonderling. Der Datenverkehr wird über das Tor-Netz geleitet oder direkt über WLAN und Bluetooth. Kontakte lassen sich ausschließlich über das gegenseitige scannen des QR-Codes, d. h. also beim persönlichen Kontakt, hinzufügen. Alle Inhalte sind Ende-zu-Ende verschlüsselt und ausschließlich auf den Endgeräten gespeichert. Das Programm wurde einem Audit unterzogen den es mit Bravour bestanden hat.

Briar fällt in sofern aus der hiesigen Aufzählung, da die Entwickler nicht den Massenmarkt im Sinn haben, sondern einen extrem sicheren Dienst für besonders gefährdete Zielgruppen erstellen wollen. Komfortfunktionen werden daher grundsätzlich der Sicherheit untergeordnet. Ein Punkt wo Lösungen wie Signal durchaus machmal Kompromisse eingehen.

Tox

Tox ist ebenfalls eine Peer-to-Peer Lösung. Ursprünglich gab es zumindest in der Außendarstellung einen starken Fokus auf Videokommunikation, inzwischen bietet man auch hier das Komplettpaket aus Text, Sprach- und Videokommunikation. Ähnlich wie bei IRC und XMPP gibt es keine richtig offiziellen Clients, sondern das Angebot variiert je nach Plattform und beruht lediglich auf einem gemeinsamen Kern. Das betrifft leider auch Funktionsumfang und Stabilität.

Problematisch ist, dass die Hinzufügung von Kontakten lediglich über eine sehr lange ID erfolgen kann, die auf einem anderen Weg als Tox ausgetauscht werden muss. Zur Verschlüsselung greift man auf die NaCI Bibliothek zurück, was von allen anderen vergleichbaren Lösungen abweicht.

Zusammengefasst

Der Artikel umfasst nur einen Bruchteil der existierenden, quelloffenen Kommunikationslösungen und zeigt dennoch bereits das Problem auf. Viele verschiedene Lösungen wollen das gleiche Angebot machen: Sichere, quelloffene und transparente Software für Text-, Sprach und Videokommunikation zwischen Mobilgeräten und/oder Desktopsystemen. Dabei gibt es einen Wettstreit unterschiedlicher Ansätze von dezentralen Systemen, über zentrale Server bis hin zu Peer-to-Peer Verbindungen. Während man die Parallelität dieser Ansätze noch nachvollziehen kann, ergeben viele Doppelentwicklungen innerhalb dieser Bereiche kaum noch Sinn.

Im Kommunikationsbereich setzt sich nämlich nicht die beste Lösung durch, sondern die am weitesten verbreitete. Hier gilt insbesondere jenes Argument nicht, das im Linux-Bereich oft herangezogen wird: Vielfalt fördert Entwicklung. Denn der Netzwerkeffekt beförderte die Durchsetzung von WhatsApp und Facebook, die zu keinem Zeitpunkt die technisch beste oder beliebteste Lösung darstellten. Keine der oben genannten Lösungen hat die Chance eine nennenswerte Reichweite zu erreichen, wenn die für Sicherheit und Datenschutz sensibilisierte Zielgruppe sich auf dutzende Lösungen (und oben sind schließlich nur die freien Möglichkeiten aufgelistet) verteilt.

Deshalb bleibt WhatsApp & Co erfolgreich.

Bilder:
Einleitungs- und Beitragsbild von geralt via pixabay