staging.inyokaproject.org

In der jüngeren Vergangenheit berichteten verschiedene Online-Medien (siehe [0] und [1]) über eine neuartige sehr effiziente Zip-Bombe [2], welche der Entwickler David Fitfield entwickelt und zusammen mit einer detaillierten Beschreibung veröffentlicht [3] hat.

Es reizte mich, diese Zip-Bombe auszuprobieren. Im folgenden beschreibe ich, wie ich eine Disk-Image-Datei [4] und ein Loop-Device [5] verwendet habe, um dies gefahlos tun zu können, ohne mir mein komplettes Dateisystem vollzuschreiben.

Die Prozedur besteht aus den folgenden Schritten:

1. Disk-Image-Datei mit definierter Größe erzeugen
2. Dateisystem in erstellter Disk-Image-Datei erzeugen
3. Einhängepunkt erzeugen und Disk-Image-Datei einhängen

Die einzelnen Schritte werden im Detail im folgenden Code-Block dargestellt:

[root@example.com ~]# fallocate -l 1G /tmp/zipbomb.img
[root@example.com ~]# mkfs.ext4 -F /tmp/zipbomb.img
mke2fs 1.42.9 (28-Dec-2013)
Discarding device blocks: done                            
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

[root@example.com ~]# mount -o loop /tmp/zipbomb.img /mnt
[root@example.com ~]# mount | grep /mnt
/tmp/zipbomb.img on /mnt type ext4 (rw,relatime,seclabel,data=ordered)
[root@example.com ~]#

Nun hängt in /mnt ein Dateisytem von 1 GB Größe, welches von der Zip-Bombe vollgeschrieben werden kann. Viel Spaß beim Ausprobieren.

Und wie probiere ich nun die Zip-Bombe aus?

Na ganz einfach:

[root@example.com ~]# cd /mnt
[root@example.com ~]# wget https://www.bamsoftware.com/hacks/zipbomb/zbsm.zip
[root@example.com ~]# unzip zbsm.zip

Es dauert auch nicht lange, bis euer Dateisystem unter /mnt voll ist.

Quellen und weiterführende Links

[0] DerStandard: Verstopfte Festplatte: „ZIP-Bombe“ verwandelt 46 Megabyte in 4,5 Petabyte
[1] Golem.de: Malware: Zip-Bombe entpackt 46 MByte zu 4,5 Petabyte
[2] Wikipedia: Archivbombe
[3] David Filield: A better zip bomb
[4] Wikipedia (en): IMG (file format)
[5] Wikipedia: Loop device

Unter Umständen kann es passieren, dass ein Linux-System mit der falschen Uhrzeit läuft. Soll ein solches System manuell die aktuelle Uhrzeit gebracht werden, so kann hierfür der Befehl ntpdate genutzt werden. Dazu muss im ersten Schritt das passende Paket installiert werden:

apt install ntpdate

Anschließend kann der Befehl genutzt werden. Er muss hierbei mit einem NTP-Server aufgerufen werden:

ntpdate pool.ntp.org

Damit wurde die Zeit anhand des NTP-Servers neu gesetzt. Wichtig ist es das der Befehl mit administrativen Rechten ausgeführt wird.

Seit 2016 betreiben wir im BITS Red Hat Enterprise Linux als drittes Server-Betriebssystem neben Solaris und Microsoft Windows Server. Nachdem wir nun erste Betriebserfahrung mit der für uns neuen Distribution gesammelt haben, möchte ich in diesem Jahr unser Betriebskonzept überarbeiten, um die Erkenntnisse aus dem bisherigen Betrieb einfließen zu lassen und (hoffentlich) Verbesserungen für den zukünftigen Betrieb herbei zu führen.

Ansible wird in diesem Konzept eine wesentliche Rolle einnehmen. Als Konfigurations-Management-Werkzeug wird es für Teile des Betriebssystems und für das zentrale RHEL-Patchmanagement zum Einsatz kommen.

Die zu bewältigenden Konfigurationsaufgaben unterscheiden wir dabei in:

• Parameter die im Bereitstellungsprozess initialisiert werden und anschließend in der Hoheit des jeweiligen Systembetreibers liegen sowie
• Parameter welche dauerhaft durch das Konfigurations-Management verwaltet werden; diese gliedern sich wiederum in die
  • Zeilenbasierte Verwaltung von Konfigurationsdateien und
  • Dateibasierte Verwaltung von Konfigurationsdateien

In diesem Beitrag führe ich die einzelnen Parameter und Optionen auf, welche zukünftig von Ansible verwaltet werden. Von diesen wird zukünftig auf weitere Beiträge verlinkt, welche die konkrete Umsetzung mit Ansible beschreiben und dokumentieren. Es mag sich also lohnen von Zeit zu Zeit wieder hier vorbei zu schauen.

Initialisierte Parameter

Hierunter sind Parameter und Optionen zu verstehen, die zu Beginn im Bereitstellungsprozess konfiguriert werden, um sicherzustellen, dass sich das neue System optimal in unsere Infrastruktur einfügt. Diese werden initial und einmalig gesetzt und gehen nach der Übergabe des Systems in die Hoheit des jeweiligen Systembetreibers über. Der Systembetreiber ist bei uns die Person, welche den spezifischen Server administriert und Dienste auf diesem betreibt.

Zu den initial konfigurierten Parametern zählen im Einzelnen:

• DNS-Konfiguration
• Zeitserver-Konfiguration
• Postfix-Konfiguration zum Versand von System-Mails
• System-Registrierung und Verknüpfung mit einer Subskription
• Konfiguration der BITS-Standard-Repositories
• Konfiguration der Host-Firewall
• Konfiguration von SELinux
• Installation eines definierten Standardsatzes an Software-Paketen

Dauerhaft verwaltete Parameter

Diese Parameter/Optionen werden bei lokalen Änderungen auf dem System durch Ansible überschrieben. Dabei handelt es sich um

• Die Stage-Zuordnung über das Ansible-Inventory
• Das Anlegen und verwalten eines Benutzers zur Anbindung an das BMC-Monitoring
• Die Verwaltung spezifischer lokaler Benutzerkonten
• Die Steuerung des SSH-Servers, der authorized_keys Dateien und die Verwaltung der öffentlichen SSH-Schlüssel der Benutzer
• Steuerung des RHEL-Patchmanagements

Seit 2016 betreiben wir im BITS Red Hat Enterprise Linux als drittes Server-Betriebssystem neben Solaris und Microsoft Windows Server. Nachdem wir nun erste Betriebserfahrung mit der für uns neuen Distribution gesammelt haben, möchte ich in diesem Jahr unser Betriebskonzept überarbeiten, um die Erkenntnisse aus dem bisherigen Betrieb einfließen zu lassen und (hoffentlich) Verbesserungen für den zukünftigen Betrieb herbei zu führen.

Ansible wird in diesem Konzept eine wesentliche Rolle einnehmen. Als Konfigurations-Management-Werkzeug wird es für Teile des Betriebssystems und für das zentrale RHEL-Patchmanagement zum Einsatz kommen.

Die zu bewältigenden Konfigurationsaufgaben unterscheiden wir dabei in:

• Parameter die im Bereitstellungsprozess initialisiert werden und anschließend in der Hoheit des jeweiligen Systembetreibers liegen sowie
• Parameter welche dauerhaft durch das Konfigurations-Management verwaltet werden; diese gliedern sich wiederum in die
  • Zeilenbasierte Verwaltung von Konfigurationsdateien und
  • Dateibasierte Verwaltung von Konfigurationsdateien

In diesem Beitrag führe ich die einzelnen Parameter und Optionen auf, welche zukünftig von Ansible verwaltet werden. Von diesen wird zukünftig auf weitere Beiträge verlinkt, welche die konkrete Umsetzung mit Ansible beschreiben und dokumentieren. Es mag sich also lohnen von Zeit zu Zeit wieder hier vorbei zu schauen.

Initialisierte Parameter

Hierunter sind Parameter und Optionen zu verstehen, die zu Beginn im Bereitstellungsprozess konfiguriert werden, um sicherzustellen, dass sich das neue System optimal in unsere Infrastruktur einfügt. Diese werden initial und einmalig gesetzt und gehen nach der Übergabe des Systems in die Hoheit des jeweiligen Systembetreibers über. Der Systembetreiber ist bei uns die Person, welche den spezifischen Server administriert und Dienste auf diesem betreibt.

Zu den initial konfigurierten Parametern zählen im Einzelnen:

• DNS-Konfiguration
• Zeitserver-Konfiguration
• Postfix-Konfiguration zum Versand von System-Mails
• System-Registrierung und Verknüpfung mit einer Subskription
• Konfiguration der BITS-Standard-Repositories
• Konfiguration der Host-Firewall
• Konfiguration von SELinux
• Installation eines definierten Standardsatzes an Software-Paketen

Dauerhaft verwaltete Parameter

Diese Parameter/Optionen werden bei lokalen Änderungen auf dem System durch Ansible überschrieben. Dabei handelt es sich um

• Die Stage-Zuordnung über das Ansible-Inventory
• Das Anlegen und verwalten eines Benutzers zur Anbindung an das BMC-Monitoring
• Die Verwaltung spezifischer lokaler Benutzerkonten
• Die Steuerung des SSH-Servers, der authorized_keys Dateien und die Verwaltung der öffentlichen SSH-Schlüssel der Benutzer
• Steuerung des RHEL-Patchmanagements

Ich habe eine neue Erweiterung für Firefox entwickelt, welche auf spielerische Art dabei hilft, Ordnung in die Lesezeichen zu bringen – nämlich auf Tinder-Art.

Lesezeichen aufräumen ist langweilig. Daran ändert für viele auch die von mir entwickelte Lesezeichen-Erweiterung Bookmarks Organizer nichts, welche dabei hilft, nicht mehr funktionierende Lesezeichen, Weiterleitungen sowie Duplikate zu finden.

Einen anderen, dynamischeren Ansatz bietet meine neue Erweiterung Keep or Delete Bookmarks. Keep or Delete Bookmarks bringt etwas Spaß in die Aufgabe der Lesezeichen-Organisation, indem sie es erlaubt, die Lesezeichen wie auf „Tinder“ oder ähnlichen Diensten auszusortieren.

Doch was genau bedeutet das eigentlich?

Die Idee ist simpel: Die Erweiterung zeigt immer ein einzelnes Lesezeichen an, welches vollkommen zufällig ausgewählt wird, bestehend aus dem Titel, der URL sowie dem Ordner, in welchem sich das Lesezeichen befindet.

Der Nutzer hat hier nun verschiedene Möglichkeiten: Er kann das Lesezeichen entweder löschen, der Erweiterung sagen, dass das Lesezeichen behalten werden soll, oder das Lesezeichen überspringen, dann erscheint es irgendwann später wieder. Eine vierte Option ist es, das Lesezeichen in einem neuen Tab zu öffnen. Das hilft, wenn man sich bezüglich eines Lesezeichens noch nicht sicher ist und dieses erst überprüfen möchte.

Nach jeder Aktion erscheint umgehend das nächste Lesezeichen. Dabei stellt die Erweiterung sicher, dass niemals zweimal hintereinander das gleiche Lesezeichen angezeigt wird.

Vor dem Löschen eines Lesezeichens erscheint standardmäßig immer ein Bestätigungsdialog. Dieser kann aber ganz einfach über die Checkbox am Seitenanfang deaktiviert werden. Eine Änderung der Checkbox wirkt umgehend, ein Neuladen der Erweiterungs-Oberfläche ist also nicht notwendig.

