[Eisfair] eismirror, squid vorkonfiguriert oder wie updates cachen?

[Ansgar Püster]

Hallo Kay,

Am 23.12.2018 um 20:42 schrieb Kay Martinen:
> Hallo

[...]

> Gibt es da eine Fertige Baukastenlösung oder wie realisiert ihr die
> updates von mehreren Eisfair-servern? Evtl. insbesondere wenn einige
> davon auf einem VM-Host(ProxMoxVE) laufen. Derzeit hab ich nur einen
> Physischen EIS, aber 3-4 Virtuelle.

Ich aktualisiere alle meine physischen und virtuellen Server
unter Nutzung von pack-eis. Nur bei Entwicklungstests nutze
ich lokale Files und dann /var/install/bin/install-local-package.

Zu den von dir genannten Softwareelementen:

1.) eismirror
Wird schon lange nicht mehr gepflegt. Zumindest "meine"
Version basierte auf den alten eis-list.txt Verweislisten,
die es nicht mehr gibt.

2.) eisman mirror
Wird von Daniel weiterhin gepflegt.
Diese Variante einen Mirror zu erstellen hat aus meiner Sicht
zwei Eigenschaften, die zumindest mich von einer Nutzung
abhalten (siehe zusätzlich auch unten bei URL-Handling).

a.) Ein Mirror für Eisfair-1 Pakete kann nur auf einem
Eisfair-1 System erstellt werden. Ein Mirror für Eisfair-64
Pakete kann nur auf einem Eisfair-64 System erstellt werden.
Nur über einen "üblen" Trick ist es möglich auf einem Sytem
beide Mirror zu erstellen. Die eisfair-noarch Pakete werden
dabei dann allerdings doppelt gespeichert.

b.) Mirror enthält nur den "Treiber" des Base-Updates (base.tar.gz),
nicht aber die eigentliche Base-Updates, wie z.B.
    update-2.8.10.tar.gz
    update-2.8.11.tar.gz
Diese sind im Vergleich zum "Treiber" des Base-Updates erheblich
größer. Ein Base-Update OHNE Zugang zum pack-eis Server ist daher
mit einem eisman mirror meines Wissens NICHT möglich.

Aktuelle Größen
eismirror-1   ca. 4,1 GByte		
eismirror-64  ca. 2,4 GByte

3.) Squid
Der Update der Eisfair-Pakete geschieht über https!
Für https baut der Squid Tunnel auf, die Objekte werden
meines Wissens nicht im Squid Cache gespeichert.

Ausflug zu IPfire (update_accelerator):
-- schnipp --
A client on the local network requests a file per HTTP.
-- schnipp --

Ob es sinnvoll ist einen Squid als "man in the middle"
aufzubauen und https umzubauen oder (mit üblen Tricks)
den Eisfair-Update auf http umzubiegen finde ich fraglich.
Offen ist auch, wie lange das noch möglich ist.

4.) "Administration of package URLs"
Das Handling von "Administration of package URLs" sieht, so
meine Erfahrung, nicht vor mit einem Mirror und ohne pack-eis
zu arbeiten. Selbst, wenn man den pack-eis URL entfernt, wird
pack-eis intern als Default eingesetzt.

5.) "eine Fertige Baukastenlösung" kenne ich nicht.

Ggf. solltest du mal ein ein/zwei Beispielen beschreiben,
was du dir vorstellst und insbesondere warum du so arbeiten
willst/musst.

So weit erst mal.
Gruß,
Ansgar