In message <2ac849e6-3851-47ad-9844-968cf0067...@plan-b.pwste.edu.pl>, Marek Za rychta writes: > W dniu 11.03.2025 o 19:02, Cy Schubert pisze: > > 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 hav > e > >>>>>>>>> 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 th > is > >>>>>>>> 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 co > de > >>>>>> 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#L6 > 3 > >>> 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. > > > I don't know. It's the same bug from the beginning, but it reveals in > different ways. It looks like the early exit from can_run_nonroot > function prevented loading mac_ntpd.ko module. All affected setups in my > case had set options: logfile, keys and driftfile what is probably still > completely fine. These configs are old, but the syntax is still correct > and I believe using ntp keys or setting logfile from the config directly > shouldn't be banished.
Aside from my commit to use -u instead of su, the script hasn't changed, except for comments, since 2022. The problem must be your config, somewhere. Reverting the script to rely in su instead of ntpd handling setuid() itself, though helping you now see that the commit wasn't the problem, was needless. Patching your script with the suggested error messaging patch would have given us clarity to the problem rather than randomly reverting commits until it magically worked. You need to apply the error messaging patch or we continue to *guess* what the problem might be. Guessing is not a smart debugging strategy. Sitting here at my desk I do not have any useful information beyond guesses. Sorry for the rant but I've worked on software support, sysadmin, and various development roles throughout my 50+ year career. When users provide little to no information to go on all we are left with is to guess. Right now my guess is that there is something wrong with your setup. Beyond that I don't know because the only information I have is, it doesn't work for you. And since I cannot reproduce your problem here on 15-CURRENT, 14.2-RELEASE, or 13.5-RELEASE, I have no additional visibility into your problem. I need data. > > With kind regards, > > -- > 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