Hat man sich entschieden, ein Lesezeichen zu behalten, merkt sich das die Erweiterung. Über den Whitelist-Button erhält man eine Übersicht aller dieser Lesezeichen und kann diese entweder einzeln oder alle zusammen wieder zurück in den „Pool“ werfen. Nachträglich gelöschte Lesezeichen, auch wenn diese nicht über diese Erweiterung gelöscht wurden, werden automatisch auch aus der Whitelist von Keep or Delete Bookmarks entfernt.

Download der Erweiterung

Wie alle meine Erweiterungen ist auch Keep or Delete Bookmarks über addons.mozilla.org zu beziehen:

Download Keep or Delete Bookmarks für Firefox

Quellcode, Fehler melden, Vorschläge

Keep or Delete Bookmark ist Open Source (MPL 2.0) und der Quellcode auf GitHub zu finden. Dies ist auch der Ort, an welchem Fehler gemeldet und Vorschläge gemacht werden können.

Entwicklung unterstützen

Wer die Entwicklung des Add-ons unterstützen möchte, kann dies tun, indem er der Welt vom Keep or Delete Bookmarks erzählt und die Erweiterung auf addons.mozilla.org bewertet. Auch würde ich mich sehr über eine kleine Spende freuen, welche es mir ermöglicht, weitere Zeit in die Entwicklung des Add-on zu investieren, um zusätzliche Features zu implementieren.

Der Beitrag Keep or Delete Bookmarks: Neue Lesezeichen-Erweiterung für Firefox erschien zuerst auf soeren-hentzschel.at.

Ein Reverse Proxy liefert eine Ressource, welche er von einem oder mehreren Servern holt, an einen Client aus. Bei Gitea kann es durchaus sinnvoll sein, dieses hinter einem Reverse Proxy zu betreiben. Standardmäßig läuft der Dienst auf dem Port 3000. Möchte der Nutzer ihn über die normalen Ports für HTTP (80) bzw. HTTPS (443) erreichbar machen, könnte das Ganze durchaus über die Konfiguration von Gitea in Verbindung mit der systemd-Unit geschehen.

Allerdings ist ein weiterer Vorteil bei einem Reverse Proxy, das die angefragte Infrastruktur aus der Sicht der Clients versteckt wird. Mittels Nginx kann es solcher Reverse Proxy realisiert werden. Dazu muss die Nginx-Konfiguration für die Domain angepasst werden:

nano /etc/nginx/sites-available/example

In diesem Fall befasst sich die Konfiguration mit der verschlüsselten Kommunikation per HTTPS und der Weiterleitung von unverschlüsselten Verbindung in Richtung der verschlüsselten Verbindung.

server {
  listen 80;
  listen [::]:80;

  server_name example.org;

  return 301 https://$host$request_uri$is_args$args;
}

server {
  listen 443;
  listen [::]:443 default_server;

  ssl on;
  ssl_certificate        /etc/letsencrypt/live/example.org/fullchain.pem;
  ssl_certificate_key    /etc/letsencrypt/live/example.org/privkey.pem;

    server_name org;

    location / {
        proxy_pass http://localhost:3000;
    }
}

Anhand der Konfiguration wird ersichtlich das Gitea auf dem Server unverschlüsselt betrieben werden kann, da die eigentliche Verschlüsselung über HTTPS vom Reverse Proxy, in diesem Fall Nginx, übernommen wird. Nachdem die Konfiguration gespeichert wurde, muss Nginx neugestartet werden:

service nginx restart

Anschließend muss die Gitea-Konfiguration nochmals angepasst werden:

nano /home/git/gitea/custom/conf/app.ini

Dort muss die ROOT_URL nun so definiert werden, wie der Client sie nun sieht. Die ROOT_URL kann von:

ROOT_URL         = https://example.org:3000/

zu:

ROOT_URL         = http://example.org/

geändert werden. Die Werte PROTOCOL, CERT_FILE und KEY_FILE können entfernt werden, da die Verschlüsslung nun von Nginx übernommen wird. Nach der Änderung der Konfiguration muss Gitea ebenfalls neugestartet werden:

service gitea restart

Nachdem die Konfiguration durch geführt wurde, ist Gitea unter zwei URLs erreichbar:

http://example.org:3000/
https://example.org/

Intern läuft Gitea auf dem Port 3000. Damit dieser nicht von außen erreichbar ist, sollte eine entsprechende Firewall-Regel konfiguriert werden.

Nach der Installation von Gitea läuft dieses standardmäßig über unverschlüsseltes HTTP. Um dies zu ändern muss die app.ini welche sich im Verzeichnis /home/git/gitea/custom/conf/ befindet bearbeitet werden:

nano /home/git/gitea/custom/conf/app.ini

In der Sektion server welche für gewöhnlich wie folgt aussieht:

[server]
SSH_DOMAIN       = localhost
DOMAIN           = localhost
HTTP_PORT        = 3000
ROOT_URL         = http://example.org:3000/
DISABLE_SSH      = false
SSH_PORT         = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = /home/git/gitea/data/lfs
LFS_JWT_SECRET   = plgd0f1J4RlmWFnk9K4oHeV6Wey_vI55x7uC81Rp5Mc
OFFLINE_MODE     = false

müssen einige Änderungen vorgenommen werden. Die Schlüssel PROTOCOL, CERT_FILE und KEY_FILE müssen hinzugefügt und die ROOT_URL angepasst werden. Danach sollte die server-Sektion in etwa so aussehen:

[server]
SSH_DOMAIN       = localhost
DOMAIN           = localhost
HTTP_PORT        = 3000
PROTOCOL         = https
CERT_FILE        = custom/https/cert.pem
KEY_FILE         = custom/https/key.pem
ROOT_URL         = https://example.org:3000/
DISABLE_SSH      = false
SSH_PORT         = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = /home/git/gitea/data/lfs
LFS_JWT_SECRET   = plgd0f1J4RlmWFnk9K4oHeV6Wey_vI55x7uC81Rp5Mc
OFFLINE_MODE     = false

Nachdem die Konfiguration gespeichert wurde muss das passende Zertifikat erzeugt werden:

cd /home/git/gitea/custom/
mkdir https
cd https
./gitea cert -ca=true -duration=8760h0m0s -host=example.org

Alternativ und in den meisten Fall sinnvoller ist es allerdings an dieser Stelle Zertifikate von Let’s Encrypt einzubinden. Dazu müssen die Zertifikate für die Domain im ersten Schritt erzeugt werden:

letsencrypt certonly

Anschließend muss die app.ini angepasst werden:

nano /home/git/gitea/custom/conf/app.ini

Dort werden die Werte für CERT_FILE und KEY_FILE so konfiguriert das sie auf die Let’s Encrypt-Zertifikate zeigen:

CERT_FILE    = /etc/letsencrypt/live/example.org/fullchain.pem
KEY_FILE     = /etc/letsencrypt/live/example.org/privkey.pem

Damit ist Gitea nach einem Neustart des Service per HTTPS und damit verschlüsselt erreichbar.

Vor ein paar Jahren schrieb ich eine Anleitung, in der es darum ging Gogs zu installieren. Schon damals hatte sich eine Abspaltung unter dem Namen Gitea herausgelöst, welche einen Community zentrierten Ansatz bei der Entwicklung fuhr. Gitea ist eine vollwertige Lösung, welche einen Git-Server, eine Weboberfläche und weitere Entwicklerwerkzeuge, wie einen Bugtracker und eine Wiki bereitstellt.

Zur Installation von Gitea muss im ersten Schritt Git installiert werden:

apt-get install git

Nachdem dies geschehen ist, wird ein Nutzer für Gitea angelegt und in dessen Kontext gewechselt:

adduser --disabled-password --gecos "" git
su git
cd

Nun kann Gitea heruntergeladen werden. Dazu muss der passende Download-Link über die Projektseite ermittelt werden:

wget https://dl.gitea.io/gitea/1.8.3/gitea-1.8.3-linux-amd64

Im Normalfall sollte hierbei die Linux-AMD64-Version genutzt werden. Nach dem Download kann Gitea für den ersten Testlauf gestartet werden:

mkdir gitea
mv gitea-1.8.3-linux-amd64 gitea/gitea
cd gitea
chmod 755 gitea
./gitea

Nach dem Start kann Gitea im Browser unter der URL aufgerufen werden:

http://example.org:3000/

Sobald der erste Testlauf erfolgreich durchgeführt wurde, sollte Gitea wieder beendet werden. Im nächsten Schritt muss die systemd-Unit eingerichtet werden, welche dafür sorgt, dass der Service automatisch gestartet wird. Dazu wird im ersten Schritt die entsprechende Datei angelegt:

nano /etc/systemd/system/gitea.service

Diese Datei wird nun mit folgendem Inhalt befüllt:

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
#After=mysqld.service
#After=postgresql.service
#After=memcached.service
#After=redis.service

[Service]
# Modify these two values and uncomment them if you have
# repos with lots of files and get an HTTP error 500 because
# of that
###
#LimitMEMLOCK=infinity
#LimitNOFILE=65535

Type=simple
User=git
Group=git
WorkingDirectory=/home/git/gitea
ExecStart=/home/git/gitea/gitea web
Restart=always
Environment=USER=git HOME=/home/git

# If you want to bind Gitea to a port below 1024 uncomment
# the two values below
###
#CapabilityBoundingSet=CAP_NET_BIND_SERVICE
#AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

Nachdem die systemd-Unit angelegt wurde, kann sie aktiviert und gestartet werden:

systemctl enable gitea
systemctl start gitea

Damit wird Gitea automatisch gestartet und läuft als Service im Hintergrund. Im Browser kann Gitea nun aufgerufen werden und installiert werden. Dazu wird der Anmelden-Button in der Weboberfläche gedrückt oder alternativ die URL:

http://example.org:3000/install

aufgerufen. In der Installationsroutine wird unter anderem die Datenbank-Verbindung definiert und es besteht die Möglichkeit einen administrativen Nutzer anzulegen. Für kleinere Installation kann SQLite3 als Datenbank-Backend bedenkenlos genutzt werden.

Sollten Fehler bei der Installation des Services oder bei Gitea aufgetreten sein, so lohnt es sich in das systemd-Log mittels:

systemctl status gitea

hineinzuschauen. Das Gitea-eigenen Logs befindet sich bei dieser Installation unter /home/git/gitea/log/:

/home/git/gitea/log/gitea.log 
/home/git/gitea/log/http.log 
/home/git/gitea/log/xorm.log

Eine Welt in Minecraft hat die Angewohnheit, mit der Zeit immer größer zu werden. In einem solchen Fall ist eine Karte natürlich sehr praktisch. Mithilfe des Tools Mapcrafter kann eine solche Karte erstellt werden. Der Mapcrafter erzeugt neben den Kartenkacheln auch eine JavaScript-Anwendung, mit der diese betrachtet werden können.

Im ers­ten Schritt muss das Mapcrafter-Repository mittels:

git clone https://github.com/mapcrafter/mapcrafter.git

auf den Ser­ver geholt werden. Mit dem Befehl wird das Git-Repository, in welchem sich der Quelltext befindet, auf den Server geklont. Im Git-Kontext bedeutet dies, dass das gesamte Repository heruntergeladen wird. Falls Git nicht installiert ist, muss das entsprechende Paket mittels:

apt install git

installiert werden. Die aktuelle Entwicklung findet im Branch world113 statt, so das in diesen gewechselt werden muss:

cd mapcrafter
git checkout world113

Bevor die Software kompiliert werden kann, müssen einige Abhängigkeiten installiert werden:

