Darren Reed wrote: > What prompted me to ask about this was the design choice to > have each inetd service be its own service in the same name > space as inetd's service - it suggests one particular model of > defining services within SMF where there is a master/slave > relationship. (It feels a bit quirky to be managing or observing > inetd services with SMF when, from a distance, they don't > immediately look like they're under inetd.)
That is actually very useful. There are some services which can be started "under" inetd but also started standalone. I feel very strongly that inetd should NOT be exposed to the end admin, it is really an implementation artifact. This was a major bug in the old UNIX model that SMF fixes. inetd is a delegated restarter and could thus be considered part of the SMF framework if you like. Not exposing inetd into the FMRI means you can change the implementation detail that a service is started under inetd. We have already exploited this fact with the Kerberos kprop service, it used to run under inetd and now runs standalone, nothing changed as far as the interfaces that admin uses, they still just use svcadm enable krb5_prop. If you look at svc:/network/login you will see that we already use multiple instances of this for rlogin in the clear, with krb5 auth and krb5 auth+encryption. The telnet service on the other hand doesn't work that way because it does the krb5 negotiation as part of the core protocol (cf STARTTLS vs https on port 443). What is the REAL problem you are trying to solve here ? -- Darren J Moffat
