Answers embedded. >>> SYNOPSIS >>> /usr/lib/smbsrv/nbtd >> >> >> Are users or scripts supposed to interact directly with the binary? >> If not, then why document it? >> > I'll let Keyur confirm, but I don't believe so. It was included for > completeness more than anything.
That is correct. The nbtd(1M) and the nbt(4) man pages were included for completeness purposes. >> I suspect that this should actually be a Project Private detail, and >> that the SMF FMRI is the documented administrative interface. >> >>> EXIT STATUS >>> >>> The following exit values are returned: >> >> >> Similarly, I don't think these should be public interfaces, unless >> there's some clear need for some other part of the system to invoke >> the daemon directly. If there is such a need, then that's an >> important bit of architecture to discuss. (And, if so, this might not >> be a fast-track anymore.) >> > Again, I'll ask Keyur to respond on details here. Same answers as above. These are not public interfaces. The nbtd(1M) and the nbt(4) man pages were included for completeness purposes. >>> Use the svcadm command to perform administrative actions on >>> the nbtd service, such as enabling, disabling, or restarting >>> the service. Use the svcs command to query the service >>> status. >> >> >> Who enables this? Is the administrator expected to know when to do >> this, or does it get enabled automatically when needed (when sharectl >> demands it)? >> nbtd daemon is disabled by default. Most administrators know if they need to enable/disable NetBIOS protocol in their network. Some scenarios to enable NetBIOS include, having a system in a network, which has NT 4.0 (and/or previous) OS installed, or systems not upgraded to ADS. Some administrators choose to disable NetBIOS from their network, in order to reduce network traffic caused by periodic host announcements. Enabling/disabling of this daemon is at the discretion of the administrator.
