16
Debian Server- Aktualisierungen
Hallo,
bei uns sollen diverse Spezial Rechner mit einem Debian eingesetzt werden.
An verschiedenen Standorten weltweit .
Jetzt plant unsere Entwicklung das sich diese Rechner jeweils einzeln bei Debian und auf Github ihre Updates holen.
Das ist für die ersten 3- 5 Prototypen ja auch erstmal okay.
Spätestens im Produktivbetrieb würde ich es aber gerne sehen wenn die Rechner über einen sowieso vorhandenen VPN Tunnel ihre Updates ziehen.
Im Falles eines Windows Server würde ich dafür einen WSUS oder sowas nehmen. Aber bei Debian oder Github? Gibt es dafür etwas ähnliches?
Bzw. wie wäre hier von eurer Seite die Empfehlung? bzw. Best Practise.....
Einen FTP Server aufsetzen und dementsprechend auf dieser Kiste die Repositories zur Verfügung stellen?
brammer
bei uns sollen diverse Spezial Rechner mit einem Debian eingesetzt werden.
An verschiedenen Standorten weltweit .
Jetzt plant unsere Entwicklung das sich diese Rechner jeweils einzeln bei Debian und auf Github ihre Updates holen.
Das ist für die ersten 3- 5 Prototypen ja auch erstmal okay.
Spätestens im Produktivbetrieb würde ich es aber gerne sehen wenn die Rechner über einen sowieso vorhandenen VPN Tunnel ihre Updates ziehen.
Im Falles eines Windows Server würde ich dafür einen WSUS oder sowas nehmen. Aber bei Debian oder Github? Gibt es dafür etwas ähnliches?
Bzw. wie wäre hier von eurer Seite die Empfehlung? bzw. Best Practise.....
Einen FTP Server aufsetzen und dementsprechend auf dieser Kiste die Repositories zur Verfügung stellen?
brammer
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 424768
Url: https://administrator.de/contentid/424768
Ausgedruckt am: 22.11.2024 um 06:11 Uhr
16 Kommentare
Neuester Kommentar
Moin Brammer,
du kannst dir auch dein eigenes "Github" erstellen . Das nennt sich dann Gitlab.
Debian selbst kannst ja über die offiziellen Repositorys aktualisieren.
Gruss
du kannst dir auch dein eigenes "Github" erstellen . Das nennt sich dann Gitlab.
Debian selbst kannst ja über die offiziellen Repositorys aktualisieren.
Gruss
Spätestens im Produktivbetrieb würde ich es aber gerne sehen wenn die Rechner über einen sowieso vorhandenen VPN Tunnel ihre Updates ziehen.
Was ist denn der Zweck die Updates über den Tunnel zu holen? Geht es dir darum, dass diese Server keine Internetverbindung haben sollen? Du kannst dir natürlich einen eigenen Spiegelserver aufbauen und das dort hinterlegen, was du wirklich brauchst. Alternativ Apt-Cacher-NG.
Hallo brammer,
du könntest dir einen lokalen Mirror mit den Debian-Paketen einrichten. Entweder relativ einfach per "debmirror" oder mit dem offiziellen Tar von Debian "ftpsync". Ich habs neulich mit "debmirror" gemacht und funktioniert perfekt. Geht auch für Backports und Security-Updates.
Allerdings lohnt sich das nur, wenn du mehrere Maschinen in einem Netzwerk hast, welche den dann nutzen. Wenn du pro Standort eine einzelne Machine hast, installier apt-transport-https und stell die /etc/apt/sources.list auf https-URL's um, falls es dir um verschlüsselten Transfer geht.
Gruß
bloody
du könntest dir einen lokalen Mirror mit den Debian-Paketen einrichten. Entweder relativ einfach per "debmirror" oder mit dem offiziellen Tar von Debian "ftpsync". Ich habs neulich mit "debmirror" gemacht und funktioniert perfekt. Geht auch für Backports und Security-Updates.
Allerdings lohnt sich das nur, wenn du mehrere Maschinen in einem Netzwerk hast, welche den dann nutzen. Wenn du pro Standort eine einzelne Machine hast, installier apt-transport-https und stell die /etc/apt/sources.list auf https-URL's um, falls es dir um verschlüsselten Transfer geht.
Gruß
bloody
Moin,
Github: Gitlab auf einem Server einrichten und konfigurieren. Ist mit etwas Aufwand verbunden und Bedarf ein paar Tests. Es gibt auch schöne Weboberflächen wenn's notwendig ist.
Gruß,
Dani
Aber bei Debian oder Github? Gibt es dafür etwas ähnliches?
Debian: Entsprechende Mirror im RZ einrichten. Ist relativ simpel und schnell einsatzbereit.Github: Gitlab auf einem Server einrichten und konfigurieren. Ist mit etwas Aufwand verbunden und Bedarf ein paar Tests. Es gibt auch schöne Weboberflächen wenn's notwendig ist.
Allerdings lohnt sich das nur, wenn du mehrere Maschinen in einem Netzwerk hast, welche den dann nutzen. Wenn du pro Standort eine einzelne Machine hast, installier apt-transport-https und stell die /etc/apt/sources.list auf https-URL's um, falls es dir um verschlüsselten Transfer geht.
Es geht nicht immer nur um den Aufwand. Es eher um Kontrolle und Sicherheit. Wer bohrt schon gerne für Server Löcher (Outbound) in die Firewall?!Gruß,
Dani
Hallo,
Danke erst mal für das Feedback...
Die Maschinen werden von uns in einem Netzwerk bei Kunden verbaut zu dem wir sowieso ein Site to Site
VPN haben.
Daher möchte ich den Kunden nicht damit überfordern weitere Löcher in seine Firewall zu bohren.
Es soll zukünftig um mehrere hundert weltweit gehen, wo ich dann teilweise das Thema das weitere Routen nicht möglich oder zumindest problematisch sind.
Ein debian mirror Server und ein gitlab Server können ja vermutlich auf der selben VM liegen...
Das hört sich alles vielversprechend an!
Danke.
Vielleicht kommt ja noch eine weitere Idee..
Brammer
Danke erst mal für das Feedback...
Die Maschinen werden von uns in einem Netzwerk bei Kunden verbaut zu dem wir sowieso ein Site to Site
VPN haben.
Daher möchte ich den Kunden nicht damit überfordern weitere Löcher in seine Firewall zu bohren.
Es soll zukünftig um mehrere hundert weltweit gehen, wo ich dann teilweise das Thema das weitere Routen nicht möglich oder zumindest problematisch sind.
Ein debian mirror Server und ein gitlab Server können ja vermutlich auf der selben VM liegen...
Das hört sich alles vielversprechend an!
Danke.
Vielleicht kommt ja noch eine weitere Idee..
Brammer
Hallo brammer,
ich könnt mir vorstellen das dein VPN da ziemlich mit zu knacken hat. Sind zwar, wenn mans regelmäßig macht pro Server
nur wenige Pakete die aktualisiert werden, aber da musst du dir dann vermutlich auch was für nen Zeitversatz der Updates einfallen lassen.
Per IPsec sind eh langsamere Datenraten möglich als über die normale Internetleitung, und dann
kommt das auch stark auf die eingesetzte Hardware an.
Hoffe habt da eine ausreichende Anbindung.
Finde da ist absolut nix schlimmes dran, wenn man die Debian-Server direkt anspricht. Oder ist das ein soo restriktives Netzwerk das nichtmal HTTPS nach außen geht?
Gruß
bloody
ich könnt mir vorstellen das dein VPN da ziemlich mit zu knacken hat. Sind zwar, wenn mans regelmäßig macht pro Server
nur wenige Pakete die aktualisiert werden, aber da musst du dir dann vermutlich auch was für nen Zeitversatz der Updates einfallen lassen.
Per IPsec sind eh langsamere Datenraten möglich als über die normale Internetleitung, und dann
kommt das auch stark auf die eingesetzte Hardware an.
Hoffe habt da eine ausreichende Anbindung.
Finde da ist absolut nix schlimmes dran, wenn man die Debian-Server direkt anspricht. Oder ist das ein soo restriktives Netzwerk das nichtmal HTTPS nach außen geht?
Gruß
bloody
Daher möchte ich den Kunden nicht damit überfordern weitere Löcher in seine Firewall zu bohren.
Sofern ein Proxy verfügbar ist, könnte Apt ja auch die Updates darüber holen.
Hallo,
die zur Verfügung stehende Bandbreite für VPN macht wir am wenigsten Sorgen, da stehen wir stabil.
In dieses Anlagennetz haben wir für Wartung einen VPN Tunnel.
Keine Weitere Verbindung. Weder rein noch raus.
Jetzt möchte ich vermeiden das wir in dieses Netz einen 2. Weg öffnen müssen. Aus Sicherheitsgründen würde ich das lieber über den existierenden Tunnel realisieren.
brammer
die zur Verfügung stehende Bandbreite für VPN macht wir am wenigsten Sorgen, da stehen wir stabil.
Oder ist das ein soo restriktives Netzwerk das nichtmal HTTPS nach außen geht?
Ja. Wir bauen Anlagen die als autarkes Netz im Kundennetz laufen.In dieses Anlagennetz haben wir für Wartung einen VPN Tunnel.
Keine Weitere Verbindung. Weder rein noch raus.
Jetzt möchte ich vermeiden das wir in dieses Netz einen 2. Weg öffnen müssen. Aus Sicherheitsgründen würde ich das lieber über den existierenden Tunnel realisieren.
brammer
Zitat von @brammer:
Keine Weitere Verbindung. Weder rein noch raus.
Jetzt möchte ich vermeiden das wir in dieses Netz einen 2. Weg öffnen müssen. Aus Sicherheitsgründen würde ich das lieber über den existierenden Tunnel realisieren.
Keine Weitere Verbindung. Weder rein noch raus.
Jetzt möchte ich vermeiden das wir in dieses Netz einen 2. Weg öffnen müssen. Aus Sicherheitsgründen würde ich das lieber über den existierenden Tunnel realisieren.
Dann würde ich für debian und github einfach einen lokalen Mirror in der Zentrale aufsetzen.
lks
Moin,
Gruß,
Dani
Es soll zukünftig um mehrere hundert weltweit gehen, wo ich dann teilweise das Thema das weitere Routen nicht möglich oder zumindest problematisch sind.
bei dieser Anforderung evtl. Gedanken über ein CDN im Intranet machen. Je nachdem wie eure VPN Topologie aussieht, kannst du damit die Last besser bewältigen bzw. die Auslastung einiger WAN/VPN-Verbindungen entlasten.Gruß,
Dani
Na @brammer das ist ja ne Info, die schon in der Frage hätte stehen können ;)
Dann MUSS natürlich die Kapazität vom VPN reichen.
An meinen vorgeschlagenen Lösungen halte ich dabei fest.
Je nachdem wieviele pro Kundennetzwerk, würd sich dann ein Mirror bei euch in der Zentrale und ein lokale beim Kunden anbieten, damit die Pakete nicht x-fach durchs VPN müssen.
Ich habs mein Debian-Mirror ungefähr nach folgender Anleitung eingerichtet: https://stoertebecks.com/debian-mirror-aufsetzen/
Gruß
bloody
Dann MUSS natürlich die Kapazität vom VPN reichen.
An meinen vorgeschlagenen Lösungen halte ich dabei fest.
Je nachdem wieviele pro Kundennetzwerk, würd sich dann ein Mirror bei euch in der Zentrale und ein lokale beim Kunden anbieten, damit die Pakete nicht x-fach durchs VPN müssen.
Ich habs mein Debian-Mirror ungefähr nach folgender Anleitung eingerichtet: https://stoertebecks.com/debian-mirror-aufsetzen/
Gruß
bloody
Hallo,
@bloodstix,
danke für den Link...lese ich mal quer...
Das die Info mit dem autarken Netz gefehlt hat, ist Ansichtssache
Ich dachte mit der Anforderung von mir
Aber okay, man kann nie genug Informationen liefern...
brammer
@bloodstix,
danke für den Link...lese ich mal quer...
Das die Info mit dem autarken Netz gefehlt hat, ist Ansichtssache
Ich dachte mit der Anforderung von mir
wenn die Rechner über einen sowieso vorhandenen VPN Tunnel ihre Updates ziehen.
sei das Grund genugAber okay, man kann nie genug Informationen liefern...
brammer
Hallo,
@Dani
ob es gleich ein CDN sein muss .... schaun wir mal , aber danke für den Hinweis.
Die Last auf unseren VPN Verbindungen macht mir mittelfristig noch keine Sorgen.
brammer
@Dani
ob es gleich ein CDN sein muss .... schaun wir mal , aber danke für den Hinweis.
Die Last auf unseren VPN Verbindungen macht mir mittelfristig noch keine Sorgen.
brammer
@brammer
Gruß,
Dani
ob es gleich ein CDN sein muss .... schaun wir mal , aber danke für den Hinweis.
Das sicher nicht. Wir haben auch klein angefangen (2 Server mit LB im RZ) und nutzen inzwischen (3 Jahre später) ein CDN. Da dessen Realisierung deutlich günstiger war als bestehende Daten- bzw. VPN-Verbindungen aufzustocken und Spitzen abzufangen. Ich dachte evtl. habt ihr sowas in Planung bzw. im Einsatz für andere Themen.Gruß,
Dani
Hallo,
@Dani
das bin ich am abklären.... aber die Mühlen mahlen langsam .....
brammer
@Dani
evtl. habt ihr sowas in Planung bzw. im Einsatz für andere Themen.
das bin ich am abklären.... aber die Mühlen mahlen langsam .....
brammer
Hey,
schau dir auch mal Ansible oder Puppet an - wenn du das von Anfang an nutzt, wird die Verwaltung später viel einfacher, wenn es mehrere Server werden!
Wo die Updates dann gezogen werden ist relativ egal; würde intern mit dem apt-cacher beginnen und dann ggf. einen Debian-Mirror einrichten.
Gruß
schau dir auch mal Ansible oder Puppet an - wenn du das von Anfang an nutzt, wird die Verwaltung später viel einfacher, wenn es mehrere Server werden!
Wo die Updates dann gezogen werden ist relativ egal; würde intern mit dem apt-cacher beginnen und dann ggf. einen Debian-Mirror einrichten.
Gruß
