Standardeditor im Terminal unter macOS Big Sur ändern

Der Standardeditor im Terminal unter macOS Big Sur, welches die Z shell nutzt, ist vim. Soll dieser Standard geändert werden, muss die Profildatei der Z shell angepasst werden:

nano ~/.zshrc

Dort wird nun folgende Zeile hinzugefügt:

export EDITOR=nano

Nachdem dem Speichern der Änderung, sowie einem Neustart der Terminal-App ist der neue Editor als Standard gesetzt.

Probleme bei der Installation von Homebrew unter macOS

Nach der Installation von Homebrew unter macOS Big Sur kann es unter Umständen (meist bei der M1/ARM Variante) passieren, das der Nutzer folgende Meldung erhält:

Warning: /opt/homebrew/bin is not in your PATH.

Gelöst werden kann dies in dem die Konfiguration für die Z shell angepasst wird. Dazu wird im Terminal eine neue Datei erstellt:

nano ~/.zshrc

In dieser Datei wird der Pfad der Homebrew-Installation der PATH-Variable hinzugefügt:

export PATH=/opt/homebrew/bin:$PATH

Beim nächsten Start der Shell, kann Homebrew dann problemlos genutzt werden.

550-Inconsistent/Missing DNS PTR record

Beim Senden einer Mail an eine Mail des Anbieters Freenet erhielt ich vom Mailserver folgende Antwort:

host emig.freenet.de[2001:748:100:40::8:115]
said: 550-Inconsistent/Missing DNS PTR record (RFC 1912 2.1)
(example.org) 550 [2001:db8:a0b:12f0::1]:34865 (in reply to RCPT TO command)

Der PTR Resource Record, auf den hier verwiesen wird, ist ein wichtiges Element für Durchführung von Reverse DNS-Abfragen. Für die IPv4- und die IPv6-Adresse des Servers hatte ich einen solchen Eintrag gesetzt. Deshalb war ich etwas verwundert, dass diese Meldung gesendet wurde. Bei der Nachforschung stellte ich dann fest, dass der Server eine IPv4-Adresse besitzt, aber ein ganzes IPv6-Subnetz. Das ist nicht weiter verwunderlich, allerdings sendet Postfix nicht mit einer festen IPv6-Adresse, sondern nutzt irgendeine Adresse aus dem Subnetz. Werden die Einstellungen von Postfix geöffnet:

nano /etc/postfix/main.cf

findet sich dort der Eintrag:

inet_interfaces = all

Durch diesen Eintrag ist nicht genau festgelegt, welche IP-Adresse für das Senden genutzt wird. Hier sollten die genauen IP-Adressen festgelegt werden:

inet_interfaces = 82.91.44.12,2001:db8:a0b:12f0::1

Anschließend sollte Postfix neu gestartet werden:

service postfix restart

Wird nun erneut eine Mail an den Freenet-Server geschickt, so kann es passieren, dass die Fehlermeldung erneut zurückgesendet wird. In einem solchen Fall muss noch einige Minuten bis Stunden gewartet werden, bevor der Freenet-Server die Mails entgegennimmt.

Standardeditor für die Z shell einstellen

In der neuen macOS-Version Catalina wurde die Standardshell seitens Apple gewechselt. Statt der Bourne-again shell, kurz Bash, wird nun die Z shell, kurz zsh, genutzt. Grund hierfür ist, dass die Lizenz, welche von Bash genutzt wird, aus Sicht von Apple zu restriktiv ist. Aus diesem Grund wurde zur Z shell gewechselt. In dieser ist, unter macOS, standardmäßig vi als Editor eingestellt. Soll der Standardeditor geändert werden so muss die entsprechen Konfigurationsdatei der Z shell im Terminal bearbeitet werden:

nano ~/.zshrc

In diese Datei muss nun folgende Zeile eingetragen werden:

export EDITOR=nano

Damit wird, nachdem die Konfiguration gespeichert wurde und die Shell neu geöffnet wurde, nano als Standardeditor genutzt.

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.