Boycott Systemd

Status
Für weitere Antworten geschlossen.
Das Schöne bei dem FreeBSD Projekt ist, dass es eine Demokratie ist. Jeder kann Vorschläge einbringen. Wenn jemand die notwendige Arbeit macht - oft ist es prinzipbedingt die Person oder die organisation, die den Vorschlag eingebracht hat - sind die Chancen gut, dass nach einer Diskussion der Vorschlag angenommen und umgesetzt wird. Ich habe in all den Jahren nur selten erlebt, dass sinnvolle, sauber durchargumentierte Änderungsvorschläge pauschal abgelehnt wurden.

Wenn die rc-Scripte so schlimm sind, bringt doch bitte einen Vorschlag zu ihrer Weiterentwicklung oder einem Ersatz ein. Denn derzeit gibt es vielleicht 5 mögliche Ersatzlösungen, in unterschiedlichen Entwicklungsstadien. Die Diskussion, ob und wie diese in FreeBSD integriert werden könnten, hat allerdings schlicht und ergreifend noch niemand begonnen. Dabei ist jetzt die Zeit dafür, da gerade in diesem Moment die Weichen in Richtung 12.0 gestellt werden.
 
Wenn die rc-Scripte so schlimm sind, bringt doch bitte einen Vorschlag zu ihrer Weiterentwicklung oder einem Ersatz ein. Denn derzeit gibt es vielleicht 5 mögliche Ersatzlösungen, in unterschiedlichen Entwicklungsstadien. Die Diskussion, ob und wie diese in FreeBSD integriert werden könnten, hat allerdings schlicht und ergreifend noch niemand begonnen. Dabei ist jetzt die Zeit dafür, da gerade in diesem Moment die Weichen in Richtung 12.0 gestellt werden.

Entsprechend eingereichten Vorschlag hatte ich ja schon verlinkt, weiter vorne. Nannte sich jobd. Die Diskussion startete als ich fragte ob dann, alleine schon aufgrund weil es nicht mehr rc.d ist, Leute hier dann von FreeBSD weggehen. Denn ein großer Kritikpunkt hier an systemd ist nämlich auch sein Feature-Reichtum.

Ich nehme auch lieber Perl aus den 80ern. Aber wieso ist das Alter entscheidend?

Ahja, und da nimmst du Perl 1.0 zu...
 
Nein, der Kritikpunkt ist, dass vieles nur unzureichend getestet wird und noch seltener gewartet. Wenn ein Admin ohnehin Skripten kann, dann kann er auch die Stromschnellen überwinden die skriptbasierte Daemons haben. Aber systemd ist ein schwarzes Loch, wo nur noch Red Hat durchsteigt und offensichtlich zu viele Dinge konzentriert. Man kann nicht alles vereinheitlichen, ein Desktop hat andere Bedürfnisse als ein Server oder ein Embedded System.
 
Aber systemd ist ein schwarzes Loch, wo nur noch Red Hat durchsteigt und offensichtlich zu viele Dinge konzentriert.

(Achtung, Sarkasmus) Wenn du systemd nicht verstehst, dann solltest du keinen Server administrieren (/Sarkasmus)

Klar ist systemd komplexer als ein "Fire-and-Forget" Init-System, was hinterher nicht mehr weiß was eigentlich läuft oder nicht. Aber die Behauptung, dass nur noch RedHat durchsteigen würde, sehe ich recht unbegründet. Die Arbeitsweise ist recht klar.
 
Entsprechend eingereichten Vorschlag hatte ich ja schon verlinkt, weiter vorne. Nannte sich jobd.
Ich kenne jobd. Und auch lauchd, relaunchd, nosh, s6, runit, etc. Es sind aber alles erstmal nur Code-Repos auf Gitub und anderen Plattformen. Der Code ist nur der allererste Schritt auf dem Weg einer Integration von FreeBSD. Bisher ist niemand den zweiten Schritt gegangen, nämlich eine Diskussion über die Nachteile von rc zu starten und darzulegen, was seine jeweilige Alternative besser macht und wieso diese nicht mehr vorhandenen Nachteile den großen Aufwand einer Integration in FreeBSD rechtfertigen. Dazu gehört auch eine Strategie, wie rc mit immerhin knappen 35 Jahren zumindest teilweise gegebener Rückkompatibilität kontrolliert deprecated und schließlich - wie man im FreeBSD-Slang sagt - im Rahmen eines "deorbit" komplett entfernt werden kann. Dazu gehört eine saubere Argumentationslinie, um all die Personen zu überzeugen, die die wahrscheinlich zehntausenden, dort draußen vorhandenen Scripte im neuen Syntax reimplementieren dürfen. Die Portmaintainer, die über Jahre zwei unterschiedliche Systeme unterstützen müssen...
 
Dazu gehört eine saubere Argumentationslinie, um all die Personen zu überzeugen, die die wahrscheinlich zehntausenden, dort draußen vorhandenen Scripte im neuen Syntax reimplementieren dürfen. Die Portmaintainer, die über Jahre zwei unterschiedliche Systeme unterstützen müssen...

Und für wie wahrscheinlich hältst du das? Man hat ja bei Debian schon gesehen wie viel verbrannte Erde die Diskussion+Entscheidung hinterlassen hat. Das hat sicherlich jeder mitbekommen... Auch so Sachen, dass man bei systemd z.B. eine grundlegende Sandbox out-of-the box bekommt, einfach indem ich in das Service-File ein Flag setzt, sehe ich als Argument wenig griffig, wenn es aufgrund von fehlenden und (aus welchen Gründen auch immer) nicht angenommenen Sicherheitsfeatures schon FreeBSD Forks wie HardenedBSD gibt.