apt install build-essential cmake libboost-all-dev libjpeg-dev libpng-dev

Anschließen kann die Software kompiliert und installiert werden:

cmake .
make 
make install
ldconfig

Nach der Installation könnte Mapcrafter über den Befehl:

/usr/local/bin/mapcrafter -c example.conf -b -j 4

ausgeführt werden. Allerdings muss vor dem ersten Start noch eine Konfigurationsdatei erstellt werden. In dieser Konfigurationsdatei ist definiert, wie die Karte gerendert werden soll. Die Datei und die Skripte zur Aktualisierung werden im Kontext des Nutzers minecraft angelegt:

su minecraft
cd
mkdir map
nano example.conf

Exemplarisch könnte die Konfigurationsdatei wie folgt aussehen:

output_dir = /home minecraft/map
background_color = #000000

[marker:teleporter]
name = Teleporter
prefix = Hauptteleporter
icon = beacon.png
icon_size = [32, 32]
show_default = false
title_format = %(textp)

[marker:signs]
name = Signs
icon = sign.png
icon_size = [32, 32]
show_default = false
title_format = %(textp)

[world:world]
input_dir = world
world_name = Example

[global:map]
image_format = png
png_indexed = true
rotations = top-left
texture_size = 16

[map:day_isometric]
name = Day (isometric)
render_view = isometric
render_mode = daylight
world = world

Nachdem die Konfigurationsdatei angelegt wurde, kann die Karte testweise mittels des Befehls:

/usr/local/bin/mapcrafter -c example.conf -b -j 4

erzeugt werden. Damit die Aktualisierung später automatisch geschieht, werden die Befehle zur Aktualisierung der Skripte in eine Skript-Datei geschrieben:

nano updateMap.sh

Diese Datei wird mit folgendem Inhalt befüllt:

#!/bin/bash
/usr/local/bin/mapcrafter -c example.conf -b -j 4
/usr/local/bin/mapcrafter_markers -v -c example.conf

Anschließend soll ein Cronjob eingerichtet werden. Dazu wird der Crontab-Editor geöffnet:

crontab -e

In der sich öffnende Datei muss nun folgende Zeile hinzugefügt werden:

0    1    * * *   (. ~/.profile; /usr/bin/screen -dmS mapcrafter /home/minecraft/updateMap.sh)

Danach kann die Datei geschlossen werden. Der Cronjob startet nun um 1 Uhr die tägliche Aktualisierung der Karte.

linuxmuster.net ist eine Open Source Schulserverlösung für Schulen jeglicher Art und Größe. Aktuell ist die Version 7 in Entwicklung und der Start der Beta-Phase steht unmittelbar bevor. In den letzten Monaten ist einiges passiert und ich möchte in diesem Artikel kurz einen Überblick über die aktuellen Entwicklungen geben.

Neuigkeiten rund um linuxmuster.net

• linuxmuster.net hat in diesem Jahr bereits zwei Auszeichnungen erhalten. Die freie Schulserverlösung hat einen 2. Platz beim Thomas-Krenn Award gewonnen sowie die Auszeichnung mit dem „Comenius eduMedia Siegel“ erhalten.
• In Kürze findet eine Schulung zur neuen Version 7 für Dienstleister statt. Wer Interesse hat, findet hier weitere Informationen.
• Die Beta-Phase von linuxmuster.net v7 steht in den Startlöchern. Vieles ist schon fertig und einige Schulen setzen die neue Lösung bereits produktiv ein. Ganz fertig ist sie allerdings noch nicht und es fehlt v.a. noch einiges an Dokumentation.
• Auf den Chemnitzer Linuxtagen gab es einen Vortrag zu linuxmuster.net. Sehr zu empfehlen für alle, die einen kompakten Überblick über die Schulserverlösung erhalten wollen.

Mithelfen

Ein Open Source Projekt lebt von der Mitarbeit vieler – nicht anders ist das bei linuxmuster.net. Wenn du also mithelfen möchtest, findest du hier eine gute Übersicht, in welchen Bereichen, das Projekt noch Hilfe braucht. Egal ob Entwicklung, Dokumentation, Fehler finden, Support – in jedem Bereich gibt es die Möglichkeit sich einzubringen.

Fazit

Wir setzen linuxmuster.net seit 3 Jahren bei uns in der Schule ein und sind wirklich sehr zufrieden damit. Die vielen Möglichkeiten zur Erweiterung oder individuellen Anpassung sind großartig und mit LINBO gibt es ein sehr praktisches Tool, um viele Rechner mit wenig Aufwand in einer Schule zu verwalten. Aktuell planen wir den Umstieg auf linuxmuster.net v7. Dies wird ein größeres Update sein, da sich viele Dinge geändert haben.

Für jeden, der sich für die Schulserverlösung interessiert und vielleicht in den Sommerferien damit erste Erfahrungen sammeln möchte, empfehle ich die linuxmuster.net v7. Es gibt viele hilfsbereite Schuladmins und auch einen offiziellen Support von Seiten des Projekts, wo man seine Fragen loswerden und in jedem Fall eine Antwort bekommen kann (und dazu meist sehr schnell).

8 Kommentare

Der Beitrag linuxmuster.net – Neuigkeiten zur Schulserverlösung erschien zuerst auf .:zefanjas:..

Heute kam ich in die Situation auf einen Ubuntu Server in der SQL Datenbank mittels phpmyadmin in einem Feld ein Zeichen gegen ein anderes zu tauschen. Konkret ging es um Umlaute die ich in einer HTML Konformen weise speichern wollte.

Mit folgenden Befehl kann ich ein Zeiten in einem Feld tauschen:

UPDATE tabellenname SET feldname=REPLACE(feldname,'Ü','& Uuml;')
(Leerzeichen nach dem & entfernen…)

Das Spielprinzip von Minecraft, welches mittlerweile von Microsoft aufgekauft wurde, lässt sich am besten als LEGO für Erwachsene beschreiben. In einer Welt, die nur aus Blöcken besteht, kann sich der Spieler ausleben und seiner Kreativität freien Lauf lassen.

Vor einigen Jahren schrieb ich einen Artikel, wie ein Minecraft-Server unter Ubuntu aufgesetzt wird. Da der Artikel mittlerweile etwas veraltet ist, wird die Anleitung mit diesem Artikel aktualisiert.

Um einen Minecraft-Server aufzusetzen, muss im ersten Schritt Java mittels:

apt install openjdk-11-jre

installiert werden. Nun kann die Version des installierten Javas mittels des Befehls:

java --version

bestimmt werden. Für die Ausführung von Minecraft wird hierbei Java 7 oder höher benötigt. In der Ausgabe des Befehls finden sich die notwendigen Informationen:

openjdk 11.0.3 2019-04-16
OpenJDK Runtime Environment (build 11.0.3+7-Ubuntu-1ubuntu218.04.1)
OpenJDK 64-Bit Server VM (build 11.0.3+7-Ubuntu-1ubuntu218.04.1, mixed mode, sharing)

Nachdem damit die Grundvoraussetzungen erfüllt sind, wird mittels:

adduser --disabled-login --gecos "" minecraft
su minecraft

ein Nutzer für den Server angelegt und in diesen Nutzer gewechselt. Im Kontext des Nutzer muss nun der Server heruntergeladen werden. Die aktuelle URL des Server ist über die Minecraft-Webseite in Erfahrung zu bringen:

wget https://launcher.mojang.com/v1/objects/d0d0fe2b1dc6ab4c65554cb734270872b72dadd6/server.jar

Nachdem der Server heruntergeladen wurde, kann er für einen ersten Tests gestartet werden:

java -Xmx1024M -Xms1024M -jar server.jar nogui

Beim ersten Start wird folgende Meldung erscheinen:

[13:36:13] [main/ERROR]: Failed to load properties from file: server.properties
[13:36:14] [main/WARN]: Failed to load eula.txt
[13:36:14] [main/INFO]: You need to agree to the EULA in order to run the server. Go to eula.txt for more info.

Im Home-Verzeichnis des Nutzers findet sich nun eine Datei mit dem Namen eula.txt. Diese Datei muss bearbeitet werden:

nano eula.txt

Der Wert:

eula=false

muss hierbei auf den Wert true gesetzt werden. Anschließend kann die Datei gespeichert werden und der Editor verlassen werden. Nach dem abermaligen Start des Servers mittels:

java -Xmx1024M -Xms1024M -jar server.jar nogui

sollte derselbe nun hochfahren. Nachdem der Server erfolgreich hochgefahren wurde, sollte er wieder beendet werden. Damit der Service automatisch hochfährt, muss eine sogenannte systemd-Unit angelegt werden. Dazu wird der Nutzer minecraft verlassen und die systemd-Unit angelegt:

exit
nano /etc/systemd/system/minecraft.service

Die neu angelegte Datei wird nun mit folgendem Inhalt befüllt:

[Unit]
Description=Minecraft Server
After=network.target

[Service]
Type=simple
WorkingDirectory=/home/minecraft
User=minecraft
Group=minecraft

Restart=always

ExecStart=/usr/bin/screen -DmS minecraft-server java -Xmx4096M -Xms2048M -jar server.jar nogui

ExecStop=/usr/bin/screen -p 0 -S minecraft-server -X eval 'stuff "save-all"15'
ExecStop=/usr/bin/screen -p 0 -S minecraft-server -X eval 'stuff "stop"15'
ExecStop=/bin/sleep 2

[Install]
WantedBy=multi-user.target

Nachdem die Datei gespeichert wurde, kann die systemd-Unit aktiviert werden:

systemctl enable minecraft
systemctl start minecraft

Damit ist der Minecraft-Server eingerichtet und startet automatisch und läuft anschließend im Hintergrund.

Im Home-Verzeichnis des Nutzers minecraft finden sich einige Dateien, welche der Konfiguration des Servers dienen. In der Datei ops.json werden die Operatoren für den Server hinterlegt. Die Datei server.properties enthält die grundlegenden Einstellungen des Servers. Wurde die Option white-list auf den Wert true gesetzt, so können die berechtigten Nutzer in der Datei whitelist.json hinterlegt werden.

Laufende Angriffe auf SKS-Keyserver offenbaren schonungslos wie kaputt dieser zentrale Teil der PGP-Infrastruktur ist. Ein neuer Keyserver mit Verifizierungsfunktion soll abhilfe schaffen, verabschiedet sich aber vom Web of Trust. Nach vielen negativen Meldungen erleben wir gerade die letzten Zuckungen eines sterbenden Konzept. Zum Glück gibt es Alternativen.

Die zentralen Schlüsselserver gehörten mal zum Grundprinzip von PGP. Die zu Grunde liegende Idee war, dass jeder seinen öffentlichen Schlüssel hochladen und anderen zur Verfügung stellen kann. Die Keyserver waren miteinander vernetzt weshalb die Schlüssel sich auf die verschiedenen Keyserver verteilten. Die Echtheit des öffentlichen Schlüssels überprüfte man nie. Das hatte System, da man mittels des so genannten Web of Trust die Echtheit verifizieren sollte. Jeder konnte und sollte ihm bekannte Schlüssel signieren und damit die Echtheit bestätigen. Ein Konzept, das ganz offensichtlich aus den Kindertagen des Internets mit ein paar hundert Anwender stammte und nie wirklich funktioniert hat. Wie angreifbar dieses Konzept ist war seit längerem hinreichend bekannt.

