Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 493078 - >net-misc/openntpd-20080406 - pkg_setup creates unusable symlink to /etc/localtime
Summary: >net-misc/openntpd-20080406 - pkg_setup creates unusable symlink to /etc/loca...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Christoph Junghans (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-01 21:42 UTC by Thomas Deutschmann (RETIRED)
Modified: 2013-12-05 00:25 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Deutschmann (RETIRED) gentoo-dev 2013-12-01 21:42:00 UTC
Hi,

per default, openntpd will chroot to "/var/lib/openntpd/chroot" (NTP_HOME).

Therefore all >net-misc/openntpd-20080406 ebuilds (=net-misc/openntpd-20080406-{3,4,5}) are creating ${NTP_HOME}/etc/localtime as symlink to "/etc/localtime".

But a symlink which targets a file outside the chroot environment won't work. So this doesn't work. :)

If "localtime" is really needed (not sure if openntpd will log in localtime when logging to a logfile, I am just using openntpd with syslog) the runscript should create (and update!) localtime on each start. Also, if this is really needed, don't we need "/dev/log" in chroot, too?

Reproducible: Always
Comment 1 Christoph Junghans (RETIRED) gentoo-dev 2013-12-02 13:40:47 UTC
(In reply to Thomas D. from comment #0)
> Therefore all >net-misc/openntpd-20080406 ebuilds
> (=net-misc/openntpd-20080406-{3,4,5}) are creating ${NTP_HOME}/etc/localtime
> as symlink to "/etc/localtime".
> 
> But a symlink which targets a file outside the chroot environment won't
> work. So this doesn't work. :)
> 
> If "localtime" is really needed (not sure if openntpd will log in localtime
> when logging to a logfile, I am just using openntpd with syslog) the
> runscript should create (and update!) localtime on each start. Also, if this
> is really needed, don't we need "/dev/log" in chroot, too?
The whole thing was introduced due to systemd support (bug #471610), so bringing back start_pre is not an option. I think a hardlink (see 20080406-r6) should work as it does things on a lower level.

Concerning /dev/log, it seems it has been working without it for a long time.
Comment 2 Thomas Deutschmann (RETIRED) gentoo-dev 2013-12-02 14:02:41 UTC
I run openntpd through strace and "/dev/log" is no problem: The master process, running as root, will communicate with syslog.

Have you verified that the chrooted child process is used for logging (therefore needs localtime) when logging to a logfile?

I also disagree that using hardlinks will solve the problem: Think about setups where /var and /etc isn't located on the same partition/disk. Now the ebuild will fail on these setups...

I don't understand why systemd folks don't want to use "ExecStartPre". Sometimes there are services which needs some kind of pre-work. See bug 479490 for example.

My solution:
1) Remove the symlink

2) For OpenRC: Update localtime in chroot every time ntpd will be started

   For systemd: Do nothing :>  Add an ewarn/einfo to pkg_postinst() telling the user he/she has to copy /etc/localtime to chroot (maybe you should do that when the package will be installed for the first time, check via REPLACING_VERSIONS). Also make clear that the user has to keep an eye on that file if his timezone will change/be updated.


=> Don't remove/break things for OpenRC just because they don't work on systemd. If you can update chroot with OpenRC, update the chroot environment in the runscript. If you cannot (or should not) do the same on systemd, well.. don't do it, systemd's decision (but tell the user) :)
Comment 3 Christoph Junghans (RETIRED) gentoo-dev 2013-12-05 00:25:37 UTC
+  05 Dec 2013; Christoph Junghans <ottxor@gentoo.org>
+  openntpd-20080406-r6.ebuild:
+  fixed cross-device link issue (bug #493178)
+