_n4p_

Wir nutzen Bookstack für sämtliche interne Dokumentation bis auf Passwörter.

da gibt es diverse anleitungen, sogar im samba wiki.

damit nur bestimmte nutzer darauf zugreifen können, muss der samba mitglied deiner Active Directory Domäne sein. Reicht das als Denkanstoß?

zusätzlich zu dem Einwand bezüglich Grafikkarten und CAD Das liest sich irgendwie total wirr. Erst wird erklärt das es Switche gibt die Dinge tun, dann geht es um Verfügbarkeit und Skalierbarkeit und plötzlich steht da was von Gruppenrichtlinien. Und keiner der Punkte ist verständlich ausgeführt. darüberhinaus: das Problem von langen Wartezeiten, "unflüssiger" Bearbeitung und fehlendem Zugriff von Außen wird hier auf magische Weise durch VDI gelöst. Warum? Alternativen? Kostenrechnung? ----------- vCenter ist kein Hypervisor, ESXi ist der Hypervisor. wenn VMWare (wieder die Frage nach Alternativen) warum dann kein Horizon? oder ist es Horizon und du willst es im Antrag nur "verstecken"?

OK, Ron

google ;D fand die idee interessant und hab nach "patchpanel with indicator" gesucht .. tada ;D

Bitte einmal hier nachlesen: https://de.wikipedia.org/wiki/Domain_Name_System#Auflösung_eines_DNS-Requests

this? https://fibertronics-store.com/Cat6-Patch-Panel-24-Port-Rackmount-with-LED-Indicator-PP-C6U8BBH24L.htm

das tut er auch. aber es gibt so dinge wie dns cache und SOA Records im DNS. https://de.wikipedia.org/wiki/SOA_Resource_Record Speziell die Werte für Refresh, Expire, TTL

Die ursprüngliche SNM ist nicht 255.255.255.0 sondern 255.255.252.0 Weil das Netz das dir am Anfang zur Verfügung steht nur eine endliche Größe hat.

stimmt, Netto zählt auch.

Also ernsthaft kaputt war noch nichts, ein mittleres Problem sind VMware Vorlagen. Die erste angelegte Vorlage ist nun etwas über ein Jahr alt. Das erste was "kaputt" geht ist der arch-keyring. Pakete von damals gibt es nicht mehr und neue bekommt man unter umständen nicht weil die Signaturen nicht mehr stimmen. Etwas nervig. Dann kann man sich erstmal aktuelle Schlüssel besorgen (pacman-key --refresh-keys) und dann den neuen keyring holen (pacman -S archlinux-keyring) Updates hab ich bisher monatlich manuell gemacht. Daher dann auch das "Problem" das jeder Server je nach Paketaktivität mal ne halbe Stunde nur Updates herunterlädt. Ansonsten gab es mal Reibungsverluste mit einer Software die sich auf Fehlverhalten älterer mariadb-Versionen verlassen hat, aber das wäre wohl auch von Debian 9 auf 10 passiert. Bei den Servern mit docker möchte ich auch aktuelle Versionen und beim Rest stört es nicht wenn php plötzlich auf 7.4 updated. Bei kritischen Systemen kann man vor dem Update immer noch n Snapshot machen. Insgesamt bin ich echt zufrieden damit

