Hallo zusammen,
in unserem Umfeld gibt es einen zentralen Proxy-Server, über den freigeschaltete Clients ins Internet dürfen. Unabhängig davon entstehen derzeit in meinem Teilbereich immer mehr Debian-Clients die über kurz oder lang Aktualisierungen erhalten können sollen.
Damit jetzt nicht jeder einzelne Server am zentralen Proxy (den ich z.B. gar nicht in der Hand habe) freigeschaltet werden muss, hatte ich die Idee einen Proxy für unsere Debian-Rechner aufzusetzen, über den die benötigten Repositories erreicht werden können.
Somit musste bisher nur mein eigener Proxy am zentralen Proxy freigeschaltet werden (Aktualisierungen kann dieser sich bereits holen), alles andere kann ich selbst dann über z.B. die Squid-Konfig lösen (Berechtigung, etc.).
Löse ich jetzt auf einem nachgelagerten Debian-Rechner ein apt-get update aus, sehe ich in der Squid-Access-Log auf meinem Proxy-Server die Anfragen, die allerdings nicht erfolgreich verarbeitet werden.
1519728152.921 0 <IP-eines-nachgelagerten-Clients>TCP_DENIED/403 4094 GET http://deb.debian.org/debian/dists/stre ... slation-en - HIER_NONE/- text/html
Ich bin mir jetzt a) nicht sicher ob dieses Vorgehen eine saubere Lösung ist und b) wenn ja, wo die 403 herkommt. Von meinem Proxy? Vom zentralen Proxy? Sollte ich eventuell die IP-Adresse des anfragenden Clients durch die meines Proxy ersetzen lassen?
Vielleicht hat jemand nen Tipp für mich.
Vielen Dank
Marvin
Change | Problem mit Apt-Cacher >> Pakete werden nicht geholt/weitergeleitet
-
- Beiträge: 8
- Registriert: 16.02.2018 12:21:51
Change | Problem mit Apt-Cacher >> Pakete werden nicht geholt/weitergeleitet
Zuletzt geändert von Marvin1979 am 02.03.2018 14:03:45, insgesamt 1-mal geändert.
Re: Squid hinter einem Proxy nutzen
vllt willst du eher apt-cacher http://debiananwenderhandbuch.de/apt-cacher.html
apt-cacher
alternativ gibt es auch noch
approx
![Debian](/pics/debianpackage.png)
alternativ gibt es auch noch
![Debian](/pics/debianpackage.png)
Re: Squid hinter einem Proxy nutzen
Ich würde auch
apt-cacher oder ähnliches für das Caching von Debian-Paketen verwenden. Einen zweiten Cache nachzuschalten ist generell sinnfrei, da der erste Cache alles cacht. Aber selbst den zentralen Proxy würde ich weglassen oder mindestens nicht cachen lassen. Bei den heutigen Bandbreiten und multimedialen Inhalten lohnt sich Caching praktisch nicht mehr. Frag mal nach der Bandbreiteneinsparung, was das finanziell bringt (DSL X.000 zu DSL X+Y.000) und den damit verbundenen Ärger, Administrationsaufwand und Stromkosten.
![Debian](/pics/debianpackage.png)
Re: Squid hinter einem Proxy nutzen
uname hat geschrieben:27.02.2018 13:20:24Einen zweiten Cache nachzuschalten ist generell sinnfrei, da der erste Cache alles cacht. Aber selbst den zentralen Proxy würde ich weglassen oder mindestens nicht cachen lassen.
- ein Proxy ist nicht nur ein Cache
- ein Proxy kann per ACL unerwünschte Inhalte blockieren
- ein Proxy kann Zugangsberechtigungen regeln
- ein Proxy kann Firmenpolicy sein
Vor allem ist heute der größte Teil des WWW hinter https versteckt. Dank Verschlüsselung wird da ohnehin gar nichts gecached und auch Filterung via ACL ist dank https extrem eingeschränkt bis unmöglich.Bei den heutigen Bandbreiten und multimedialen Inhalten lohnt sich Caching praktisch nicht mehr.
Grundsätzlich ist es aber möglich, einen zweiten Proxy hinter einen Zentralproxy zu stellen. Wenn man aber die Zwangsregistrierung durch einen Proxy umgehen will, sollte das auf jeden Fall mit dem Arbeitgeber abgesprochen werden und der zweite Proxy als Slave vom ersten Proxy konfiguriert werden.
-
- Beiträge: 8
- Registriert: 16.02.2018 12:21:51
Re: Squid hinter einem Proxy nutzen
Die Idee hinter dem Ganzen bei mir ist, dass nicht jeder Debian-Rechner direkt am zentralen Proxy freigeschaltet werden muss, sondern dass es quasi eine Instanz dazwischen gibt, die ich unter meiner Hand habe, und die grundsätzlich alle benötigten Pakete herunterladen darf.
Im Sinne eines Systembetriebes innerhalb eines Unternehmensbereiches hätte das den Vorteil, dass diese Thematiken, welche Quellen freigeschaltet werden sollen und für wen, im Überblick behalten und vernünftig dokumentiert werden kann.
--> Zum Problem.
Der Debian-Server, welcher am zentralen Proxy die Freischaltung zum den Debian-Quellen hat, hat jetzt das Paket Apt-Cacher installiert bekommen. Soweit ich verstanden haben, lädt dieser in sein definiertes Verzeichnis die angefragten Pakete und stellt sie Dritten zur Verfügung.
Folgendes wurde konfiguriert:
Ich habe auf meinem Debian-Server eine apt.conf angelegt, in der der zentrale Proxy-Server definiert wurde. Hierüber kann ich, zumindest für meinen Server, auch schon Aktualisierungen vornehmen oder andere Pakete installieren.
Die sources.list auf einem nachgelagerten Rechner hatte ich folgendermaßen bearbeitet:
Führe ich dort nun ein apt-get update aus erhalte ich relativ schnell folgende Zeilen:
Die access.log von apt-cacher spuckt an der Stelle leider auch nichts aus, von daher bin ich derzeit am Rätseln, wo das Problem liegt.
Viele Grüße
Marvin
Im Sinne eines Systembetriebes innerhalb eines Unternehmensbereiches hätte das den Vorteil, dass diese Thematiken, welche Quellen freigeschaltet werden sollen und für wen, im Überblick behalten und vernünftig dokumentiert werden kann.
--> Zum Problem.
Der Debian-Server, welcher am zentralen Proxy die Freischaltung zum den Debian-Quellen hat, hat jetzt das Paket Apt-Cacher installiert bekommen. Soweit ich verstanden haben, lädt dieser in sein definiertes Verzeichnis die angefragten Pakete und stellt sie Dritten zur Verfügung.
Folgendes wurde konfiguriert:
Ich habe auf meinem Debian-Server eine apt.conf angelegt, in der der zentrale Proxy-Server definiert wurde. Hierüber kann ich, zumindest für meinen Server, auch schon Aktualisierungen vornehmen oder andere Pakete installieren.
Die sources.list auf einem nachgelagerten Rechner hatte ich folgendermaßen bearbeitet:
Code: Alles auswählen
deb http://ip-meines-servers/apt-cacher/deb.debian.org/debian stretch main
Code: Alles auswählen
...
Ign:7 http://ip-meines-servers/apt-cacher/deb.debian.org/debian stretch/main Translation-de_DE
Ign:3 http://ip-meines-servers/apt-cacher/deb.debian.org/debian stretch/main all Packages
Fehl:4 http://ip-meines-servers/apt-cacher/deb.debian.org/debian stretch/main amd64 Packages
404 Not Found
Ign:5 http://ip-meines-servers/apt-cacher/deb.debian.org/debian stretch/main Translation-en
Ign:6 http://ip-meines-servers/apt-cacher/deb.debian.org/debian stretch/main Translation-de
Ign:7 http://ip-meines-servers/apt-cacher/deb.debian.org/debian stretch/main Translation-de_DE
Paketlisten werden gelesen... Fertig
W: The repository 'http://ip-meines-servers/apt-cacher/deb.debian.org/debian stretch Release' does not have a Release file.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: Fehlschlag beim Holen von http://ip-meines-servers/apt-cacher/deb.debian.org/debian/dists/stretch/main/binary-amd64/Packages 404 Not Found
E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.
Viele Grüße
Marvin
Re: Change | Problem mit Apt-Cacher >> Pakete werden nicht geholt/weitergeleitet
Ich müsste jetzt die VM ausgraben wo ich das mal gebraucht habe (dort habe ich oft Maschinen debootstrapped) und ich meine ich hatte auch Probleme mit apt-cacher und bin dann zu approx gewechselt, weil das sehr viel einfacher zum einrichten und verwalten war...
Aber zu deinem problem: Was siehst du, wenn du mit einem Browser deinen Apt-cacher ansurfst? Wenn idh das richtig weiß, solltest du ein Repo dort sehen.
Aber zu deinem problem: Was siehst du, wenn du mit einem Browser deinen Apt-cacher ansurfst? Wenn idh das richtig weiß, solltest du ein Repo dort sehen.