10 Jahre Thailand 

Entries tagged [und]

Update Opensuse Bottle auf Tumbleweed

by Nudels


Posted on Dienstag Mai 04, 2021 at 04:38nachm. in Technik - Administration




Alcapone ist endlich eingetroffen


Nach einem ganzen Monat Zollabwicklung in Bangkok und 2 Tagen Transport nach Atsamat ist meine Entwicklungsumgebung endlich zuhause eingetroffen. 500 Baht Zoll kann ich verschmerzen, denn Alcapone und Clyde haben es faustdick hinter den Ohren. Alcapone ist ein Linux-Server, der als Systementwicklungsumgebung eingerichtet ist und Clyde ist der dazu gehörende Client. Beide sind etwas in die Jahre gekommen, die kaum spürbaren Performance-Nachteile kann ich verschmerzen.




Alcapone - is home again



Alcapone läuft auf der Basis eines NC6220 HP-Compaq-Notebooks, ein Großvater also. Das Betriebsystem ist noch Opensuse Bottle und da ich u.a. die Aircrack-ng Suite als Werkzeug benutzen möchte, ist hier dringend ein Update angesagt. Mir schwebt Tumbleweed vor - wird ja auch ziemlich in den Himmel gelobt. Alte Geräte eignen sich im übrigen hervoragend zur Nutzung der Basisdienste von z.B.: Aircrack-ng. Der Grund liegt in der Treiber- und Firmwarekompatiblität, dazu später mehr. Auf geht es, der Opa bekommt ein frisches Kleid.



Update auf Tumbleweed und Nacharbeiten


Das Neueinrichten  einer Systementwicklerumgebung ist eine sehr zeitaufwendige Angelegenheit, deshalb ist das Anfertigen einer Disc-Image-Copy ratsam. Ich beschreibe das Update hier jetzt so ausführlich, da hinterher doch so einige Überaschungen auf mich zu kamen. Der erste Schritt muss eigentlich nicht sein, denn ich habe ein Disc-Image. Es ist lediglich eine Alternative zur Rekonstruktion für ein Failure.


