Nicolas Williams wrote: > On Tue, May 27, 2008 at 12:48:22PM -0700, Jordan Brown wrote: >> Nicolas Williams wrote: >>> It's probably not that hard to add such a thing. I can see cron having >>> its own svc.configd repository (with mods for doing authorization >>> somewhat differently than SMF), for example, and a simplified API >>> layered atop libscf; plus svcs/svccfg/svcprop-like UIs, plus Visual >>> Panels support. >> That sounds like a whole Goodyear store worth of reinvented wheels... > > How so when you'd be re-using large chunks of the existing SMF > framework?
It looks like you're reinventing all of the SMF UIs, to begin with. >> I don't deny some desire for specialist UIs, just as you presumably want >> [...] > > ^desire^need^ OK, but the same applies to inetd. >> Here's a thought experiment that might help: how would one extend SMF >> to support per-user services? Suppose I want to run my "foo" program > > Start with a new restarter, and new property group type so as to provide > different authorization semantics than SMF provides today. It doesn't seem like you should need any new properties, at least not ones that users should have to look at. If I (a random user) say to create a new service, it needs to be tied to me through mechanisms that I cannot affect. > The FMRI type issue is somewhat orthogonal, but I agree that cron jobs > and user services shouldn't be listed by svcs(1). Yet I don't think > svcs should have to be modified to filter certain FMRI prefixes by > default -- filtering by FMRI type seems much more appropriate, plus it > seems more natural/less confusing as a UI. I think user is orthogonal to FMRI type, that a per-user inetd service FMRI should have the same form as a system-wide one. It *does* seem like maybe the FMRI type should be tied to the restarter, but that boat has sailed: inetd based services are "svc:". Syntactically, perhaps you just add a "user@" somewhere in the FMRI, just as you can in http: and ftp: URLs. Internal-representation-wise, it seems like another field, perhaps but not necessarily represented as a special property. >> Once we've got the per-user-service extension, cron jobs start to fit in >> even better. > > But I'd argue that user services too need their own FMRI type, and > certainly their own repository (stored in your home directory by > default), since you'd probably want them to follow you, rather than your > choice of system to login to. No, it's pretty clear to me that per-user services must be tied to a particular machine. I want them to run all the time - that is, after all, why I'm running them as a service instead of as part of my desktop session - and if I'm not logged in, which of the tens of thousands of machines that I could log in on should they run on? Stuff tied to my desktop session, yes, but see the other fork of this thread.