Wie immer bei diesen uralten, nicht zentralisierten Protokollen, ist die Gemeinschaft unfähig zur Reform. Wir erleben das gleiche Problem bei XMPP und anderen Protokollen, wo man so lange am kaputten Kern rumpatcht bis es zig Inkompatibilitäten gibt und man nur noch in einer speziellen Server- und Clientversionskombination interagieren kann. Gepaart mit einer ordentlichen Portion Überheblichkeit, denn wer Kritik übt, hat einfach das System nicht verstanden. Bei EFAIL konnte man zuletzt diese Abwehrkommunikation beobachten (siehe: Kommentar: EFAIL - Nebelkerzen und was ist eigentliche eine Lücke?). Das wiederholt sich nun mit hoher Wahrscheinlichkeit.

Erste Ansätze kann man bereits beobachten. Einige OpenPGP-Entwickler raten davon ab die SKS-Keyserver weiter zu nutzen. Stattdessen soll man auf einen neuen Keyserver wechseln, der sich zwar durch eine Verifikation der E-Mail Adressen auszeichnet, aber nebenbei faktisch das Web of Trust abschafft. Durch die Dezentralisierung des Protokolls dauert es aber viel zu lange bis diese Entwicklungen beim Anwender ankommen. Alle Implementierungen müssen schließlich die voreingestellten Keyserver auswechseln. Selbst wenn die Entwickler das wirklich machen (was noch nicht gesichert ist) dauert es Jahre bis das alle Anwender erreicht - sofern diese überhaupt noch ihre Clients aktualisieren bzw. überhaupt noch aktiv gepflegte Programme nutzen.

Das Prinzip E-Mail Verschlüsselung mittels OpenPGP ist einfach am Ende. Ebenso wie die Verschlüsselung der E-Mail allgemein (siehe: Die E-Mail wird niemals sicher sein!). PGP ist in fast keinem E-Mail Programm mit nennenswerter Verbreitung implementiert - nicht mal im Vorzeige-Open-Source-Projekt Thunderbird. Man muss immer mehr oder minder umständlich mit Addons agieren. Es gibt zig ungelöste Probleme. Neben EFAIL kann man Signaturen optisch imitieren und die nachträglich zur Vereinfachung hinzugefügten Änderungen haben - siehe XMPP - es auch nicht besser gemacht. Würde die Community hier ähnlich strenge Kriterien anlegen wie sonst an die proprietären Marktführer, OpenPGP wäre schon lange erledigt. Scheinbar genießen diese uralten Protokolle aber einen gewissen Anciennitätsbonus.

OpenPGP hat immer noch seine Stärken. Insbesondere zur privaten Verschlüsselung auf Dateibasis oder auch zum verteilen von schützenswerten Dateien in einem kleinen Kreis ohne ein Passwort weiter geben zu müssen. Auch bei der Signierung von Paketen im Linux-Bereich ist es nach wie vor unverzichtbar.

Zur Verschlüsselung von E-Mail Nachrichten ist es aber endgültig gestorben - so es denn jemals gelebt hat. Außerhalb der Open Source-Gemeinde nutzt das sowieso niemand, da die meisten Firmen - so sie denn überhaupt ihre E-Mails absichern - auf S/MIME gesetzt haben.

Die gute Nachricht lautet: Es ist vollkommen egal. E-Mails haben das Sicherheitsniveau von Postkarten und das haben mittlerweile sehr viele Menschen begriffen. Niemand teilt sensible private Informationen noch per E-Mail, schon alleine weil die private E-Mail-Nutzung massiv rückläufig sind. Moderne Messenger haben ein viel höheres Sicherheitsniveau, selbst für WhatsApp gilt das (siehe auch: Sichere Messenger - Verschlüsselung und Metadaten).

---

Bilder:

Einleitungs- und Beitragsbild von ribkhan via pixaybay | Ampelchaos von Greg Montani via Pixabay | VW Bus von v2osk via Unsplash

Laufende Angriffe auf SKS-Keyserver offenbaren schonungslos wie kaputt dieser zentrale Teil der PGP-Infrastruktur ist. Ein neuer Keyserver mit Verifizierungsfunktion soll abhilfe schaffen, verabschiedet sich aber vom Web of Trust. Nach vielen negativen Meldungen erleben wir gerade die letzten Zuckungen eines sterbenden Konzept. Zum Glück gibt es Alternativen.

Die zentralen Schlüsselserver gehörten mal zum Grundprinzip von PGP. Die zu Grunde liegende Idee war, dass jeder seinen öffentlichen Schlüssel hochladen und anderen zur Verfügung stellen kann. Die Keyserver waren miteinander vernetzt weshalb die Schlüssel sich auf die verschiedenen Keyserver verteilten. Die Echtheit des öffentlichen Schlüssels überprüfte man nie. Das hatte System, da man mittels des so genannten Web of Trust die Echtheit verifizieren sollte. Jeder konnte und sollte ihm bekannte Schlüssel signieren und damit die Echtheit bestätigen. Ein Konzept, das ganz offensichtlich aus den Kindertagen des Internets mit ein paar hundert Anwender stammte und nie wirklich funktioniert hat. Wie angreifbar dieses Konzept ist war seit längerem hinreichend bekannt.

Wie immer bei diesen uralten, nicht zentralisierten Protokollen, ist die Gemeinschaft unfähig zur Reform. Wir erleben das gleiche Problem bei XMPP und anderen Protokollen, wo man so lange am kaputten Kern rumpatcht bis es zig Inkompatibilitäten gibt und man nur noch in einer speziellen Server- und Clientversionskombination interagieren kann. Gepaart mit einer ordentlichen Portion Überheblichkeit, denn wer Kritik übt, hat einfach das System nicht verstanden. Bei EFAIL konnte man zuletzt diese Abwehrkommunikation beobachten (siehe: Kommentar: EFAIL - Nebelkerzen und was ist eigentliche eine Lücke?). Das wiederholt sich nun mit hoher Wahrscheinlichkeit.

Erste Ansätze kann man bereits beobachten. Einige OpenPGP-Entwickler raten davon ab die SKS-Keyserver weiter zu nutzen. Stattdessen soll man auf einen neuen Keyserver wechseln, der sich zwar durch eine Verifikation der E-Mail Adressen auszeichnet, aber nebenbei faktisch das Web of Trust abschafft. Durch die Dezentralisierung des Protokolls dauert es aber viel zu lange bis diese Entwicklungen beim Anwender ankommen. Alle Implementierungen müssen schließlich die voreingestellten Keyserver auswechseln. Selbst wenn die Entwickler das wirklich machen (was noch nicht gesichert ist) dauert es Jahre bis das alle Anwender erreicht - sofern diese überhaupt noch ihre Clients aktualisieren bzw. überhaupt noch aktiv gepflegte Programme nutzen.

Das Prinzip E-Mail Verschlüsselung mittels OpenPGP ist einfach am Ende. Ebenso wie die Verschlüsselung der E-Mail allgemein (siehe: Die E-Mail wird niemals sicher sein!). PGP ist in fast keinem E-Mail Programm mit nennenswerter Verbreitung implementiert - nicht mal im Vorzeige-Open-Source-Projekt Thunderbird. Man muss immer mehr oder minder umständlich mit Addons agieren. Es gibt zig ungelöste Probleme. Neben EFAIL kann man Signaturen optisch imitieren und die nachträglich zur Vereinfachung hinzugefügten Änderungen haben - siehe XMPP - es auch nicht besser gemacht. Würde die Community hier ähnlich strenge Kriterien anlegen wie sonst an die proprietären Marktführer, OpenPGP wäre schon lange erledigt. Scheinbar genießen diese uralten Protokolle aber einen gewissen Anciennitätsbonus.

OpenPGP hat immer noch seine Stärken. Insbesondere zur privaten Verschlüsselung auf Dateibasis oder auch zum verteilen von schützenswerten Dateien in einem kleinen Kreis ohne ein Passwort weiter geben zu müssen. Auch bei der Signierung von Paketen im Linux-Bereich ist es nach wie vor unverzichtbar.

Zur Verschlüsselung von E-Mail Nachrichten ist es aber endgültig gestorben - so es denn jemals gelebt hat. Außerhalb der Open Source-Gemeinde nutzt das sowieso niemand, da die meisten Firmen - so sie denn überhaupt ihre E-Mails absichern - auf S/MIME gesetzt haben.

Die gute Nachricht lautet: Es ist vollkommen egal. E-Mails haben das Sicherheitsniveau von Postkarten und das haben mittlerweile sehr viele Menschen begriffen. Niemand teilt sensible private Informationen noch per E-Mail, schon alleine weil die private E-Mail-Nutzung massiv rückläufig sind. Moderne Messenger haben ein viel höheres Sicherheitsniveau, selbst für WhatsApp gilt das (siehe auch: Sichere Messenger - Verschlüsselung und Metadaten).

---

Bilder:

Einleitungs- und Beitragsbild von ribkhan via pixaybay | Ampelchaos von Greg Montani via Pixabay | VW Bus von v2osk via Unsplash

Mozilla wird am Dienstag Firefox 68 veröffentlichen. Firefox 68 wird gleichzeitig die neue Basis für Firefox ESR sein, die Firefox-Version mit Langzeitunterstützung. Während Firefox 68 und Firefox ESR 68 grundsätzlich identisch sind, gibt es doch ein paar wichtige Unterschiede zwischen beiden Versionen. Auch sonst gibt es einiges Wissenswertes für System-Administratoren.

Mozilla wird am 9. Juli 2019 Firefox 68 und Firefox ESR 68 veröffentlichen. Nutzer von Firefox ESR 60 haben ab dann noch 15 Wochen Zeit, ehe sie mit Erscheinen von Firefox 70 und Firefox ESR 68.2 am 22. Oktober 2019 automatisch auf Firefox ESR 68 migriert werden. Wie schon Firefox ESR 60 unterscheidet sich auch Firefox ESR 68 in ein paar Aspekten von seinem Mainstream-Pendant.

Firefox ESR 68: Kein WebRender

WebRender stammt wie die mit Firefox 57 eingeführte CSS-Engine Stylo ebenfalls aus Mozillas Next-Generation-Engine Servo und ist in der Programmiersprache Rust geschrieben. Es handelt sich bei WebRender um einen Renderer für Webseiten-Inhalte, welcher unter stärkerer Einbeziehung der Grafikkarte als bisher im Grunde wie eine Spiele-Engine arbeitet, aber für das Rendering von Web-Content optimiert ist und dadurch große Performance-Vorteile liefern soll.

Mit Firefox 67 hat es WebRender erstmals in eine finale Version von Firefox geschafft, allerdings erst für einen kleinen Teil der Nutzer. Während Mozilla WebRender weiter verbessert und für immer mehr Nutzer aktiviert, wird WebRender in Firefox ESR 68 für alle Nutzer komplett deaktiviert bleiben.

Firefox ESR 68: System-Zertifikate

Standardmäßig nutzt Firefox seinen eigenen Zertifikatsspeicher und bietet damit eine erhöhte Sicherheit gegenüber anderen Browsern. Im Unternehmensumfeld jedoch ist es häufig gewünscht, dass Zertifikate aus dem Zertifikatsspeicher des Betriebssystems genutzt werden. Darum ist dies in Firefox ESR 68 standardmäßig aktiviert.

Zur Deaktivierung muss der folgende Schalter über about:config auf false geschaltet werden:

security.enterprise_roots.enabled

Firefox ESR 68: Deaktivierte MITM-Erkennung

