Brock Pytlik wrote: > General questions:
> Can any package affect any smf service in a permanent way? For example, > if I get package foo, can it permanently disable my firewall/ip filter > (for example), or enable telnet which wasn't previously enabled? Is it > possible to deliver a new service which is started on installation? > It depends on our level of checking, and which packages you're talking about... Clearly, installing a version of ipf that won't modload will place ipfilter in maintenance, but I don't think that's your concern. As long as packages don't interfere w/ each other (eg attempt to deliver the same file), it's an unlikely problem. To deliver a new service that's automatically enabled merely requires delivering a manifest that's so configured. This is against policy... > It seems like an action can specify more than one actuator. What happens > if it specifies several actuators for the same service? For example, it > states it wants the same service refreshed, suspended, tmp suspended, > and restarted? I think the test in t_actuators.py is getting at this, > but I don't really understand why it produces the output it does. > refresh_fmri says refresh this serice after changes to this file restart_fmri says restart this service after changes to this file suspend_fmri says suspend this service during the packaging op that modifies this file all are possible, but it's prob. not useful to set more than one. Whether or not a service gets temp. enabled or not depends on its state... suspend just does a disable -t; the enable is either enable -t or enable, whichever returns the service to it's previous state. > actuators.py: > 39-70: Maybe brief comments explaining the purpose of overriding each > method? subclassing hints, in other words... ok. > 134: I'd probably prefer using a set here, rather than integer ordering, > it might make the code easier to read and follow, but it's not a big deal I'll pass on this, if that's ok. My brain deals w/ this more easily :-). > Nit: 259-262: indentation looks wrong to me yup.... fixed. > > Roughly what would change if this was moved to another OS? Would the > major/only change be changing /usr/sbin/svcadm and > /usr/bin/svcprop to point somewhere else? If so, it seems like those > might be candidates to live in a member variable so that sub-classes > could easily override those commands, but take advantage of the rest of > the structure. __call would likely need to be overridden as well, but > the other methods seem generic (but then I don't know much about how SMF > has been ported to other OS's). It would change completely. Class Actuator would need to be re-implemented. > > image.py: > 184-185: I can't figure out why this is needed here a leftover from previous impl. broken by api wad... removed. > > imageplan.py > 700: I believe we want to do this even on keyboard interrupt, but would > you confirm that. Yes, that's right; since the packaging operation didn't complete we want to place the affected (suspended) services in maintenance state. > > run.py: > can't figure why this is in the change set for ease of testing; the mode changed to +x. > > t_actuators: > 233-234: commented lines Fixed. Thanks for looking at this. I'll retest, resync and retest and respin the webrev. I'll likely push tomorrow ... - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
