[16:59] <stgraber> jodh: hmm, one point I just noticed in the spec that I'm not too sure about is the D-Bus section on having the user upstart listen on /com/ubuntu/upstart-session/$user
[16:59] <stgraber> jodh: I see why we need that so initctl can work until we get a working dbus session
[17:00] <stgraber> jodh: but the fact that it's not unique per session is a bit problematic
[17:02] <stgraber> jodh: would it work if we use /com/ubuntu/upstart-session/$PID (where $PID is the pid of the user upstart) and export a UPSTART_SESSION environment variable to all children containing the path?
[17:04] <stgraber> jodh: it's really only going to be useful for the dbus job as it's likely going to be the only one that'll need to talk directly to upstart as any job after that will be able to use the session bus
[17:33] <stgraber> jodh, xnox: alright, I think I'm done with https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions
[17:34] <stgraber> feel free to do any additional edits. I'm out to get some food, I'm starving ;)
[17:37] <xnox> stgraber: thanks. I will look through your edits =)
[19:55] <LeoSh> is there a special way to do a sudo entry to allow a normal user to restart a service?
[19:57] <LeoSh> when I do something like: "/usr/sbin/service uwsgi *" that doesn't work... I get: /usr/sbin/service: 123: exec: status: not found
[19:58] <LeoSh> for the command "sudo service uwsgi status"
[20:16] <JanC> LeoSh: what do you mean by "normal user"?
[20:16] <JanC> (also, this sounds like a sudo question, not an upstart question?)
[20:17] <JanC> http://manpages.ubuntu.com/sudoers explains sudo configuration
[20:29] <LeoSh> @JanC: not root
[20:29] <LeoSh> I suspect it's more of an upstart question, or at least one upstart users have run into
[20:30] <LeoSh> the other strange detail is when I do 'service uwsgi' I get 'uwsgi: unrecognized service'
[20:30] <LeoSh> even though there's a uwsgi.conf in /etc/init/ and it looks like it's all properly formatted (and 'service uwsgi restart' works without any problems)
[20:30] <JanC> not every non-root user has the same rights when using sudo
[20:31] <JanC> LeoSh: what if you use initctl ?
[20:32] <LeoSh> 'initctl status uwsgi' works fine
[20:34] <LeoSh> I'm not sure how to do an equivalent of 'service uwsgi' with initctl since it takes the command first
[20:35] <JanC> from the manpage of 'service', that is not a legal use of the service command?
[20:36] <JanC> it mentions "service SCRIPT COMMAND [OPTIONS]"
[20:37] <JanC> which means the command is mandatory?
[20:37] <JanC> unless you are using a different "service" command than I do
[20:38] <LeoSh> hmm
[20:38] <LeoSh> that's a good point
[20:38] <LeoSh> I'm on Ubuntu 12.04
[20:38] <JanC> I'm on Ubuntu 12.10 right now, but I'm pretty sure 'service' worked the same there
[20:39] <LeoSh> ok, so 'unrecognized service' is probabl unrelated to my actual issue
[20:39] <JanC> http://manpages.ubuntu.com/manpages/precise/en/man8/service.8.html
[20:40] <LeoSh> is there a way to control who is allowed to restart a service through upstart?
[20:40] <JanC> http://manpages.ubuntu.com/manpages/precise/en/man5/sudoers.5.html   ☺
[20:40] <LeoSh> yeah, that leads me to the original question :-/
[20:41] <LeoSh> the sudoers config I used works for an init.d script
[20:41] <LeoSh> but doesn't seem to work for my upstart .conf
[20:41] <JanC> (there are examples at the end of the manpage)
[20:43] <JanC> the sudoers file only cares about users, groups & command lines AFAIK
[20:44] <LeoSh> hmm
[20:44] <LeoSh> do I need to open up the other commands in sudoers? (ie. /sbin/start, /sbin/stop, etc.?)
[20:45] <JanC> only if you want to use them like that?
[20:45] <LeoSh> I don't, but looking at the error
[20:45] <LeoSh> it refers to /usr/sbin/service:123
[20:45] <JanC> hm, maybe think about how you define it and how you use it?
[20:46] <LeoSh> which attempts to exec the action: exec ${ACTION} ${SERVICE} ${OPTIONS}
[20:46] <LeoSh> and that's what fails
[20:46] <JanC> well, you run service with sudo, right?
[20:47] <LeoSh> yes
[20:48] <LeoSh> I get the following if I just try to do "status" as my non-priv user: Command 'status' is available in '/sbin/status'
[20:48] <JanC> if you execute it without an "action", that would probably fail
[20:48] <LeoSh> and that it can't be located
[20:48] <LeoSh> which is strange, since it should be running as root rather than the nonpriv user
[20:48] <LeoSh> but it explains why the init.d version works fine
[20:49] <LeoSh> it doesn't try to invoke another binary that the nonpriv user doesn't have access to
[20:50] <LeoSh> is there some really good reason to not add sbin to your path?
[20:50] <LeoSh> as a nonpriveleged user?
[20:50] <JanC> well, if $ACTION is empty, that would certainly confuse $SERVICE being called as the main application?
[20:51] <JanC> if hey have no proper checking in place  :p
[20:51] <JanC> if they*
[20:52] <LeoSh> here's the core problem
[20:52] <LeoSh> 'service' is in/usr/bin and 'start' and it's kin are over in /sbin
[20:57] <JanC> if you run 'service' as root (using sudo or otherwise) that shouldn't be a problem
[21:00] <LeoSh> I do, but it still is
[21:01] <LeoSh> I think the PATH of the user remains even when you sudo
[21:01] <JanC> that depends on sudo options, but possibly, yes
[21:20] <LeoSh> ok, yeah, the sudoers file has 'Defaults env_reset' which is recommended...
[21:33] <JanC> LeoSh: I don't have the time to investigate right now, but AFAIK sudo allows you to override that
[21:33] <LeoSh> JanC: yeah, I appreciate the help, I'm digging into it
[21:33] <LeoSh> apparently the setting comes from some unholy mix of login.defs and pam config