Alan Maguire writes: > just a note to say i've been taking a look to see what would be > required to provide an SMF serivce conversion for dhcpagent. as far as i > can see it's pretty straightforward - just a case of providing > manifest/method, > changing fork/exec of dhcpagent in libdhcpagent to a call to > smf_enable_instance() (temporary enable), and updating the service method > for network/physical to use "svcadm enable -t dhcp-agent" as opposed > to running /sbin/dhcpagent directly.
There's more to it than that. The /sbin/dhcpagent interface itself is documented and the "-a" command line flag (used for the, in my opinion, highly questionable) "adopt" functionality needs to be reimplemented in these terms. In other words, "adopt" needs to become a new libdhcpagent IPC mechanism, and /sbin/dhcpagent itself needs to enable the service and call the IPC to deliver the command line flags. Or, better still, the "adopt" functionality needs to be burned to the ground. That's probably a bigger task than just dragging the functionality around with us. I agree that it's all doable, but it's fairly far afield of what I'm trying to accomplish here, and I feel like I've already done quite enough. :-/ > as well as taking care of the privilege issue mentioned above, this would > also > solve the issue with the stop method of the "ndp" service - > the :kill run there will also take out the dhcpagent process and any eventhook > scripts launched by it, since these are in the same contract as in.ndpd. Sigh; indeed. The "and the horse you rode in on" feature is a problem. That nasty side-effect somehow missed my attention. I think that the system is still quite usable without fixing that -- the cases where in.ndpd actually does have to start up dhcpagent are few and where ndpd is restarted are fewer still -- but I agree that it's not at all right. > anyway i'll file an RFE on this soon, just wanted to give a head's up. thanks! OK. Many thanks for taking this on! -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