Nicht nur Schadsoftware, auch sogenannte „Sicherheits“-Software unterbricht verschlüsselte Verbindungen (das heißt Verbindungen über https://) immer wieder, um die Inhalte zu lesen, bevor diese den Browser erreichen, und verkauft dies dann auch noch als Feature. Man spricht dabei von einem sogenannten Man-in-the-Middle („MITM“). Die Folge für Firefox-Nutzer ist aufgrund der häufig mangelhaften Implementierung in einigen Fällen, dass Firefox keine Verbindungen über https:// mehr herstellen kann. Firefox 68 kann Verbindungsprobleme aufgrund von MITM erkennen. Dazu setzt Firefox im Problemfall die Option security.enterprise_roots.enabled auf true und versucht die Verbindung erneut. Funktioniert dies, lässt Firefox die Option auf true, ansonsten wird die Option auf false zurückgesetzt.

Da Firefox ESR 68 den Import von System-Zertifikaten standardmäßig zulässt, ist die MITM-Erkennung in Firefox ESR 68 standardmäßig deaktiviert.

Zur Aktivierung muss der folgende Schalter über about:config auf true geschaltet werden:

security.certerrors.mitm.auto_enable_enterprise_roots

Firefox ESR 68: Keine Service Workers

Service Workers bezeichnen einen Webstandard, der praktische Anwendungsfälle für moderne Webapplikationen ermöglicht. Firefox unterstützt Service Workers bereits seit Version 44. Aber wie schon in Firefox ESR 45, Firefox ESR 52 und Firefox ESR 60 werden Service Workers auch in Firefox ESR 68 standardmäßig wieder deaktiviert sein.

Zur Aktivierung muss der folgende Schalter über about:config auf true geschaltet werden:

dom.serviceWorkers.enabled

Firefox ESR 68: Keine Push-Benachrichtigungen

Ebenfalls werden Push-Benachrichtigungen in Firefox ESR 68 standardmäßig deaktiviert sein, da diese Service Workers als technische Voraussetzung haben.

Zur Aktivierung muss zusätzlich zum vorherigen Schalter der folgende Schalter über about:config auf true geschaltet werden:

dom.push.enabled

Nur in Firefox ESR 68: Deaktivierbare Signaturpflicht für Add-ons

Zum Schutz seiner Nutzer hat Mozilla eine Signaturpflicht für Add-ons in Firefox eingeführt, welche seit Firefox 43 standardmäßig aktiviert ist. Diese kann nur in Nightly-Builds sowie in der Developer Edition von Firefox deaktiviert werden, nicht in Beta- oder finalen Versionen. Die ESR-Version von Firefox 68 erlaubt auch in der finalen Ausführung die Deaktivierung der Signaturpflicht.

Zur Deaktivierung muss der folgende Schalter über about:config auf false geschaltet werden:

xpinstall.signatures.required

Achtung: Es ist aus Sicherheitsgründen nicht empfohlen, die Signaturpflicht für Erweiterungen zu deaktivieren. Wer seine Erweiterungen ausschließlich über addons.mozilla.org bezieht, findet außerdem in der Regel sowieso ausschließlich signierte Erweiterungen vor.

Nur in Firefox ESR 68: Zusätzliche Enterprise Policy

Seit Firefox 60 liefert Mozilla seine Enterprise Policy Engine aus. Damit ist es für Systemadministratoren möglich, Firefox für die Verteilung im Unternehmen vorzukonfigurieren, wofür bis einschließlich Firefox ESR 52 gerne der sogenannte CCK2 Wizard benutzt worden ist, der allerdings mit Firefox 57 und höher nicht kompatibel ist.

Die SearchEngines-Policy zum Konfigurieren der Suchmaschinen funktioniert ausschließlich in Firefox ESR.

Folgende Unterschiede aus Firefox ESR 60 existieren nicht mehr

Folgende Unterschiede existierten noch zwischen Firefox 60 und Firefox ESR 60, werden aber nicht mehr zwischen Firefox 68 und Firefox ESR 68 existieren:

Nicht mehr ESR-exklusive Enterprise Policies

In Firefox ESR 60 waren diverse Enterprise Policies ausschließlich Firefox ESR vorbehalten und konnten nicht in der Mainstream-Version von Firefox genutzt werden. Diese Einschränkung wurde für alle Enterprise Policies außer der SearchEngine-Policy (siehe oben) entfernt. Dies betrifft die Enterprise Policies zum Deaktivieren der Firefox-Updates, zum Deaktivieren der Updates für System-Erweiterungen, zum Deaktivieren von Telemetrie, zum Konfigurieren der Startseite, zum Konfigurieren der Suchleiste, zur Verwaltung von Erweiterungen, zum Blockieren von Websites, zur Konfiguration integrierter Authentifizierung, zum Überschreiben der Seite, welche beim ersten Firefox-Start erscheint, sowie zum Überschreiben der Seite, welche nach einem Firefox-Update erscheint.

Sonstiges Wissenswertes für Unternehmens-Administratoren

Zahlreiche neue Enterprise Policies und Enterprise Policy Generator

In Firefox 68 sind zahlreiche neue Einstellungen dazugekommen, welche via Enterprise Policy Engine konfiguriert werden können. Firefox 68 stellt das mit Abstand größte Update diesbezüglich seit Einführung der Enterprise Policy Engine dar.

Die von mir entwickelte Erweiterung Enterprise Policy Generator richtet sich an Administratoren von Unternehmen und Organisationen, welche Firefox konfigurieren wollen. Die Erweiterung bietet eine einfach verständliche Oberfläche, über welche alle verfügbaren Policies ganz einfach zusammengeklickt werden können, ohne dass Kenntnisse irgendeiner Art notwendig wären – inklusive Möglichkeit, Konfigurationen zu speichern oder für andere Systeme zu exportieren und zu importieren.

Download Enterprise Policy Generator für Firefox

Im Laufe der nächsten Wochen wird ein großes Update auf Enterprise Policy Generator 5.0 veröffentlicht werden, welches Unterstützung für alle neuen Enterprise Policies bringen wird. Dieses Update wird allerdings erst nach Veröffentlichung von Firefox 68 bereitstehen, aber in jedem Fall vor Ende der ESR-Übergangsphase mit Veröffentlichung von Firefox 70 und Firefox ESR 68.2.

Dokumentation für System-Administratoren

Der Enterprise Policy Generator macht die Konfiguration via policies.json plattformübergreifend zum Kinderspiel. Wer die Enterprise Policies aber lieber via Registry (Windows) oder .plist-Datei (Apple macOS) konfiguriert, findet hier die entsprechende Dokumentation.

Außerdem gibt es hier spezielle Hilfe-Seiten für die Administration von Firefox im Unternehmen.

MSI-Installer für Windows

Um System-Administratoren im Unternehmen das Anpassen und Verteilen von Firefox einfacher zu machen, bietet Mozilla jetzt auch anpassbare MSI-Installer für Firefox ESR auf Windows 7 und höher an.

MSI-Installer erlauben die Anpassung über eine MST-Datei und können über die auf Windows üblichen Deployment-Tools wie Active Directory oder Microsoft System Center Configuration Manager verteilt werden. Mozilla hat eine Dokumentation zu den MSI-Installern veröffentlicht.

Download MSI-Installer von Firefox ESR 68 (Link funktioniert ab Dienstag)

pkg-Installer für Apple macOS

Ähnlich zu den MSI-Installern für Windows arbeitet Mozilla an pkg-Installern für Apple macOS. Diese sind für Firefox ESR 68.0 noch nicht bereit, werden aber im Laufe der nächsten Monate folgen.

Dedizierte Profile pro Installation abschalten

Lesezeichen, Chronik, Erweiterungen, Passwörter, Einstellungen – diese und noch weitere Dinge werden in einem sogenannten Profil gespeichert. Verschiedene Firefox-Installationen nutzen bisher standardmäßig immer das gleiche Profil.

Seit Firefox 67 und damit auch ab Firefox ESR 68 nutzt der Mozilla-Browser dedizierte Profile pro Installation. Das heißt, dass wenn ein Nutzer mehrere Firefox-Installation hat, jede dieser Installationen ein eigenes Profil verwendet und damit standardmäßig nicht länger in allen Installationen automatisch die gleichen Lesezeichen, die gleiche Chronik etc. zur Verfügung stehen.

Gerade im Unternehmensumfeld kann dies unerwartet sein. Seit Firefox 68 kann dieses Feature über eine Umgebungsvariable abgeschaltet werden:

MOZ_LEGACY_PROFILES

Wie Umgebungsvariablen angelegt werden, ist der Dokumentation des jeweiligen Betriebssystems zu entnehmen.

Downgrade-Schutz abschalten

Ein anderes neues Feature von Firefox 67 und damit auch Firefox ESR 68 ist ein Downgrade-Schutz. Firefox verhindert, dass der Browser mit einem Profil gestartet wird, welches bereits mit einer neueren Firefox-Version genutzt worden ist. Auch dieses Feature kann seit Firefox 68 über eine Umgebungsvariable abgeschaltet werden:

MOZ_ALLOW_DOWNGRADE

Alternativ dazu kann Firefox mit dem folgenden Kommandozeilen-Argument gestartet werden:

--allow-downgrade

Der Beitrag Alles Wissenswerte zu Firefox ESR 68 inklusive Unterschiede zu Firefox 68 erschien zuerst auf soeren-hentzschel.at.

Von der Frage „Warum benutzt du Linux?“ wurde ich vor kurzem kalt erwischt. Und bei den Flurgesprächen geht es immer nur um „Windows oder Mac?“. Doch es gibt uns, die kleine Schar an glücklichen Linuxnutzern, die mit dem System wie selbstverständlich arbeitet, nichts vermisst oder Nachteile wegen diverser Vorteile in Kauf nimmt. Zeit für eine Antwort …

Auch im Jahr 2019 scheint man immer noch zu den Exoten zu gehören, wenn man auf PC oder Notebook ein Linux laufen hat. Trotz ehemaligem Ubuntu-Hype und dem so entstandenen leisen Gefühl, dass Linux zwischenzeitlich doch endlich mal im Mainstream angekommen war. Doch das scheint doch alles sehr subjektiv zu sein, denn im Real Life muss ich andere Linuxnutzer mit der Lupe suchen. Mit einer sehr großen. Mac und Windows, wohin man schaut. Auch viele Weggefährten von einst haben sich von Linux mittlerweile verabschiedet und sind mit Mac oder Windows glücklich geworden, sogar einige einst richtig eingefleischte Linux-Fans haben irgendwann die Segel gestrichen. Die Leute, die Wert auf Stil legen, haben ihren Mac – und die große Masse ist pragmatisch mit dem Arbeitstier Windows unterwegs, so mein Eindruck.

Der Exotenstatus wurde mir kürzlich einmal wieder so richtig bewusst, als es in einem Gespräch darum ging, dass Mac OS ja viel besser und nervenschonender wäre als Windows – Linux kam in dem Gespräch gar nicht vor. Mein Einwand, dass auch ein Blick auf Linux lohnen würde, wurde allseits mit einem Blick beantwortet, als hätte ein Obdachloser gerade von seinen vergoldeten Wasserhähnen im Badezimmer erzählt – eine Mischung aus überheblichem Mitleid, peinlicher Berührtheit und raschem Wegsehen schlug mir entgegen. „Den kann man doch nicht ernst nehmen“ oder einfach nur „Häh?“ schien in den Köpfen vorzugehen.

„Warum benutzt du eigentlich Linux?“

Neulich stellte mir ein Kollege dann die Frage: „Warum benutzt du eigentlich Linux?“ Ja, warum eigentlich? Ich hatte tatsächlich keine spontane Antwort parat. Das Pinguinbetriebssystem auf dem Desktop ist für mich so selbstverständlich und Normalität, dass ich über die Frage erst einmal nachdenken musste. Mit den Vor- und Nachteilen hatte ich mich gedanklich schon ewig nicht mehr befasst.

Die Frage stellt sich normalerweise einfach nicht. Als jahrelanger Linuxnutzer benutzt man eben Linux, um es einmal platt zu sagen. Dass das für das Umfeld befremdlich wirken kann und Stirnrunzeln auslöst, darauf ist man dann gar nicht mehr vorbereitet. Wahrscheinlich muss ich gewirkt haben, als würde ich darüber nachdenken, wie man dem Pöbel nun am besten erklärt, warum man auch in der Küche goldene Wasserhähne haben sollte.

Weil man sich nicht mit weniger zufriedengeben muss

Warum also tut sich ein Nichtprogrammierer dieses komplizierte, unübersichtliche Server- und Nerd-System auf dem Desktop an? Mittlerweile natürlich aus simpler Gewohnheit. Da sind all die kleinen Tricks und Helferlein, die genialen Dinge, aus denen man auch mit Bordmitteln richtig viel zaubern kann bei der alltäglichen Arbeit. Mit dem Mausrad die Arbeitsfläche wechseln. Programme automatisch auf unterschiedliche Desktops sortieren lassen. Dateisortierfunktionen individuell über Kontextmenüs organisieren. Fensterlisten, die jeden Übersichtsmodus schlagen. Verschlüsselte FTP-Verbindungen direkt in den normalen Dateimanager integrieren. Und so weiter und so fort. Wenn ich dann doch mal unter Windows oder Mac unterwegs bin, dann fehlen mir all die Handgriffe, die man sich mit den Linuxoberflächen einrichten kann, schmerzlich. Ja, man kann auch mit Windows und Mac angenehm arbeiten, aber persönlich fehlt mir dort immer der letzte Schliff. Es fühlt sich irgendwie immer etwas umständlicher an.

„Für Linuxnutzer ist die neueste Oberfläche immer nur ein Angebot“

Aber da muss es ja irgendwann auch mal Gründe gegeben haben, warum ich erstmals zu Linux gegriffen habe, bevor ich mich an all die Annehmlichkeiten gewöhnen konnte. Und die damaligen Gründe sind eigentlich immer noch dieselben, die mich auch heute noch von Linux überzeugen würden: Unabhängigkeit, Sicherheit und Sympathie.

Sicherheit meint dabei gar nicht mal so sehr die Sicherheit vor Viren und Verschlüsselungstrojanern, sondern vor allem die Sicherheit, dass ein Betriebsystemhersteller nicht einfach entscheiden kann, mit dem nächsten Update irgendwelche Funktionen zu streichen oder mir neue Arbeitsabläufe aufzuzwingen. Denn für einen Linuxnutzer ist die neueste Oberfläche immer nur ein Angebot. Wenn’s gefällt, wird es benutzt, und wenn es nicht passt, wird es passend gemacht oder einfach eine Alternative genommen – im Fall der Fälle sogar eine Weiterentwicklung einer schon aufgegebenen, veralteten Oberfläche. Wie das aktuelle Windows nach dem übernächsten Update aussieht, ist ungewiss, bei einer LTS-Linuxdistribution kann ich mich darauf verlassen, dass die Buttons und Knöpfe auch in den nächsten 5 Jahren noch an derselben Stelle sitzen.

Damit ist auch schon die Unabhängigkeit skizziert, die durch die Möglichkeit einer sehr individuellen Nutzung besteht: Im Gegensatz zu Mac und Windows bekomme ich nicht nur eine Oberfläche vorgesetzt, sondern kann die zu meinen Anforderungen passende wählen. Aber bereits beim Unterbau hat man die freie Wahl, man nimmt das für seine Zwecke geeignetste Linux: Soll der Rechner jahrelang einfach nur identisch funktionieren? Zack, ab zu Debian & Co. Darf’s der letzte Schrei sein? Ab zu Fedora oder einer Rolling-Release-Distribution. Will man was lernen und sein System wirklich verstehen? Arch & Co.sagen herzlich willkommen. Denn „das eine Linux“ gibt es gar nicht, es existieren viele Ausprägungen um den Betriebssystemkern herum. Wie bei einem Tuschkasten: blaue, rote, grüne, schwarze und violette Distributionen, ganz nach Geschmack und Einsatzgebiet.

Und dann gibt es da noch so Kleinigkeiten, die mich woanders einfach nerven. Windows knallt mir in schöner Regelmäßigkeit ein Fenster über den Workflow, um mir mitzuteilen, dass Updates bereitstehen. Das erfordert dann meistens einen Neustart, während dem ich „den Computer nicht ausschalten darf“. Bei meinem Linux blinkt ein kleines Symbol in der Leiste – und die Installation läuft im Hintergrund ohne Neustart im laufenden Betrieb. Und während ich bei Windows 10 die Privatsphäreeinstellungen durcharbeiten muss, gibt es so etwas bei Linux erst gar nicht – Ausnahmen bestätigen die Regel. Bei Linux habe ich das Gefühl, nicht belästigt zu werden und ein System zu benutzen, das in meinem Interesse arbeitet. Bei Windows habe ich oft das Gefühl, dass da noch andere Interessen eine Rolle spielen.

Wenn der WLAN-Drucker nicht will

Natürlich gibt es auch Dinge, die nicht so schön sind. Zum Beispiel dass man für manche Programme dann doch wieder ein Windows braucht, gerade im beruflichen Umfeld. Und manchmal gibt es auch Momente, in denen die Vielfalt nervt und man sich nicht schon wieder zwischen hundert Möglichkeiten entscheiden will. Manchmal will man sich einfach nicht zwischen 50 Desktopkonfigurationen entscheiden müssen, von denen doch keine alles richtig kann. Oder ganz banale Sachen wollen einfach nicht klappen, wie z. B. die Druckerverbindung über das WLAN. Und bei der Software kann man zwar aus einem riesigen Fundus wählen, doch bei kommerziellen Lösungen muss man auf Webanwendungen ausweichen oder letztlich eben doch Windows oder Mac OS booten. Warum dann nicht gleich komplett Windows oder Mac nehmen? Weil ich damit auch auf die Vorteile verzichten würde. Wenn Linux out of the box funktioniert (was es meistens tut), dann ist es simpler, als jeder Windows-Installer sein kann, intuitiv und aus einem Guss benutzbar, wie es Mac-OS-Nutzer gewohnt sind, aber ohne dabei auf bestimmte Hardware beschränkt zu sein. Wenn es mal nicht funktioniert, dann ist zugegebenermaßen Bastelei angesagt – doch entweder findet man die richtige Lösung schon um die Ecke oder kann in den vielen Foren den Quasi-Live-Support der versammelten Linuxnutzerschaft in Anspruch nehmen – oder probiert einfach eine andere Farbe aus dem Tuschkasten aus.

Linux ist Luxus

Ich gehöre sicher nicht zu den ideologischen Verfechtern freier Software, obwohl auch ich von ihr profitiere. Als Anwender gefallen mir auch Windows und Mac OS, und meine alltägliche Arbeit könnte ich auch damit gut erledigen. Insofern – und gerade weil ich manchmal auch zu anderen Systemen wechseln muss – ist Linux letztendlich ein Luxus, den ich mir bewusst leiste. Ein Luxus, der von dem Gefühl bestimmt wird, beim technisch richtigen System gelandet zu sein, das das Beste aus allen Welten nach Lust und Laune bietet … und das dabei nie langweilig wird und immer wieder Spaß macht, statt für Frust zu sorgen. Weil man auch als Anwender zu einem großen Teil Kontrolle über das System hat. Weil man damit viel mehr Individualität umsetzen kann. Dafür nimmt man dann gern in Kauf, argwöhnisch beäugt zu werden, wenn man den Pinguin auf dem Schirm hat, obwohl man weder Server aufsetzt noch Anwendungen entwickelt. Als Feld-Wald-und-Wiesen-Anwender bleibe ich wohl ein Exot. Aber das aus Überzeugung.

Unter Linux existieren eine Reihe von Nutzern. So nutzt der Nutzer des Systems einen Nutzer und auch viele andere Dienste legen Nutzer an, wie z.B. www-data. Wenn für einen Dienst ein Nutzer angelegt werden soll, so könnte der Nutzer wie folgt angelegt werden:

adduser example

Damit würde ein vollwertiger Nutzer mit einem Passwort erzeugt werden. Soll nun ein Nutzer ohne Passwort erzeugt werden, so muss der adduser-Befehl um eine Option erweitert werden:

adduser --disabled-password example

Damit wird ein Nutzer ohne Passwort angelegt. Trotzdem wäre es noch möglich sich über diesen Nutzer anzumelden. Wenn dies nicht gewünscht ist, kann der Nutzer dementsprechend angelegt werden:

adduser --disabled-login example

Dem Nutzer ist es damit nicht mehr möglich sich einzuloggen. Allerdings kann durchaus mittels su in den Kontext des Nutzers gewechselt werden, z.B. um im Kontext des Nutzers einen Dienst zu installieren.

Der Unterschied zwischen den beiden Optionen ist, dass die Option disabled-password nur das Passwort deaktiviert, aber Logins über ein SSH-Schlüsselpaar zulassen würde. Bei der Option disabled-login ist dies nicht der Fall. Hier ist kein Login mehr möglich. Rückgängig gemacht werden kann die Beschränkung des Nutzers, indem für den Nutzer ein Passwort gesetzt wird.

Seit einigen Jahren verwenden wir Zammad als Support- bzw. Helpdesk-Software in unserer Schule. Wir sind damit sehr zufrieden, denn Zammad bietet viele Features und ein angenehm zu bedienende Benutzeroberfläche. Vor einiger Zeit mussten wir unseren Server umziehen und somit auch unsere Zammad-Installation. In diesem Artikel möchte ich kurz zeigen, wie man Zammad sichern und wiederherstellen kann.

Zammad sichern

Zammad bietet von Haus aus ein Backup-Skript, welches aber standardmäßig deaktiviert ist. Man kann das Skript dazu benutzen, um regelmäßige Backups anzulegen. Es befindet sich unter /opt/zammad/contrib/backup/. Das Backup-Skript greift auf eine Konfigurationsdatei zu, in der alle wichtigen Einstellungen vorgenommen werden. Diese Datei muss man zuerst umbenennen:

$ mv /opt/zammad/contrib/backup/config.dist /opt/zammad/contrib/backup/config

Anschließend öffnet man die Datei und kann einige wenige Dinge einstellen:

$ nano /opt/zammad/contrib/backup/config 

...
BACKUP_DIR='/var/tmp/zammad_backup'
HOLD_DAYS='10'
DEBUG='no'

BACKUP_DIR legt fest, wohin die Backups gespeichert werden sollen. Das Verzeichnis muss existieren! HOLD_DAYS gibt an, wie lange ein bzw. wie viele Backup(s) aufbewahrt werden sollen.

Nun kann man das Backup-Skript ausführen:

$ cd /opt/zammad/contrib/backup
$ ./zammad_backup.sh

Das Skript legt zwei Archive an (Datenbanksicherung und Zammad-Ordner), die sich nun im konfigurieren Backup-Ordner befinden.

Hinweis: Wenn man eine Installation migrieren möchte, ist es sinnvoll, Zammad vorher anzuhalten und erst dann das Backup zu erstellen. Das spielt aber nur bei größeren Installationen eine Rolle.

Zammad wiederherstellen

Wenn man ein Backup auf dem gleichen Host wiederherstellen möchte, kann man das mit dem Wiederherstellungsskript erledigen:

$ cd /opt/zammad/contrib/backup
$ ./zammad_restore.sh

Fertig 🙂

Wenn man allerdings eine Zammad-Installation umziehen möchte (Migration, Neuinstallation), gibt es einige Dinge zu beachten:

• Zammad muss installiert sein (inklusive Elasticsearch)
• die Zammad-Version sollte gleich oder höher sein (als die vom Backup)
• es sollte die gleiche Datenbank verwendet werden (ein Wechsel ist wohl möglich, aber sehr aufwändig, da die Daten abgepasst werden müssen).
• Es sollte genügend freier Speicherplatz vorhanden sein (ca. 2x so viel wie die Größe des Backups)

Wenn alle Bedingungen erfüllt sind, muss man zuerst die Konfiguration auf dem Zielsystem aktivieren:

$ mv /opt/zammad/contrib/backup/config.dist /opt/zammad/contrib/backup/config

Danach die Backupdateien in den konfigurierten Backup-Ordner kopieren (mit cp oder wenn man LXD-Container verwendet mit lxc file push/pull) und letztendlich das Wiederherstellungsskript laufen lassen:

$ cd /opt/zammad/contrib/backup
$ ./zammad_restore.sh

Weitere Informationen finden sich in der offiziellen Dokumentation.

Fazit

Zammad bringt einen einfachen Sicherungs- und Wiederherstellungsmechanismus mit, der zuverlässig funktioniert. Wer seine Zammad-Installation nicht anderweitig sichert, kann für das Backup-Skript auch einen Cron-Job einrichten, um regelmäßig ein Backup zu erstellen.

 

1 Kommentar

Der Beitrag Zammad sichern und wiederherstellen erschien zuerst auf .:zefanjas:..

New Tab Override ist eine Erweiterung zum Ersetzen der Seite, welche beim Öffnen eines neuen Tabs in Firefox erscheint. Die beliebte Erweiterung mit mehr als 100.000 aktiven Nutzern ist nun in Version 14.3 erschienen und erscheint ab sofort als Empfehlung von Mozilla.

Was ist New Tab Override?

Seit Firefox 41 ist es nicht länger möglich, die Seite anzupassen, welche beim Öffnen eines neuen Tabs erscheint, indem die Einstellung browser.newtab.url über about:config verändert wird. Da diese Einstellung – wie leider viele gute Dinge – in der Vergangenheit von Hijackern missbraucht worden ist, hatte sich Mozilla dazu entschieden, diese Einstellung aus dem Firefox-Core zu entfernen. Glücklicherweise hat Mozilla nicht einfach nur die Einstellung entfernt, sondern gleichzeitig auch eine neue API bereitgestellt, welche es Entwicklern von Add-ons erlaubt, diese Funktionalität in Form eines Add-ons zurück in Firefox zu bringen.

New Tab Override war das erste Add-on, welches diese Möglichkeit zurückgebracht hat, und ist damit das Original. Mittlerweile hat New Tab Override mehr als 100.000 aktive Nutzer, wurde im Dezember 2016 sogar auf dem offiziellen Mozilla-Blog vorgestellt und schon mehrfach im Add-on Manager von Firefox beworben.

Download New Tab Override (WebExtension) für Firefox

Die Neuerungen von New Tab Override 14.3

Wie schon beim letzten Update auf Version 14.2 handelt es sich auch bei New Tab Override 14.3 primär um ein Wartungsupdate, welches keine neuen Features bringt. Stattdessen wurde die Checkbox entfernt, um den Fokus bei neuen Tabs auf die Webseite statt die Adressleiste zu legen. Aufgrund einer Änderung in Firefox 61 war diese Option bereits seit einiger Zeit wirkungslos, der Fokus liegt seit Firefox 61 immer auf der Webseite.

New Tab Override 14.3 wurde mit web-ext 3.1.0 (vorher: 2.9.3) erstellt und ein Rechtschreibfehler in der deutschen Übersetzung wurde korrigiert.

Von Mozilla empfohlen

Mozilla wird in Kürze offiziell sein neues Programm empfohlener Erweiterungen starten. New Tab Override ist eine von ungefähr hundert Erweiterungen, welche Mozilla ausgewählt hat. Im neuen Add-on Manager, den Mozilla mit Firefox 68 ausliefert, erscheint ab dieser Version daher eine besondere Kennzeichnung für New Tab Override.

Der Beitrag New Tab Override 14.3 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Ein kleiner Tipp für alle vim-Nuzter, die oft mit YAML-Dateien wie z.B. Ansible-Playbooks arbeiten: in diesen Dateien ist es oft entscheidend, dass die Einrückung gleichmäßig ist. Durch die spezielle Syntax mit dem Auflistungszeichen „-“ ist es schnell möglich, durcheinander zu kommen.

Abhilfe schafft die Option cursorcolumn (Doku), die die aktuelle Spalte hervorhebt. Aktiviert werden kann dieser Modus durch

:set cursorcolumn

bzw. kürzer

:set cuc

Die Deaktiviertung erfolgt über

:set nocursorcolumn

bzw. analog :set nocuc.

Nachdem ich nun einige Wochen Ubuntu 18.04 mit der Oberfläche Gnome3 nutze wird es Zeit mal ein bisschen zu schauen…. wie fühlt es sich an, und wie sinvoll ist der Wechsel von Unity gewesen.

Die ersten Tage war das Erlebnis wirklich gut, es fühlte sich alles neu an, und hat Spaß gemacht es zu erkunden. Wenn ich mir bisher einen neuen PC gekauft habe, aber mit dem gleichen Betriebssystem wir vorher hat sich nie das Gefühl von “wirklich neu” eingestellt. Und auch wenn man bei dem Betriebssystem nur Modellpflege betreibt…. der Unterschied zwischen 14.04 und 16.04 ist eher im Unterbau als in der Oberfläche.
Aber wenn man ein System mit einer neuen Oberfläche installiert fühlt es sich an wie ein neuer PC.

Positiv an der neuen Oberfläche finde ich zunächst das die Benachrichtigungen gespeichert werden und man sie sich immer wieder ansehen kann. Und auch der Dateimanager wirkt etwas aufgeräumter. Wenn ich allerdings etwas kopiere oder packe, dann kommt statt eines Fortschrittsbalken ein kleines Kreisdiagramm in der Fensterleiste von Nautilus. Das fand ich etwas verwirrend und habe nicht sofort den Sinn begriffen. Ein Statusfenster was mehrerer Kopiervorgänge zusammenfasst und diese auch pausieren oder abbrechen lässt war in meinen Augen der Höhepunkt der Evolution. Nun handelt es sich um einen Rückschritt, nur damit es moderner wirkt.
Was mir noch gefällt ist das die Bedienung sich ein wenig an Smartphones und Tablets orientiert und man so mehr oder weniger intuitiv weiß wo man hinklicken muss und das sich z.b. hinter 3 Balken ein Menü versteckt.

Bei den Nachteilen gibt es aber einige Punkte die mich sehr stören. Zunächst finde ich die Anordnung der Symbole zum Speichern, Drucken etc ist völlig unübersichtlich geworden und selbst nach Wochen mit dem Desktop muss ich jedesmal aufs neue Suchen. Das erinnert mich an Windows 10 wo ich immer wieder aufs neue anfange zu Suchen wenn ich eine Funktion brauch. Das Design der Oberfläche hat sich von Gnome2 ins negative Entwickelt und ich denke hier hat eine federführende Hand gefehlt. Ein weiterer grosser Nachteil ist das ich mit Nautilus nicht mehr meine Samba Freigaben (auf Server 16.04) ohne Probleme öffnen kann. Alternativ bin ich im Moment auf SSH umgestiegen was aber sicher nicht im Sinn des Erfinders ist. Ich vermute das die Ursache eine technische in den verschiedenen Samba Protokollversionen liegt und sicher auch zu lösen ist. Von einem modernem Desktop System erwarte ich aber das die Netzwerkumgebung mir die SMB Shares sofort öffnet. Der Wegfall von Synaptic finde ich auch schade da man mit Ubuntu-Software nur grafische Programme installiert bekommt und alternativ auf die Shell-Ebene muss. Da war Synaptic einfach besser. Von vielen wurde als negativ angesehen das Canonical mit Unity eine weitere Fragmentierung bei den Benutzeroberflächen fördert und viele fanden gut das Ubuntu nun wieder auf Gnome setzt.
Finde ich ist Augenwischerei denn in anderen Ecken schreitet die Fragmentierung munter voran und das völlig unkoordiniert. Ich sage nur Cinnamon oder Mate Desktop oder Budgie.

Abschliessend kann ich sagen das es durchaus Gründe gibt Ubuntu 18.04 zu nutzen, vor allem da alle Programme wieder in aktuellen Versionen vorliegen.
Aber im direkten Vergleich Ubuntu 16.04 mit Unity die definitiv bessere Version ist.

Mit Firefox 68 wird Mozilla eine vollständige Neu-Implementierung der Adresseleiste ausliefern, welche unter dem Namen QuantumBar entwickelt worden ist. Im nächsten Schritt wird die Adressleiste ein neues Design erhalten. Dieser Artikel gibt eine erste Vorschau.

Die Adressleiste, welche in Firefox auch Awesome Bar genannt wird, ist eine der wichtigsten Komponenten eines jeden Browsers. Und eben jene Komponente hat Mozilla von Grund auf neu und mit Webtechnologie anstelle von XUL und XBL entwickelt. Die Neu-Implementierung hört auf den Namen QuantumBar, passend zu Firefox Quantum, wie sich Firefox seit Firefox 57, dem größten Firefox-Release aller Zeiten, nennt, und ist ab Firefox 68 standardmäßig aktiviert.

Sowohl optisch als auch funktional ist die QuantumBar nur schwer von der alten Adressleiste zu unterscheiden, was in diesem Schritt auch ein ausdrückliches Ziel war. Der Nutzer wird in Firefox 68 vermutlich also trotz der großen Änderungen unter der Haube keinen Unterschied bemerken.

Darauf aufbauend plant Mozilla für ein späteres Update Änderungen der Adressleiste, welche auffallen werden. Zunächst sieht die Adressleiste dabei wie gewohnt aus. Beim Fokussieren der Adressleiste oder Öffnen eines neuen Tabs vergrößert sich diese jedoch.

Das Adressleisten-Popup geht nicht mehr über die gesamte Fensterbreite, sondern ist nur noch so breit wie die Adressleiste selbst. Auch die Darstellung der Suchmaschinen-Icons ist verändert und der neue Text an dieser Stelle macht deutlicher, dass ein Ändern der Suchmachine hier nur die Suchmaschine für die aktuelle Suche ändert.

Darüber hinaus sind weitere Verbesserungen geplant. So soll in den Adressleisten-Vorschlägen weiterhin der eingegebene Text in den Ergebnissen fett hervorgehoben werden, bei Vorschlägen von Suchmaschinen soll dies jedoch umgekehrt werden und in Zukunft der Teil hervorgehoben werden, der vorgeschlagen wird.

Außerdem plant Mozilla diverse Experimente auf Basis des neuen Designs. Das heißt, dass nicht zwangsläufig jede der weiteren Ideen für alle Nutzer umgesetzt werden wird, sondern dies vom Verlauf der jeweiligen Experimente abhängt.

Zu diesen Experimenten gehört unter anderem die Entfernung des Suchfelds auf der Firefox-Startseite, welches durch das neue Verhalten der Adressleiste redundant ist.

Ein anderes Experiment ist das Vorschlagen der meistbesuchten Webseiten, welche sonst auch auf der Firefox-Startseite erscheinen, wenn man in die Adressleiste klickt, statt gar nichts anzuzeigen, wie es aktuell der Fall ist.

Ein weiteres Experiment integriert die Such-Shortcuts besser in die Adressleiste.

Schließlich gibt es noch die Idee, neue Nutzer per Tipp auf die Suchfunktion in der Adressleiste hinzuweisen, oder auch, wenn der Nutzer die Suchmaschine per URL aufruft.

Der Beitrag Das neue Design der QuantumBar-Adressleiste von Firefox erschien zuerst auf soeren-hentzschel.at.

Mit Firefox 67 hat Mozilla den Content-Blocker von Firefox um ein optionales Blockieren von Cryptomining erweitert. Ab Firefox 69 ist der neue Schutz standardmäßig aktiviert.

In Firefox 67 hat Mozilla seinen integrierten Content-Blocker um die Möglichkeit erweitert, Cryptomining– sowie Fingerprinting-Scripts zu blockieren. Dazu muss entweder die Datenschutz-Voreinstellung „Streng“ oder „Benutzerdefiniert“ ausgewählt werden.

Während Mozilla im Hintergrund an größeren Privatsphäre-Verbesserungen wie Social Tracking als weitere Kategorie für den Content-Blocker, ein neues Tracking-Schutz-Panel, einen Schutz-Bericht sowie Firefox Proxy arbeitet, erweitert Mozilla zunächst einmal den Schutz, den standardmäßig jeder Nutzer erhält.

So werden seit Firefox 67.0.1 Tracking-Cookies von Drittanbietern standardmäßig blockiert und ab Firefox 69 wird der Cryptomining-Schutz auf die Standard-Liste gesetzt und ist damit für jeden Nutzer aktiv, ohne dass dieser erst durch den Nutzer aktiviert werden muss.

Der Beitrag Firefox 69: Cryptomining-Blocker wird standardmäßig aktiviert erschien zuerst auf soeren-hentzschel.at.

Um den digitalen Fingerabdruck von Firefox-Nutzern zu reduzieren, wird Mozilla den User-Agent von Firefox um die Angabe der CPU-Architektur reduzieren.

Browser senden bei jedem Seitenaufruf einen sogenannten User-Agent an die jeweilige Website. Dieser beinhaltet einfache Informationen über das verwendete Betriebssystem, den Browser sowie die CPU-Architektur.

Was die CPU-Architektur betrifft, unterscheidet Firefox derzeit zwischen 64-Bit-Firefox auf 64-Bit-Betriebssystem, 32-Bit-Firefox auf 32-Bit-Betriebssystem sowie 32-Bit-Firefox auf 64-Bit-Betriebssystem. Letzteres wird mit Firefox 69 entfallen. Mozilla hat bereits eine Änderung in der Nightly-Version von Firefox implementiert, womit in diesem Szenario die gleiche Angabe wie bei einem 64-Bit-Firefox auf einem 64-Bit-Betriebssystem verwendet wird. Konkret bedeutet dies für Nutzer von Windows, dass aus der Angabe WOW64 ein Win64 wird, und für Nutzer von Linux, dass aus der Angabe Linux i686 on x86_64 ein Linux x86_64 wird. Die 32-Bit- sowie die AArch64-Version von Firefox für Windows haben bereits keine Architektur-Angabe im User-Agent.

Diese Änderung wird als risikolos bewertet, weswegen die Änderung direkt erfolgte und hinter keiner versteckten Einstellung implementiert worden ist. Geplant ist allerdings, die Angabe der CPU-Architektur komplett aus dem User-Agent von Firefox für Windows und Linux zu entfernen. Auch die Eigenschaften navigator.oscpu sowie navigator.platform sollen entsprechend angepasst werden und diese Information nicht länger beinhalten. Das gilt ebenso für Android.

Diese vollständige Entfernung der CPU-Architektur besitzt aufgrund von User-Agent-Sniffing auf Webseiten ein größeres Risiko, weswegen hier noch nicht klar ist, ob die Änderung mit Firefox 69 oder erst später in Kraft treten wird.

Mit der Änderung reduziert Mozilla den digitalen Fingerabdruck seiner Nutzer, da standardmäßig weniger Informationen über das System des Nutzers preisgegeben werden. Grundsätzlich sind Änderungen des User-Agents aus Gründen der Web-Kompatibilität immer eine schwierige Angelegenheit, weil viele Websites auf Basis des User-Agents Entscheidungen treffen und nicht unbedingt jede Erkennung des User-Agents besonders flexibel umgesetzt ist. Darum erfolgen grundlegende Änderungen des User-Agents selten und immer mit Bedacht.

Der Beitrag Mozilla entfernt Architektur-Information aus User-Agent von Firefox erschien zuerst auf soeren-hentzschel.at.

Mozilla verbessert weiter die Eigenschaften von Firefox als Browser mit besonderem Privatsphäre-Schwerpunkt. Ganz aktuell arbeitet Mozilla an einem verbesserten Panel für den Tracking-Schutz in der Adressleiste von Firefox, einem umfassenden Schutz-Bericht und bringt außerdem Content-Blocking für Elemente sozialer Netzwerke. Dazu deutet sich mit Firefox Proxy ein weiteres Privatsphäre-Produkt unter der neuen Firefox-Dachmarke an.

Mozilla treibt seine Bestrebungen weiter voran, Firefox zu einem Browser mit noch besserem Privatsphäre-Schutz zu machen. Erst in Firefox 67 hat die Content Blocking-Fähigkeiten von Firefox um Fingerprinting und Cryptomining erweitert, seit Firefox 67.0.1 kurz darauf werden Drittanbieter-Tracking-Cookies standardmäßig blockiert. Und jetzt arbeitet Mozilla an einer wahren Offensive weiterer Verbesserungen rund um die Privatsphäre der Nutzer.

Wie immer ist bei Mockups der obligatorische Hinweis zu bringen, dass diese nicht zwangsläufig das finale Produkt repräsentieren müssen – weder, was das Design betrifft, noch funktional.

Neues Tracking-Schutz-Panel

Firefox-Nutzer kennen vermutlich das Symbol mit dem „i“ in der Adressleiste. Darüber sind Informationen zur Verbindung, zum Content Blocking sowie zu den Website-Berechtigungen zugänglich.

Mozilla sieht in der bisherigen Darstellung verschiedene Probleme. Zum einen werden nach Ansicht von Mozilla zu viele Informationen auf wenig Raum angezeigt, um sinnvoll damit zu interagieren. Der Begriff Content-Blocking sei zu unklar, es ist nicht eindeutig erkennbar, welcher Schutz aktiviert ist und welcher nicht, außerdem sei die Mischung aktivierter und deaktivierter Maßnahmen verwirrend.

Aus diesem Grund plant Mozilla eine Entkoppelung der Privatsphäre- von den anderen Elementen. Das Symbol mit dem „i“ wird aus der Adressleiste entfernt, dafür erscheint das Schild-Symbol, welches sonst nur bei aktiven Schutzmaßnahmen angezeigt wird, in Zukunft permanent in der Adressleiste.

Während die Informationen zur Verbindung sowie Berechtigungen weiterhin über das Schloss-Symbol erreichbar sind und nicht länger Informationen zum Content-Blocking beinhalten, zeigt das Schild-Icon nur noch Informationen zum Content-Blocking an.

Das Content Blocking-Feature als Ganzes wird umbenannt in Tracking-Schutz, es ist klar ersichtlich, ob der Schutz für die Seite aktiv ist oder nicht, blockierte sowie nicht blockierte Elemente sind klar voneinander getrennt. Das neue Panel zeigt außerdem die Anzahl der in der aktuellen Woche blockierten Elemente sowie einen Link zu einem neuen Schutz-Bericht, dazu später mehr.

Gab es auf einer Seite keine blockierbaren Elemente, soll dies bald schöner dargestellt werden.

Für die spätere Zukunft ist es auch denkbar, innerhalb des Panels bestimmte Features oder Neuerungen visuell hervorzuheben. Ein solcher Hinweis verschwindet automatisch, wenn der Nutzer diesen einmal gesehen hat, kann durch Klick auf das Info-Symbol aber jederzeit wieder geöffnet werden.

Social Blocking

Was auf diesen Bildern neben den bereits vorgestellten Änderungen zu sehen war, ist eine neue Kategorie für den Tracking-Schutz, nämlich Social Media Trackers. Social Tracking erlaubt sozialen Netzwerken wie Facebook das Tracking über Widgets wie „Gefällt mir“-Buttons auf Webseiten, selbst wenn der Nutzer überhaupt nicht auf dem jeweiligen Netzwerk registriert ist. Dieser neue Schutz blockiert solche Elemente.

Manchmal ist es doch notwendig, Social Tracker zumindest temporär zu erlauben, beispielsweise für Login-Funktionen auf Webseiten. Wenn der Nutzer also mit einer Website interagiert und dabei ein Element eines Social Trackers aktiviert wird, soll Firefox dies auf Wunsch optional erlauben.

In den Einstellungen von Firefox soll Social Tracking als eigenständiger Bereich, unabhängig von der allgemeinen Konfiguration Standard, Streng sowie Benutzerdefiniert angezeigt werden.

Schutz-Bericht

Ein komplett neues Feature, an welchem Mozilla bereits aktiv arbeitet, ist der Schutz-Bericht. Hier visualisiert Mozilla die Anzahl blockierter Elemente, getrennt nach Wochentagen, mit Unterscheidung der einzelnen Blocking-Kategorien.

Weiterhin bewirbt Mozilla hier den neuen Social Tracker-Schutz, seinen Passwort-Manager Firefox Lockwise sowie seinen Dienst Firefox Monitor, welcher über Datenlecks informiert.

Ist der Nutzer für Firefox Monitor angemeldet, dann erscheinen an dieser Stelle Informationen über die Anzahl der überwachten E-Mail-Adressen, die Anzahl der bekannten Datenlecks, welche Informationen beinhalten, die einen betreffen, sowie die Anzahl der Passwörter, die betroffen sind. Außerdem ist ein Hinweis darauf zu erkennen, dass Firefox Monitor automatisch täglich nach neuen Datenlecks scannen kann.

Wird Firefox Lockwise genutzt, erscheinen hier die Anzahl der gespeicherten Passwörter, die Anzahl doppelter Passwörter sowie die Anzahl der Geräte, mit denen synchronisiert wird.

Firefox Proxy

Die Mockups zum Schutz-Bericht zeigen ein weiteres Produkt, welches ein Logo besitzt, das sich perfekt in die neue Firefox-Dachmarke einfügt und daher als glaubwürdige Ergänzung des Firefox-Portfolios erscheint: Firefox Proxy.

Detaillierte Informationen sind dazu öffentlich noch keine bekannt, jedoch zeigt das Mockup, dass es sich dabei um eine Erweiterung für Firefox handelt. Firefox Proxy soll die Sicherheit öffentlicher WLANs erhöhen und den Nutzer vor Hackerns schützen, wie es in der Kurzbeschreibung heißt.

Ein Zeitpunkt für die Veröffentlichung der hier vorgestellten Neuerungen ist nicht bekannt. Wahrscheinlich ist, dass sich die Verbesserungen über mehrere Firefox-Versionen hinweg erstrecken.

Der Beitrag Firefox: Neues Tracking Schutz-Panel, Schutz-Bericht, Social Blocking und Firefox Proxy kommen erschien zuerst auf soeren-hentzschel.at.