Re: heads up: mac_ntpd has to be explicitly loaded in recent stable/14

From: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
Date: Tue, 11 Mar 2025 19:15:54 UTC
On Tue, 11 Mar 2025 12:08:10 -0700
Cy Schubert <Cy.Schubert@cschubert.com> wrote:

> In message <20250312040101.154420f993ed27966dfc1b40@dec.sakura.ne.jp>, 
> Tomoaki
> AOKI writes:
> > On Tue, 11 Mar 2025 08:13:51 -0700
> > Cy Schubert <Cy.Schubert@cschubert.com> wrote:
> >
> > > In message <20250311011257.dd642ecbcd132ecb7142dc35@dec.sakura.ne.jp>, 
> > > Tomoaki
> > > AOKI writes:
> > > > On Mon, 10 Mar 2025 16:37:58 +0100
> > > > "Herbert J. Skuhra" <herbert@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 st
> > artu
> > > > 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).
> >
> > The output after patch (without loading mac_ntpd.ko manually):
> >
> > Mar 12 03:27:35 ***** rc.d/ntpd[2581]: user  cannot access files
> > listed in command line, exiting
> > Mar 12 03:27:35 ***** root[2589]: /etc/rc: WARNING: failed to start ntpd
> >
> > See
> >   https://lists.freebsd.org/archives/dev-commits-src-branches/2025-February/0
> > 21308.html
> > for my options related with ntpd.
> 
> Is this before ntpd -u commit was reverted or after?

Before revert. As I don't pull updates after I read your post which
included the patch.


> Please grep ntpd /etc/rc.conf.

Result stripping comments.

% grep ntpd /etc/rc.conf
ntpd_flags="-4 -g -x -f /var/db/ntp/ntpd.drift -l /var/log/ntpd.log"
ntpd_config="/etc/ntp/ntp.conf"
ntpd_enable="YES"
ntpd_sync_on_start="YES"
daily_ntpd_leapfile_enable="YES"
% 

Regards.

> 
> >
> > > 
> > > >
> > > > -- 
> > > > Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>
> >
> >
> > -- 
> > Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>
> 
> 
> -- 
> Cheers,
> Cy Schubert <Cy.Schubert@cschubert.com>
> FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
> NTP:           <cy@nwtime.org>    Web:  https://nwtime.org
> 
> 			e^(i*pi)+1=0


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>