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
Phishfry said:
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.
Click to expand...
Just for the sake of accuracy, ppp uses tun0 instead of ppp0 for PPPoE
 
OK - this is cool - I never knew how the boot processes chose what order to run things in - now I know! Hey, I've been around since Version 6 on a PDP-11, so I span a lot of history.

So - my thoughts are that I'm a little concerned about the ppp.linkup for this because in order to start/restart these services, I'd have to have the "_enable" variables set to "yes" in rc.conf which means they would first get run at boot time, and then get run again in ppp.linkup (which, I presume, is why you have "restart" rather than "start" for named). So - I'm thinking about using my newly-discovered knowledge of the rcorder tags to get things to execute in the necessary order.

Where this might FAIL is that ppp may go into the background BEFORE the link is up with -ddial, in which case I'll have solved nothing.

Anyway - in /etc/rc.d/ntpdate I'll put
# REQUIRE: NETWORKING syslogd ppp
and in /usr/local/etc/rc.d/named I'll put
# REQUIRE: NETWORKING ldconfig syslogd ntpdate
or am I missing important inner dependencies? Does "service" also attempt to follow rcorder?

Since I provide my own resolv.conf file which includes
nameserver 192.168.1.1
nameserver 205.171.3.65
nameserver 205.171.2.65
nameserver 8.8.8.8
I should be able to use DNS names for the ntpdate execution - the first one will fail to open and it will just proceed to the next ones very rapidly, assuming the PPP link up.

Is that the right idea? I'll probably try this tomorrow afternoon so any comments before that will be greatly appreciated.

My big concern is that "ppp" is going to "PROVIDE ppp" before the link is actually up, but this is a first try with modifying the rc.d script orders, so I might be missing something big.

Oh, and since I'm doing my NAT via pf ("/sbin/pfctl -f /etc/pf.conf") maybe I should get into the modern era and control that this way, too? Maybe this is a good candidate for ppp.linkup? But then what do I do about the pf_enable="YES" in rc.conf? If I don't have it in there, "service" won't start it (unless I do "onestart") and if I do have it there, it's going to try to execute it at some other point in the boot cycle. In my own, old-fashioned startup script, I just did a dead-reckoning "sleep 10" between invoking PPP and pfctl to wait for the link to come up.
 
I got off on the wrong track here. I thought that ppp.linkup and ppp.linkdown were script files. It turns out that they are PPP configuration files, so that's not going to do what I want, and what I was saying earlier about these interacting with the rc script structure is nonsense, since I can't stick a "service" command in here anyway. I guess I'm back to looking at the netwait stuff. And I'm still not sure how I can manage reloading my firewall when the link does come up. I believe that in my case it will look like
Code: 
netwait_enable="YES"
netwait_if="tun0"
netwait_ip="205.171.3.65"
netwait_if_timeout="120"
The timeout would be just for debugging / error recovery, since this system's primary task is to be my router.

Well, that was a disaster. It stopped to wait for tun0 BEFORE ppp started, so I just hung there. I just can't figure how I can do this. Very open to suggestions!
 
Steinhelten said:
I thought that ppp.linkup and ppp.linkdown were script files. It turns out that they are PPP configuration files, so that's not going to do what I want
Click to expand...
Have you had a look at /usr/share/examples/ppp/ppp.linkup.sample, specifically the “shell” and “bg” commands?

e.g. execute a program (in the background) to do something (play a tune) when the link comes up:
Code: 
MYADDR:
 !bg /usr/X11R6/bin/auplay /etc/ppp/linkup.au
This illustrates a mechanism to run any script you want...
 
Ah! Thank you! I didn't have the forethought to look for an example there. I'll give that a shot.

Oh, wait. I don't see any "shell" command. I only find the string "shell" in two "set filter" commands. Maybe I need to create a standalone script to run, so that the things I need run sequentially rather than in parallel, but being simultaneous with PPP itself?

So... Just move pfctl, ntpdate, and named out of the rc hierarchy and into ppp.linkup.cmd and in ppp.linkup
Code: 
CenturyLink:
    !bg /etc/ppp.linkup.cmd
and in that file
Code: 
#!/bin/sh
. /etc/rc.conf
. /etc/rc.subr
$pf_program $pf_flags -f $pf_rules
$ntpdate_program $ntpdate_flags $ntpdate_hosts
/usr/local/sbin/named $named_flags
but have all their _enable variables set to NO in /etc/rc.conf so they don't get started according to the rc conventions? This seems harder and less portable than it ought to be.

My test yesterday was possibly compromised due to my ISPs RADIUS servers being down when I was trying. Maybe I should try the PROVIDE/REQUIRE approach, too - just because I think it's flawed due to ppp going into the background before the link comes up doesn't mean that's true. Sigh. This is getting tiring.
 
Your last post crossed this composition, so I see that you are tracking better, but I'll post this anyway, and respond to your specific questions later.

Because state changes on network interfaces happen asynchronously there have to be mechanisms to deal with these asynchronously. On FreeBSD, this is done with:
  • for ppp(8), use ppp.linkup and ppp.linkdown files in the directory /etc/ppp; and
  • for conventional Ethernet interfaces, one uses devd(8) configuration entries in devd.conf(5) matching "types" LINK_UP and LINK_DOWN.
These mechanisms facilitate doing anything you want when a state change occurs on a network interface.

Don't try to fight this design mechanism. Work with it.

As far as your rc scripts are concerned, design your system to boot even if the Internet is completely unavailable, and allow the asynchronous start-up of ppp(8) to run its course (to work or to fail).

To minimise reliance on the Internet, especially in the early stages of booting my firewalls:
  • I use well known IP addresses in a very limited and strategic fashion (only with the initial ntpdate(8));
  • I use dnsmasq(8) as my primary name server on the firewall, but have it read /etc/hosts so it can resolve local addresses as soon as it starts (regardless of whether the Internet is up or not);
  • On substantial networks, I use three internal NTP time servers on physical Unix hosts (with clock chips) running as peers at strata 10, 12, and 14 -- so I don't have to have the Internet time servers (typically at superior strata 0, 1, 2, ...) to keep time, but will always use them if available. Peers are now deprecated, but still work. There's a newer NTP mechanism that does the same thing (which I have not yet used).
If you follow these guidelines, much of what you do will be done after the Internet link comes up, and will be driven by the asynchronous link-up event.
 
Steinhelten said:
Just for the sake of accuracy, ppp uses tun0 instead of ppp0 for PPPoE
Click to expand...
Yes I forgot ppp0> is the console name. depending on status it could be Ppp0 or pPp0 is something like that. The PPP console name shows some status I remember.

I think we have concluded that netwait on a tunnel is probably not going to work.
But just for clarity netwait is either or.
Wait for specific interface or wait for specific IP. Not both.
Steinhelten said:
netwait_enable="YES"
netwait_if="tun0"
netwait_ip="205.171.3.65"
netwait_if_timeout="120"
Click to expand...
 
You must log in or register to reply here.
Back
Top