Ich sehe ja schon hier, wie viel "Hass" einem entgegen kommt, wenn man mal mit der Kritik anfängt. Da hätte ich als Maintainer eines Lösungvorschlags schon recht viel Angst sich in dieses Gewässer zu begeben.
 
Was heißt hier Hass? Die Umsetzung ist lausig wie auch deren Kommunikation, sagt zmd. Torvalds. Null Visionen und aus Entwicklersicht fährt man direkt auf den Abgrund zu wenn man nicht weiß, was nicht enthalten sein sollte, wo die eigentlichen Grenzen sind.
Du siehst vielleicht Systemd als Service, der Admins entlasten kann. Poettering nutzt es als Infrastruktur um den Userspace zu vereinheitlichen.
Ich habe kein Problem damit, wenn sich Linux-Admin damit herumschlagen, ich habe aber ein Problem wenn Funktionalität keine Wartung mehr erhält weil mit Systemd-Daemons das nicht mehr notwendig ist. Ich bin nicht bereit, Systemd nachzubasteln damit Drittsoftware halbwegs funktioniert, das ist nicht meine Aufgabe.
Zudem befindest du dich hier in einem BSD-Forum, vermutlich hast du noch ein BSD irgendwo im Einsatz, meinst du die Monopolisierung führt dazu das sich mehr Leute um die Baustellen kümmern, wenn man alles auslagert gen Systemd?
 
Ja gut, lassen wir das erst mal... ich weiß halt nicht wie oft ich mich da wiederholen soll. Ich bin zufriedener FreeBSD-Benutzer. Ich bin aber kein blinder FreeBSD Benutzer. Ich schaue breitflächig über den Tellerrand. Ich habe auch schon mehrfach gesagt, dass ich nicht systemd für FreeBSD fordere. Ich habe nur die Stellen in FreeBSD kritisiert die mir jedes mal sauer aufstoßen, ganz einfach weil ich auch Systeme habe die in den Punkten einfach viel viel besser sind. Und wenn ich das anspreche wird mir Inkompetenz unterstellt, nur weil ich : $(%a*) nicht für eine zeitgemäße Syntax halte.

Und falls es dir nicht aufgefallen ist, bin ich schon ziemlich lange hier und helfe auch durchaus anderen Leuten hier. Also stelle mich auch nicht als BSD-Troll hin...
 
Ich halte auch sh nicht für die Erfüllung, aber es ist ein Werkzeug, was mir die Arbeit erleichert genauso wie Batch unter Windows.
Es gibt Dinge die via Konsole/Shellskript leichter gehen als in einem Python-Skript verpackt, wie auch andersrum.
In dem Sinne, genieß den Sonntag.
 
weil ich : $(%a*) nicht für eine zeitgemäße Syntax halte.

Der Punkt ist: du bewertest das, was man dir vorsetzt, von oben aus der Sicht des Users, anscheinend ohne tieferes Verständnis, während Andere hier das Ganze von unten bewerten, teilweise aus der Sicht eines Programmierers, der ziemlich gut unterscheiden kann, ob das System in sich stimmig funktioniert, simpel ist und daraus nur etwas Komplexes gebaut wurde, oder ob einfach nur ein Komposthaufen hübsch angemalt wurde.

Nochmal: FreeBSDs rc-System zu kritisieren, ist völlig legitim, aber sich an Syntaxdetails von sh aufzuhängen, zeigt einfach nur Ignoranz.

Wenn systemd es schafft, einen Reboot in einen katastrophalen Fehlerfall zu überführen, von vornherein schon unbenutzbare Logfiles zu zerstören oder solche Blüten wie "--force --force" hervorbringt, dann weiß man als erfahrener Admin genau, wie die Scheiße unten drunter aussieht und lässt sich eben nicht von der bunt angemalten Oberfläche blenden. Wer systemd einfach nur benutzen will, mag damit in der Tat besser zurechtkommen als mit rc-Skripten. Wer aber systemd wirklich verstehen will, weil es ihm nicht egal ist, was sein Server alles treibt, der stößt schnell auf den Kompostkern und wendet sich angewidert ab.

Manche haben eben keinen Bock, im Fehlerfall gar nichts mehr machen zu können. Durch Klartext und Shell wühlt man sich als richtiger Admin im Notfall _immer_ durch.

Edit: Ich verweise immer gerne auf den Unterschied "easy" vs. "simple". Ich hoffe, der ist bekannt.
 
Nochmal: FreeBSDs rc-System zu kritisieren, ist völlig legitim, aber sich an Syntaxdetails von sh aufzuhängen, zeigt einfach nur Ignoranz.

Wenn du nicht immer bei "systemd" aufhören würdest zu lesen, dann hättest du weitaus mehr Kritikpunkte gefunden. Unlesbare SH-Skripte sind die eine Sache. Fehlende Features im gesamten eine andere. Ich kritisiere im Detail SH und dann wird mir wieder unterstellt ich kritisiere hauptsächlich SH. Wie gesagt. Ich benutze FreeBSD, ich schlage mich damit rum... schon seit Jahren. Diese Punkte gefallen mir absolut nicht, andere wiederum sehr.

Wenn man aber aufgrund von einem Problem, dass eine einzelne Person gerade hatte, dass ganze System in Frage stellt.. da hätte ich FreeBSD schon vor Jahren von meinen sämtlichen Servern schmeißen müssen.

Momentan kriegt ein Server von mir eine Kernel-Panic wenn ich nur kldload vmm && kldunload vmm ausführe. Trotzdem halte ich den FreeBSD Kernel nicht für einen großen Misthaufen.
 
Ich weshalb viele hier Shell gegenüber den INI-ähnlichen Unit-Files für überlegen halten ist, dass Shell eben eine „richtige“ Scriptsprache ist mit der sich allgemeine Probleme lösen lassen, während Unit-Files naturgemäß Limitierungen haben. Die Diskussion darüber, was besser ist, ist in meinen Augen müßig, ich verstehe einerseits warum man sich als neuer Admin die Shell-Syntax nicht unbedingt antun möchte, andererseits ist sie auch auf modernen Linux-Servern unentbehrlich. Selbst Microsoft nutzt die bash als Werbemittel für sein Ubuntu-on-Windows.
Admins, die Aufgaben auf Servern nicht automatisieren können würde ich auch nicht über den Weg trauen. Ob sie dafür ``/bin/sh``, bash, perl, python oder PowerShell nutzen ist in letztendlich aber egal. Für alle Aufgaben auf spezielle Softare mit Konfiguration durch INI-Files zurückzufallen wäre sicherlich zu kurz gegriffen, aber ich glaube das meinte -Nuke- auch nicht.

Irgendwie ist es lustig, wie beide Seiten ihre Trigger-Punkte haben, die Einen fühlen sich durch systemd-Bashing angegriffen, die anderen durch Shell-bashing.
 
Sooooo kompliziert!
Code:
#!/bin/sh

# PROVIDE: powerdxx
# REQUIRE: DAEMON
# BEFORE: LOGIN
# KEYWORD: nojail shutdown

. /etc/rc.subr

name="powerdxx"
rcvar="powerdxx_enable"
command="/usr/local/sbin/powerd++"
pidfile="/var/run/powerd.pid"

load_rc_config $name
run_rc_command "$1"
 
  • Like
Reaktionen: lme
Nö, aber so kompliziert:

Code:
#!/bin/sh
#
# $FreeBSD: head/net/samba43/files/samba_server.in 402642 2015-11-30 01:35:36Z timur $
#

# PROVIDE: samba_server
# REQUIRE: NETWORKING SERVERS DAEMON ldconfig resolv ntpd
# BEFORE: LOGIN
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
#samba_server_enable="YES"
#
# You can disable/enable any of the Samba daemons by specifying:
#samba_enable="NO"
#nmbd_enable="NO"
#smbd_enable="NO"
# You need to enable winbindd separately, by adding:
#winbindd_enable="YES"
# Configuration file can be set with:
#samba_server_config="/usr/local/etc/smb4.conf"
#

. /etc/rc.subr

name="samba_server"
rcvar=${name}_enable
# Defaults
samba_server_config_default="/usr/local/etc/smb4.conf"
smbcontrol_command="/usr/local/bin/smbcontrol"
# Custom commands
extra_commands="reload status"

start_precmd="samba_server_prestart"
restart_precmd="samba_server_checkconfig"
reload_precmd="samba_server_checkconfig"
start_cmd="samba_server_cmd"
stop_cmd="samba_server_cmd"
status_cmd="samba_server_cmd"
reload_cmd="samba_server_reload_cmd"
rcvar_cmd="samba_server_rcvar_cmd"

samba_server_checkconfig() {
    echo -n "Performing sanity check on Samba configuration: "
    if ${testparm_command} >/dev/null 2>&1; then
    echo "OK"
    else
    echo "FAILED"
    return 1
    fi
}

samba_server_prestart() {
    # Make sure we have our RUNDIR, even if it's on a tmpfs
    if [ -d "${samba_server_piddir}" -o ! -e "${samba_server_piddir}" ]; then
    install -d -m 0755 "${samba_server_piddir}"
    fi
    # https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200186
    if [ -d "${samba_server_privatedir}" -o ! -e "${samba_server_privatedir}" ]; then
    install -d -m 0700 "${samba_server_privatedir}"
    fi
#    # Remove smbd.pid before starting up samba(needed for s3fs)
#    if [ -e "${samba_server_piddir}/smbd.pid" ] ; then
#    rm -f "${samba_server_piddir}/smbd.pid"
#    fi
    samba_server_checkconfig
}

samba_server_rcvar_cmd() {
    local name rcvar
    rcvar=${name}_enable
    # Prevent recursive calling
    unset "${rc_arg}_cmd" "${rc_arg}_precmd" "${rc_arg}_postcmd"
    # Check master variable
    run_rc_command "${_rc_prefix}${rc_arg}" ${rc_extra_args}
    # Check dependent variables
    for name in ${samba_daemons}; do
    # XXX
    rcvars=''; v=''
    rcvar=${name}_enable
    run_rc_command "${_rc_prefix}${rc_arg}" ${rc_extra_args}
    done
}

samba_server_reload_cmd() {
    local name rcvar command pidfile force_run
    # Prevent recursive calling
    unset "${rc_arg}_cmd" "${rc_arg}_precmd" "${rc_arg}_postcmd"
    # Ignore rcvar and run command
    if [ -n "${_rc_prefix}" -a "${_rc_prefix}" = "one" ] || [ -n "${rc_force}" ] || [ -n "${rc_fast}" ]; then
    force_run=yes
    fi
    # Apply to all daemons
    for name in ${samba_daemons}; do
    rcvar=${name}_enable
    command="/usr/local/sbin/${name}"
    pidfile="${samba_server_piddir}/${name}.pid"
    # Daemon should be enabled and running
    if ( [ -n "${rcvar}" ] && checkyesno "${rcvar}" ) || [ -n "$force_run" ]; then
       if [ -n "$(check_pidfile "${pidfile}" "${command}")" ]; then
        debug "reloading ${name} configuration"
        echo "Reloading ${name}."
        ${smbcontrol_command} "${name}" 'reload-config' ${command_args} >/dev/null 2>&1
       fi
    fi
    done
}

