seeseekey.net - Invictus Deus Ex Machina

Gogs ist ein Git-Service welcher eine ähnliche Funktionalität wie der bekannte Dienst GitHub zur Verfügung stellt. Standardmäßig läuft der Dienst auf dem Port 3000. Möchte man ihn über die normalen Ports für HTTP (80) bzw. HTTPS (443) erreichbar machen, kann man hierfür einen Reverse Proxy nutzen. Dafür eignen würde sich zum Beispiel Nginx, der im ersten Schritt auf dem Server installiert werden muss:

apt-get install nginx

Anschließend wird die Konfiguration angelegt:

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.com;

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

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

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

    server_name example.com;

    client_max_body_size 500m;

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

Nachdem die Konfiguration für Nginx hinterlegt ist, wird die Standardkonfiguration entfernt und ein symbolischer Link für die neue Konfiguration erstellt. Anschließend wird Nginx neugestartet, damit die geänderte Konfiguration wirksam wird:

rm /etc/nginx/sites-enabled/default
ln -s /etc/nginx/sites-available/example /etc/nginx/sites-enabled/example
service nginx restart

Nach der Anpassung der Nginx-Konfiguration, muss die app.ini (sie befindet sich im gogs/custom/conf/ Ordner) von Gogs angepasst werden und dort die neue ROOT_URL ohne zusätzlichen Port angegeben werden. Anschließend kann auf Wunsch, per Firewall, der Port 3000 für Zugriffe von außen gesperrt werden.

Einführung in die uncomplicated firewall

Wenn man einen eigenen Server betreibt und die mail()-Funktion von PHP benutzen möchte, so benötigt man auf dem Server einen Mail Transfer Agent kurz MTA. Über diesen MTA versucht die mail()-Funktion ihre Mails zu versenden. Ist kein MTA auf dem System installiert, schlägt der Versand von Mails fehlt. Nun ist es bei vielen Servern nicht gewünscht, einen vollwertigen MTA zu installieren. Abhilfe schafft hier der Nullmailer welcher mittels:

apt get install nullmailer

installiert werden kann. Nullmailer leitet die Mails, an einen Mailserver der Wahl weiter. Dazu muss er konfiguriert werden:

nano /etc/nullmailer/remotes

In dieser Datei wird der Mailserver mit seiner Konfiguration eingestellt:

mail.example.com smtp --port=587 --starttls --user=nutzername --pass=geheim

Nutzt man einen Mailserver mit einem selbstsignierten Zertifikat benötigt eine weitere Option:

mail.example.com smtp --port=587 --starttls --user=nutzername --pass=geheim --insecure

Anschließend sollte der Mailversand ohne Probleme funktionieren. Schlägt er trotzdem fehl, findet man genauere Informationen im Syslog unter /var/log/syslog.

In den letzten Tagen gab es zwei Artikel zum Thema Counter-Strike 1.6 Server:

In diesem Artikel, der die Fortsetzung der obigen Artikel darstellt, soll es um die Installation von Bots auf dem Counter-Strike 1.6 Server gehen. Damit kann auch gespielt werden wenn auf Server mal nicht so viel los ist. Zur Installation des POD-bot wird wieder das Metamod benötigt, welches im letzten Artikel im Zusammenhang mit dem AMX Mod installiert wurde. Zur Installation laden wir den POD-bot herunter und verschieben ihn in den addons-Ordner:

wget https://seeseekey.net/wp-content/uploads/2017/04/podbot.zip
unzip podbot.zip
rm podbot.zip
mv podbot /home/counterstrike/game/cstrike/addons/podbot

Anschließend muss der POD-bot Mod aktiviert werden. Dazu editieren wir die Datei /home/counterstrike/game/cstrike/addons/metamod/plugins.ini und fügen dort folgendes hinzu:

; POD-bot
win32 addons/podbot/podbot_mm.dll
linux addons/podbot/podbot_mm_i386.so

Damit ist die Grundinstallation des POD-bot abgeschlossen. In der Datei /home/counterstrike/game/cstrike/addons/podbot/podbot.cfg kann der POD-bot nun im Einzelnen konfiguriert werden. Besonders interessant sind dabei folgende Optionen:

# passwordkey - need set as setinfo to get access to the main podbot menu.
# usage (in the below example You may need to write Your-own passwordkey
# string instead default _pbadminpw - if You changed it):
# setinfo _pbadminpw "your_password"
pb_passwordkey "_pbadminpw"

