Andre Molyneux wrote:
> The behavior we see of the SMF tftp service on a system acting as an
> AI server is:
>
> - Prior to the first 'installadm create-service' for an x86
> service, 'svcs -a | grep tftp' shows nothing.
>
> - Once an x86 service has been configured, 'svcs -a | grep tftp`
> shows that tftp is online.
>
> The installadm test suite has been disabling tftp as part of its
> cleanup. I'm guessing this was done on the assumption that, since
> tftp didn't show up at all prior to a service being configured,
> that it should be disabled after services are torn down. This
> seems to be a bad assumption as the observed behavior is that,
> once the test suite disables tftp, subsequent creation of x86
> install services do *not* enable the tftp service. As a result,
> the x86 install service can't really be used as tftp is disabled
> and the client can't get the files it needs.
>
> I'm assuming at this point that the suites should *not* disable tftp.
> Is that a correct assumption?
>
> Regards,
>
> Andre
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
Andre,
Installadm activates the TFTP service by adding the tftp in the
inetd.conf file and running inetconv. Once the TFTP service is added to
inetd, installadm doesn't actively manage the service. So if the TFTP
service is disabled, installadm will not enable it. Your test suite also
should not manage tftp service (do not disable/enable the TFTP service).
Thanks,
Sundar
