James Carlson writes: > lianep at eng.sun.com writes: > > You're talking about actually duplicating an instance, which often > > (but not always) means that both couldn't run at the same time, as they'd > > be competing for the same system resources. Can you help me understand > > how this is useful in testing? Is it just so you can revert back to > > the system's original state/configuration after the test, or for > > something more subtle? > > I've often wanted to do this -- by running the two instances with > different configuration files, and different configured network ports > or lists of interfaces.
You're talking about the scenario you snipped from my mail: > > We'd been considering things from the production/deployment point of > > view more than the testing point of view. If you're deploying > > multiple instances of the same service, you probably want to inherit > > the service's properties and explicitly override a few config variables. You want to override the config file explicitly: > > For example, I sometimes want to run more than one sshd, with > different sets of interfaces and ports bound, and different > configuration files specified for each. (For example, one bound on an > internal RFC 1918 address and another bound on an external Internet- > facing address.) > > There's no "competition," because they're intentionally configured > differently. > > The only way I've found to do it so far is by setting up my own rc*.d > scripts. That seems to be because ssh doesn't offer you a way in the service to specify the config file. If it did, you could do: svccfg -s network/ssh add myinst svccfg -s ssh:myinst setprop ... (new configfile) svcadm enable ssh:myinst I bet if you file a bug, they'd be willing to add that. More instance duplication code which forces you to edit the method (the current thing you need to do) isn't the right answer. Adding a supported config file variable is. liane -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep
