-Nuke-
Well-Known Member
ist es üblich sich ein Skript zu basteln.
Und das mache ich natürlich mit SH aus den 80ern... klar... weil es keine modernen Skriptsprachen gibt
Folge dem Video um zu sehen, wie unsere Website als Web-App auf dem Startbildschirm installiert werden kann.
Anmerkung: Diese Funktion ist in einigen Browsern möglicherweise nicht verfügbar.
ist es üblich sich ein Skript zu basteln.
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.
Ich nehme auch lieber Perl aus den 80ern. Aber wieso ist das Alter entscheidend?
Aber systemd ist ein schwarzes Loch, wo nur noch Red Hat durchsteigt und offensichtlich zu viele Dinge konzentriert.
Wenn man sich mal damit auseinandergesetzt hat schon. Vermutlich haben das so einige die hier mit Diskutieren nicht getan. Da kannst du dich um Kopf und Kragen reden.Die Arbeitsweise ist recht klar.
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...Entsprechend eingereichten Vorschlag hatte ich ja schon verlinkt, weiter vorne. Nannte sich jobd.
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...
weil ich : $(%a*) nicht für eine zeitgemäße Syntax halte.
Nochmal: FreeBSDs rc-System zu kritisieren, ist völlig legitim, aber sich an Syntaxdetails von sh aufzuhängen, zeigt einfach nur Ignoranz.
#!/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"
#!/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"
Das wäre mir jetzt ziemlich neu. Ich verwende PostgeSQL seit fast einem Jahrzehnt produktiv und habe noch nie eine Jail gebraucht.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.
Mich macht es nur immer stutzig, wenn mir ein Programm sagt, was zu tun ist, als wie wenn es das selbst tut.Wenn man systemctl daemon-reload braucht, sagt einem systemctl das auch.
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.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.
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.Sorry, aber diese Datei ist vollkommen einfach lesbar und für jeden verständlich.
Und das Selbe in einem Unit-File?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.
Ich glaube ich habe mich nochmal undeutlich ausgedrückt oder wir sind einfach anderer Meinung.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?
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.
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?
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.- uff... etc/rc.subr hat ja ÜBER 2000 Zeilen
Und was ist LimitRTTIME=infinity? Und was sind die WantedBy targets? Brauch ich die?- load_rc_config... hmm, brauche ich das? Was tut das?
Im Gegensatz zu einer komplett neuen Sprache?- run_rc_command Dollar Sternchen? Huh?
[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
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.So ein simples systemd service File ist dort auf den ersten Blick wesentlich selbsterklärender, meiner Meinung nach.
Also wenn das einzige Argument "es funktioniert" ist, dann würde ich es wirklich nicht ändern.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".
Das wäre mir jetzt ziemlich neu. Ich verwende PostgeSQL seit fast einem Jahrzehnt produktiv und habe noch nie eine Jail gebraucht.
Mich macht es nur immer stutzig, wenn mir ein Programm sagt, was zu tun ist, als wie wenn es das selbst tut.
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.
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.
Und das Selbe in einem Unit-File?
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.
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.
So wie hier. Wenn rc.d in FreeBSD kritisiert wird, wird man ja auch gleich als inkompetent bezeichnet.
Das habeich auch (php-5.6.27)!Apache ist direkt beim Start mit einem Coredump weggesegelt.
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.
;extension=imap.so
Wir verwenden essentielle Cookies, damit diese Website funktioniert, und optionale Cookies, um den Komfort bei der Nutzung zu verbessern.
Siehe weitere Informationen und konfiguriere deine Einstellungen