Wenn sbopkg an rsync scheitert: SlackBuilds.org per Git nutzen

18.08.2026 · 5 Min. Lesezeit

Nachdem Slackware unter WSL eingerichtet und die Zscaler-Root-CA importiert war, funktionierten die üblichen HTTPS-Verbindungen problemlos.

Der nächste Schritt war daher eigentlich Routine: sbopkg installieren und das SlackBuilds.org-Repository synchronisieren.

Genau dabei bin ich über das nächste Problem gestolpert.

Das Problem

Wer Slackware nutzt, kommt früher oder später mit sbopkg in Berührung. Das Werkzeug erleichtert die Arbeit mit den SlackBuilds.org-Repositories (SBo) und übernimmt unter anderem das Herunterladen und Bauen von SlackBuilds.

Standardmäßig synchronisiert sbopkg den lokalen SBo-Tree über rsync.

Auf meinem Firmenlaptop hinter einer durch Zscaler abgesicherten Unternehmensinfrastruktur schlug diese Synchronisation reproduzierbar fehl:

sbopkg -r

Der Aufruf endete ohne Erfolg.

Da das Problem in einer Unternehmensumgebung auftrat, lag der erste Verdacht natürlich bei der Netzwerk-Infrastruktur.

Ist Port 873 überhaupt erreichbar?

rsync verwendet normalerweise TCP-Port 873. Also habe ich zunächst überprüft, ob dieser Port grundsätzlich erreichbar ist:

nc -vz rsync.slackbuilds.org 873

Das Ergebnis war überraschend positiv:

rsync.slackbuilds.org [66.85.79.67] 873 (rsync) open

Der TCP-Port war also erreichbar.

Damit war zumindest klar: Es handelt sich nicht um den klassischen Fall eines komplett blockierten Ports.

Der nächste Test: rsync direkt ansprechen

Als Nächstes habe ich den rsync-Dienst direkt angesprochen:

rsync --list-only rsync://rsync.slackbuilds.org/slackbuilds/

Diesmal war das Ergebnis eindeutig weniger erfreulich:

rsync: [Receiver] safe_read failed to read 1 bytes:
Connection reset by peer (104)

rsync error: error in rsync protocol data stream (code 12)

Die TCP-Verbindung kam also zustande, aber die Verbindung wurde anschließend während der Kommunikation wieder beendet.

Mit aktiviertem Debugging wurde das noch deutlicher:

opening tcp connection to rsync.slackbuilds.org port 873
Connected to rsync.slackbuilds.org (66.85.79.67)
msg checking charset: UTF-8
rsync: [Receiver] safe_read failed to read 1 bytes:
Connection reset by peer (104)

Das ist ein interessanter Unterschied.

Der Netzwerkweg bis zum Ziel funktioniert. Erst beim eigentlichen Protokollaustausch bricht die Verbindung ab.

Ein Hinweis auf einen Netzwerkfilter

Dieses Verhalten ist ein starker Hinweis auf einen vorgeschalteten Netzwerkfilter.

Eine vollständig blockierte Verbindung würde typischerweise bereits beim Aufbau scheitern, beispielsweise mit einem Timeout. Hier passiert dagegen etwas anderes:

1. DNS funktioniert.
2. Die TCP-Verbindung zu Port 873 wird aufgebaut.
3. Der rsync-Handshake beginnt.
4. Die Verbindung wird anschließend aktiv zurückgesetzt.

Das passt zu einer Infrastruktur, die nicht nur IP-Adressen und Ports betrachtet, sondern den darüber übertragenen Datenverkehr analysiert und bestimmte Protokolle oder Verbindungen beendet.

In meiner Umgebung war Zscaler die Ursache.

Das ist auch nachvollziehbar: rsync über TCP/873 ist ein relativ spezielles Protokoll und wird in vielen Unternehmensnetzwerken nicht benötigt. HTTPS dagegen ist praktisch überall notwendig und entsprechend stark unterstützt.

Damit war die Diagnose für mich ausreichend:

Der Server ist erreichbar, Port 873 ist offen, aber der rsync-Verkehr wird auf dem Weg zum Ziel beendet.

Die Frage war nun: Muss sbopkg tatsächlich über rsync synchronisieren?

SlackBuilds.org kann mehr als rsync

Die Antwort lautet: nein.

Das SlackBuilds.org-Repository für Slackware 15.0 ist nicht ausschließlich über rsync erreichbar. SBo stellt unter anderem Git, HTTP, FTP und rsync als Zugriffsmöglichkeiten zur Verfügung.

Damit gibt es eine naheliegende Alternative:

Git statt rsync.

