3 ms·

Honest question: has FreeBSD become more automation friendly? i.e. putting all the configuration in /etc/rc.conf may be nice for a systems administrator manuall

Honest question: has FreeBSD become more automation friendly? i.e. putting all the configuration in /etc/rc.conf may be nice for a systems administrator manually editing things, but makes it hard for installation scripts which configure the system incrementally (e.g. Ansible). One thing I like about Linux is support for /etc/foo.d directories instead of /etc/foo.conf. Or is this not a problem in practice? In our new "cloud native" systems we are ending up with a number of single-purpose VMs in AWS or GCP. So being able to run a minimal OS image with OpenBSD has it's attraction. At this point, it's easier to use CentOS or Ubuntu due to application compatibility. I suppose the next logical step is Docker or NixOS.

JdeBP 11y ago
Dealing with /etc/rc.conf isn't any harder than dealing with /etc/fstab, /etc/master.passwd, /etc/ttys, or any of the other text-files-with-specific-defined-formats databases. There's no reason to think that one only edits them manually. One manipulates the account database with tools such as "pw useradd" and suchlike. One can manipulate /etc/rc.conf{,.local} and its replacements with tools too. The OpenBSD people have a while back (http://www.openbsd.org/plus56.html http://www.openbsd.org/plus56.html) explicitly re-defined /etc/rc.conf{,.local} to be a database of name=value pairs (rather than a shell script with arbitrary content), precisely so that it can be manipulated and parsed by programs other than shells. They have the rcctl tool (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/rcctl.8 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/...) which is explicitly designed to let one do things like rcctl enable ntpd and rcctl disable ntpd to enable and disable the ntpd service. Whilst FreeBSD has yet to catch up with the formality, the existence of tools such as sysrc (https://www.freebsd.org/cgi/man.cgi?query=sysrc https://www.freebsd.org/cgi/man.cgi?query=sysrc) mean that treating FreeBSD /etc/rc.conf{,.local} (and indeed other files that can be manipulated with sysrc such as /boot/loader.conf) as a similar database file is a growing idiom, FreeNAS becoming the exception and not the rule in this regard. Services managed on FreeBSD through nosh (http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...) have the advantage that they can use the daemontools envdir mechanism, which separates configuration variables for separate services quite simply and easily. This is a long-standing and well-understood mechanism, which has been around for approaching two decades at this point and which one can find widely discussed and documented. nosh has a mechanism for importing /etc/rc.conf{,.local}, moreover. In nosh there is also an rcctl shim that maps both to this envdir mechanism and to the native service management. So one can do the same rcctl things such as %rcctl get ntpd flags -p /var/run/ntpd.pid -f /var/db/ntpd.drift % which can read (and with the concomitant "rcctl set" modify, of course) the variables in a conventionally-placed envdir, and rcctl enable ntpd and rcctl disable ntpd which will make the appropriate service bundle modifications to enable and disable the service.

JdeBP 11y ago

Dealing with /etc/rc.conf isn't any harder than dealing with /etc/fstab, /etc/master.passwd, /etc/ttys, or any of the other text-files-with-specific-defined-formats databases. There's no reason to think that one only edits them manually. One manipulates the account database with tools such as "pw useradd" and suchlike. One can manipulate /etc/rc.conf{,.local} and its replacements with tools too. The OpenBSD people have a while back (http://www.openbsd.org/plus56.html http://www.openbsd.org/plus56.html) explicitly re-defined /etc/rc.conf{,.local} to be a database of name=value pairs (rather than a shell script with arbitrary content), precisely so that it can be manipulated and parsed by programs other than shells. They have the rcctl tool (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/rcctl.8 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/...) which is explicitly designed to let one do things like rcctl enable ntpd and rcctl disable ntpd to enable and disable the ntpd service. Whilst FreeBSD has yet to catch up with the formality, the existence of tools such as sysrc (https://www.freebsd.org/cgi/man.cgi?query=sysrc https://www.freebsd.org/cgi/man.cgi?query=sysrc) mean that treating FreeBSD /etc/rc.conf{,.local} (and indeed other files that can be manipulated with sysrc such as /boot/loader.conf) as a similar database file is a growing idiom, FreeNAS becoming the exception and not the rule in this regard. Services managed on FreeBSD through nosh (http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...) have the advantage that they can use the daemontools envdir mechanism, which separates configuration variables for separate services quite simply and easily. This is a long-standing and well-understood mechanism, which has been around for approaching two decades at this point and which one can find widely discussed and documented. nosh has a mechanism for importing /etc/rc.conf{,.local}, moreover. In nosh there is also an rcctl shim that maps both to this envdir mechanism and to the native service management. So one can do the same rcctl things such as %rcctl get ntpd flags -p /var/run/ntpd.pid -f /var/db/ntpd.drift % which can read (and with the concomitant "rcctl set" modify, of course) the variables in a conventionally-placed envdir, and rcctl enable ntpd and rcctl disable ntpd which will make the appropriate service bundle modifications to enable and disable the service.