Zum Inhalt springen

_n4p_

Mitglieder
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    1.326

  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    14

 Inhaltstyp 

Blogeinträge von _n4p_

  1. _n4p_

    DIY NAS

    Von _n4p_,

    Vorher
    Der Plan mal wieder ein NAS zu bauen schwirrt schon seit längerem durch meinen Kopf. Alles auf dem PC zu lagern um das Dokument dann doch vom Laptop aus zu bearbeiten oder den Film dann über die PS4 zu sehen ergibt halt auch nur begrenzt Sinn. Also dann dochmal den alten Shuttle-Barebone aus der Schrott-Ecke auf Arbeit mit nach hause genommen, ne alte Grafikkarte und etwas RAM aus der Wühlkiste genommen und zusammengebaut. Positiv: Das Gerät schaltet ein und läuft offenbar auch. Negativ: Es produziert kein Bild, zumindest nicht an meinem Monitor. Was an allem Möglichen liegen könnte. Die Grafikkarte könnte selbst kaputt sein, der DVI auf DP Adapter funktioniert nicht in der benötigten Richtung. Einen anderen Monitor oder eine weitere Grafikkarte zum testen ist aber nicht vorhanden. Ende der Geschichte, bauen wir also kein NAS.
    Planänderung
    Doch. Sonst wäre das hier ja albern. Ne Grafikkarte kaufen um festzustellen das es was anderes ist, wäre auch quatsch. Aber vor einigen Wochen durch Zufall gesehen das jemand ein NAS aus nem RaspberryPi 4 gebaut hat. Die Idee an sich ist ja nix spektakulär Neues. Neu für mich war der 4xSATA-Hat. 

    Es gibt sogar ein Bündel aus SATA-Hat und einem Gehäuse, in dem neben Raspi und Hat auch noch 4 2,5 Zoll SATA-Platten Platz finden. Da ich aber nur einige 3,5 Zoll HDDs übrig habe, war das Gehäuse keine Option. Im weiteren Verlauf der Suche bin ich dann auf den NanoPi M4 gestoßen, bzw. zuerst auf den SATA-Hat für diesen.

    Der NanoPi wird von einem RK3399 angetrieben, daher kann das Board sogar PCIe. Während der Raspi-Hat 2 USB Kanäle nutzt, nutzt der NanoPi-Hat also PCIe. Außerdem ist der RK3399 doch schneller als der RaspberryPi 4. Dafür ist der NanoPi M4v2 auch etwas teurer. Mit Kühlkörper, SATA-Hat und eMMC Karte kostet der Spaß etwa 120 € inkl. Versand. Da kommt dann wohl auch noch etwa 25 € Einfuhrumsatzsteuer drauf. Für nur 20 € mehr hätte man das auch gleich bei Antratek bestellen können. Aber den Shop hab ich erst später gefunden. Das gesamte Konstrukt könnte dann so aussehen.

    Der SATA-Hat versorgt auch gleich den NanoPi mit Strom. Mit dem Molex-Anschluss auf dem Hat kann man auch die Festplatten mit Strom versorgen. Um 4 Festplatten zu betreiben sollte man den Hat aber mit ATX-Netzteil betreiben, dazu kann man den 4-poligen Anschluss auf dem Board nutzen.
    Ein passendes Gehäuse
    Nach einigen verworfenen Ideen - selbst defekte QNAPs gehen auf ebay für jenseits der 150 € Marke weg - werde ich das alte Barbone von Shuttle ein wenig umbauen. Dazu habe ich zunächst einen Festplattenkäfig für 5 3,5 Zoll Platten bestellt. Da ich das Original-Netzteil aus dem Barbone weiter nutzen werde, kann ich nur 4 Platten einbauen, aber mehr wollte ich sowieso nicht. Außerdem möchte ich versuchen den CPU-Kühler des Gehäuses zu nutzen. Damit ist allerdings die oben gezeigte Konfiguration unmöglich, da die CPU des NanoPi auf der Unterseite verbaut ist. Ich muss also den NanoPi umdrehen und den SATA-Hat dann also irgendwie neben dem NanoPi einbauen. Dafür benötigt man aber nur ein paar Kabel und anderen Kleinkram. 

    Und zu guter Letzt möchte man das Gerät auch einschalten können. Da ich ein ATX-Netzteil benutze, könnte man einfach am Mainboard-Stecker - der ja nicht genutzt wird - Pin 16 und 18 Überbrücken. Da das Netzteil dann daerhaft läuft, ist das nicht die beste Lösung. Es gibt sogar schon fertige Schalter für diesen Einsatzzweck. Die schönste Variante die ich gefunden habe. 

    Wartezeit verkürzen
    Da einige Teile eine Lieferzeit von 2-4 Wochen haben. Kann ich mich in der Zwischenzeit ein wenig um die Software und den Umbau des Barebone-Gehäuses kümmern. Zum Umbau wird es in einem nächsten Teil ein paar Bilder geben, aber viel zu sagen gibt es da nicht. Die Software könnte aber noch spannend werden. Es gibt zwar diverse fertige Images für den NanoPi, aber die mag ich nicht. Es gibt allerdings auch ein paar Images aus dem Arch Linux ARM-Projekt für den RK3399. Der erste Schritt wäre nun diese erstmal unter QEMU zu testen und Software nachzuinstallieren bzw runter zu werfen. Der NanoPi hat zwar auch einen SD-Slot von dem er booten kann, das Ziel ist aber die eMMC Karte für das Betriebssystem zu nutzen. Dazu bietet FriendlyArm zwar ein Tool an das ein Linux-Image von der SD-Karte auf die eMMC schreibt. Allerdings muss man dafür sein eigenes Linux in ein Image mit diesem Tool verpacken. Die Anleitung für interessierte gibt es hier: http://wiki.friendlyarm.com/wiki/index.php/EFlasher#Make_Your_Own_eFlasher
  2. _n4p_
    Einleitung
    Die grundlegende Frage gleich vornweg: Warum sollte man Docker auf einem Windows Server betreiben?
    Nunja, weil man es kann. Außerdem besteht die Infrastruktur bei den meisten unserer Kunden aus MS SQL-Server und Windows Servern auf denen unsere Software installiert wird. Hier könnte man nun argumentieren, dass unsere Software "nur" PHP und Apache benötigt und das zusammen mit PostGreSQL oder ORACLE durchaus auf Linux laufen könnte. Ja, ist richtig, wir möchten aber nicht auch noch irgendwelche Linux Installationen bei unseren Kunden pflegen.
    Sucht man, naiv wie man ist, einfach mal nach "docker windows", landet man früher oder später bei "Docker CE for Window". Hat man das installiert und den ersten Container gestartet, wird einem auffallen das die Container nicht beim Booten starten. Da ist auch nichts falsch konfiguriert, das soll so sein. Dafür gibt es sicherlich Gründe. Diese Version ist für Entwickler gedacht, die Docker auf ihrem Windows 10 PC betreiben wollen. Wollen wir aber gar nicht …
    Installation
    Also installieren wir mal das richtige
    PS> Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force PS> Install-Module -Name DockerMsftProvider -Force PS> Install-Package -Name docker -ProviderName DockerMsftProvider -Force Danach möchte der Server einmal neu starten und wir können mit docker version schauen ob das funktioniert hat.
    PS C:\> docker version Client: Version: 18.09.0 API version: 1.39 Go version: go1.10.3 Git commit: 33a45cd0a2 Built: unknown-buildtime OS/Arch: windows/amd64 Experimental: false Server: Engine: Version: 18.09.0 API version: 1.39 (minimum version 1.24) Go version: go1.10.3 Git commit: 33a45cd0a2 Built: 11/07/2018 00:24:12 OS/Arch: windows/amd64 Experimental: true An der Stelle konfigurieren wir den Dienst erstmal ein wenig. Das kann man prinzipiell auch über eine json-Datei erledigen. Anleitungen dazu findet man genug. Man kann die Parameter aber auch direkt dem Dienst übergeben.
    PS E:\> Stop-Service Docker PS E:\> Remove-Service Docker PS E:\> New-Service -Name Docker -DisplayName "Docker Engine" -StartupType Boot -BinaryPathName "C:\Program Files\Docker\dockerd.exe --run-service -H npipe:// -H 0.0.0.0:2375 --data-root=E:\docker --experimental" PS E:\> Start-Service Docker Für Remove-Service benötigt man allerdings PowerShell Version 6. Die gibt es zwar seit August 2018, ist dennoch nicht im Server 2019 enthalten. Nach dem Neustart des Dienstes legt Docker nun seine benötigte Verzeichnisstruktur unter E:\docker an. Und durch –experimental können wir später –plattform=linux nutzen.
    Nun ist es endlich soweit, wir holen unser erstes Image. Normalerweise würde man das einfach mit
    PS> docker pull microsoft/nanoserver erledigen. Das funktioniert zwar, aber ...
    Das was man dann bekommt ist ein Server 2016 SAC Image. Was per se zwar nicht verkehrt ist, aber im ersten Moment auf einem Server 2019 nicht funktioniert. Hier müsste man dem docker run noch ein --isolation=hyperv mitgeben oder man holt ein neues Image. Für Images die zum Server 2019 passen benötigt man spezifische Tags und kann sich nicht auf den Standard :latest verlassen. Images vom Nanoserver und Windows Server Core holen wir mit.
    PS> docker pull mcr.microsoft.com/windows/nanoserver:1809 PS> docker pull mcr.microsoft.com/windows/servercore:ltsc2019 Anschließend verpassen wir den Images noch neue Tags
    PS> docker image tag mcr.microsoft.com/windows/nanoserver:1809 nanoserver:1809 An dieser Stelle können wir auch schon mal einen Container mit einem der Images starten.
    PS> docker run -it --name testdings microsoft/nanoserver powershell Damit bekommen wir eine PowerShell Instanz in dem laufenden Container und können Dinge tun. Updates installieren, wäre eines dieser Dinge. Das erledigt man normalerweise mit sconfig auf der geöffneten PowerShell.
    In den nächsten Teilen bereiten wir die Build-Umgebung vor, basteln uns ein Dockerfile und bewundern das Ergebnis
  3. _n4p_
    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  
  4. _n4p_

    Abenteuer mit Linux - Teil II

    Von _n4p_,

    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
  5. _n4p_

    Abenteuer mit Linux

    Von _n4p_,

    Hinweise
    Dies wird keine Anleitung für Linuxanfänger. Es wird keine Patentrezepte zum Lösen von Problemen geben. In so gut wie jedem beschriebenem Fall wird es alternative Lösungen geben. An einigen Stellen wird etwas Vorwissen vorausgesetzt.
    Motivation
    Als begeisterter Windowsnutzer seit ca 15 Jahren mit etwas Langeweile, habe ich beschlossen mal etwas verrücktes zu versuchen. Die winzige 256 GB SSD meines Yoga 3 Pro war mal wieder übervoll, also wurde endlich mal eine neue gekauft auf die das Windows umziehen sollte. Was lag also näher als der kleinen SSD auf ihre alten Tage noch etwas Spaß zu gönnen. Nebenbei könnte ich auf die Art die Linuxkentnisse etwas vertiefen und sehen wie viel Spaß Linux auf dem Desktop beziehungsweise Laptop macht. Zum Einen ist dies nicht der erste Ausflug in die Linuxwelt. Erste Versuche wurden zu Zeiten von Debian 2/3 unternommen. Anfangs noch mit SuSE und Red Hat um dann recht schnell bei Debian zu landen und einige Jahre dabei zu bleiben. Zum Anderen habe ich auch beruflich ein paar Linuxserver, mit unterschiedlichen Distributionen, zu verwalten.
    Fragen vor dem Anfang
    Die wichtigste oder unwichtigste Frage am Anfang ist welche Distribution es werden soll. Schaut man bei Distrowatch vorbei versinkt man schnell in einer Unmenge an Varianten. Unter Hauptdistributionen findet man eine Liste der populärsten Distributionen mit einer groben Unterteilung nach Komplexität. Da schon etwas Erfahrung mit Linux vorhanden ist und ich auch nichts komplett vorgekautes benutzen wollte, hab ich mich für Arch Linux entschieden. Einige Server auf Arbeit laufen auch schon damit. Es ist also kein vollkommenes Neuland.
    Die Installation
    Zur Installation gibt es nicht viel zu sagen. Es gibt im Arch-Wiki eine ausführliche Anleitung, der man problemlos folgen kann sofern man lesen und tippen kann. Ein kleiner Stolperstein liegt in der Partitionierung. Früher hab ich beispielsweise /usr auf eine eigene Partition ausgelagert. Unter Arch funktioniert das nicht, da /bin und /sbin nur Symlinks auf /usr/bin und /lib sowie /lib64 Links auf /usr/lib sind. Danach fangen dann die Probleme an.
    Das erste mal booten
    Was zuerst auffällt ist die winzige Schrift in der Konsole, immerhin hat das Yoga 3 Pro ein QHD+ Display bei gerade mal 13 Zoll Diagonale. Zum Glück hatten schon viele ähnliche Probleme und es gibt auch dazu einen Artikel im Arch Wiki.
    Danach möchte man eventuell noch etwas mehr Software installieren. Das wird aber erstmal nichts. Aus Gründen wird der "falsche" Treiber für das WLan-Modul geladen. Der falsche Treiber landet also auf der Blacklist. Ohne WLan wird es allerdings schwierig den richtigen Treiber zu bekommen. Eine Lösung dafür ist einfach nochmal das Installationsmedium zu booten und in das installierte System zu "chrooten". Im Installationssystem ist auch der richtige Treiber verfügbar und kann in das Zielsystem installiert werden. Ist das alles geschafft, darf man dann noch etwas lernen. Es gibt noch "rfkill", mit dem man Bluetooth und WLan ein- beziehungsweise ausschalten kann/darf/muss. Nun kann man das WLan mit "wifi-menu" oder "wpa_supplicant" konfigurieren und weitere Software installieren.
  6. _n4p_

    NAS ohne PI

    Von _n4p_,


    Homelab
    Einige haben ja DIY NAS gelesen und ich wurde auch schon gefragt ob da noch was passiert. Ja ein paar Dinge sind passiert. Diverse Gehäuseteile wurden gekauft einige wurden gedruckt. CPU Kühler für den Shuttle-Barbone wurden gekauft und modifiziert um auf dem Nano PI Platz zu finden. Und irgendwann ist man an dem Punkt das ganze mal testhalber einzuschalten und enttäuscht zu werden. Android läuft auf dem PI prima, die getesteten Linuxvarianten eher "meh". Der NanoPI versorgt nun mit Android 11, einem Touch-Display und ein paar Verstärkermodulen eine Küche mit Spotify, Audible, Youtube, ..
    Aufmerksamen Lesern ist sicher nicht entgangen das es nun offenbar kein NAS gibt. 
    Also ja schon, aber es ist nicht mehr so Low-Power wie anfangs gewollt war.
    Neue (alte) Hardware
    Während and dem Barebone Gehäuse für den PI gebastelt wurde ist ein gebrauchter Supermicro Server eingezogen. Darauf liefen - oder auch nicht - zunächst einige Hypervisor (ESXi, HyperV, Proxmox). Die ursprüngliche Ausstattung war dann auch bald zu wenig und es gab einige Upgrades:
    2x L5640 (6 Kern "Low-Power") 6x 16GB DDR3-1066 ECC REG Anfang des Jahres hat sich dann das alte "Datengrab" - eine externe 4TB Platte - verabschiedet. Dies rückte das NAS Projekt mal wieder in den Fokus. Für einen niedrigen 4-stelligen Betrag wurden dann einige Festplatten besorgt.
    Geplant war dann eigentlich den RAID-Controller an eine VM im Proxmox durchzureichen und dort Truenas zu installieren. Truenas beziehungsweise ZFS allgemein benötigt direkten Zugriff auf die Datenträger ohne einen RAID-Controller. HBA sind hier das Mittel zum Zweck, einige RAID-Controller kann in den IT-Mode umflashen. Leider mag der Controller weder den IT-Mode noch war das Passthrough wirklich erfolgreich.
    Allerdings bietet Truenas Scale auch eine auf KVM basierte Virtualisierung und k8s basierte Container-Apps. Also weg mit Proxmox und Truenas direkt installiert, Glücklicherweise bot das Supermicro-Board genug SATA Ports um auf den Controller verzichten zu können. Beachten muss man hierbei, daß der Datenträger auf dem Truenas installiert wird nicht weiter zur Verfügung steht. Eine Installation auf einem USB-Stick ist nicht empfehlenswert, man benötigt also am besten eine kleine SSD zur Installation.
    Nach der Installation und Ersteinrichtung des ZPools wird man von einem fröhlichen Dashboard begrüßt.

    Für den Heimgebrauch kann man durchaus auf L2-ARC und slog-Device verzichten. Die Anforderungen für einen brauchbaren slog übersteigen die Fähigkeiten normaler SSDs ohnehin. Wenn man also nicht grad ein paar Enterprise-SSDs rumliegen hat, lässt man das besser. Der L2-ARC hilft nur wenn der ARC voll läuft oder zu klein für das Working-Set ist. Einen L2-ARC kann man einfach nachrüsten falls er wieder erwarten doch notwendig wird. Wobei selbst dann mehr RAM für einen größeren ARC sinnvoller ist.
    Was nun?
    Einerseits hat das NAS nun mehr Leistung als mit dem NanoPi möglich gewesen wäre, dafür steht kein Proxmox Server mehr zur Verfügung. Wie schon gesagt bietet Truenas Scale eine rudimentäre Schnittstelle zu KVM Virtualisierung und App-Container über k8s, in Freenas und Truenas Core wird/wurde das über die FreeBSD eigenen Jails gelöst.
    Der Truenas eigene App-Pool wächst immer weiter und bietet neben üblichen wie NextCloud und PLEX auch beispielsweise miniIO. Man kann aber auch eigene Container importieren oder den sehr umfangreichen Truecharts Katalog nutzen.
    Für das Heimnetz stellt Truenas nun einige Dienste bereit

    Über einen externen Proxy und VPN werden einige der Dienste auch nach außen freigegeben, so kann man beispielsweise den codeserver von jedem beliebigen Browser nutzen.
    Neue (neue) Hardware
    Leider war diese Hardwarekonfiguration tatsächlich sehr weit von stromsparend entfernt. Ohne Last verbrauchte das System zwischen 150 und 170 Watt. Spitzenverbrauch lag bei 230 Watt. Da das System dauerhaft laufen soll war das schlicht zu viel. Tatsächlich hat das System meinen Stromverbrauch in etwas über 6 Monaten mehr als verdoppelt.
    Neue Hardware ist deutlich energieeffizienter, also mal schauen was es so gibt. Leider ist die alte Hardware so alt, daß nichts davon in einem neuen System nutzbar wäre. Die Alder-Lake Plattform war zum Zeitpunkt des Wechsels sehr verlockend. 
    Die Wahl fiel letztlich auf:
    64 GB DDR4 RAM in 2 Modulen Core i5-12500T B660 Mikro-ATX Board  Nach einiger Wartezeit und etwas RAM aus einem alten Desktop sieht das dann so aus.

    Der Stromverbrauch des neuen Systems liegt nun bei 75-80 Watt und 120 Watt unter last. Nicht perfekt aber besser. Beim aktuellen Stromverbrauch muss man auch bedenken, daß Truenas die Festplatten nicht schlafen legt und diese damit mindestens 20 Watt bei Zugriffen eher 40 Watt verbrauchen.
     
  7. _n4p_
    Dockerfile
    Damit man nicht mit jedem Container alles neu machen muss, kann man sich über Dockerfiles eigene Images erzeugen. Die hier gezeigte Version ist mehr oder weniger die finale Version. Davor gab es natürlich diverse Fehlversuche sei es wegen eigener Fehler oder weil man manche Dinge auch einfach nicht vermutet hätte. Unter Windows Nanoserver gibt es beispielsweise gar kein msiexec und das msiexec vom Server Core schreibt die Registryeinträge gar nicht oder irgendwohin wo sie später nicht gefunden werden. Mit setx kann man zwar globale Umgebungsvariablen setzen, startet man den Apache aber als Dienst, wird die Pfadeinstellung dennoch nicht genutzt.
    # Wir benutzen unser schon gepulltes Windows Servercore Image FROM servercore:ltsc2019 COPY install /install # Installiert die ODBC Treiber im Image # Wer hier eine Ausgabe zum Debuggen will kann noch "/l! out13.log" anhängen RUN ["msiexec", "/a C:\\install\\msodbcsql_13.msi", "/qn"] RUN ["msiexec", "/a C:\\install\\msodbcsql_17.msi", "/qn"] # Installation von VC Redist - 15 wird bei Server 2019 nicht benötigt RUN ["C:\\install\\vc_17.exe", "/quiet", "/install"] RUN ["C:\\install\\vc_13.exe", "/quiet", "/install"] # Die Registry-Datei für die ODBC Treiber importieren RUN "reg import C:\\install\\odbc.reg" # install brauchen wir nicht mehr RUN "RMDIR /S /Q C:\\install" # /instantclient entspricht dann C:\instantclient im Image COPY instantclient /instantclient # einfach großartig - wenn jemand eine Idee hat wie ich Apache als Service erklären kann wo der instantclient liegt ... ENV PATH="C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\ContainerAdministrator\AppData\Local\Microsoft\WindowsApps;C:\instantclient" # Apache usw. kopieren - *1 COPY webapp /webapp WORKDIR /webapp # wir möchten mit dem Container reden EXPOSE 80 # kopieren von php und der php.conf ins Apache config Verzeichnis - *2 COPY php/php /webapp/php COPY php/php.conf /webapp/Apache24/conf/extra # zum Testen/Debuggen #ENTRYPOINT ["cmd.exe"] # und los geht’s ENTRYPOINT ["C:\\webapp\\Apache24\\bin\\httpd.exe"] Das Dockerfile kommt dann mit in das Build-Verzeichnis und das neue Image kann mit folgendem Befehl erzeugt werden.
    PS E:\build\>docker build -t test . Mit
    PS E:\build\>docker run -it -p 80:80 --name test_container test starten wir den Container und prüfen das alles wie gewünscht funktioniert. Ist das der Fall teilen wir das Dockerfile in 3 Dateien. Das Dockerfile wird dann bei *1 und *2 aufgeteilt. Der erste Teil bleibt wie er ist und wir nennen das Dockerfile core2019. Und bauen ein Image daraus.
    PS E:\build\>docker image build -t core2019 -f .\core2019 . Das zweite Dockerfile sieht dann so aus
    FROM core2019:latest COPY webapp /webapp EXPOSE 80 und das dritte so
    FROM apache_core2019:latest COPY php/php /webapp/php COPY php/php.conf /webapp/Apache24/conf/extra WORKDIR /logodata ENTRYPOINT ["C:\\webapp\\Apache24\\bin\\httpd.exe"]
    Ich habe die Dockerfiles nach dem Image benannt das sie erzeugen. Die weiteren Images baue ich also mit
    PS E:\build\>docker image build -t apache_core2019 -f .\apache_core2019 . PS E:\build\>docker image build -t php_apache_core2019 -f .\php_apache_core2019 . Damit hat man zwar etwas Overhead bei jedem Build, da jedesmal das komplette Verzeichnis zum Buildprozess übergeben wird. Allerdings können wir so sehr einfach andere PHP und/oder Apache Versionen in ein anderes Image packen ohne den Standard zu verlieren oder die grundlegende Installation wiederholen zu müssen.
    Lauf Docker, Lauf!
    Die entstandenen Images kann man nun wieder mit kürzeren Namen taggen und schließlich starten
    PS> docker run --restart unless-stopped -d --name flamara -p 17000:80 -v E:\share\develop:C:\webapp\docroot -v E:\share\config:C:\webapp\docroot\config\ --dns=10.0.0.20 php2019:latest Mit -p mappen wir einen Port des Hosts zu dem freigegebenen Port des Containers. Dann mappen wir mit -v zum einen die Webapplikation selbst ins docroot des Containers und auch die Konfiguration der Software.
    So können wir beliebige Versionen der Software mit der gleichen Konfiguration (Benutzer, Rechte, Datenbankanbindung) in der gleichen Umgebung testen.
    Die nächsten Schritte wären nun, das Ganze mit einem Linux Base-Image zur erstellen und danach automatisierte Builds.
  8. _n4p_
    Vorbereitung
    Als nächstes bereiten wir die Build-Umgebung vor. Wir laden Apache, PHP, passende vc_redist (17 und 13), Microsoft ODBC Treiber 13 und 17, SQLSRV5.3, und einen Oracle Instantclient herunter.
    Ich überspringe an dieser Stelle einige Schritte und zeige nur die endgültige Version. Ihr verpasst aber nichts Dramatisches, der Buildprozess wurde nur einige Male verändert und die Verzeichnisstruktur entsprechend angepasst. Der Sinn oder Unsinn wird dann vermutlich klar, wenn wir uns die Dockerfiles ansehen.
    Also legen wir erstmal folgende Struktur an:
    Build ├───install ├───instantclient ├───webapp │   ├───Apache24 │   └───docroot └───php     └───php In install legen wir die VC Redist Installer und die ODBC Treiber MSI-Pakete ab. Ich habe die umbenannt um sie leichter unterscheiden zu können.
    Den Instantclient kann man einfach entpacken und den Inhalt des instantclient_18_3-Verzeichnisses in instantclient ablegen.
    In php/php wird das heruntergeladene PHP entpackt und in webapp/Apache24 der Webserver. Die httpd.conf nach Belieben anpassen, darauf achten das das DocumentRoot webapp/docroot sein soll und noch eine webapp/Apache/conf/extra/php.conf includieren. Die gibt es zwar nicht, das erledigt dann der Buildprozess.
    Die php.conf kommt nach /php und sieht etwa so aus:
    LoadModule php7_module "C:\webapp\php\php7apache2_4.dll" AddType application/x-httpd-php .php PHPIniDir "C:\webapp\php" DirectoryIndex index.php Nun noch PHP konfigurieren und dann sind die Vorbereitungen abgeschlossen.
    Eigentlich ... also quasi schon ...
    Aus irgendeinem Grund werden die Registry-Einträge für die ODBC-Treiber nicht geschrieben. Weder beim Build noch im laufenden Container. Also erstellen wir noch eine odbc.reg und legen die mit nach /install. Die Datei kann man erzeugen, indem man den Schlüssel exportiert. Dazu kann man kurzzeitig die ODBC Treiber auf dem Host installieren.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

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

Links

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...