lianep at eng.sun.com wrote: >Darren Reed writes: > >... > >>To go another step, if I wanted to run an extra inetd, >>and created a new instance for it using the same mechanism: >> >>svccfg -s network/inetd add myinst >> >>Would I then get a new instance of rlogin, telnet, etc, to go >>with inet:myinst and if so, how would these interact with the >>other :myinst's that I've created? >> > >$ svcprop -p general/single_instance inetd >true > >inetd is defined as a single_instance service right now... that >property (currently unenforced, but we'll enforce it someday) means >that there should never be multiple instances of inetd running. >
Ok, that makes sense. This is the 2nd "magic" general property that I'd consider interesting to look at. What man pages should I be looking at to find out about things like this? Or should I just be reading the DTD ? /usr/share/lib/xml/dtd/service_bundle.dtd.1 >As to what will happen if you do launch multiple inetds? You'd have to >try (or look at the code), but I strongly suspect it'll end in tears. >Ah heck... > When I first started using Unix, I tried running every command I could, just to see what happened...including inetd - as non-root. Several days later the sysadmin sent me an email with the many pages of syslogd output - it had kept trying to start all of the services and failing and retrying every x minutes until killed... Anyway, that's getting away from what I wanted to discuss...and while I mention inetd here, the questions driving the discussion are more generic than just this particular case. 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.) Now if inetd weren't confined to a single instance, and given that it has a .conf file, it's reasonable to expect this, should the service naming be different? For example, if I have inetd as svc:/network/inetd:default Could I name a service like this: svc:/network/inetd-default/telnet:default or something else that makes the "inetd:default" part of the FMRI. The important part would be for this segment in the name to carry forward, automatically, to the slave service. Could SMF be extended to do that? The idea being that if I had: svc:/network/inetd:default and added this one: svc:/network/inetd:myinst I would automatically end up with two telnet services: svc:/network/inetd-default/telnet:default svc:/network/inetd-myinst/telnet:default This would also allow me to still create a new telnet service that lived on a different port for ":myinst" of either. Can SMF be told that if it creates a new copy of one particular service to also create another copy of a different one, if two services are joined together? Or would that always be a manual task? >... >Per-user inetds were requested during the S10 beta process, but code >will need to be written to support it. > That's a strange request...is there an RFE number for this? btw, should "bind_addr" be mentioned in inetd(1m) ? Also would having "bind_addr" present as a configuration option for inetd itself be considered for use as the default to apply to its services where this field isn't set? What about adding "bind_interface" (at both the global inetd level and on a per service basis) ? Darren
