Jump to content

_n4p_

Mitglieder
  • Gesamte Inhalte

    891
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    6

_n4p_ hat zuletzt am 11. März gewonnen

_n4p_ hat die beliebtesten Inhalte erstellt!

Über _n4p_

  • Rang
    Reg.-Benutzer

Letzte Besucher des Profils

1.977 Profilaufrufe
  1. Wir nutzen Bookstack für sämtliche interne Dokumentation bis auf Passwörter.
  2. damit nur bestimmte nutzer darauf zugreifen können, muss der samba mitglied deiner Active Directory Domäne sein. Reicht das als Denkanstoß?
  3. 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"?
  4. google ;D fand die idee interessant und hab nach "patchpanel with indicator" gesucht .. tada ;D
  5. Bitte einmal hier nachlesen: https://de.wikipedia.org/wiki/Domain_Name_System#Auflösung_eines_DNS-Requests
  6. this? https://fibertronics-store.com/Cat6-Patch-Panel-24-Port-Rackmount-with-LED-Indicator-PP-C6U8BBH24L.htm
  7. 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
  8. 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.
  9. 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
  10. 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
  11. _n4p_

    Projektidee

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

    Ubuntu installieren

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

Fachinformatiker.de, 2019 SE Internet Services

fidelogo_small.png

if_icon-6-mail-envelope-closed_314900.pnSchicken Sie uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App


Get it on Google Play

Kontakt

Hier werben?
Oder senden Sie eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...

Wichtige Information

Fachinformatiker.de verwendet Cookies. Mehr dazu in unserer Datenschutzerklärung