Was und Warum? In den letzten Monaten wurden die meisten unserer Linuxserver auf Arch-Linux umgestellt. Ein paar Ausnahmen wird es weiterhin geben. vCenter läuft beispielsweise auf der VMWare eigenen Linux-Distribution, andere Software bringt in Form einer virtuellen Appliance auch eigene Linux-Distributionen oder verlangt nach einer spezifischen Distribution mit speziellen Paketen. Jedenfalls sind 11 Server auf Arch-Linux Basis im Einsatz. Eine Update-Runde dauert bei unserer Internetanbindung dann eine Weile. Das Ziel war nun die Angelegenheit zu Beschleunigen. Dafür gibt es prinzipiell mehrere Möglichkeiten. Einen eigenen Arch Mirror aufbauen ein zentraler Cache für Pakete ein verteilter Cache für Pakete Beim eigenen Mirror hat man dann einen Server auf dem alle Arch-Pakete liegen. Für den zentralen Cache lädt ein Server zunächst das Paket um es dann zunächst über das Netzwerk im Cache abzulegen und von dort aus zu installieren. Dafür werden Pakete die alle Server benötigen im verteilten Cache auf jedem Server abgelegt. Pacman Cache Für den zentralen Cache müssten alle Server über NFS o.ä. auf den Server mit dem Cache zugreifen. Vom Aufwand abgesehen, bastelt man sich so natürlich einen Single-Point-of-Failure. Für den verteilten Cache benötigt man nur einen simplen Webserver und ein paar Zeilen Shell-Befehle. Für diesen Zweck genügt darkhttpd vollkommen. Hat man den installiert "konfiguriert" man ihn einfach indem die Systemd Unit angepasst wird. Dann benötigt man noch ein paar Links im Paket-Cache und ist im Grunde fertig. pacman -S darkhttpd systemctl enable darkhttpd nano /etc/systemd/system/multi-user.target.wants/darkhttpd.service systemctl daemon-reload ln -s /var/lib/pacman/sync/*.db /var/cache/pacman/pkg systemctl restart darkhttpd Die Unit sieht dann in etwa so aus. [Unit] Description=Darkhttpd Webserver After=network.target [Service] Type=simple ExecStart=/usr/bin/darkhttpd /var/cache/pacman/pkg --port 9090 --uid http --gid http --mimetypes /etc/conf.d/mimetypes ProtectSystem=full ProtectHome=on PrivateDevices=on NoNewPrivileges=on [Install] WantedBy=multi-user.target Der Pacman-Cache in /var/cache/pacman/pkg wird hier zum WWW-Root. Als Port wurde 9090 gewählt, da auf keinem der Server etwas auf dem Port läuft. Welchen Port man letztlich wählt ist egal. Die Standardoptionen "chroot" und "no-listing" werden entfernt. Mit chroot funktionieren Symlinks nicht und Verzeichnislisting ist fürs Debuggen ganz sinnvoll. Updates Damit die Server nun ihre Pakete von dem vorbereiteten Server erhalten, muss der auf jedem weiteren Server in die Mirrorliste eingetragen werden. Da die Mirrorliste zeilenweise verarbeitet wird, müssen die neuen Einträge an den Anfang der Datei. Server = http://enton.<domäne>.intern:9090 Der Port :9090 ist natürlich durch den vorher gewählten Port vorgegeben. Danach funktionieren Updates wie gewohnt mit pacman -Syu. Mehr Da die Server verschiedene Aufgaben haben, sind auch unterschiedliche Pakete installiert, einige haben docker, andere php oder mariadb oder eine bunte Mischung. Nachdem der Cache eines Servers nun für alle verfügbar ist, bekommen wir aber zumindest Standardpakete (Kernel, ..) für alle weiteren Server nun aber aus dem lokalen Netz. Der Vorgang lässt sich nun für weitere Server wiederholen. Die Mirrorliste wird einfach nur länger. Wenn alle Server ihren Cache freigeben und in jeder Mirrorliste alle Server eingetragen sind, ist dann auch egal, welcher Server mit Updates beginnt. Die nächsten Server sollten mit ihren Updates allerdings auf vorherige Server warten, da sonst die Pakete noch nicht auf den lokalen Servern verfügbar sind und wieder aus dem Netz geladen werden. Als Fallback für neue Pakete oder Pakete die kein anderer Server hat, sollten in der Mirrorliste nicht nur die eigenen Server eingetragen sein. Ein praktisches Tool um die Liste aktuell zu halten ist reflector. Ich habe auf einem der Webserver eine Liste aller lokalen Paketcaches. Aus der Liste und reflector kann man sich vor den Updates dann eine frische Mirrorliste basteln. curl --silent http://kangama.<domäne>.local:9090/liste |grep -v `hostname` && reflector -f 5 -l 5 -c de > /etc/pacman.d/mirrorlist

nein, versuch nicht dran rum zubasteln. das Thema ist für die Tonne.

schlechtes Zeichen. mal versuchen in einen anderen USB port zu stecken