samba_server_cmd() {
    local name rcvar rcvars v command pidfile samba_daemons result force_run
    # Prevent recursive calling
    unset "${rc_arg}_cmd" "${rc_arg}_precmd" "${rc_arg}_postcmd"
    # Stop processes in the reverse order
    if [ "${rc_arg}" = "stop" ] ; then
    samba_daemons=$(reverse_list ${samba_daemons})
    fi
    # Ignore rcvar and run command
    if [ -n "${_rc_prefix}" -a "${_rc_prefix}" = "one" ] || [ -n "${rc_force}" ] || [ -n "${rc_fast}" ]; then
    force_run=yes
    fi
    # Assume success
    result=0
    # Apply to all daemons
    for name in ${samba_daemons}; do
    # XXX
    rcvars=''; v=''
    rcvar=${name}_enable
    command="/usr/local/sbin/${name}"
    pidfile="${samba_server_piddir}/${name}.pid"
    # Daemon should be enabled and running
    if ( [ -n "${rcvar}" ] && checkyesno "${rcvar}" ) || [ -n "$force_run" ]; then
       run_rc_command "${_rc_prefix}${rc_arg}" ${rc_extra_args}
       # If any of the commands failed, take it as a global result
       result=$((${result} || $?))
    fi
    done
    return ${result}
}

samba_server_config_init() {
    local name
    # Load configuration
    load_rc_config "${name}"
    # Defaults
    samba_server_enable=${samba_server_enable:=NO}
    samba_server_config=${samba_server_config=${samba_server_config_default}}
    samba_server_configfile_arg=${samba_server_config:+--configfile="${samba_server_config}"}            #"
    #testparm_command="/usr/local/bin/samba-tool testparm --suppress-prompt --verbose ${samba_server_configfile_arg}"
    testparm_command="/usr/local/bin/testparm --suppress-prompt --verbose ${samba_server_config}"
    # Determine what daemons are necessary to run Samba in the current role
    samba_server_role=$(${testparm_command} --parameter-name='server role' 2>/dev/null)
    case "${samba_server_role}" in
    active\ directory\ domain\ controller)
       samba_daemons="samba"
       ;;
    auto|*)
       samba_daemons="nmbd smbd winbindd"
       ;;
    esac
    # Load daemons configuration
    for name in ${samba_daemons}; do
    load_rc_config "${name}"
    # If samba_server_enable is 'YES'
    if [ -n "${rcvar}" ] && checkyesno "${rcvar}"; then
       if [ "${name}" != "winbindd" ]; then
        # Set variable to 'YES' only if it is unset
        eval ${name}_enable=\${${name}_enable-YES}
       else
        # Winbindd
        samba_server_idmap=$(${testparm_command} --parameter-name='idmap uid' 2>/dev/null)
        if [ -n "${samba_server_idmap}" ]; then
           winbindd_enable="YES"
        fi
       fi
    fi
    # If variable is empty, set it to 'NO'
    eval ${name}_enable=\${${name}_enable:-NO}
    done
    # Fetch parameters from configuration file
    samba_server_lockdir="$(${testparm_command} --parameter-name='lock directory' 2>/dev/null)"
    samba_server_lockdir=${samba_server_lockdir:=/var/db/samba4}
    samba_server_piddir="$(${testparm_command} --parameter-name='pid directory' 2>/dev/null)"
    samba_server_piddir=${samba_server_piddir:=/var/run/samba4}
    samba_server_privatedir="$(${testparm_command} --parameter-name='private dir' 2>/dev/null)"
    samba_server_privatedir=${samba_server_privatedir:=/var/db/samba4/private}
}

# Load configuration variables
samba_server_config_init
# Common flags
command_args=${samba_server_configfile_arg}
samba_flags=${samba_flags="--daemon"}
nmbd_flags=${nmbd_flags="--daemon"}
smbd_flags=${smbd_flags="--daemon"}
winbindd_flags=${winbindd_flags="--daemon"}
# Requirements
required_files="${samba_server_config}"
required_dirs="${samba_server_lockdir}"

run_rc_command "$1"

Aber wie in Beitrag #1063 ganz unten gesagt -> Führt eh zu nichts. Aber gut, das was ich anbringen wollte wird nicht verstanden. Ich hab auch keine Lust es noch mal zu erklären. Feiert weiter rc.d...
 
Wer andere Init-Systeme ausprobieren möchte, kann ja entsprechende Distris/Forks nehmen - ist ja nun wirklich nicht so schwer.
Jordan Hubbard hat mit NextBSD ein solches Projekt aufgesetzt (scheint mir allerdings nicht allzuweit gediehen zu sein). Das ist darauf ausgelegt, mit launchd zu arbeiten (nicht out-of-the-box... muss noch konfiguriert werden).
Und TrueOS ist gerade auf OpenRC umgestiegen - mit dem von Kris Moore verkündeten Ziel, bei Erfolg auch FreeBSD dafür zu gewinnen. Er berichtete in BSD Now kürzlich, dass die Boot-Zeit seines Laptops von über 1 Minute auf ca. 20 Sekunden gesunken sei. Bevor hier jemand gleich draufschlägt: Für den typischen Server ist das natürlich völlig unerheblich für TrueOS (alias PC-BSD) ist das aber sehr interessant.
Also: Es gibt verschiedene Ansätze, neue/andere Init-Systeme in FreeBSD zu etablieren. Funktioniert aber nur, wenn sich genügend Menschen dafür finden, diese Möglichkeiten auch einmal auf Herz und Nieren zu testen. Ich finde ide Vielfalt klasse. Und dass es Menschen gibt, die es wenigstens versuchen, anstatt nur zu lamentieren. Und denkt dran: Wir würden immer noch mit den alten pkg_* Tools leben, wäre Baptist nicht so frech (naiv?) gewesen, pkgng zu entwickeln.
 
