In message <9756f69e-c849-4a01-b7c0-4b89a57e1...@plan-b.pwste.edu.pl>, Marek Za rychta writes: > This is a multi-part message in MIME format. > --------------AE7s5oJnhOW0uW76c0IQR0yC > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 8bit > > W dniu 11.03.2025 o 18:20, Cy Schubert pisze: > > In message<f63d67b5-6e05-481f-9560-06150eb5a...@plan-b.pwste.edu.pl>, > > Marek Za > > rychta writes: > >> W dniu 11.03.2025 o 17:29, Marek Zarychta pisze: > >>> W dniu 11.03.2025 o 16:13, Cy Schubert pisze: > >>>> In message<20250311011257.dd642ecbcd132ecb7142d...@dec.sakura.ne.jp>, > >>>> Tomoaki > >>>> AOKI writes: > >>>>> On Mon, 10 Mar 2025 16:37:58 +0100 > >>>>> "Herbert J. Skuhra"<herb...@gojira.at> wrote: > >>>>> > >>>>>> On Mon, 10 Mar 2025 13:06:25 +0100, David Wolfskill wrote: > >>>>>>> On Mon, Mar 10, 2025 at 01:51:40PM +0200, Marek Zarychta wrote: > >>>>>>>> Hello List Subscirbers, > >>>>>>>> > >>>>>>>> in the past the module was loaded automatically upon NTPD server > >>>>>>>> startu > >>>>> p. > >>>>>>>> It's no longer true, now it has to be loaded earlier. > >>>>>>>> Perhaps people running stable/14 might find this message useful. > >>>>>> Hmm, works for me on main and stable/14. > >>>>>> > >>>>>>> So... I noticed this for (precisely) one of the five machines I have > >>>>>>> that track stable/14 -- the other 4 get mac_ntpd loaded > >>>>>>> automagically as > >>>>>>> usual. > >>>>>>> > >>>>>>> In the failing case, it seems that > >>>>>>> > >>>>>>> sysctl security.mac.version > >>>>>>> > >>>>>>> yielded > >>>>>>> > >>>>>>> sysctl: unknown oid 'security.mac.version' > >>>>>> I only get this if I build a kernel without "options MAC". But in this > >>>>>> no mac_* kernel modules are built and ntpd fails with: > >>>>>> > >>>>>> Starting ntpd. > >>>>>> daemon control: got EOF > >>>>>> /etc/rc.d/ntpd: WARNING: failed to start ntpd > >>>>> In this case, you'll find something like > >>>>> Need MAC 'ntpd' policy enabled to drop root privileges > >>>>> daemon child exited with code 255 > >>>>> in ntpd logfile (/var/db/ntpd.log in my case, but > >>>>> possibly /var/log/messages by default). > >>>> I don't understand why some systems (those in this thread) have a > >>>> problem > >>>> not loading mac_ntpd while others, i.e. my stable/14 at $JOB, are > >>>> fine. I'd > >>>> like to try to understand the differences between those that work and > >>>> those > >>>> that don't. > >>>> > >>>> First of all, the ntpd rc script bails without saying why when it > >>>> encounters a problem. can_run_nonroot() simply returns a bad return code > >>>> leaving us to wonder why. > >>>> > >>>> The first order of business is to produce a patch to indicate why it > >>>> bails. Please apply the attached patch and let me know where it fails. > >>>> Messages will be printed to stderr and to /var/log/messages (assuming > >>>> daemon.err is sent there). > >>>> > >>>>> -- > >>>>> Tomoaki AOKI<junch...@dec.sakura.ne.jp> > >>>>> > >>>> > >>>> > >>>> Cheers, > >>>> Cy Schubert<cy.schub...@cschubert.com> > >>>> FreeBSD UNIX:<c...@freebsd.org> Web:https://FreeBSD.org > >>>> NTP:<c...@nwtime.org> Web:https://nwtime.org > >>>> > >>>> e^(i*pi)+1=0 > >>> Output from the patch: > >>> > >>> Mar 11 17:20:35 plan-b ntpd[60113]: ntpd 4.2.8p18-a (17): Starting > >>> Mar 11 17:20:35 plan-b ntpd[60113]: Command line: /usr/sbin/ntpd -p > >>> /var/db/ntp/ntpd.pid -c /etc/ntp.conf -u ntpd:ntpd > >>> Mar 11 17:20:35 plan-b ntpd[60113]: > >>> ---------------------------------------------------- > >>> Mar 11 17:20:35 plan-b ntpd[60113]: ntp-4 is maintained by Network > >>> Time Foundation, > >>> Mar 11 17:20:35 plan-b ntpd[60113]: Inc. (NTF), a non-profit 501(c)(3) > >>> public-benefit > >>> Mar 11 17:20:35 plan-b ntpd[60113]: corporation. Support and training > >>> for ntp-4 are > >>> Mar 11 17:20:35 plan-b ntpd[60113]: available at > >>> https://www.nwtime.org/support > >>> Mar 11 17:20:35 plan-b ntpd[60113]: > >>> ---------------------------------------------------- > >>> Mar 11 17:20:35 plan-b ntpd[60114]: switching logging to file > >>> /var/log/ntp > >>> Mar 11 17:20:36 plan-b ntpd[60113]: daemon child exited with code 255 > >>> Mar 11 17:20:36 plan-b root[60118]: /etc/rc.d/ntpd: WARNING: failed to > >>> start ntpd > >>> > >>> Debugging output from from the unpatched /etc/rc.d/ntpd: > >>> > >>> (...) > >>> > >>> + echo 'Starting ntpd.' > >>> Starting ntpd. > >>> + [ -n '' ] > >>> + _cd='' > >>> + _doit=' /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -u > >>> ntpd:ntpd' > >>> + [ -n '' ] > >>> + [ -n '' ] > >>> + [ -n '' ] > >>> + [ -n '' ] > >>> + _doit=' limits -C daemon /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid > >>> -c /etc/ntp.conf -u ntpd:ntpd' > >>> + _run_rc_doit ' limits -C daemon /usr/sbin/ntpd -p > >>> /var/db/ntp/ntpd.pid -c /etc/ntp.conf -u ntpd:ntpd' > >>> + local _m > >>> + debug 'run_rc_command: doit: limits -C daemon /usr/sbin/ntpd -p > >>> /var/db/ntp/ntpd.pid -c /etc/ntp.conf -u ntpd:ntpd' > >>> + umask > >>> + _m=0022 > >>> + > >>> + eval ' limits -C daemon /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c > >>> /etc/ntp.conf -u ntpd:ntpd' > >>> + limits -C daemon /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c > >>> /etc/ntp.conf -u ntpd:ntpd > >>> daemon control: got EOF > >>> + _return=255 > >>> + umask 0022 > >>> + [ 255 -ne 0 ] > >>> + [ -z '' ] > >>> + return 1 > >>> + warn 'failed to start ntpd' > >>> + [ -x /usr/bin/logger ] > >>> + logger '/etc/rc.d/ntpd: WARNING: failed to start ntpd' > >>> + echo '/etc/rc.d/ntpd: WARNING: failed to start ntpd' > >>> /etc/rc.d/ntpd: WARNING: failed to start ntpd > >>> + return 1 > >>> > >> The real problem is here: > >> + [ -n '' ] > >> + local 'fileopts=^[ \t]*crypto|^[ \t]*driftfile|^[ \t]*key|^[ > >> \t]*logfile|^[ \t]*statsdir' > >> + grep -E -q '^[ \t]*crypto|^[ \t]*driftfile|^[ \t]*key|^[ > >> \t]*logfile|^[ \t]*statsdir' /etc/ntp.conf > >> + return 1 > >> > >> To reproduce: use config matching the regex from the above, for example > >> add line: > >> > >> logfile /var/log/ntp.log > >> > >> to the ntp.conf > >> > >> 15-CURRENT is also affected this way. That's a bit odd that nobody > >> reported it yet. > >> > >> Problems made by can_run_nonroot function can be fixed by removing lines > >> 60-64 from the starting script. > >> > >> https://github.com/freebsd/freebsd-src/blob/main/libexec/rc/rc.d/ntpd#L63 > > What is in your ntpd_config in rc.conf? > # grep ntpd_config /etc/rc.conf /etc/defaults/rc.conf > /etc/defaults/rc.conf:ntpd_config="/etc/ntp.conf" # ntpd(8) > configuration file
Without the patch I replied with, we're back to guessing. Yet, every feels the problem is in a different part of the rc script. The mystery is why are all my instances (13, 14, 15) working and yours not? I have reverted the commit. A rewrite of the rc script will be required in order to implement ntpd's chroot. > > -- > Marek Zarychta -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org NTP: <c...@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0