# Set the password to have access to the podbot menu on DS by 'pb menu'
# console command typed in client's admin PC or called from the binded key.
# Example of bind on Your client PC:
# bind "=" "pb menu"
pb_password "your_password"

# Switches to on/off Botchatting. <0|1>. Default is 1.
pb_chat 1

# Set the below value to 1 to enable auto kill bots if all human players
# are dead already. <0|1>. Default is 0.
pb_autokill 0

# Set the below value to delay (in seconds) autokill bots if
# autokill function is enabled (above). Default is 45.
pb_autokilldelay 45

# These lines below are adding automatically the bots to the server when
# the new game is created on the listenserver or the dedicated server
# is starting.
# As many such lines like "pb add" is here as many bots will be added
# to the server (unless You will not exceed pb_maxbots setting).
pb add 100
pb add 100

Mit dem Kommando:

setinfo _pbadminpw "your_password"

weist man sich gegenüber dem POD-bot aus und erhält administrative Rechte und kann anschließend das Kommando:

pb menu

in der Counter-Strike-Konsole nutzen um die Bots zu konfigurieren.

Vor ein paar Tagen beschrieb ich wie man einen Counter-Strike 1.6 Server unter Ubuntu aufsetzt. Dem Server in der Vanila-Version fehlen allerdings einige Komfort-Features wie z.B. das Voten von Maps. Möchte man diese Funktionalität nutzen, benötigt man ein entsprechendes Mod. Hier empfiehlt es sich das AMX Mod zu installieren. Dieses benötigt den Metamod, der allerdings direkt im Paket enthalten ist. Im ersten Schritt muss der Mod auf dem Server installiert werden. Dazu wechselt man auf das Home-Verzeichnis des Servernutzers und gibt dort folgende Kommandos ein:

mkdir amxmod
cd amxmod
wget http://www.amxmod.net/amxfiles/amxmod_2010.1/amxmod_2010.1_cs-en.zip
unzip amxmod_2010.1_cs-en.zip 
rm amxmod_2010.1_cs-en.zip
cp * /home/counterstrike/game/cstrike/ -r
cd ..
rm -r amxmod/

Mit den Kommandos wird der Mod heruntergeladen und an die richtige Stelle verschoben. Anschließend muss die Pluginliste für das Metamod aktiviert werden:

mv /home/counterstrike/game/cstrike/addons/metamod/sample_plugins.ini /home/counterstrike/game/cstrike/addons/metamod/plugins.ini

Damit das AMX Mod erkennt wer im Spiel über administrative Rechte verfügt, muss die users.ini-Datei bearbeitet werden. Diese befindet sich im Ordner /home/counterstrike/game/cstrike/addons/amx/config/users.ini. Der einfachste Weg den Administrator zu definieren ist es die Steam-ID des jeweiligen Spielers zu benutzen. Zur Ermittlung der Steam-ID des Spielers öffnet man im Spiel mittels der ^-Taste die Konsole und gibt dort den Befehl status ein. Anschließend kann der Nutzer der users.ini-Datei hinzugefügt werden:

"STEAM_0:1:12345"    ""       "abcefijmnopqrstu" "ce"

Dabei muss nur die Steam-ID im vorderen Teil geändert werden. Danach ist die Grundkonfiguration erledigt und der Server kann gestartet werden. Damit die Mods aktiviert werden, muss ein neuer Parameter beim Start übergeben werden:

-dll addons/metamod/dlls/metamod.so

In der vollständigen Kommandozeile könnte dies dann so aussehen:

./hlds_run -game cstrike +map de_dust2 +maxplayers 20 -dll addons/metamod/dlls/metamod.so

Sobald der Server hochgefahren ist kann in der Konsole des Spieles mittels des Befehls:

meta list

überprüft werden ob das Plugin erfolgreich gestartet wurde.

Der AMX Mod wurde erfolgreich installiert

In der Standard-Installation verfügt der AMX Mod über 76 Befehle, welche für den Betrieb und die Steuerung des Servers genutzt werden können:

