_n4p_

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)

Nachdem hier quasi schon alles empfohlen wurde .. Hetzner bietet mit den Storage Boxen noch eine Alternative. Der Speicher kann unter anderem einfach als Netzlaufwerk eingebunden werden. Außerdem gibt es automatisierte Snapshots und sie bieten einen AV-Vertrag nach Artikel 28.

Richtig Budgie basiert auf Gnome. Früher war ich zwar kein Gnome Fan aber das sieht schon ganz brauchbar aus. Die Skalierung funktioniert bei dem 4K Display allerdings eher so mittel-gut. Gnome typisch kann man nur 100, 200 und 300% auswählen. 200% ist dann schon wieder zu groß, das Problem lässt sich aber mit xrandr beheben. Das kommt dann im nächsten Teil. oh-my-zsh kenn ich schon, muss mich nur mal tiefer damit beschäftigen. Kommt wohl auch beim nächsten mal, zusammen mit tmux und ranger. Für Tiling-WMs bin ich zu faul xD

Im letzten Teil haben wir die Grundinstallation geschafft und konnten das WLAN-Modul zur Mitarbeit überreden. Diesmal soll das System ... nunja "arbeitsfähig" werden. Kleinkram Zunächst werden ein paar nützliche Helfer installiert. dhcpd - ist einfacher als immer nach der korrekten Konfiguration zu fragen zsh - coole Shell ist cool, dazu ein anders Mal mehr ntpd - um an der Uhr drehen zu lassen acpid - Laptop zuklappen -> Laptop schläft ein. Prima (ab und an gibt es Probleme beim aufwachen) htop - welcher Prozess braucht hier eigentlich soviel CPU/RAM? Da man ja nicht als root arbeiten soll - an einigen Stellen wird das auch aktiv verhindert - wird noch ein neuer Benutzer angelegt. Der kommt in die Gruppen audio, video und wheel. Damit er hören und sehen kann. Der wheel Gruppe wird noch sudo erlaubt. Das ist am Laptop zwar egal da es eh nur den einen Nutzer geben wird und man es auch nur dem spezifischen Benutzer erlauben könnte, aber naja .. alte Gewohnheiten. Ein Wellensittich Hab ich das Arch-Wiki schon gelobt? Nicht nur das man zu allem eine Anleitung zur Installation und Konfiguration bekommt, es gibt sogar sinnvolle Übersichten zu verfügbaren Packeten nach Themengebieten. Wenn man also nicht weiß welche Desktopumgebung mit welchem Windowmanager man möchte kann man sich hier einen aussuchen. Nun mag es etwas faul oder einfallslos wirken, aber der erste Eintrag in der Liste gefällt mir. Budgie .. es gibt eigentlich nicht viel zu sagen, man findet Dinge da wo man sie erwartet, oder im ersten Moment halt nicht, weil gnome-control-center und budgie-extras noch nicht installiert sind. Das Ding wirkt jedenfalls schön aufgeräumt. Doch damit man das selbst beurteilen kann müssen ein paar kleinere Pakete wie xorg, mesa, Grafiktreiber, ein Display Manager und Audiokram wie alsa und pulseaudio installiert werden. Das funktioniert alles überaschend problemlos. Die üblichen Verdächtigen Mittlerweile ist es spät und so ein leerer Desktop ist nun auch recht langweilig. Also schnell noch Chromium, VLC und Nautilus installiert. Youtube läuft, Musik und Videos vom Windows-PC im Netzwerk kann man auch ansehen. Prima. Netflix .. ne geht nicht ... War ja auch zu einfach. Netflix braucht eine Erweiterung für Chromium - chromium-widevine. Dies gibt es allerdings nur im AUR. YAY - AUR Im Arch User Repository findet man letztlich alles das es nicht ins offizielle Repo geschafft hat. Das ganze funktioniert so ähnlich wie die FreeBSD Ports. Nur das die Pakete hier in einem GIT liegen. Zur Installation wird das entsprechende Paket vom Server geklont und mit makepkg "installiert". Auch für diese Aufgabe gibt es Helferlein. YAY zum Beispiel. Da auch das ein AUR-Paket ist, muss es natürlich zunächst auf dem beschriebenem Weg installiert werden. Danach kann man weitere Pakete aus dem AUR einfach mit yay paketname installieren. Makepkg ist dann übrigens so ein Programm das nicht als root ausgeführt werden möchte. Ich erwähne das, weil ich es regelmäßig vergesse und yay immer erstmal als root klone. Ein Terminal für den Desktop Derweil nervt es ungemein den Desktop jedesmal für ein paar Shell-Befehle zu verlassen. Dafür gab es doch auch ein paar Lösungen .. Früher hab ich dafür eTerm benutzt - E16 fand ich ziemlich gut, die neue Version müsste ich irgendwann mal anschauen. Aber gut, ohne enlightenment kein eTerm, was gabs noch? xterm! .. Ja nun .. ähm pacman -R xterm (u)rxvt ereilte das gleiche Schicksal. Warum? Die Schrift ist auf dem Display einfach irrsinnig winzig. Gewonnen hat vorerst alacritty. Temperaturprobleme Nach einer Weile youtube schauen wundert man sich eventuell warum der Laptop ein Loch in den Tisch brennt. Er wird unfassbar heiß. Nach der Installation von sensors und xsensors hat man zumindest die Gewissheit, sich das Problem nicht einzubilden. htop ergänzt das Bild mit 60-90% CPU-Auslastung und einem load um 5 herum. Tendenz steigend. Das war in dem Moment aber vermutlich eine Auswirkung des Powermanagments. Nach etwas Recherche und powertop ist einigermaßen klar was hier das Problem ist. Linux reduziert den CPU-Takt deutlich später als Windows, muss es aber irgendwann auf jeden Fall tun. Ab dem Moment steigt der load, da die CPU ja nun langsam ist. Durch hohen load wird die CPU wieder beschleunigt sowie es etwas Reserven gibt. Das Gerät pegelt sich dann langsam um die 80°C ein. Der Fairness halber muss hier aber erwähnt werden, das es unter Windows dann gern mal Probleme gab Videos flüssig darzustellen. Bluetooth für Anfänger Eigentlich wollte ich nur meine Kopfhörer mit dem Laptop koppeln. Das Bluetooth-Icon wird ja angezeigt und scheint auch eingeschaltet zu sein. Kopfhörer werden mal gefunden und können nicht koppeln, bleiben gleich unauffindbar oder können zwar koppeln aber dann nicht verbinden. Im Arch-Wiki findet man dann den Hinweis pulseaudio-bluetooth zu installieren falls das noch nicht passiert ist. Ne, das war es nicht .. Nach einer Ewigkeit gefummel mit bluetoothctl auch keine neuen Erkenntnisse außer Fehlermeldungen der obskureren Art. error updating services: Host is down (112) Die führen dann aber tatsächlich ins Arch-Forum und zu dem Hinweis doch mal dmesg |grep bluetooth nach sinnvollen Fehlermeldungen abzusuchen. Und tatsächlich konnte die Firmware nicht geladen werden. Wie ich dann aus diesem Post lernte, gibt es von Lenovo zwar keine passende Firmware allerdings funktioniert die von Acer auch ganz prima. .. Firmware

