Thanks Stuart.
I did some more digging and found that salt itself was the culprit.
In my formula, I had a state to write out /etc/rc.conf.local followed
by a state to start the ospf2d service.
I created the state for /etc/rc.conf.local, as a file.managed state,
not understanding that the service.running state was responsible for
the modification of /etc/rc.conf.local in the first place.
The state that starts the ospf2d service uses the results of
'/usr/sbin/rcctl getdef ospf2d flags' in order to set the flags,
unless additional arguments are fed via **kwargs.
Here is my resultant working state:
enable_ospf2_service:
service.running:
- name: ospf2d
- enable: True
- kwarg:
flags: '-f /etc/ospf2d.conf'
This should be helpful for anyone else running Saltstack in an OpenBSD
environment and needing to feed custom flags to a process in the
future.
On Wed, Feb 20, 2019 at 5:07 AM Stuart Henderson <s...@spacehopper.org> wrote:
>
> On 2019-02-19, Henry Bonath <he...@thebonaths.com> wrote:
> > --- /var/backups/etc_rc.conf.local.current Wed Jan 16 01:30:06 2019
> > +++ /etc/rc.conf.local Fri Feb 15 13:05:17 2019
> > @@ -1,9 +1,7 @@
> > bgpd_flags=
> > ldpd_flags=
> > -ospf2d_flags=-f /etc/ospf2d.conf
> > ospf2d_rtable=2
> > ospfd_flags=
> > pf=NO
> > pkg_scripts=salt_minion ospf2d
> > salt_minion_rtable=3
> >
> > Is my syntax incorrect? Would /etc/daily be doing something here to my
> > configuration?
> >
> > Why would this line keep being automatically removed?
>
> It's unlikely to be /etc/daily at 13:05:17. Check system logs for around
> that time, consider turning on process accounting to see if it gives any
> clues?
>
>