Wir sichern die alten Repositories



  • mkdir /etc/zypp/repos.d/old

  • mv /etc/zypp/repos.d/*.repo /etc/zypp/repos.d/old


Wir richten die neue Repositories ein



  • zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/oss repo-oss

  • zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/non-oss repo-non-oss

  • zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/debug repo-debug

  • zypper ar -f -c http://download.opensuse.org/update/tumbleweed/ repo-update




Die Source Repositories hinzufügen



  • zypper ar -f -d -c http://download.opensuse.org/tumbleweed/repo/src-oss repo-src-oss

  • zypper ar -f -d -c http://download.opensuse.org/tumbleweed/repo/src-non-oss repo-src-non-oss


Das Ergebnis prüfen



  • zypper lr -u


Upgrade ausführen



  • zypper dup


Das Upgrade ist durch und es sieht nicht nach einem Kapitalschaden aus. Einige ältere Dienste wie pureFtp wurden entfernt, es ist verkraftbar. Bevor es los geht mit den Fine tuning muss die Suse-Firewall konfiguriert werden. Sie ist gut und wird automatisch immer mit installiert, ich werde sie später aber durch den Kernel-Paket-Filter iptables ersetzen. Er bietet mehr Flexibilität. Zu tun ist zunächst:



  • die öffentlichen Netzwerkadapter in der Firewall auf external setzen

  • die öffentlichen Dienste auf external/internal setzen


Es folgt Überraschung Nr.1


ifconfig fehlt in der Standard-Installation. Es wird durch das iproute2util package ersetzt. Es ist nicht weiter tragisch und ich biete einen groben Überblick der Command Pendants:


ifconfig vers. ip



  • list adapters --> ifconfig --> ip a

  • add adapter --> ifconfig eth0 add 192.168.1.5 -->  ip a add 192.168.1.5 dev eth0

  • del adapter --> ifconfig eth0 del 192.168.1.5 -->  ip a del 192.168.1.5 dev eth0

  • chg mac --> ifconfig eth0 hw ether 3c:a6:16:a1:b6:f7 --> ip link set dev eth0 address 3c:a6:16:a1:b6:f7

  • chg mtu --> ifconfig eth0 mtu 2000 --> ip link set dev eth0 mtu 2000

  • en/dis-able multicast --> ifconfig eth0 multicast --> ip link set dev eth0 multicast on

  • txquelength --> ifconfig eth0 txqueuelen 1200 --> ip link set dev eth0 txqueuelen 1200

  • promisc mode --> ifconfig eth0 mode promisc --> ip link set dev eth0 promisc on

  • monitor mode --> ifconfig eth0 mode monitor --> ip link set dev eth0 monitor on

  • en/dis-able allmulticast --> ifconfig eth0 allmulti --> ip link set dev eth0 allmulti on

  • en/dis-able adapter --> ifconfig eth0 down / up --> ip link set eth0 down / up

  • en/dis-able arp --> ifconfig eth0 arp --> ip link set dev eth0 arp on



Network-Manager


Nach einer vollständigen Installation von Tumbleweed, ist in der Regel auch der Network-Manager installiert und grob konfiguriert. Das ist für alte Unix-Linux Hasen ungewöhnlich, denn wenn er läuft, ist der Zugriff auf die Netwerkkonfiguration nach alter Art blockiert, oder wirkungslos. Es geht im Wesentlichen um die Bedienung des Netzwerkes auf der Shell und hierbei im Speziellen um das Starten der Wifi-Verbindung. Deshalb folgt jetzt noch ein Überflug:


Die Konfigurationsdatei findet man im Ordner:  /etc/NetworkManager/system-connections und sie heißt: <ssid-name>.nmconnection


Hier ein Muster für das Wifi-Netz mit der ssid Nils mit einer statischen IP-Adresse bei 192.168.1.8/24 auf dem Gerät wlp2s4 und einen DNS-Zugang bei  OpenDNS:


[connection]
id=wlp2s4
uuid=2957e8d5-6c82-3be7-8299-3b2767d239bf
type=wifi
permissions=
timestamp=1639890507
zone=public

[wifi]
mac-address-blacklist=
mode=infrastructure
ssid=Nils

[wifi-security]
key-mgmt=wpa-psk
psk-flags=1

[ipv4]
address1=192.168.1.8/24,192.168.1.1
dns=208.67.222.222;
dns-search=208.67.220.220;
method=manual

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto


Wenn solch eine Minimalkonfiguration vorhanden ist, läßt sich die Wifi-Verbindung wie folgt starten:


Checke Geräte: nmcli device


DEVICE   TYPE      STATE        CONNECTION
wlp2s4       wifi        connected    wlp2s4
enp16s0     ethernet  unavailable  --
lo               loopback  unmanaged    --


Checke Verbindungen: nmcli connection


NAME    UUID                                                           TYPE      DEVICE
wlp2s4    2957e8d5-6c82-3be7-8299-3b2767d239bf  wifi      wlp2s4
eth0         a3986d28-9c1c-38d6-97a3-e915a386ec7d  ethernet  --


Wie man sieht ist wlp2s4 schon am Wifi bereits angemeldet. Ist dieses nicht der Fall, einfach die nächsten 4 Schritte durchlaufen.


Netzwerk starten: nmcli networking on


Wifi starten: nmcli radio wifi on


Am Wifi anmelden: nmcli --ask device connect wlp2s4


Pasword eingeben: .... und fertig - angemeldet.


Das Ganze läßt sich dann auch in ein Shell-Script verpacken und mit dem SystenV daemon über den Bootlevel starten:


#! /usr/bin/bash

nmcli networking on;
nmcli radio wifi on;
echo "password
" | nmcli --ask device connect wlan-device;
exit 0;


.... der Zeilenumbruch nach dem password, simmuliert uns ein Eingabe-Enter. So läuft der Aufbau zum Wifi automatisch durch.



In diesem Zusammenhang passt auch noch die Erkenntnis, dass die /etc/services nicht mehr dort zu finden ist, wo Du sie eigentlich erwartest. Sie liegt neben anderen jetzt hier:

alcapone:/home/gebaavr/proto # ls /usr/etc
default  lesskey      login.defs  nsswitch.conf  profile.d  securetty  skel        vdpau_wrapper.cfg  xdg
ethers   lesskey.bin  networks    pam.d          protocols  services   SUSE-brand  X11




Es folgt Überraschung Nr.2


Alcapone ist altersschwach und er vergisst Datum und Uhrzeit. Ich brauche den ntp-service. Aber wo zum Teufel ist die ntp.conf?  Wer nacht ntpd und ntp.conf sucht wird enttäuscht - der daemon heißt in Tumbleweed chronyd und die conf entsprechen /etc/chrony.conf. Wer es schnell mag kann die Konfiguration in Yast erledigen. Aus alter Tradition benutze ich den Zeitserver ptbtime1.ptb.de der Physikalisch-Technische Bundesanstalt in Braunschweig. Der chronyd ist bereits eingerichtet und startet zur Bootzeit. Alcapone hat leider keine Möglichkeit die Zeitparameter über die System-BIOS-Oberfläche zu setzen. Hier ein Tip wie man sich Helfen kann, wenn das Booten überhaupt nicht klappt:


Ich habe einen bootfähigen USB-Stick mit einer älteren Linux-Distribution, die auch mit Fantasiezeiten bootet. Beim Booten das rescue system aus dem Bootmenü starten. Wenn die Konsole dann da ist, die Zeit setzen:



  • date -s "YYYY-MM-TT hh:mm:ss"


Nachdem die Zeit gesetzt ist, diese in die Hardware-Clock, also BIOS zurückschreiben:





  • hwclock -wu



...dann reboot ohne Stick

Hier sind die Zeichenpendants für deutsche Tastatur in englischer Systemumgebung:



            ß -> -
            Ö -> :
            Ä -> "


Es folgt Überraschung Nr.3


Wie erwähnt läuft der Zeit-daemon nach der Installation bereits in seinen Run-Leveln. Was ist mit all den anderen, die ich noch brauche und wo zum Teufel ist /etc/init.d mit dem rc-tree geblieben. Dort wo ich den Ordner init.d erwartet hatte, prangt jetzt: 


                            lrwxrwxrwx 1 root root 35 May  1 11:04 init.d -> /usr/java/latest/.java/init.d/jexec


Ich kann nicht sagen, ob dieses durch die Installation von einem JDK verursacht wurde, da ich dieses recht voreilig gemacht hatte und den /etc/-Ordner vorher nicht genau untersucht hatte. Lassen wir das. Tumbleweed unterstützt vorrangig das SystemD und SystemV mit init.d und rc.d ist damit obsolete. Hier ist ein kleiner Überblick.



  • default runlevel ändern --> systemctl set-default multi-user.target

  • default runlevel abfragen --> systemctl get-default

  • runlevel wechseln --> systemctl isolate multi-user.target / graphical.target

  • reboot--> systemctl reboot / shutdown

  • status.. etc --> systemctl status/start/stop sshd

  • current status -->  systemctl is-enabled sshd



init PID 0 ... funktioniert natürlich auch noch:



  • init 0 ---> shutdown

  • init 3 ---> switch to runlevel 3 multiuser

  • init 5 ---> switch to runlevel 5 graphical

  • init 6 ---> reboot

  • ... und dazu die Abfrage runlevel ---> N 3


Die spannende Frage ist jetzt: Wie bekommen ich meine Services in die Runlevels und den Bootprozess?


Es folgt ein Beispiel für den Apache Tomcat Server:


Es werden 2 Dateien benötigt start-stop-daemon.sh und daemon.service. Für den Tomcat nenne ich die Service-Datei auch Tomcat.service und sie sieht dann so aus:



[Unit]
Description=rctomcat

[Service]
Type=oneshot
ExecStart=/usr/share/apache-tomcat-9.0.45/bin/daemon.sh run
ExecStop=/usr/share/apache-tomcat-9.0.45/bin/daemon.sh stop
RemainAfterExit=yesgaoff

[Install]
WantedBy=multi-user.target



Der daemon.service wird mit /etc/systemd/system verlinkt.



  •   ln -s /usr/share/apache-tomcat-9.0.45/bin/tomcat.service tomcat.service



Der start-stop-daemon.sh muss ausführbar sein. Wie man an der *.service Datei und den Link erkennt, spielt es keine Rolle, wo sie liegen. Der Link und der Eintrag in der *.service-Datei in der Sektion Service sind entscheidend. Die Datei daemon.sh ist in der Source-Distribution von Apache enthalten. Sie kann unverändert auf Tumbleweed eingesetzt werden. Es folgt ein letzter Schritt nach Bedarf:


Dienst nur aktivieren



  • systemctl enable tomcat.service



Dienst on boot aktivieren



  • systemctl enable --now tomcat.service





Tomcat jsvc als wrapped Service





Es folgt Überraschung Nr. 4


Sie hat weniger etwas mit Tumbleweed zu tun, sonder eher etwas mit der Default Installation des Gnu-C-Compilers. Der aktuelle C-Compiler im Repository ist die Version 10.1 und da verbirgt sich schon die Überraschung. Ab der Version gcc10 folgt Gnu dem aktuellen C-Standard und verwendet das CFLAG -fno-common als default. So läßt sich die AirCrack-Suite leider nicht compilieren und linken. Es gibt eine Reihe von externen Definitionen, die zunächst in Deklarationen umgewandelt werden müssen. Darüber hinaus sind Anpassungen im Gnu-Autobuild-System erforderlich, die die Linker und Compiler Flags umfassend anpassen. Viel Arbeit, die sich irgendwann mal auszahlt, aber nicht jetzt. Ich möchte auf den aktuellen C-Standard nicht verzichten, also brauche ich parallel zu gcc10 eine Version, die default im -fcommon Mode arbeitet. Die Version gcc9 wäre dann die nächste. Mit dem Linux Tool update-alternatives läßt sich dann nach Bedarf die richtige Version einstellen und siehe da, der Build flutscht durch, wie mit Vaseline geschmiert.


Die vorerst letzte Überraschung


Sie hat auch weniger mit Tumbleweed zu tun. Die Version von Firefox aus dem Tumbleweed-Repositorie akzeptiert keine TSL/SSL-Verbindungen, die von let's-Encrypt zerifiziert wurden. Wer jetzt nur diesen Browser hat kann dieses nicht lesen und auch nichts ändern. Das ist Schade. Wer über einen anderen Browser verfügt, dies schliesst eine andere FireFox-Version ein, kann von dort das Zertifikat exportieren, auf den Tubleweed-Server übertragen und es dort in den FireFox importieren. Alle anderen Browser, die in meiner IT-Landschaft installiert sind, akzeptieren das Zertifikat. Das schliesst auch mein Android Smartphone ein. Import/Export Step by Step:



  • In trustet Firefox-Version  die 3 parallelen Striche oben rechts öffnen

  • Options öffnen - das ist das Zahnrad

  • Privacy & Security öffnen

  • Im vorletzten Abschnitt Certificates - View Certificates öffnen

  • Im oberen Menue Authorities auswählen

  • Nach unten scrollen bis zu Digital Signiture Trust Co.

  • Hier die Let'sEncrypt Authority auswählen und exportieren

  • Das Export-Ergebnis auf gleichem Wege auf Tumbleweed in FireFox importieren.






Let'sEncrypt Authority