W dniu 11.03.2025 o 20:06, Cy Schubert pisze:
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.
Dear Committer,
in the past (and now, after the revert of commit
521f66715afb312b356afafc68cbc044a436a753), NTPD was run as root. The
change introduced in 521f66715afb312b356afafc68cbc044a436a753 no longer
allowed root, but with mac_ntpd.ko loaded it was possible to start NTPD
using the ntpd user account. Removing line 63 from the startup scripts
[1], regardless of the change introduced by
521f66715afb312b356afafc68cbc044a436a753, allows NTPD servers to be
started using the ntpd user account on all my affected machines.
Furthermore, all affected machines have "logfile", "keys" and
"driftfile" set, and NTPD works fine on them using the ntpd account if
only mac_ntpd is loaded. So indeed the topic "heads up: mac_ntpd has to
be explicitly loaded in recent stable/14" was unfortunate. Sorry for the
noise and bringing this up, because probably in the past on all these
machines NTPD was started using UID 0. Please allow me to apologize, I
simply missed a change made 7 years ago in the line 63 (grep -E -q
"${fileopts}" "${ntpd_config}" && return 1) and I was 100% sure that all
my servers use the mac_ntpd.ko policy and the NTPD daemon is started
under UID 123. Only few of them was behaving this way, the most of them
still used UID 0 to run the daemon.
Dear Subscribers,
please forgive me for making unnecessary noise again.
I am so embarrassed that I will not write another post on this thread today.
Yours sincerely
1.https://github.com/freebsd/freebsd-src/blob/main/libexec/rc/rc.d/ntpd#L63
--
Marek Zarychta