Doch in dem Fall schon. Ich hab quasi von Anfang an (als er die Frage in der Chatbox gestellt hat) gesagt das es ein Problem mit dem DNS ist. Das zeigt ja auch der Screenshot. Dann schreibt er hier plötzlich was von Gateway. Die Antworten auf Chief Wiggums Fragen zeigen ja das er NICHT verstanden hat was das Problem war oder er Begriffe völlig durcheinander wirft. Das an sich ist nach 2 Monaten Ausbildung keine Schande. Aber "Ich habe gemacht was man mir gesagt hat und jetzt geht es" zeigt ja das es hier KEINEN Lernerfolg gab. Einfach zugeben das man keine Ahnung wäre völlig ok. Nur scheinbar in voller Überzeugung Käse erzählen ist so .. Aber hey, ok .. @Chev Chellios Mal ganz grob erklärt: Damit ein Computer einer Domäne - genauer einem AD - beitreten kann, muss der Computer wissen mit welchem Server er über diesen Beitritt verhandeln soll. Dazu stellt er seinen bekannten DNS-Servern bestimmte Fragen. Zum Beispiel fragt er den DNS nach der IP für "_ldap._tcp.deine-domäne.intern". Kennt der befragte DNS diese IP nicht, scheitert der Beitritt. Ist der DNS nicht erreichbar, scheitert der Beitritt. Es wird allerdings nicht nur die eine Frage gestellt, und nicht alle müssen eine richtige Antwort ergeben. Anschließend wird mit dem angegebenen Benutzer und Passwort eine Authentifizierung versucht. Auf dem AD-Server ist es (in deinem Fall) sinnvoll die Adresse 127.0.0.1 als DNS anzugeben, damit er selbst sein AD findet. Normalerweise gibt man dem Domaincontroller als DNS einen anderen DNS Server (eigenständiger DNS, anderer Domaincontroller). Die Adresse 127.0.0.1 ist das sogenannte Loopback-Interface, alles was dort rausgeschickt wird, kommt wieder zurück. Auf dem Domainencontroller funktioniert das, weil dort ein DNS vorhanden ist und antworten kann. Beim Client ist kein DNS installiert und daher scheitert generell die Namensauflösung und speziell kann natürlich auch die Domäne nicht gefunden werden. Ein externer DNS wie 8.8.8.8 oder 1.1.1.1 helfen auch nicht, da die nichts von deiner Domäne wissen können. Ein Router oder Gateway ist bei deinem Setup an dem Prozess nicht beteiligt.

