OpenWrt Forum Archive

Topic: Authoritative nameserver, NTP server / WRT build environment

The content of this topic has been archived on 30 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi everyone, just got my WRT54G the other day and am thoroughly enjoying running Linux on it!

With some pointers from a couple of guys from #wrt54g, I made a couple of packages for myself that others might find useful.  One is for nsd, an authoritative nameserver.  The other is for OpenNTPD, an NTP server/client that's a fair bit smaller than the standard ntpd.  The packages are at http://mcc.id.au/openwrt/.

Now, I'm trying to get another thing cross compiled for my WRT but the configure script is having a fit because it can't run some of its test programs, due to it generating binaries for the WRT and not being able to run them.  Is there a publicly accessible machine that can be used for natively compiling things for the WRT, as handhelds.org do for the iPAQ?  If not, any hints on getting a native build environment going?  I'm guessing some NFS mounted storage space.  What packages will I need?

Thanks,

Cameron

I'm trying to install openntpd, but I get errors:
==
# ipkg install openntpd

Downloading http://mcc.id.au/openwrt/openntpd_20040719p_mipsel.ipk ...
Connecting to mcc.id.au[218.214.19.12]:80
openntpd_20040719p_m 100% |****************************| 19784       00:00 ETA
Done.
Unpacking openntpd...Done.
Configuring openntpd...expr: syntax error
[: 100: unknown operand
Adding group _ntp ()
expr: syntax error
[: 100: unknown operand
Adding user _ntp ()

You probably want to:
  1. Edit /etc/ntpd.conf to specify which addresses to listen on for
     NTP clients.
  2. Add "/usr/sbin/ntpd" to /etc/init.d/S50services to have it start
     at boot time.
Done.
===
Then, not unexpectedly:
===
# /usr/sbin/ntpd
ntpd: unknown user _ntp
===
Is some other package missing from my system?  No dependencies are listed for this package.

To run ntpd you additionally need to:

echo "ntp 123/udp" > /etc/services
mkdir /nowhere

-Gregor

Thanks for the input, but these steps don't seem to fix the problem:
====
# echo "ntp 123/udp" > /etc/services
@OpenWrt:/etc/init.d# mkdir /nowhere
@OpenWrt:/etc/init.d# ipkg install openntpd

Downloading http://mcc.id.au/openwrt/openntpd_20040719p_mipsel.ipk ...
Connecting to mcc.id.au[218.214.19.12]:80
openntpd_20040719p_m 100% |****************************| 19784       00:00 ETA
Done.
Unpacking openntpd...Done.
Configuring openntpd...expr: syntax error
[: 100: unknown operand
Adding group _ntp ()
expr: syntax error
[: 100: unknown operand
Adding user _ntp ()

You probably want to:
  1. Edit /etc/ntpd.conf to specify which addresses to listen on for NTP clients.
  2. Add "/usr/sbin/ntpd" to /etc/init.d/S50services to have it start at boot time.
Done.
===
# /usr/sbin/ntpd
ntpd: unknown user _ntp
===
Duh.

Hmm, must be something wrong with my postinst script then.  You do have a working awk, sort and tail installed, right?  (They should be provided by busybox, so I guess they would be there.) 

Ok, try running this on your WRT:

awk -F : '{ print $3 }' /etc/group | sort -n | tail -1

and tell me what it says, and if you're ok with it, post your /etc/group file.  The only thing I can think of is that maybe your /etc/group file (and /etc/passwd) is empty, and that's what's screwing it up.

Anyway, to get around the problem just create a user and group called _ntp.  But I'd like it if you could persist with the package so I can see what's wrong with my scripts.

(You shouldn't need to mkdir /nonexistent either.)

Thanks,

Cameron

Now, I'm trying to get another thing cross compiled for my WRT but the configure script is having a fit because it can't run some of its test programs, due to it generating binaries for the WRT and not being able to run them.  Is there a publicly accessible machine that can be used for natively compiling things for the WRT, as handhelds.org do for the iPAQ?  If not, any hints on getting a native build environment going?  I'm guessing some NFS mounted storage space.  What packages will I need?

Cool .. I wanted to run a name server too, but bind and djbdns looked too big and horrible, respectively, and I didn't find nsd.  Putting together a native build environment would probably take some work, but the OpenWRT busybox has chroot, so you could prepare a nfs image and mount and chroot to it.  Compiling things like gcc and binutils for mipsel would be a pain though.  Would it be easier to just hack up the configure script?

cam wrote:

Hmm, must be something wrong with my postinst script then. You do have a working awk, sort and tail installed, right? (They should be provided by busybox, so I guess they would be there.)

Ok, try running this on your WRT:

Code:
awk -F : '{ print $3 }' /etc/group | sort -n | tail -1

and tell me what it says, and if you're ok with it, post your /etc/group file. The only thing I can think of is that maybe your /etc/group file (and /etc/passwd) is empty, and that's what's screwing it up.

Anyway, to get around the problem just create a user and group called _ntp. But I'd like it if you could persist with the package so I can see what's wrong with my scripts.

(You shouldn't need to mkdir /nonexistent either.)

Thanks,

Cameron

OK, I removed the openntpd package and made sure all its old files were gone. Then, fresh install:
===
# ipkg install openntpd

Downloading http://mcc.id.au/openwrt/openntpd_20040719p_mipsel.ipk ...
...[same as before]
Configuring openntpd...expr: syntax error
[: 100: unknown operand
Adding group _ntp ()
expr: syntax error
[: 100: unknown operand
Adding user _ntp ()
...[same as before]
====
# awk -F : '{ print $3 }' /etc/group | sort -n | tail -1

# cat /etc/passwd

_ntp::::ntpd user:/nowhere:/noshell

# cat /etc/group

_ntp:*::
# /usr/sbin/ntpd
ntpd: unknown user _ntp
====
Seems like the passwd, group files are OK?  But the _ntp user is not found...

Thanks for your input, much appreciated.

Putting together a native build environment would probably take some work, but the OpenWRT busybox has chroot, so you could prepare a nfs image and mount and chroot to it.  Compiling things like gcc and binutils for mipsel would be a pain though.  Would it be easier to just hack up the configure script?

Yeah maybe I will just hack it and hope that it works.  I wonder also if I did have a native build environment on there whether there'd be enough memory to do big compilations.

# awk -F : '{ print $3 }' /etc/group | sort -n | tail -1

# cat /etc/passwd

_ntp::::ntpd user:/nowhere:/noshell

# cat /etc/group

_ntp:*::

Ok, so your /etc/passwd and /etc/group files look quite strange.  You don't have an entry for the root user or group.  That's where my script is failing; it isn't finding any numbers in the file (which is why the _ntp entries in there are missing UID and GID numbers between those colons).  How about you remove those _ntp lines from /etc/group, /etc/passwd and /etc/passwd-, ensure that you have proper lines for the root user and group in those files, then install the package again.  Something like this in /etc/passwd:

root:x:0:0:root:/tmp:/bin/ash

with a complementary line in /etc/passwd-, and this in /etc/group:

root:x:0:

Once entries are in there, my package scripts should work.  I am surprised though that you had nothing in these files before my scripts tried to add entries to them.  How are you able to log in to your WRT?

Cameron

The passwd and group files are created by the dropbear installation script; openwrt only provides a telnet without login, hence no password files.

The passwd and group files are created by the dropbear installation script; openwrt only provides a telnet without login, hence no password files.

Ah, I see.  I've updated the postinst script to handle this case.  ipkg update and give the new packages a shot thanks yawlhoo.

Cameron

I plead guilty (blush) to simple telnetting to my router and logging in without a password.

Your new package allows a clean install, but then I see further problems.  First, nptd does not properly demonize, after starting ntpd, it doesn't show up in the process list.  Starting ntpd with the "-d" switch gives:
===
# ntpd -d
fatal: getservbyname: Input/output error
dispatch_imsg in main: pipe closed
Lost child: child exited
Terminating
====
This is then fixed by:
====
# echo "ntp   123/udp" >> /etc/services
====
(shouldn't your install handle this?), but then:
====
# ntpd -d
fatal: chroot: No such file or directory
dispatch_imsg in main: pipe closed
Terminating
====
Thanks for your help.

Ah: I grepped through the openntpd source code, and in ntp.c found:
==
...
    if (chroot(pw->pw_dir) == -1)
        fatal("chroot");
===
so it appears that a previous poster was correct, it is necessary to "mkdir /nowhere" (and to add ntp to /etc/services).  Maybe you should at least add checks for these in your package installs?
===
with these changes, and your postinstall changes in place, ntpd works.
===
Thanks again for your help, and in preparing the package in the first place.

One final thing I discovered: in the "addresses to listen on" section of /etc/ntpd.conf:
===
# Addresses to listen on (ntpd does not listen by default)
# listen on *
# listen on 127.0.0.1
# listen on ::1
===
trying to use the first entry one gets: "listen on *not supported on this  platform, interface address required".  Grepping through the openntpd source code this is apparently due to the lack of the "getifaddrs" call on the WRT54G(S) platform:
====
    if (conf->listen_all) {
#ifdef HAVE_GETIFADDRS
        struct ifaddrs      *ifap;
        struct sockaddr     *sa;
....
        freeifaddrs(ifap);
#else
        fprintf(stderr, ""listen on *" not supported on this "
            "platform, interface address requiredn");
        exit(1);
#endif
    }
===
FWIW.

Does this actually work for anyone?
It doesn't appear to update the time for me, running ntpd in debug (-d) mode shows the following:

[..]
reply from 61.9.198.77: offset 145294240.271110 delay 0.573404, next query 30s
reply from 62.220.226.2: offset 145294240.317157 delay 0.247023, next query 30s
adjusting local clock by 145294240.161959s
adjtime failed: Invalid argument

Seems to be working for me.  Maybe you need to use "rdate" to get the clock close to being correct, before invoking nptd?  My /etc/init.d/S60ntpd script looks like this:
===
# cat S60ntpd
#!/bin/sh

echo "syncing with rdate to NIST..."
/usr/sbin/rdate -s time.nist.gov
echo "starting ntpd..."
/usr/sbin/ntpd -f /etc/ntpd.conf
===
Maybe we really need to implement ntpq, say to call "ntpq -p"

Yeah, I was just giving it some extreme testing wink

However to test it better I set the time to about 6 minutes behind (using date -s) and ran it again and it is still 6 minutes behind 2 hours later.

The output didn't show the Invaild argument error and it says adjusting clock by 400 seconds but the time reported by ntp (ntpdate -q from another machine) and the time reported by date don't change.

Well I've left it running for nearly two days now but the time is still 6 minutes behind, using strace shows that the adjtime syscall is made as expected but the time is still wrong..

strace:
22087 adjtimex({modes=32769, offset=456061094, freq=0, maxerror=16384000,
esterror=16384000, status=64, constant=2, precision=1, tolerance=33554432,
time={1092166763, 590001}}) = 5

I have been fiddling around with my system so I am not sure why this is happening, but it seems that maybe solely by starting with less of a time difference  (about 1 min initially) than you did, the local clock appears to slowly be coming into sync, judging by the output of "rdate -p time.nist.gov; date":
===
0) initially  8-11-04, about 10PM PDT, local clock set to lag NIST by ~ 1 min.

1) subsequently:
===
Fri Aug 13 05:20:01 2004
Fri Aug 13 05:19:08 UTC 2004
diff = 53s

Fri Aug 13 15:43:00 2004
Fri Aug 13 15:42:09 UTC 2004
diff = 51s
...
===
I will continue tracking this, although obviously, any conclusions are going to take a while to establish.

If this is correct, then an initial sync of the local clock before starting ntpd should be enough to ensure reasonably accurate subsequent timekeeping.

The discussion might have continued from here.