Ebenso ist "das haben wir schon immer so gemacht" ebenso schädlich. Immerhin brauche ich eine Jail (!!!) um PostgreSQL unter FreeBSD korrekt upgraden zu können.
Das wäre mir jetzt ziemlich neu. Ich verwende PostgeSQL seit fast einem Jahrzehnt produktiv und habe noch nie eine Jail gebraucht.

Und ja, das Argument ist auch kein echtes Argument. Da stimme ich dir zu, allerdings mit der kleinen Fußnote, dass Änderungen begründet sein sollten, nicht die Abwesenheit davon. Zumindest wenn die Dinge funktionieren. Wenn sie das nicht tun, dann hat man aber ein echtes Argument. :)

Wenn man systemctl daemon-reload braucht, sagt einem systemctl das auch.
Mich macht es nur immer stutzig, wenn mir ein Programm sagt, was zu tun ist, als wie wenn es das selbst tut.

Und das es .socket Dateien gibt als Kritikpunkt zu sehen... wie gesagt. Es ist ein Feature von systemd und kein Muss. Dein Problem war vermutlich einfach der Name.
Ich glaube du hast mich da falsch verstanden. Das Feature ist ja die Funktionalität, nicht das File. Das war als Antwort auf deine Argumentation, dass es bei rc.d mehrere Files braucht um was zu tun. Der Fix wäre sowas wie eine [socket] section im Unitfile zu haben.

Sorry, aber diese Datei ist vollkommen einfach lesbar und für jeden verständlich.
Genau, das ist doch meine Argumentation! Eben, weil es fast wie ein Shell-Skript ist. Nur dass man mit einem normalen Shell Skript das ganze einfacher hätte und man sich einfacher täte Kontrollstrukturen zu bauen. Allerdings geht das alles auch gegen die Behauptung, dass Unit-Files dazu da sind nur deklarativ, statt prozedural zu arbeiten.