Hexenwerk!

warum nicht einfach implode um das Array-Elemente in einen String zu schreiben?

Eine IPv4 Adresse besteht aus einem Netz- und einem Hostanteil. Die Subnetzmaske definiert nur die genaue Aufteilung der beiden Teile. So genau sollte man begrifflich schon sein. Ob man nun 192.168.164.0/24 oder 192.168.164.0-192.168.164.255 schreibt ist vollkommen gleichwertig. Ich verstehe nicht wo ihr da Interpretationsspielraum seht. Da steht ja das das der gegebene Adressbereich ist und nicht "das netz in dem die Adressen 192.168.164.8 bis 192.168.164.100 liegen soll in Teilnetze aufgeteilt werden". Letztlich kann man auch aus 2 gegebenen Adressen die Subnetzmaske/Präfixlänge errechnen die man braucht damit beide in einem Netz liegen.

Zunächst mal. Klassenbasierte IP-Adressbereiche gibt es nicht mehr .. seit 1994 glaub ich Das das einem ehemaligen Klasse-C Netz entspricht darf als Zufall betrachtet werden. Der Bereich 10.200.50.0-10.200.50.255 ist auch ein /24er Netz. Zu deiner Frage. Man kann das ausrechnen. Eine IPv4 ist 32 Bit lang, jedes Oktett besteht aus 8 Bit. Da sich in der Aufgabe die ersten drei Oktette nicht ändern, kann man einfach 3*8 rechnen. Hat man einen Bereich wie 172.16.32.0-172.16.47.255 wird es etwas schwieriger. Hier ändert sich das dritte Oktett. Man subtrahiert nun einfach 32 von 47. Also benötigen wir 20 Bits für die Netzmaske (8+8+4).

kleiner denkanstoß: der gegebene Adressbereich ist ein /24er Netz. Um das Netz in 4 gleich große Teile aufzuteilen "braucht" man 2 weitere Bits vom Hostanteil für den Netzwerkteil (00,01,10,11).

Gesucht ist ein Wert der um 25% reduziert 390 ergibt. Anders gesagt die 25% von X sind die Leistungsreserve, nicht 25% von 390.