Zack Newman writes:
> On 2021-11-01, Kapetanakis Giannis <bilias@edu.physics.uoc.gr> wrote:
> > Hi,
> >
> > Just a notice for this.
> > I have a system which is a DNS server it self and runs isc-bind, so the daemon is \
> > started from $pkg_scripts.
> > rc.firsttime is run before pkg daemons are started so the system cannot (yet) \
> > resolve since it lists itself in /etc/resolv.conf
> > If there is no other reason, maybe rc.firsttime could be moved after package \
> > daemons are started.
> Unless you're married to isc-bind, you can run unbound(8) as a recursive, validating, and caching recursive DNS server instead or nsd(8) as an authoritative DNS server. Both of those are part of the base insta
> ll and are started early in rc(8). That's what I do, and I have no issues.
>
> If you insist on using something not part of base, then you can always edit rc(8) or rc.firsttime(8) such that the daemon runs sooner. While that is not recommended and requires you to accept responsibility of
> your "custom" system, I have not had any trouble getting dhcpcd running when dhcpleased runs allowing me to set up both IPv6 (which I prefer) and IPv4 early on in the boot process. I avoid enabling it in rc.c
> onf.local(8) though.
Alternatively the only time rc.firsttime is used is every six months
after an upgrade, in which case boot manually into single-user mode
and edit rc.firsttime to start bind early (or do it before the
installer exits).
Calling rc.firsttime could not be moved to after package daemons
have started without introducing unreliablility into the auto-upgrade
process (until they are started the machine is in a state understood
by the installer, afterwards all bets are off).
On the gripping hand, all it does is run fw_update and syspatch.
Matthew
No comments:
Post a Comment