Thailand

Subversion - Grundinstallation

Kun Pho — Wed, 2 Feb 2022 07:58:42 +0100

Der Teufel steckt oft im Detail

... und das Detail ist teuflisch gut versteckt. Als Programmierer weiß man nicht nur, wie ein Versionskontrollsystem funktioniert, sondern auch wie man es installiert und konfiguriert. Stop - Installation ok, Konfiguration ? Wie oft kommt dieses in 10 Jahren vor? Und schon wieder habe ich Stunden verbracht, mit der Fehlermeldung: svn:Authorization failed! Es ist die schlichte Aussage, dass die Anmeldung ok war, aber die Berechtigungen für den Vorgang nicht ausreichen. Die vielen Stunden Suche und Recherche kannst Du Dir sparen, wenn Du eine gute Check-Liste hast. Nach erfolgreicher Installation geht es so für eine einfache SVN-Installation weiter.

Die Beschreibung passt zu: OpenSuse Tumbleweed und Subversion 1.14.1 (r1886195)

Konfigurationsdateien

Subversion verteilt die Einstellungen auf globale und Repository-abhängige Parameter. Die globalen Einstellungen findest Du im Home-Verzeichnis des Eigentümers, dieses ist der User, der die Installation durchgeführt hat und das Verzeichnis dort heißt: .subversion. Bei einer einfachen Installation interessiert mich nur, wie die Keystore-Abfrage deaktiviert werden kann und das läßt sich in der Datei config einstellen:

vi $HOME/.subversion/config

password-stores =

kwallet-wallet =

Beide Einträge leer lassen. Mehr ist hier erstmal nicht zu tun.

Die Einstellungen in den Repositories setzen natürlich voraus, dass sie bereits existieren:

mkdir -p /srv/svn/repos/

svnadmin create /srv/svn/repos/InternetPuzzle131

Der Ordner /srv/svn/repos/ ist der Trailer für jedes Repository. Danach wird ein Repository für das Projekt InternetPuzzle131 angelegt. Die Aufruf-URL für dieses Repository ist dann: svn://192.168.1.10/InternetPuzzle131

Statt der IP-Adresse kann natürlich auch ein bekannter Hostname oder eine Domaine benutzt werden. Achtung! Bei allen Konfigurationen immer den vollen Pfad mitnehmen. Es interessieren uns hier 3 Dateien. Sie liegem im Ordner /srv/svn/repos/InternetPuzzle131/conf:

authz

passwd

svnserve.conf

Alle Einträge in den Konfigurationsdateien beginnen in Spalte 0. Ein Leerzeichen vor einem Eintrag, wird auch als solches gelesen! Wir stellen hier die Berechtigungen ein. In authz fügen wir die folgenden Zeilen ein:

[InternetPuzzle131:/]

* = r

niknak = rw

seinfreund = rw

Sie Bedeuten: Im Repository InternetPuzzle131 gilt rekursiv vom Root-Verzeichnis (/) abwärts für anonymous-user die Lese-Berechtigung und die user: niknak und seinfreund haben zusätzlich die Schreib-Berechtigung. Da niknak und seinfreund die gleichen Berechtigungen haben, kann man sie auch in eine Gruppe zusammen fassen. Das sieht dann in authz so aus:

[groups]

nn_and_sf = niknak,seinfreund

[InternetPuzzle131:/]

* = r

nn_and_sf = rw

In passwd werden die user mit Passwörtern beglückt Jeder Benutzer hat eine eigene Zeile. Das sieht dann so aus und braucht keine weitere Erklärung:

[users]

niknak = knickknack

seinfreund = dideldumm

In svnserve.conf sind 4 Einstellungen zu machen:

anon-access = read

auth-access = write

password-db = passwd

authz-db = authz

Die ersten beiden Zeilen drücken das Gleiche aus, wie die file-bezogenen Berechtigungen aus authz, hier aber mit Bezug auf das Repository. Die letzten Beiden sind die Verweise auf die Dateien.

Jetzt sollten wir eigentlich fertig sein. Es funktioniert aber trotzdem noch nicht

Das teuflische Detail:

vi /etc/sysconfig/svnserve enthält die Start-Optionen für den Subversion-Daemon und die sind default auf Read only gesetzt:

SVNSERVE_OPTIONS="-d -R -r /srv/svn/repos"

rcsvnserve stop

lösche das -R und werde glücklich.

SVNSERVE_OPTIONS="-d -r /srv/svn/repos"

rcsvnserve start

Nun läßt sich das Repository ohne Fehler befüllen, z.B. mit:

svn import /home/nicknak/ftp-Ordner/InternetPuzzle131/ file:///srv/svn/repos/InternetPuzzle131 -m Inital

... und wenn es wieder raus soll mit:

svn co svn://localhost/InternetPuzzle131 /home/nicknak/InternetPuzzle131

aus dem lokalen Datei-System.

In Eclipse benutze ich das Plugin: subversive SVN-Teamprovider und NativeJavaHL - Connector. Beide über den üblichen Weg installieren und fertig. Das Grundsystem läuft somit reibungslos. Es gibt noch einen kleinen Fallstrick: Wenn Du Subversion als root installiert hast und Deinen ersten Commit absetzen möchtest stolperst Du über Diese Meldung:

Some of selected resources were not committed.
Permission denied
svn: Commit failed (details follow):
svn: Can't open file '/srv/svn/repos/KrimsKrams/db/txn-current-lock': Permission denied

Das ist jetzt kein Faux pas, denn wenn Du die Versionskontrolle nur lokal einsetzen möchtest, ist dieses durchaus legitim. Es hebelt aber den Sinn der verteilten Entwicklung aus. Dann schauen wir uns mal den Verursacher an:

drwxr-sr-x 1 root root 310 Jun 9 11:02 db

Der Subversive-Client kommt nicht als authentischer root zum Server und die Subversion-Datenbank verhindert somit einen Schreibzugriff aus der Ferne, da hilft auch das Sticky-Bit nicht weiter. Die Berechtigungen für das db-Verzeichnis müssen also dem Client entsprechend angepasst werden.

Für für das Fine-tuning empfehle ich einen Blick in die Apache - Doku und den Gesamt-Überblick in Red-Bean.

Update Opensuse Bottle auf Tumbleweed

Kun Pho — Wed, 2 Feb 2022 07:54:59 +0100

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.

Das alte System auf den aktuellstem Stand bringen

zypper up

zypper dup

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

Wenn wir eine Fehlermeldung in der Form: <dienstxy> needs glibc >= 2.28 erhalten, sieht es ganz schlecht aus. Wir können testen was bei uns installiert ist:

ldd --version
ldd (GNU libc) 2.18
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Die glibc ist eine Basislib, aus der das System gebaut wurde und es gibt unendlich viele Dienste, tools, ... etc, die aus ihr erstellt wurden.

Glück gehabt, 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 ist immer gut, einen systemctl daemon-reload aufzurufen, um den system Daemon zu informieren. 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

Zu guter Letzt die Paketinstallation

Es hat sich erfreulicherweise nichts geändert. Hier nochmal der Ablauf am Beispiel Subversion:

Als root oder mit sudo

zypper addrepo https://download.opensuse.org/repositories/devel:tools:scm:svn/openSUSE_Tumbleweed/devel:tools:scm:svn.repo

zypper refresh

zypper install subversion