Server administrieren - wo fange ich an?

Ich hatte diese Meldung bei der Installation auch schon mal gesehen, habe mich aber nicht groß drum gekümmert, weil alles lief.

Zitat von Bud

Bei mir passt alles:

Spoiler anzeigen

2023-08-21 21_38_49-Clipboard.jpg

Was hast du denn alles geändert?

Hmm, habe eigentlich nur den Passwortschutz in die Konfiguration (Apache) integriert. So, jetzt habe ich mich für 90 Minuten aus meinem Munin-Server ausgesperrt, jetzt muss wohl mal wieder diese unglaublich tolle VNC-Konsole benutzen um überall wieder reinschauen zu können. Ist mir schon klar, dass da bei einem chown Befehl irgendwo ein Punkt zuviel oder statt des Doppelpunkts drinstehen muss. Aber in den Dateien, die ich editiert habe, kann ich kein "chown" finden. Könnte höchstens da herkommen, wo der User gesetzt wird, unter dem Munin laufen soll (/etc/munin/munin.conf?) Da habe ich aber nichts am User geändert, zumindest nicht absichtlich. Das läuft weiterhin unter root (wenn ich mich recht erinnere). So, aber jetzt erst mal ran an die VNC-Konsole

Puh, das war schlimmer als erwartet. Das ist keine Konsole, sondern eine Zumutung, alle paar Sekunden laufen wirre Datemkolonnen über den Bildschirm. Die Tastatur ist amerikanisch und per Maus eingebbare Taste ist zum Beispiel die Windows-Taste. Was soll ich damit??? Aber gut, geschafft. Jetzt verstehe ich, warum so vielePasswörter 123456 sind, ist einfach leichter in so einem Bildschirmsalat einzugeben als mein 29-stelliges Passwort. In der o.g. Datei steht das mit dem User gar nicht. Da ist nichts, was mit einem "chown" was zu tun haben könnte. Ich gehe eher mal davon aus, das ist in dem munin.service drin.

Edit: Naja, fast

root@mini:/# cat /etc/init.d/munin
#!/usr/bin/env /lib/init/init-d-script

### BEGIN INIT INFO
# Provides:          munin
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# X-Start-Before:    cron
# Short-Description: Create munin master directories on boot
# Description:       Create munin master directories on boot. Munin itself runs as CGI or via cron and does not run a separate daemon.
### END INIT INFO

DESC="Preparing munin directories"
DAEMON=/usr/share/munin/munin-update
NAME=munin


# keep in sync with debian/munin-common.tmpfile (systemd-only)
do_start_prepare() {
    mkdir -p /run/munin /var/cache/munin/www
    chown munin /run/munin
    chown munin. /var/cache/munin/www
    chmod 755 /run/munin
    chmod 755 /var/cache/munin/www
}


# there is no process to be started or stopped ("munin-update" is executed via cron)
do_stop_cmd_override() { true; }
do_start_cmd_override() { true; }

Da ist der Punkt, aber wie kommt der da rein? Und wie wieder raus? Einfach editieren?

Zitat von Bud

Ich möchte mich in nächster Zeit ein wenig in VPN einlesen, und deswegen mal wieder eine kleine Umfrage:

Hab bisher nur OpenVPN benutzt weils das als Image bei Netcup gibt und ich in Kroatien den Eberhofer sehen wollte.

Zitat von tab

Einfach editieren?

freilich.

Zitat von Bud

Ich möchte mich in nächster Zeit ein wenig in VPN einlesen

wer jetzt einsteigt, nimmt wireguard mit wireguard-ui

und für die cray zuhause dann zum keys generieren wireguard-vanity-keygen

oder zumindest irgendwas wireguardartiges, wie innernet etc.

Hab ich gemacht, dann kommt eine Warnung:

Warning: The unit file, source configuration file or drop-ins of munin.service changed on disk. Run 'systemctl daemon-reload' to reload units.

Das habe ich dann einfach ausgeführt und jetzt ist die Warnung mit dem chown. weg. Ich hoffe das bleibt so, obwohl trotzdem alles lief, aber "Das sieht nicht aus!" (Copyright Stenkelfeld)

seltsam ist ja woher das »munin.« kam. es sind ja 2 chmods und der erste ist korrekt.

evtl. ein bug im installer?

Zitat von Olivetti

