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 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.
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.
With kind regards,
--
Marek Zarychta
