> One concern I had while working on this was that changing the point at which > YP is enabled might affect the boot process. ypbind is started right after > ypldap, and ypldap becomes discoverable to ypbind before it daemonises, > so this doesn't change the ordering.
Yes, it is a bit weird. There is still a way to make this more autoatic. ypldap could continue to create the ypbind RPC contact point, but if traffic happens it means "oh shit, I must abandon managing the binding file myself, ypbind will be doing it". But maybe it is better if ypldap has a special mode, which means it has no ypbind connection point which can act as a potential weakness. You don't want to delete the binding file upon exit? pledge/unveil reasons? Losing the lock is enough for libc to give up. If you run in this mode, how does ypbind react? It spins searching for a ypserv/ypldap which does not respond? Also we need this in /etc/rc. The domainname must be set for libc to talk to ypldap, so we should only start it in that circumstance. I'd rather fail to start it here, to make people think. Index: rc =================================================================== RCS file: /cvs/src/etc/rc,v retrieving revision 1.561 diff -u -p -u -r1.561 rc --- rc 17 Jul 2022 03:17:37 -0000 1.561 +++ rc 22 Jul 2022 14:12:51 -0000 @@ -498,9 +498,9 @@ if [[ $ipsec != NO && -f /etc/ipsec.conf fi echo -n 'starting RPC daemons:' -start_daemon portmap ypldap +start_daemon portmap if [[ -n $(domainname) ]]; then - start_daemon ypserv ypbind + start_daemon ypldap ypserv ypbind fi start_daemon mountd nfsd lockd statd amd echo '.'
