Eigene custom-setup.sh als Lösung für SSL-Probleme beim Update von indi-allsky

Das offizielle setup.sh von indi-allsky ist funktional umfangreich und installiert die gesamte Laufzeitumgebung inklusive Webserver-Konfiguration. Für typische Installationen ist dieses Verhalten sinnvoll, führt jedoch zu Problemen, wenn eigene Apache-Einstellungen genutzt werden – insbesondere bei Let’s-Encrypt-Zertifikaten, benutzerdefinierten VirtualHosts oder spezifischen Redirect-Regeln.

Im praktischen Betrieb zeigte sich, dass setup.sh bei jedem Durchlauf die Datei /etc/apache2/sites-available/indi-allsky.conf neu generiert. Dadurch:

wird ein selbst signiertes SSL-Zertifikat erstellt,
gehen individuelle SSL-Pfad- und ServerName-Einstellungen verloren,
entstehen Listener-Konflikte (Ports 80/443 mehrfach belegt),
schlägt der Apache-Neustart am Ende des Setup-Prozesses fehl.

Eine zunächst angedachte Lösung war, die Datei mittels chattr +i schreibzuschützen. Das verhindert zwar die Überschreibung, führt aber dazu, dass das Setup-Skript mit Fehlermeldungen abbricht, da die Datei nicht ersetzt werden kann. Damit war klar: Diese Methode ist in der Praxis nicht geeignet.

Die Lösung: eine eigene, stabile Setup-Routine

Um den Updateprozess verlässlich und konfliktfrei zu gestalten, wurde eine eigene Wrapper-Routine entwickelt: custom-setup.sh. Dieses Skript ruft die offizielle Setup-Routine weiterhin vollständig auf, verhindert jedoch gezielt, dass der Apache-Konfigurationsblock von setup.sh ausgeführt wird.

Das funktioniert über zwei Variablen, die bereits im Originalskript vorgesehen sind:

INDIALLSKY_WEBSERVER=“apache“ erzwingt die Verarbeitung im Apache-Zweig des Setups.

WEBSERVER_CONFIG=“false“ sorgt dafür, dass der gesamte Block zur Neugenerierung der Apache-Konfiguration übersprungen wird – unabhängig davon, was der Nutzer im Whiptail-Dialog auswählt.

Damit bleiben alle individuellen Anpassungen an der Apache-Konfiguration (Zertifikate, VirtualHosts, Redirects etc.) vollständig erhalten, während alle anderen Komponenten von indi-allsky regulär aktualisiert werden.

custom-setup.sh erstellen


#!/bin/bash
set -e

# Wrapper für das offizielle setup.sh von indi-allsky,
# jedoch ohne dass die Apache-Konfiguration überschrieben wird.
# XXX ist mit dem korrekten Pfad zu ergänzen

INDI_DIR="/home/XXX/indi-allsky"
CONF_APACHE="/etc/apache2/sites-available/indi-allsky.conf"

echo ">>> custom-setup.sh: gestartet"

# 1. Prüfen, ob setup.sh existiert
if [ ! -f "${INDI_DIR}/setup.sh" ]; then
    echo "FEHLER: ${INDI_DIR}/setup.sh wurde nicht gefunden"
    exit 1
fi

# 2. Prüfen, ob eine Apache-Konfiguration vorhanden ist
if [ ! -f "$CONF_APACHE" ]; then
    echo "WARNUNG: $CONF_APACHE existiert nicht."
    echo "custom-setup.sh läuft weiter, aber die Apache-Konfiguration wird nicht verwaltet."
fi

echo ">>> Webserver: apache"
echo ">>> Blockiere Apache-Konfigurationsänderungen in setup.sh"

export INDIALLSKY_WEBSERVER="apache"
export WEBSERVER_CONFIG="false"

cd "$INDI_DIR"
./setup.sh

echo ">>> setup.sh abgeschlossen, prüfe Apache..."

if command -v apachectl >/dev/null 2>&1; then
    echo ">>> apachectl configtest"
    sudo apachectl configtest

    echo ">>> Starte apache2 neu"
    sudo systemctl restart apache2

    echo ">>> Aktive VirtualHosts:"
    sudo apachectl -S
else
    echo "HINWEIS: apachectl nicht gefunden – überspringe Apache-Prüfung."
fi

echo ">>> custom-setup.sh erfolgreich abgeschlossen."

Installation der eigenen Setup-Routine

Die Datei custom-setup.sh wird direkt im Hauptverzeichnis der indi-allsky-Installation angelegt, beispielsweise unter /home/xxx/indi-allsky/. Nachdem der oben gezeigte Inhalt eingefügt wurde, wird die Datei ausführbar gemacht:

 chmod +x custom-setup.sh

Ab diesem Zeitpunkt erfolgt jedes Update ausschließlich über das neue Skript:

 ./custom-setup.sh

Das ursprüngliche setup.sh bleibt funktional vorhanden, sollte jedoch nicht mehr direkt ausgeführt werden, da es die bestehende Webserver-Konfiguration überschreiben und Zertifikate oder Listener-Einstellungen beschädigen kann. Mit der custom-setup.sh bleibt die Apache-Konfiguration unverändert, während die Anwendung selbst weiterhin korrekt aktualisiert wird.