Die rc-Skripte in FreeBSD sind aber alle andere als einfach und leserlich. Ein nicht unerheblicher Teil sieht so aus (Auszug):
Code:
        for ifn in $_cooked_list; do
        case ${ifn#epair} in
        [0-9]*[ab])     ;;      # Skip epair[0-9]*[ab].
        [0-9]*)
                for _str in $_cooked_list; do
                case $_str in
                $ifn)   _tmp_list="$_tmp_list ${ifn}a ${ifn}b" ;;
                *)      _tmp_list="$_tmp_list ${ifn}" ;;
                esac
                done
                _cooked_list=${_tmp_list# }
        ;;
        esac
        done

Ist jetzt natürlich ein extremes Beispiel.
Und das Selbe in einem Unit-File?

Aber genau ein Großteil der ganzen Dienste braucht eben genau nicht viel außer ein Start, Stop und ein paar Status Dienste. Warum soll ich ein System überaus komplex definieren nur damit Randfälle "ein bisschen hübscher sind", aber jeder simple Fall einfach umständlich ist?
Ich glaube ich habe mich nochmal undeutlich ausgedrückt oder wir sind einfach anderer Meinung.

Ein rc.d-Skript ist meines Erachtens in dem von der erwähnten Standardfall ziemlich ident mit der Komplexität bzw. mit der Schönheit eines Unitfiles. Du hast ein wenig Boilerplate. Bei Systemd [Unit], [Service], [Install] und anderes bla, und dann eben genau das was du willst und bei rc.d. /etc/rc.subr, etc.


So gut wie jedes Init-Skript lädt im Vorfeld /etc/rc.subr und hat dann selbst keine einfach verständliche Syntax sondern auf den ersten Blick mMn vollig unverständliche Deklarationen.

Wie ist es im Gegenzug bei Systemd? [Unit], [Service], [Install], etc. und obwohl's eine Konfigurationsfile ist nicht mal Warnungen, wenn da was davon fehlt. Komplett unnötig, kann aber zu Fehlern führen, die mitunter leise ignoriert werden. Hatte ich letztens erst.


edit, nehmen wir mal als Beispiel mdnsd. Ein schön kurzes Skript....

Code:
# PROVIDE: mdnsd
# REQUIRE: DAEMON
# KEYWORD: shutdown

. /etc/rc.subr

name=mdnsd
rcvar=mdnsd_enable

load_rc_config $name

: ${mdnsd_enable="NO"}
: ${mdnsd_pidfile="/var/run/${name}.pid"}

command="/usr/local/sbin/${name}"
pidfile="${mdnsd_pidfile}"

run_rc_command $*

Fragen die einem Noob da kommen:

- Wie, warum ist das PROVIDE da wichtig, da ist doch ein Kommentarzeichen davor?

Ganz ehrlich? Da stimme ich einerseits zu, andererseits musst du sowohl bei Systemd, als auch bei rc.d einfach in die Manual gucken. Bei Systemd fragst du dich eben warum das eine in [Unit] und das andere in [Service], warum .socket ein eigenes File, etc.

- uff... etc/rc.subr hat ja ÜBER 2000 Zeilen
Uff, wieviel Zeichen hat allein der Code, der Unite Files parsed? Und wie groß ist die Syntax die du lernen musst? Shell nehme ich an, kennt der Admin grundsätzlich. Sorry, aber hier vergleichst du echt den Source Code des Systems oder beschwerst dich über gleich bleibenden Boilerblade Code. Und das weiß ein User genau so schnell, wie er unter Systemd alles ins richtige Heading packen muss, nur dass es derzeit unter rc.d lauter ist.

- load_rc_config... hmm, brauche ich das? Was tut das?
Und was ist LimitRTTIME=infinity? Und was sind die WantedBy targets? Brauch ich die?

- run_rc_command Dollar Sternchen? Huh?
Im Gegensatz zu einer komplett neuen Sprache?

Ich habe mal das Unit File ausgegraben:

Code:
[Unit]
Description=Zero-configuration networking
After=network.target
[Service]
Type=forking
ExecStartPre=/bin/rm -f /var/run/mdnsd.pid
ExecStart=/usr/sbin/mdnsd
ExecReload=/bin/kill -HUP $MAINPID
PIDFile=/var/run/mdnsd.pid
Restart=always
RestartSec=10s
[Install]
WantedBy=multi-user.target

Warzm Description und After in Unit?
Was gibt es für Types?
Was ist der Unterschied zwischen ExecStartPre und einfach vielen ExecStats, wie beim von mir erwähnten File?
Was ist $MAINPID? Gibt's auch noch was anderes? Wie greife ich darauf zu? Vor allem wenn ich mehrere ExecStarts habe? Es gibt auch GuessMainPid. Was ist $MAINPID wenn das auf no ist?


So ein simples systemd service File ist dort auf den ersten Blick wesentlich selbsterklärender, meiner Meinung nach.
Ich stimme dir da teilweise zu. Worum's mir geht, ist dass du einfache Unitfiles und einfache RC-Skripts gleich gut schreiben kannst, nach einer Woche. Ich glaube sogar, dass die aller minimalisten Varianten unter Sytemd vielleicht am ersten Tag gleich schnell sind.

Ich würde aber sogar sagen, dass es für die einfachen Fälle am Besten ist ein Template zu nutzen oder sogar ein command (sowas wie für useradministration) zu bauen und zu verwenden. Hintergedanke da wären eben so Fehler, was [Unit] und [Service] oder einfach blöde Tippfehler oder gar sowas, wie keys, wo man sich vertut (fork vs forking, etc.) eindämmen kann. Wenn du ohnehin nur ein simples Command hast das du startest sollte das einfacher gehen.

Aber auch wenn man auf den Ouput schaut. Ich habe nach einem RC-Skript doch ein wenig mehr, wie Configoptionen. Das ist so eine Sache, die mir wirklich fehlt. Ein Flag zu haben mit dem ich den Port oder die Listening-Adresse in einer zentralen rc.conf habe ist einfach was, was ich nicht mehr missen mag. Das war auch das warum ich das mit dem Socket-File gebracht habe.

Unit Files/RC Scripts schreibt man einmal, entweder der Package Maintainer oder das Projekt. Aber der Admin konfiguriert sowas quasi beruflich. Ja, da hoffe ich auch, dass das nicht jeden Tag geändert wird, aber es wird trotzdem in etwa einmal pro Unternehmen sein und nicht potentiell einmal weltweit.

Mir ist übrigens auch klar, dass jetzt Beiträge wieder dieser nur wieder ein "das Haar in der Suppe suchen" Flamewar triggern könnte. Dann sind wir wieder am Anfang: "Wir haben das immer schon so gemacht" oder "es funktoniert" -> "Man sollte nichts ändern".
Also wenn das einzige Argument "es funktioniert" ist, dann würde ich es wirklich nicht ändern.

Aber man sollte es nicht ändern ist kein Argument. Und es ist auch kein ausschließendes Argument. Es ist eine Kosten/Nutzen-Abwägung.

So wie ich das sehe macht systemd ein paar Dinge einfacher, ein paar andere Dinge schwieriger. Ich sehe jetzt nicht viel, was es groß vereinfacht, zumindest nichts, wo es dafür andere vereinfachende Dinge (zum Beispiel, dass ich dann Konfigurationsoptionen für eine einheitliche Konfiguration für rc.conf habe) eintausche. Meine Behauptung ist ja auch nicht, dass rc.d oder OpenRC perfekt wäre. Für mich geht derzeit, wenn ich SystemD und sowohl gegen FreeBSD's rc.d, als auch gegen OpenRC eher für diese Systeme auf und zwar als Admin, als auch als Package Maintainer und Entwickler, auch weil es meines Erachtens relativ gut Wissensbereiche und Zuständigkeiten abdeckt.

Allerdings sehe ich mich da jetzt auch nicht so radikal auf einer Seite. Das ist auch der Grund warum ich das Ganze philosophisch genannt haben. Da gibt's einfach auch Themen, die mich unter FreeBSD und Linux im täglichen Betrieb mehr stören. Insgesamt tendiere ich da auch am Server mehr zu FreeBSD, während das Ganze am Desktop ausgewogener ist. Gut, man mag vielleicht Denken, dass man da mit dem init-System weniger am Hut hat. Das hat aber auch andere Gründe.

Und zum Flamen: Ja, ich glaube wenn es um die Konfiguration geht ist es einfach stark Geschmackssache. Das führt dann oft zu Geflame. Und was ich so mitbekomme von Systemd sind die großen Vergehen, teilweise auch behoben worden. Derzeit geht die Rechnung bei mir trotzdem noch eher für andere init-Systeme auf. Für mich haben da init.d-Systeme ziemlich ersetzt. Es hat Vorteile, ist dafür komplexer. Gäb's nur init.d und SystemD auf der Welt würde ich potentiell zu letzteren tendieren. Allerdings habe ich die Abwägung noch nie wirklich gemacht. Ansonsten habe ich mal gehofft, dass OpenRC gehofft und dass das vielleicht über kurz oder lang auf alle Systeme übergeht, aber da gab's nie so wirklich viel Werbung, weil auch wen es Cross-Platform ist einfach zu nah an Genoo-Linux liegt und es von dort niemand groß raus getragen hat. Anders als bei SystemD.

So wie ich das sehe, ist Systemd vs rc.d keine objektive Abwägung, bzw. wenn man die Details objektiv durch gehen würde fällt das nicht so stark für eine Seite aus. Und dann ist es einfach nur init. Klar, das ist wichtig, aber auch wirklich kein Killerargument. Das gleiche Spiel hat man ja mit Package Managern, (teilweise mit) Programmiersprachen, etc. Solange die Basics funktionieren und man keine Hölle durchlebt, und das tut man bei den Wenigsten, dann wird's da wie dort Verfechter und wohl nie einen Gewinner geben. Die Zeit, wo man Systemd kritisieren konnte, weil es nicht funktioniert ist im Großen und Ganzen am Ende (soweit es das für irgendein Init-System sagen kann) und dann gibt's halt hier und da einen Rant. Und wer's wirklich nicht mag ist irgendwohin ausgewichen. Ich glaube die anfängliche Panik, dass man Systemd haben muss ist auch ziemlich verflossen. Wohl auch weil es einfach kein größeres Projekt zum absoluten Muss gemacht hat.

EDIT: Btw. wahrscheinlich letzter ausführlicherer Post, weil ich die nächsten zwei Wochen wahrscheinlich etwas etwas mehr Stress haben werde. ;)