Das ist für eine Unternehmensumgebung besonders praktisch, weil Git über HTTPS auf GitHub zugreifen kann und HTTPS in der Regel wesentlich weniger problematisch ist als ein eigener Dienst auf TCP-Port 873.

Das SBo-Repository per Git klonen

Für Slackware 15.0 habe ich deshalb das offizielle SlackBuilds.org-Git-Repository lokal ausgecheckt.

Zunächst lege ich das Verzeichnis an, das sbopkg für den lokalen SBo-Tree verwendet:

mkdir -p /var/lib/sbopkg/SBo
cd /var/lib/sbopkg/SBo

Anschließend wird der Branch für Slackware 15.0 geklont:

git clone \
  --branch 15.0 \
  --single-branch \
  https://github.com/SlackBuildsOrg/slackbuilds.git \
  15.0

Damit entsteht folgende Struktur:

/var/lib/sbopkg/SBo/
└── 15.0/
    ├── academic/
    ├── audio/
    ├── development/
    ├── games/
    ├── graphics/
    ├── libraries/
    ├── multimedia/
    ├── network/
    └── ...

Das entspricht dem lokalen Repository-Aufbau, den sbopkg für SBo/15.0 verwendet. sbopkg unterstützt Slackware 15.0 seit Version 0.38.2 offiziell.

Funktionstest

Bevor ich sbopkg starte, lässt sich schnell überprüfen, ob der Checkout vorhanden ist:

ls /var/lib/sbopkg/SBo/15.0

Erscheinen dort Verzeichnisse wie audio, development, graphics oder network, ist der lokale Repository-Tree vorhanden.

Danach kann sbopkg wieder ganz normal gestartet werden:

sbopkg

Die Paketsuche und das Bauen der SlackBuilds funktionieren weiterhin wie gewohnt.

Der entscheidende Unterschied ist lediglich, wie der lokale SBo-Tree aktualisiert wird.

Repository aktualisieren

Statt künftig

sbopkg -r

aufzurufen, aktualisiere ich das Repository mit Git:

cd /var/lib/sbopkg/SBo/15.0
git pull

Damit wird der lokale Checkout auf den aktuellen Stand des SlackBuilds.org-Repositories gebracht.

Der Vorteil ist offensichtlich: Für die Aktualisierung wird kein rsync-Dienst und damit auch kein TCP-Port 873 benötigt.

Ein wichtiger Unterschied zu sbopkg

An dieser Stelle lohnt sich eine kleine Klarstellung.

sbopkg selbst unterstützt unterschiedliche Repository-Konfigurationen und kennt neben den klassischen SBo-Repositories auch Git-basierte Repository-Konfigurationen.

Mein Ansatz ist etwas pragmatischer: Ich lasse die bestehende sbopkg-Konfiguration für Slackware 15.0 unverändert und stelle den erwarteten lokalen Repository-Tree einfach über Git bereit.

Das bedeutet:

                     bisher

sbopkg
   │
   └── rsync ───────► SlackBuilds.org
                       TCP/873


                     meine Lösung

Git ──HTTPS─────────► GitHub
   │
   ▼
/var/lib/sbopkg/SBo/15.0
   │
   ▼
sbopkg

Damit bleibt sbopkg für seine eigentliche Aufgabe zuständig: SlackBuilds suchen, Abhängigkeiten berücksichtigen, bauen und installieren.

Git übernimmt lediglich die Synchronisation des Repository-Trees.

Fazit

Wenn sbopkg -r in einer Unternehmensumgebung mit

Connection reset by peer

oder

rsync protocol data stream (code 12)

scheitert, lohnt es sich, nicht nur auf den Status des Ports 873 zu schauen.

Ein offener TCP-Port bedeutet noch lange nicht, dass das darüber laufende Protokoll tatsächlich funktioniert.

In meinem Fall ließ sich der TCP-Handshake erfolgreich durchführen, während die Verbindung beim eigentlichen rsync-Protokoll zurückgesetzt wurde. Das war ein deutlicher Hinweis auf einen vorgeschalteten Netzwerkfilter – in meiner Umgebung Zscaler.

Die pragmatische Lösung war schließlich überraschend einfach:

rsync durch Git ersetzen.

SlackBuilds.org bietet für Slackware 15.0 ohnehin mehrere Zugriffsmöglichkeiten an, darunter Git und rsync.

Mit einem lokalen Git-Checkout kann sbopkg weiterhin mit seinem gewohnten Repository-Aufbau arbeiten, während die Synchronisation über HTTPS erfolgt.

Für mich war das jedenfalls deutlich schneller, als mit der Netzwerkabteilung über die Freischaltung von rsync auf TCP-Port 873 zu diskutieren.