_n4p_

ca 98% es sei denn das letzte Paket Nutzdaten ist kleiner als 42(46) Byte

Warum kann man mit dem aktuellen AG nicht am 01.02. darüber reden die Kündigungsfrist zu verkürzen? Bei einem Aufhebungsveertrag ist die Kündigungsfrist des Arbeitsvertrages völlig irrelevant. Man könnte sich auch einen Grund für eine fristlose Kündigung suchen. Eventuell gibt es Fehler im Vertrag die man ausnutzen könnte. Und als letztes Mittel, falls der Vertrag das hergibt (eventuelle Vertragsstrafen), einfach nicht mehr zur Arbeit gehen. (gabs hier bei uns schon, allerdings noch in der Probezeit)

ich bin mal so frei und gebe zu, dass ich keine ahnung habe was da berechnet werden soll. Worum geht es hier?

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

Es ging dabei um den Teil mit "AP sind vorhanden". Würde ich mich halt nicht drauf verlassen, dass du nicht doch noch welche kaufen musst. Ich würde eher schreiben das du prüfen musst ob die vorhandenen APs für euer Vorhaben ausreichen. Zum anderen klingen Teile des Antrages so nach "absolute Sicherheit" wird benötigt/wird durch das Projekt realisiert. WPA-Enterprise ist auch nicht absolut sicher. (Evil Twin) Was mir noch fehlt wäre die Frage warum das deine Lösung ist. Welche Alternativen gäbe es und warum sind die weniger gut als WLAN. Dein aktuelles Thema ist nur ein Auftrag. Du sollst ja aber zu einem "komplexen" Problem eine Lösung finden, hier steht die Lösung fest.

hier gibt es eine liste mit treibern https://wireless.wiki.kernel.org/en/users/drivers ich geh mal davon aus es ist ein usb-stick. dann kannst du mit dmesg |grep usbcore sehen welchen treiber du brauchst. beispielsweise usbcore: registered new interface driver rtl8xxxu mit dmesg |grep firmware kannst du überprüfen ob die firmware richtig geladen wurde danach kann das wlan mit wpa_supplicant oder NetworkManager eingerichtet werden

Naja für das Projekt schon. So ein AP kann eine begrenzte Menge an Clients verwalten. Und schon deutlich vor erreichen dieser Grenze bricht die Leistung ein und das Arbeiten macht weniger Spaß als mit langen Netzwerkkabeln.

werden die aktuell nicht genutzt? Wieviel Nutzer soll ein AP bedienen? Wie gut ist die Abdeckung durch die vorhandenen APs tatsächlich? Hier fehlt ein WLAN Controller neben deinem Triple-A. Ein abhörsicheres WLAN? Was genau kann denn verhindern das jemand mit Kismet o.ä. den gesamten WLAN-Traffic mitnimmt? Am Ende installierst du einen Radius und sagst du bist fertig? denke, das reicht nicht.

Atom und Visual Studio Code sollten über snap verfügbar sein

nun, dann mach es halt einfach nicht.

du kannst doch mit slapcat ein ldif exportieren, das dann in Samba4 importiert wird (Theorie, hab ich noch nie gemacht)