1: amx_help - displays this help
2: amx_langmenu - displays language menu
3: amx_language [|save] - displays/sets/saves language
4: amx_listmaps - lists maps that can be nominated
5: amx_who - displays who is on server
6: say /currentmap - displays current map (say)
7: say /ff - displays friendly fire status (say)
8: say /flop15 - displays worst 15 players (MOTD)
9: say /flop15new - displays worst 15 players (MOTD)
10: say /hp - displays info. about your killer (chat)
11: amx_csayy [color]  - sends center hud message to all players - anonymous
12: amx_flicksay [color]  - sends flickering hud message to all players
13: amx_flicksayy [color]  - sends flickering hud message to all players - anonymous
14: amx_fsay   [color]  - sends hud message to all players
15: amx_fsayy   [color]  - sends hud message to all players - anonymous
16: amx_fxsay [color]  - sends fx hud message to all players
17: amx_fxsayy [color]  - sends fx hud message to all players - anonymous
18: amx_help - displays this help
19: amx_kick  [reason] - kicks
20: amx_kickmenu - displays kick menu
21: amx_langmenu - displays language menu
22: amx_language [|save] - displays/sets/saves language
23: amx_leave  [tag] [tag] [tag] - kicks non specified players
24: amx_listmaps - lists maps that can be nominated
25: amx_map  - changelevel
26: amx_mapmenu - displays changelevel menu
27: amx_name   - changes player's name
28: amx_plugcmdmenu [filename.amx/plugin name] - displays plugins commands menu
29: amx_psay   - sends private message
30: amx_psayy   - sends private message - anonymous
31: amx_say  - sends message to all players
32: amx_sayy  - sends message to all players - anonymous
33: amx_scrollsay [color]  - sends scroll message to all players
34: amx_scrollsayy [color]  - sends scroll message to all players - anonymous
35: amx_slap  [power] - slaps
36: amx_slapmenu - displays slap/slay menu
37: amx_slay  - slays
38: amx_speechmenu - displays speech menu
39: amx_teammenu - displays team menu
40: amx_teleportmenu - displays teleport menu
41: amx_tsay [color]  - sends left side hud message to all players
42: amx_tsayy [color]  - sends left side hud message to all players - anonymous
43: amx_vote    [answer #3] [answer #4] - starts a custom vote
44: amx_voteban  [ip] - starts a voteban
45: amx_voteff - starts a vote to enable/disable Friendly Fire
46: amx_votekick  - starts a votekick
47: amx_votemap  [map] [map] [map] - starts a votemap
48: amx_votemapmenu - displays votemap menu
49: amx_votenextmap [time] - the map will be changed [time] seconds after the end of the vote
50: amx_who - displays who is on server
51: amxmodmenu - displays menus
52: say <@[@|@]|#[#|#]|$[$|$]>[color]  - displays chat/hud message
53: say /currentmap - displays current map (say)
54: say /ff - displays friendly fire status (say)
55: say /flop15 - displays worst 15 players (MOTD)
56: say /flop15new - displays worst 15 players (MOTD)
57: say /hp - displays info. about your killer (chat)
58: say /me - displays current round stats (chat)
59: say /rank - displays your rank (chat)
60: say /rankstats - displays your server stats (MOTD)
61: say /rankstatsnew - displays your server stats (MOTD)
62: say /report - displays weapon status (say_team)
63: say /score - displays last score (chat)
64: say /stats - displays players stats (menu/MOTD)
65: say /statsme - displays your stats (MOTD)
66: say /streak - display info. about your killing streak
67: say /switch - switch client's stats on or off
68: say /thetime - displays the time (say)
69: say /timeleft - displays time left on map (say)
70: say /top15 - displays top 15 players (MOTD)
71: say /top15new - displays top 15 players (MOTD)
72: say currentmap - displays current map
73: say nextmap - displays next map
74: say thetime - displays current time
75: say timeleft - displays timeleft
76: say_team @ - displays message to admins

Counter-Strike 1.6 hat mittlerweile einige Jahre auf dem Buckel, gehört aber immer noch zu den beliebtesten Multiplayer-Spielen. Möchte man unter Ubuntu einen Server aufsetzen, so ist dies in wenigen Schritten erledigt. Im ersten Schritt müssen Abhängigkeiten installiert und ein Nutzer für den Server angelegt werden:

apt-get install lib32gcc1
adduser counterstrike

Nach dem Anlegen des Nutzers wird in dessen Kontext gewechselt und dort die Ordner-Infrastruktur angelegt:

su counterstrike
cd
mkdir steam
mkdir game

Nun steht die Installation des Steam-Kommandozeilen-Clients an:

cd steam
wget http://media.steampowered.com/installer/steamcmd_linux.tar.gz
tar -xvzf steamcmd_linux.tar.gz
rm steamcmd_linux.tar.gz

Danach kann der Steam-Client gestartet werden und der Counter-Strike-Server installiert werden:

./steamcmd.sh
login anonymous
force_install_dir /home/counterstrike/game/
app_update "90 -beta Beta" validate

Beim app_update kann es bei der Installation zu folgender Fehlermeldung kommen:

Error! App '90' state is 0x6 after update job.

Zur Lösung des Problems muss der Befehl:

app_update "90 -beta Beta" validate

so oft ausgeführt werden, bis der Vorgang schlussendlich erfolgreich beendet wird. Anschließend kann der Steam-Client mit dem Kommando exit beendet werden. Bevor man den Server startet, sollte man die server.cfg-Datei den Umständen entsprechend anpassen. Diese befindet sich im Ordner /home/counterstrike/game/cstrike/. Fertig konfiguriert könnte diese so aussehen:

// Use this file to configure your DEDICATED server. 
// This config file is executed on server start.

// server password
sv_password "geheim"
rcon_password "geheim"

// disable autoaim
sv_aim 0

// disable clients' ability to pause the server
pausable 0

// default server name. Change to "Bob's Server", etc.
hostname "Mein erster CS-Server"

// maximum client movement speed 
sv_maxspeed 320

// 20 minute timelimit
mp_timelimit 20

sv_cheats 0

// load ban files
// exec listip.cfg
// exec banned.cfg

Wenn man beim Start des Servers mittels:

./hlds_run -game cstrike +map de_dust2

folgende Ausgabe erhält:

dlopen failed trying to load:
/home/counterstrike/.steam/sdk32/steamclient.so
with error:
/home/counterstrike/.steam/sdk32/steamclient.so: cannot open shared object file: No such file or directory

muss ein symbolischer Link erstellt werden, welcher auf den linux32-Ordner der Steam-Installation zeigt:

cd
mkdir .steam
ln -s /home/counterstrike/steam/linux32 /home/counterstrike/.steam/sdk32

Anschließend kann der Server wieder gestartet werden. Alternativ kann der Server natürlich auch in einer screen-Umgebung gestartet werden, so das dieser im Hintergrund läuft.

Wenn man Let’s Encrypt Zertifikate erzeugt, so landen diese im Ordner /etc/letsencrypt/. Die Rechte sind dabei so gewählt das nicht privilegierte Prozesse auf diese Zertifikate nicht zugreifen können. Läuft nun z.B. ein Server mit solchen Rechten, so kann er das Zertifikat nicht ohne weiteres nutzen. Um diesem Umstand zu beseitigen sollte eine neue Nutzergruppe angelegt werden:

groupadd tls-certificates

Dieser Gruppe wird nun der Nutzer hinzugefügt, welcher den Serverdienst betreibt:

usermod -a -G tls-certificates git

Damit wird der Nutzer git der Gruppe tls-certificates hinzugefügt. Nun müssen nach der Zertifikatsgenerierung die Berechtigungen angepasst werden:

#!/bin/sh
service gogs stop
letsencrypt renew --agree-tos
chgrp -R tls-certificates /etc/letsencrypt
chmod -R g=rX /etc/letsencrypt
service gogs start

In diesem Skript wird im ersten Schritt der Service gestoppt. Anschließend werden neue Zertifikate erzeugt und die Berechtigungen angepasst. Damit kann die Gruppe tls-certificates auf die Zertifikate zugreifen. Danach wird der Service wieder gestartet, was nun dank Zugriff auf die Zertifikate ohne Probleme funktioniert.

Mit Hilfe des Befehls dd ist es unter Linux und vielen anderen unixoiden Systemen möglich, eine Festplatte mit Nullen zu überschreiben. Ist die Festplatte dabei z.B. als sda im System registriert, so funktioniert das Überschreiben mit folgendem Befehl:

dd if=/dev/zero of=/dev/sda

Je nach Festplattengröße kann der Vorgang dabei durchaus einige Stunden in Anspruch nehmen.

Vor einigen Tagen habe ich damit begonnen alle von mir betriebenen Webseiten auf TLS umzustellen. Dabei nutzte ich Zertifikate der Zertifizierungsstelle Let’s Encrypt. Let’s Encrypt ging dabei im letzten Jahr in Betrieb und liefert kostenlose Zertifikate für TLS. Die CA wird dabei unter anderem von der EFF und Mozilla unterstützt. Im Gegensatz zu anderen Lösungen ist der Prozess bei Let’s Encrypt hochgradig automatisiert, so das die Einrichtung schnell von statten geht.

Der offizielle Client hört dabei auf den Namen Certbot (früher Let’s Encrypt Client) und implementiert das ACME-Protokoll (Automated Certificate Management Environment) über welches der Prozess abgewickelt wird. Neben dem offiziellen Client gibt es viele weitere Clients welche das ACME-Protokoll implementieren. Um Let’s Encrypt unter Ubuntu zu nutzen, muss im ersten Schritt der Client installiert werden:

apt-get install letsencrypt

Nachdem der Client installiert wurde, kann mit der Erzeugung der Zertifikate begonnen werden. Im Gegensatz zu Apache wird unter Nginx die automatische Einrichtung nicht unterstützt. Aus diesem Grund werden nur die Zertifikate mit dem Client erzeugt. Dies geschieht mit dem Befehl:

letsencrypt certonly

Damit wird der interaktive Modus gestartet in welchem das Zertifikat erzeugt werden kann. Zuerst wird nach einer Mailadresse gefragt, mit welcher das Recovery in Notfällen möglich ist. Anschließend müssen die allgemeinen Geschäftsbedingungen akzeptiert werden. Nun wird nach den Domains gefragt, für welche ein Zertifikat erstellt werden soll. Hier kann man mehrere Domains per Komma bzw. Leerzeichen getrennt angeben – allerdings scheint dies in der aktuellen Version nicht zu funktionieren. Stattdessen wird nur für die erste angegebene Domain ein Zertifikat erzeugt. Standardmäßig benötigt Certbot während der Generierung der Zertifikate Zugriff auf den Port 80. Hintergrund für dieses Verhalten ist das der Client kurz einen Webserver aufsetzt um die Kommunikation mit der CA durchzuführen.

Abgelegt werden die erzeugten Zertifikate dabei im Ordner /etc/letsencrypt/. In diesem Ordner liegen neben den Stammzertifikaten auch die eigentlichen Zertifikate für die einzelnen Domains. Nun kann dieses Zertifikat in Nginx eingebunden werden. Dazu muss die Konfigurationsdatei der jeweiligen Seite (z.B. /etc/nginx/sites-available/example) geöffnet werden. Im ersten Schritt wurde dazu in der Konfiguration eine Weiterleitung eingerichtet:

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

        server_name .example.org;

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

Diese Weiterleitung sorgt dafür das eine Verbindung über unverschlüsseltes HTTP automatisch auf die verschlüsselte Variante umgeleitet wird. Weiter geht es mit der Konfiguration der verschlüsselten Verbindung:

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

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

        ...

Jedes erzeugte Zertifikat von Let’s Encrypt ist 90 Tage lang gültig, so das ein automatischer Prozess eingerichtet werden sollte um die Zertifikate automatisch zu erneuern. Mit dem Befehl:

letsencrypt renew --agree-tos

kann dabei der Erneuerungsprozess angestoßen werden. Möchte man das ganze ohne Risiko testen, so sollte der Parameter –dry-run angefügt werden.

letsencrypt renew --agree-tos --dry-run

Bei der Erneuerung der Zertifikate kann es nun vorkommen das man den Nginx-Server vorher beenden muss. Das ganze kann man in ein Skript gießen:

#!/bin/sh
service nginx stop
letsencrypt renew --agree-tos
service nginx start

Dieses Skript kann man nun zum Beispiel einmal in der Nacht per Cronjob ausführen. Der Client überprüft dabei ob eine Erneuerung notwendig ist und führt diese dann automatisch durch.

Wenn man unter Linux eingehende und abgehende Pakete kontrollieren, umleiten oder blockieren möchte, so kann man für diese Aufgabe iptables nutzen. Das Problem an iptables ist das es relativ kompliziert in der Anwendung ist.

Damit man hier nicht im Regen steht, gibt es (neben vieler anderer Firewall-Lösungen für Linux) die uncomplicated firewall kurz ufw. Technisch gesehen handelt es sich bei ufw um ein Frontend für iptables. Seit der Version 8.04 (Hardy Hedon) ist ufw ein Bestandteil der Ubuntu-Distribution. Neben Ubuntu ist ufw unter anderem auch für Debian verfügbar. Installiert werden kann ufw mittels des Befehls:

apt-get install ufw

Standardmäßig ist ufw deaktiviert, so das die Installation im ersten Schritt keinerlei Auswirkungen hat. Den aktuellen Status sowie die definierten Regeln können dabei mittels:

ufw status

eingesehen werden. Das könnte dann z.B. so aussehen:

Status: Aktiv

Zu                   Aktion      Von
--                   ------      ---
8080/tcp             DENY        Anywhere                                
22/tcp               ALLOW       Anywhere                            
22/tcp (v6)          ALLOW       Anywhere (v6)

Ist der Status auf inaktiv gesetzt, so muss ufw erst mit dem Befehl:

ufw enable

aktiviert werden. Hierbei muss man beachten das eine unbedachte Aktivierung von ufw dazu führen kann das man sich aus dem Rechner aussperrt. Dies liegt daran das am Anfang keinerlei Regeln definiert sind – so werden Pakete an Port 22 ignoriert; dies führt dazu das keine Verbindung per SSH möglich ist. Um dem vorzubeugen sollte eine Regel für SSH definiert werden, bevor ufw aktiviert wird:

ufw allow 22/tcp

Bei dieser Schreibweise handelt es sich um die vereinfachte Form zum Anlegen einer Regel. Neben allow, sind dabei auch die Werte deny und reject möglich. Während bei allow die Pakete passieren können, werden sie bei deny blockiert – im Gegensatz dazu wird bei reject der Absender darüber informiert das die Pakete abgelehnt wurden. Möchte man komplexere Regeln definieren nutzt man ufw nach folgendem Schema:

ufw allow proto tcp from any to 127.0.0.1 port 1234

Damit werden alle Verbindungen per TCP von beliebigen IP-Adressen an die spezifizierte IP-Adresse weitergeleitet. Als Port wird als Eingangs- und Zielport Port 1234 genutzt. Die Regeln welche ufw verwaltet werden in drei Dateien gespeichert:

/etc/ufw/before.rules
/var/lib/ufw/user.rules
/etc/ufw/after.rules

Abgearbeitet werden die Regeln in der Reihenfolge wie oben angegeben – somit könnte eine Regel in der user.rules-Datei definiert sein, welche anschließend von einer anderen Regel in der after.rules-Datei überschrieben wird. Die selbst definierten Regeln sind dabei in der user.rules zu finden. Neben dem Anlegen ist es natürlich auch möglich Regeln wieder zu löschen. Für obige SSH-Regel würde das dabei so aussehen:

ufw delete allow 22/tcp

Daneben ist es möglich ufw auf die Standardeinstellungen zu setzen. Dazu dient der Befehl:

ufw reset

Alle Regeln werden dabei auf die Standardeinstellungen zurückgesetzt. Für die bestehenden Regeln wird ein Backup im Verzeichnis /etc/ufw/ angelegt. Möchte man ufw wieder deaktivieren, so nutzt man den Befehl:

ufw disable

Beim beschriebenen reset-Befehl wird ufw ebenfalls deaktiviert. Damit sind die grundlegenden Konfigurationsschritte erklärt – für die weitergehende Konfiguration empfiehlt sich der entsprechende Artikel bei ubuntuusers.

Unter Umständen kann es unter Ubuntu, oder anderen Distributionen basierend auf Debian passieren, das ein apt-get Vorgang fehlschlägt. Dies kann sich darin äußern das apt-get nicht mehr genutzt werden kann – stattdessen bekommt man folgende Meldung zu sehen:

E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/) is another process using it?

Hintergrund ist das dpkg Sperrdateien mit dem Name lock anlegt und sie nach getaner Arbeit wieder entfernt. Bei plötzlichen Unterbrechungen wie z.B. einem Stromausfall kann es passieren das die Dateien nicht mehr entfernt werden. Lösen kann man das Problem indem man die entsprechenden Sperrdateien entfernt:

rm /var/lib/dpkg/lock
rm /var/lib/apt/lists/lock
rm /var/cache/apt/archives/lock

Abschließend sollte dpkg bzw. apt-get wieder ohne Probleme funktionieren.