Ntpd config file support

[Laszlo Papp]

On Tue, Mar 18, 2014 at 9:17 PM, Ralf Friedl <Ralf.Friedl at online.de> wrote:
> Hi Laszlo
>
> First, please either write your message below the quotes, or omit the
> quotes. Especially don't quote parts that are not relevant to your message.

I have no idea what point you are trying to make in here, sorry, nor
do I care about the details 'cause the thread is already huge.

>> At least three people expressed that it is about convenience, a useful
>> one.
>
> Well, all of them didn't provide a convincing argument. And most others on
> this list wonder why you make such a big deal about something that can be
> solved with a few lines in a shell script. If you want a configuration file
> only for the time servers, this script will give you compatibility to the
> ntp.org config file:
> #!/bin/sh
> NTPD_OPTIONS="..."
> exec busybox ntpd $NTPD_OPTIONS $(sed -nre 's/^server *(.*)$/-p
> \1/g'/etc/ntp.conf )

I wonder if you are serious about this compared to the alternative way:

/etc/busybox-ntpd/busybox-ntpd.conf
foo=bar

I guess you are trying to be smart in here without actually realizing
significant difference between the two versions. I would not even
bother to use busybox's ntpd if I had to write such ugly lines that is
much more difficult to maintain than needed to.

>> Anyway, please comment on the init script that I posted earlier when
>> you get around to it, as well as the corresponding config file..
>
> I'm not Harald, but I will comment on it anyway.
> Short version:
> It's a very nice script. Use it. Be very happy with it.
>
> Long version:
> I guess it fits into your distibution, but it's useless for most others.
> That was one of the points Harald made, you want things specific to your
> distibution in Busybox, where they don't belong. You could place it
> somewhere in the contrib directory, but it would probably be a waste of
> space and bandwidth.
> Most distributions come with a template for such a script, and it shouldn't
> take more than a few minutes to adapt such a template.
> You use start-stop-daemon. Why do you think everybody would even have the
> program, or want to use it?

Seriously though, you did not get the point of the thread, have you?
*No one* has suggested to add initscripts to busybox. Please do
re-read the thread. A short configuration file was just suggested. You
are the first one indicating that initscript would need to be added.

> Your script has a reaload case, where you send SIGHUP. What should ntpd do
> on SIGHUP? Reload the config file? You said that reloading the config is not
> necessary when it was about code size, so why send SIGHUP?

Sorry, I cannot follow your logic in here. There is no any need for
signal handling in order to load a config on start, really.

> Finally, the export in the configuration file is not necessary.

It was already discussed, I am afraid.

> In one email in this thread someone suggested to make the configuration
> hardcoded as the compile time configuration. I just hope that was meant as a
> joke.

Not at all, no. It was serious, at least from my side.

>> > Usually scripts in/etc/init.d use /etc/default/* as config values
>>
>> > (some distros, even using them as main config files). The scripts that
>> > Laszlo posted fit that pattern.
>> Not quite; actually "/etc/default" is more like a Debian, et al,
>> pattern. OpenWrt will use something. Yocto uses something else, etc.
>> And for what it is worth, buildroot is also strange with
>> "/etc/default/ntpd" without any busybox indication.
>
> Which again shows that distributions are different, so which distibution
> style should Busybox pick? It is up to the distribution to provide the right
> information to the program.

Exactly the opposite. You really missed the point of this thread. The
whole point about configuration file is to unify it, for me at least.

>> I would ask this question from myself if I were you: what do I gain or
>> lose with such a feature added or rejected? ...
>
> That is a good question if maximizing the number of users is the top
> priority.

Dropping users do not make any sense without gaining more which seems
to be the case here so far.

> Also someone suggested that devices today have GHz CPUs and at least 512MB
> RAM. Well, maybe they are not the target audience of busybox. There are also
> devices with 16MB RAM and 4MB flash.

Actually, the compilation time option has already been said, but let
us consider that for a second it has not... Are you telling me that a
simple open/read/close will saturate the flas because it is complex.
You better stop writing software then because you exceed the limit
very quickly. :-)

>> I do not follow. The busybox user is the distro and maintainer in this
>> case, really. The end user is not necessarily even aware of busybox,
>> I would really appreciate more respect here towards end users.
>> The end users have raised their opinion how they
>> would like to see your software behaving.
>
> I hope you realize that you are contradicting yourself here, within a few
> lines of a single email.

No, I do not. I still stick by my opinion in here I am afraid.