Zeit unter Linux manuell synchronisieren

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.

Code-Formatierung unter IntelliJ IDEA selektiv deaktivieren

IntelliJ IDEA bietet, wie wahrscheinlich jede brauchbare IDE, eine Funktionalität um den Quelltext automatisch zu formatieren. Manchmal kann es allerdings notwendig sein die Funktionalität für bestimmte Dateien oder Abschnitte zu deaktivieren. IntelliJ IDEA bietet dem Nutzer eine Möglichkeit dies zu tun. Dazu muss in den Einstellungen unter Code Style im Tab Formatter Control das entsprechende Feature aktiviert werden. Im Beispiel sieht das Ganze wie folgt aus:

// @formatter:off
try {
  // Do something wrong
} catch(Exception e) {
  // Gotta Catch 'Em All
}
// @formatter:on

Durch den einleitenden Kommentar @formatter:off wird die Code-Formatierung deaktiviert; am Ende des Blockes wird er mittels @formatter:on wieder aktiviert. Damit ist es mögliche Abschnitte und Dateien von der Code-Formatierung auszunehmen.

Chronologische Abfrage unter Elasticsearch

Elasticsearch ist eine quelloffene Suchmaschine. Über eine Query kann eine Suche spezifiziert werden, welche für die entsprechenden Ergebnisse sorgt. Manchmal soll allerdings die Ausgabe der Daten eines Index von Elasticsearch chronologisch erfolgen. Dies ist z.B. sinnvoll, wenn Logdaten oder ähnliches in diesem gespeichert werden. In einem solchen Fall sollen sie unter Umständen chronologisch ähnlich dem Aufruf tail -f angezeigt werden. Dazu dient folgender Request:

GET https://elastic.example.org:9200/index/_search

Zusätzlich muss die eigentliche Query im Body der Anfrage, als JSON hinterlegt werden:

{
  "query": {
    "match_all": {}
  },
  "size": 10,
  "sort": [
    {
      "timestamp": {
        "order": "desc"
      }
    }
  ]
}

Das hier für die Sortierung genutzte Feld timestamp muss in den Daten enthalten sein, sonst funktioniert die Sortierung nicht. Nach dem Absetzen der Query, erhält der Nutzer zehn Einträge, beginnend mit den neusten Einträgen.

Reverse Proxy für Gitea konfigurieren

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.

HTTPS für Gitea aktivieren

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.