Aber immer wieder schön, dass man hier zwischen Rants und sachlicher Diskussion unterscheiden kann und bei letzterem nicht gleich unter die Gürtellinie geht. :)
 
Ich antworte mal nochmal, wegen des ausführlichen Beitrags.

Das wäre mir jetzt ziemlich neu. Ich verwende PostgeSQL seit fast einem Jahrzehnt produktiv und habe noch nie eine Jail gebraucht.

Bei PostgreSQL ist es oft (eigentlich fast immer) nötig einen kompletten Datenbank-Dump zu machen und diesen dann wieder in die neue Version einzuspielen. Den Datenbank-Dump musst du aber mit der _neuen_ Version von PostgreSQL machen. Diese kriegt man aber unter FreeBSD schlicht nicht installiert, da es zum Versionskonflikt kommt und dir auch von der Datenbank benötigte Dateien dann überschreibt. Eigentlich dürfte PostgreSQL auch gar nicht nach /usr/local/bin installiert werden, da man sich damit auch diverse andere Features verbaut. Das pg_upgrade Programm ist z.B. unbrauchbar unter FreeBSD, weil pg_upgrade beide Versionen parallel installiert haben will. Leider sind die Port-Maintainer nicht bereit dies zu ändern "weil das schon immer so war". Entsprechender Mailing-Listen Post ist per Google auffindbar.

Wenn man direkt über die Ports geht, kann man da noch ein bisschen tricksen, aber mit PKG ist mir das noch nie gelungen. Und wie gesagt... eigentlich sollte PostgreSQL nie so installiert werden.

Mich macht es nur immer stutzig, wenn mir ein Programm sagt, was zu tun ist, als wie wenn es das selbst tut.

Ein anderer würde sagen: Starte mir nicht einfach irgendwas neu!

Ich glaube du hast mich da falsch verstanden. Das Feature ist ja die Funktionalität, nicht das File. Das war als Antwort auf deine Argumentation, dass es bei rc.d mehrere Files braucht um was zu tun. Der Fix wäre sowas wie eine [socket] section im Unitfile zu haben.

Das Problem ist hier, dass hier ein Socket ggf. mehrere Dienste "überschatten" kann.

Genau, das ist doch meine Argumentation! Eben, weil es fast wie ein Shell-Skript ist. Nur dass man mit einem normalen Shell Skript das ganze einfacher hätte und man sich einfacher täte Kontrollstrukturen zu bauen. Allerdings geht das alles auch gegen die Behauptung, dass Unit-Files dazu da sind nur deklarativ, statt prozedural zu arbeiten.

Wie gesagt, es hindert auch keiner einen daran ein Shell-Skript dort anzuhängen, wenn unbedingt nötig. Aber allgemein ist es nicht nötig, da halt vom Init-System ein Großteil der Fälle abgedeckt ist. Vom Config-Check bis hin zu diversen System-Flags.

Und das Selbe in einem Unit-File?

Es war mehr ein Beispiel für die Qualität und Programmier-Stils der SH-Skripte in FreeBSD...

