Boot order and dependencies - getting PPP to wait

S

Steinhelten

I am using a FreeBSD system as my router / gateway via PPP over ethernet to my ISP. When my system boots, it may not have the right time. The problem manifests in that named says "validating ./NS: verify failed due to bad signature (keyid=21831): RRSIG validity period has not begun". So - I need the system time set before I can start named. I think what I need to happen is
1) connect to the ISP and wait for the PPP link to come up
2) set up resolv.conf to include DNS servers from the ISP
3) run "ntpdate"
4) start named now that I have a valid time on the system
5) start ntpd to maintain the time
so - what's the best, most robust and stable way to get the system to do that?

Actually, it may be can be simpler than that. With the proper resolv.conf, it should be sufficient to just wait for the PPP link to come up. Just so long as either ntpdate or ntpd has set the system time before named tries to start, I think I'll be OK. I might not even need the "ntpdate" depending on the order these things happen. Now that I think of it - how do I even find out what order these things happen in? Maybe all I need is to change the PPP mode from "ddial" [sic] to "background"? I dunno - I'm a little lost here, which is why I need y'all.
 
edit named rc.d script and add "require timeXXX"
-------------
ppp config file for logging:
Code: 
set log Phase Chat Connect Carrier LCP IPCP CCP Command
--------------
Then start:
Code: 
dial profile_name
 
First, your problem points out a deeper underlying issue: If your system goes down for a long period, and then comes up, named will not start, because "RRSIG validity period has not begun". It might be a good time to address that in the way you have named configured, with a "plan B" in case the time is incorrect.

Failing that ...

There are tricks you can use to get the time close when booting. For example, the last update time of certain system logs, or the build date of some OS utilities. Obviously, this is far from perfect, but for most use cases, it works well enough. On Linux, systemd can be configured to use those tricks; that seems to be the default on RPis. Still, I would suggest installing a RTC. I have used small inexpensive 5-pin boards that sit on the GPIO connector and contain a DS3231 chip and a tiny battery. Available for example from Jameco.
 
Alain De Vos said:
edit named rc.d script and add "require timeXXX"
-------------
ppp config file for logging:
Code: 
set log Phase Chat Connect Carrier LCP IPCP CCP Command
--------------
Then start:
Code: 
dial profile_name
Click to expand...
I'm sorry. I'm simply not clever enough to figure out what you mean by "timeXXX". Also, I don't find anything else that looks like the syntax of "require timeXXX" in the rc.d/named file - they all look like shell command and assignments. require sounds like perl.

Just for reference, when I catenate the default settings with those specific to my profile_name, I get
Code: 
set log Phase Chat LCP IPCP CCP tun command device PPPoE:ue1 authname SECRET authkey SECRET dial login ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
 
One way to kind of circumvent the issue, use IP addresses in your ntpd.conf. Not ideal but it'll work.
 
Go to /etc/rc.d
Look for the files ppp & ntpd
In these files on top you have.
# PROVIDE
# REQUIRE
# BEFORE
# KEYWORD
They configure a "starting order".
For the file "/etc/rc.d/ntpd" add "ppp" to the line " # REQUIRE" , ie :
# REQUIRE: DAEMON ntpdate FILESYSTEMS devfs ppp
Now when rc starts it's services it will wait for ppp to be started before ntpd is started.

Did you manage to start ppp in debug mode ?
 
Normally I would agree with Alain De Vos but I think PPP is different in all networking aspects.

For example you could try NETWAIT directive on ppp0 but I have serious doubts because PPP networking is so different.

/etc/rc.conf
Code: 
netwait_enable="YES"            # Enable rc.d/netwait (or NO)
netwait_if="ppp0"                      # Wait for active link on each intf in t
netwait_if_timeout="120"         # Total number of seconds to monitor link state.
 
I really think that covacat has the right idea with the ppp.linkup script. It's portable, it's consistent, it runs after ppp link is established.
Is the link DHCP? Basically does the ISP give you DNS servers, complete resolv.conf?
Basically your steps 1 thru 5 are pretty much "the linkup script"
 
mer said:
I really think that covacat has the right idea with the ppp.linkup script. It's portable, it's consistent, it runs after ppp link is established.
Is the link DHCP? Basically does the ISP give you DNS servers, complete resolv.conf?
Basically your steps 1 thru 5 are pretty much "the linkup script"
Click to expand...
well i use it myself (with mpd though)
 
  • Like
Reactions: mer
I don't use PPP any more, and my firewalls run on Linux, but the principles are the same.

Ethernet links come up asynchronously, and there are hooks to run scripts when there is a state change. For PPP, these scripts live in /etc/ppp on both Linux and FreeBSD. See ppp(8).

My old PPP code has hook scripts, run when a link comes up (run in alphabetic order of name on Linux) called:
  • B350_up_ntpdate: sets date using ntpdate and IP address of well known Internet NTP Servers;
  • B360_up_dnsmasq: restarts dnsmasq (my name server of choice);
  • B370_up_ntp: restarts ntpd; and
  • B400_up_ddclient: runs ddclient (dynamic DNS client) to register new IP address with Internet DNS provider.
As covcat suggests you can organise these actions from /etc/ppp/ppp.linkup on FreeBSD.
 
  • Like
Reactions: mer
You must log in or register to reply here.
Back
Top