seltsam ist ja woher das »munin.« kam. es sind ja 2 chmods und der erste ist korrekt.

evtl. ein bug im installer?

Ja, ich verstehe es auch nicht, in der Datei war ich vorher definitiv nicht zugange. Bug im Installer wird wohl das Wahrscheinlichste sein. OS ist Debian 12.

welche installation (art/quelle) hast du benutzt?

Zitat von Olivetti

welche installation (art/quelle) hast du benutzt?

Ich habe das Debian 12 Image von St***o benutzt, dann per apt-get update und apt-get upgrade aktualisiert. Erst cron installiert, dann nach dem Plan von Bud weiter installiert, jedenfalls was die installierten Pakete betrifft. Also Standardquellen. Bzw habe ich sie jedenfalls nicht geändert.

Types: deb deb-src
URIs: mirror+file:///etc/apt/mirrors/debian.list
Suites: bookworm bookworm-updates bookworm-backports
Components: main

Types: deb deb-src
URIs: mirror+file:///etc/apt/mirrors/debian-security.list
Suites: bookworm-security
Components: main

root@mini:~# cat /etc/apt/mirrors/debian.list
https://deb.debian.org/debian
root@mini:~# cat /etc/apt/mirrors/debian-security.list
https://deb.debian.org/debian-security

Zitat von Bud

Ich möchte mich in nächster Zeit ein wenig in VPN einlesen

Beides, Wireguard und OpenVPN.

Hauptsächlich Wireguard wegen der Einfachheit und Geschwindigkeit und OpenVPN auf TCP 443 als Backup für restriktive Firewalls

Das Problem liegt am Paket in dem Debian Repository: https://packages.debian.org/bookworm/all/munin/download Dort ist es schon so.

Da hat wohl der Maintainer schlampig gearbeitet. Es ist generell etwas unsauber, dass hier immer noch die das alte Init Skript zum Einsatz kommt und man das in Bookworm nicht geschafft hat, ein vernünftiges Systemd Service File mitzuliefern. Man hätte ja z.B. einfach mal bei Fedora nachschauen können wie die das machen. Die bringen sogar einen systemd.timer mit anstelle von Cron.

Da müsste man mal einen Bugreport bei Debian aufmachen und das melden.

Man könnte das auch lokal bei sich temporär anpassen. Allerdings ist die Gefahr groß, dass das beim nächsten Update wieder überschrieben wird.

Zitat von Bud

Dann wäre der einzige Unterschied, welcher mir auffallen würde, apt-get dist-upgrade

Nee, meine .bash_history sagt, dass ich das wohl auch mal ausgeführt hatte

Zitat von Paul

Das Problem liegt am Paket in dem Debian Repository: https://packages.debian.org/bookworm/all/munin/download Dort ist es schon so.

Auf meinen anderen Muninserver mit Ubuntu 20.04 ist der Fehler aber auch drin.

Die entsprechende Zeile in /etc/init.d/munin sieht so aus:

mkdir -p /var/cache/munin/www && chown munin. /var/cache/munin/www && chmod 755 /var/cache/munin/www

Zitat von aRaphael

Auf meinen anderen Muninserver mit Ubuntu 20.04 ist der Fehler aber auch drin.

Die entsprechende Zeile in /etc/init.d/munin sieht so aus:

Code

mkdir -p /var/cache/munin/www && chown munin. /var/cache/munin/www && chmod 755 /var/cache/munin/www

Da Ubuntu ja auf Debian basiert und die einfach viele Pakete übernehmen, war das jetzt quasi fast zu erwarten Aber erschreckend finde ich, dass das vorher noch niemandem aufgefallen ist. Hat es dafür echt das Netcup Forum gebraucht? "chown munin:" wäre jetzt eine gültige Anweisung gewesen. Gut möglich, dass hier einfach jemand das Shift vergessen hat. Aber fällt sowas nicht auf? Über Jahre nicht? Ehrlich gesagt zweifel ich gerade so ein wenig an der Qualitätssicherung in Debian...

Oder gibt es irgendeine dubiose Funktion in chown, die einen "." erlaubt? Wäre mir zumindest jetzt neu.

Zitat von Paul

Gut möglich, dass hier einfach jemand das Shift vergessen hat.

Aber nur, wenn er ein deutsches Tastaturlayout hatte.