So wie ich das sehe macht systemd ein paar Dinge einfacher, ein paar andere Dinge schwieriger. Ich sehe jetzt nicht viel, was es groß vereinfacht, zumindest nichts, wo es dafür andere vereinfachende Dinge (zum Beispiel, dass ich dann Konfigurationsoptionen für eine einheitliche Konfiguration für rc.conf habe) eintausche. Meine Behauptung ist ja auch nicht, dass rc.d oder OpenRC perfekt wäre. Für mich geht derzeit, wenn ich SystemD und sowohl gegen FreeBSD's rc.d, als auch gegen OpenRC eher für diese Systeme auf und zwar als Admin, als auch als Package Maintainer und Entwickler, auch weil es meines Erachtens relativ gut Wissensbereiche und Zuständigkeiten abdeckt.

Ich skippe wie angekündigt mal das Diskussion rund um systemd-Internas, da a) hier Diskussionen rund um systemd nur Flamewars auslöst und b) systemd hyping nicht meine Intention ist. Zur allgemeinen Syntax der entsprechenden Konfiguration: Auch die OpenRC-Startskripte die ich so bisher gesehen habe sind gefühlt 10000mal lesbarer als der hingeschmierte SH-Code in den meisten FreeBSD Skripten. Ich stehe nicht hier und halte die systemd Service-Dateien für das absolut Geilste. Natürlich findet man Fälle die in der jeweils anderen Deklaration besser aussieht. Aber mein Argument dazu bleibt: Keiner verbietet dir in systemd Skripte. Aber rc.d hat kein Äquivalent für die Service-Dateien.

Wie schon gesagt, bietet ein neueres Init-System durchaus noch weit mehr Vorteile und hier ist nunmal die Einstellung "es funktioniert, wir ändern nichts" eben das Doofe. Denn wenn man nichts ändert kriegt man auch keine Vorteile. Ein Dienst der über systemd oder (in Teilen) OpenRC gestartet wird, kann unter anderen "On-Demand" gestartet werden, oder noch viel besser direkt ohne große Konfiguration in einer Sandbox liegen. Weiterhin ist es auch möglich mal eben diverse Limits und andere Flags direkt zu setzen. Und das gilt dann auch nicht nur für einen Prozess oder einen Benutzer sondern auch gerne über ganze Prozessgruppen. Datenbanken und Webserver spawnen ja gerne mal mehr als einen Prozess.

Gut, hier kann man schlecht vergleichen, da FreeBSD diverse Features des Linux-Kernels nicht hat. Ebenso bietet hier rc.d nichts. Entsprechend wird auch viel Kram innerhalb der SH-Skripte gemacht die anderweitig unnötig sind.

Noch weitere Features sind, dass das Init System auch weiß was zusammengehört und was einzelne Dienste sind. Ein "service nginx status" ist in FreeBSD relativ nutzlos. Ob ein Dienst läuft oder nicht sehe ich auch so. Ein systemctl status nginx gibt mir aber _sehr_ ausführliche und nützliche Informationen rund um den gewählten Dienst. Neben Laufzeit und Last auch noch die Logdaten und anderer Kram.

Alles Sachen die ich unter FreeBSD _sehr_ vermisse... Ich hab hier zig httpd und nginx-Prozesse laufen. Der Host kann mir nicht sagen wo die laufen. Wenn irgend ein Dienst eine hohe Last hat, dann darf ich Jail für Jail durchgehen und selbst suchen, mal grob ausgedrückt.

Und der Punkt mit der zentralen rc.conf... so zentral ist die gar nicht mehr. In meinem Fall splittet sich die rc.conf bereits auf in die rc.conf und die jails.conf. Auch sind diverse Dienst-Optionen darin nicht sichtbar. Nur eben das was das Init-Skript eben vorsieht, was in der rc.conf stehen könnte, teils auch mit nicht einheitlicher Syntax.

So wie ich das sehe, ist Systemd vs rc.d keine objektive Abwägung, bzw. wenn man die Details objektiv durch gehen würde fällt das nicht so stark für eine Seite aus.

Wenn man die modernen Init-Systeme auf das Featureset von rc.d runterbricht ja. Verstreut man aber leichte Prisen von Sandboxing, Limits und Laufzeit-Infos, und automatisches Neustarten von Diensten, dann erübrigt sich schnell die Diskussion. Aber das war hier schon vor ein paar Seiten das Thema. Es endete in etwa in "ich brauche das nicht, darum bin ich dagegen".
 
Das Thema mit PostgreSQL haben wir auch schon mal hier diskutiert (und sind glaube ich zu dem Schluss gekommen - ist halt so - Jail oder nicht möglich)
 
rc.d hat mir beim Versuch Apache 2.4+PHP7 zum Laufen zu kriegen auch dauernd gesagt, dass Apache "started" sei... nö. Apache ist direkt beim Start mit einem Coredump weggesegelt. Davon wusste natürlich rc.d so gar nichts.

Aber gut, man muss sich auf einem IRC halt auch benehmen, sonst fliegt man halt. Unhöfliche Kritik wird halt nicht gerne gesehen.

So wie hier. Wenn rc.d in FreeBSD kritisiert wird, wird man ja auch gleich als inkompetent bezeichnet.
 
Apache ist direkt beim Start mit einem Coredump weggesegelt.
Das habeich auch (php-5.6.27)!
Code:
root@www /usr/local/etc/php # service apache24 restart
Performing sanity check on apache24 configuration:
Syntax OK
Stopping apache24.
Waiting for PIDS: 9954.
Performing sanity check on apache24 configuration:
Syntax OK
Starting apache24.
Der Apache läuft hier aber def. nicht. Problem ist das IMAP Modul von PHP. cat /usr/local/etc/php/ext-20-imap.ini
Code:
;extension=imap.so
Dann funktioniert es...

Hier wäre es wirklich schön, wenn es etwas mehr "Intelligenz" geben würde.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben