[09:40] <JohnFlux_> Hey all
[09:41] <JohnFlux> I come in here every month to check on the status of upstart and dbus :)
[09:41] <JohnFlux> Is it now possible to communicate via dbus to upstart to start/stop/restart/etc services?
[09:41] <JohnFlux> if not dbus, then some other method
[09:46] <JohnFlux> I know you guys are busy, but if I can communicate to upstart, then I can add this functionality to the kde task manager
[09:46] <JohnFlux> then users can easily start and restart services
[10:12] <atsampson> well, trivially you can communicate with it using initctl stop/start/status/etc...
[10:25] <JohnFlux> atsampson: well, I'll need to know the pid of the process as well
[10:25] <JohnFlux> and just running initctl status   won't be very reliable.  presumably the output could change 
[10:25] <atsampson> initctl'll tell you that; "nmbd (start) running, process 1254"
[10:25] <JohnFlux> between distros, with versions etc
[10:26] <atsampson> it looks from the man page as if the output's designed to be parsed
[10:26] <JohnFlux> also there'd be no notification if the status changes etc
[10:26] <JohnFlux> I think someone was working on dbus interface
[10:27] <JohnFlux> dunno how far along that got
[10:27] <atsampson> you can say "initctl jobs" to get notifications about job state changes
[10:27] <JohnFlux> how does that work?
[10:27] <atsampson> well, you run "initctl jobs", and it prints a parseable line to stdout for each state change
[10:28] <JohnFlux> hmm, it needs to be run as root?
[10:28] <JohnFlux> is that a bug?
[10:28] <atsampson> yes, it does, and no, it would be a bug if you could modify system services as a non-root user, surely?
[10:29] <JohnFlux> why would monitoring them be modifying the system services?
[10:30] <atsampson> why wouldn't monitoring system services be a privileged operation?
[10:30] <atsampson> (disclaimer: I'm just a user of upstart, so please feel free to ignore anything I say...)
[10:31] <JohnFlux> atsampson: hmm
[10:32] <JohnFlux> atsampson: 'ps' doesn't require root, and you could monitor whether services start/stop through that
[10:32] <JohnFlux> although not very efficently
[10:32] <atsampson> if I'm using upstart to manage services on a machine with untrusted users, I probably don't want them seeing the details of all the services I'm running
[10:32] <JohnFlux> I can see that there might be sensitive information
[10:32] <JohnFlux> but for just simple status changes, that should be public knowledge
[10:32] <JohnFlux> a normal user can run 'status apache'  etc
[10:33] <atsampson> ps does require root on some systems, at least to see processes that aren't yours (there's at least one kernel patch for Linux that provides sensible permissions on the files on /proc, for example)
[10:33] <JohnFlux> hmm, wait no they can't
[10:33] <JohnFlux> a normal user can do    /etc/init.d/apache2 status
[10:33] <JohnFlux> but not   status  apache2
[10:33] <JohnFlux> that's very strange
[10:34] <atsampson> start/stop/status are just symlinks to initctl; "start" = "initctl start"
[10:34] <JohnFlux> atsampson: the vast vast majority of users aren't going to be filternig ps
[10:34] <JohnFlux> atsampson: hum
[10:34] <JohnFlux> that's really wrong
[10:34] <atsampson> erm, no, it's not...
[10:34] <JohnFlux> checking if apache is running should not require root
[10:34] <JohnFlux> just check whether the pid is there
[10:35] <JohnFlux> atsampson: why would   /etc/init.d/apache2 status   not require root, but status apache2  does ?
[10:35] <atsampson> if you want that behaviour, I think it'd be better to put it somewhere other than upstart
[10:36] <JohnFlux> s/would/should/
[10:36] <atsampson> it seems a bit silly to put lots of complicated access control stuff into init, rather than having some other daemon/service that can make requests to upstart on your behalf and do access control
[10:36] <JohnFlux> atsampson: well, I want to be able to show the list of running services to the user in the kde task manager
[10:37] <atsampson> so perhaps the solution'd be to have a daemon that spoke the upstart protocol to init on one side, and dbus to other processes, and then you could configure that to do access control?
[10:37] <JohnFlux> `hmm
[10:37] <JohnFlux> how does initctl work?
[10:38] <atsampson> init's got to be as simple, reliable and secure as possible, really
[10:38] <JohnFlux> how does it check the status of a process?
[10:38]  * atsampson straces
[10:38] <atsampson> it talks over a Unix socket to init, it appears
[10:38] <JohnFlux> ah hmm
[10:39] <atsampson> there's a library in the upstart package that wraps up the protocol, so it could presumably be used in something else without too much trouble...
[10:40] <JohnFlux> presumably that requires root privillages as well?
[10:40] <atsampson> yes
[10:40] <JohnFlux> hum
[10:42]  * atsampson decides it's a good time for tea
[10:42] <JohnFlux> it's always a good time for tea :)
[10:44] <atsampson> :)
[10:46] <JohnFlux> I suspect I'm going to have to make a small setuid root program that just calls initctl statu
[10:46] <JohnFlux> s
[10:47] <JohnFlux> :-/
[10:47] <atsampson> or provide a bit of sudo config...
[10:47] <JohnFlux> well, users aren't going to want to type in a root password just to see what is running
[10:47] <JohnFlux> i don't think any other OS does that
[17:47] <Keybuk> JohnFlux: sorry, wasn't around to answer your questions earlier
[17:47] <Keybuk> is it possible to communicate via dbus?  no, not today
[17:47] <Keybuk> will it be?  yes, in trunk - there's only one thing higher on the todo list now
[17:47] <Keybuk> is it possible by any other method today?  yes, released versions use a custom IPC protocol
[17:48] <Keybuk> you can use that through initctl
[17:48] <Keybuk> or use libupstart (which initctl is a CLI wrapper for)
[17:48] <Keybuk> obviously the library is deprecated, and doesn't even exist in trunk
[17:48] <Keybuk> the initctl output is intended to be parsed by humans and machines
[17:48] <Keybuk> but obviously may change with the DBus change
[17:48] <Keybuk> why root only?
[17:49] <Keybuk> simple: avoids local-root security exploits due to bugs in the initctl protocol
[17:49] <Keybuk> dbus would solve that since non-root requests can be made through the dbus daemon
[18:27] <JohnFlux> Keybuk: hey
[18:28] <JohnFlux> Keybuk: thanks for the reply
[18:28] <JohnFlux> Keybuk: It would be awesome to get this information via dbus, as a non-root user
[18:28] <JohnFlux> Keybuk: I'll wait for that :-)
[19:22] <kwrobel2008> Hi everybody
[19:24] <kwrobel2008> I'd like to post a question here regarding switching of runlevels:
[19:24] <kwrobel2008> I'm running Ubuntu Gutsy (Server Edition), and would like to run a script I wrote
[19:25] <kwrobel2008> that backs up an entire HD to external media
[19:25] <kwrobel2008> However, I'd like to first switch to a "runlevel" that's similar to single-user mode
[19:25] <kwrobel2008> Basically, I don't want any crucial background process running while the script executes
[19:26] <kwrobel2008> And afterwards, I'd like to go back to the "runlevel" I came from (probably 2?)
[19:26] <kwrobel2008> Does anyone here know how I might accomplish that?
[19:32] <Keybuk> telinit 1
[19:32] <Keybuk> that switches you to single-user mode
[19:33] <kwrobel2008> HI
[19:33] <kwrobel2008> Right. No I got the general idea
[19:34] <kwrobel2008> But how do I control the flow of things?
[19:34] <kwrobel2008> can I run telinit 1, and the next call my script, and then telinit 2?
[19:37] <Keybuk> I'm not sure I follow, sorry
[19:38] <kwrobel2008> Right. And I know that upstart is really an event-driven model.
[19:38] <kwrobel2008> But since it's being used as a so-called SysV Init replacement...
[19:39] <kwrobel2008> Anyway, let me try to be more specific:
[19:39] <kwrobel2008> I wrote a script, called bootbak,
[19:39] <kwrobel2008> That script reformats an external hard USB drive (250GB Maxtor)
[19:40] <kwrobel2008> and then copies the entire filesystem to that drive, modifies /etc/fstab and grub/menu.lst,
[19:40] <kwrobel2008> and writes an appropriate MBR to it so I can boot of the USB HD in case of total system failure
[19:41] <kwrobel2008> Now, the server to be backed up is an email server which receives tons of emails, especially during the night (SPAM, sigh)
[19:42] <ion_> Why not install multiple HDDs and use redundancy?
[19:42] <kwrobel2008> That aside, what I was thinking is to bring down all services, like postfix, dovecot, apache a.s.f.
[19:43] <kwrobel2008> ion_: eventually, we will install multiple USB HD on a hub and run that script each day against a different drive
[19:43] <kwrobel2008> for rotation
[19:43] <kwrobel2008> Point is, to make it short: I'd like to do this:
[19:44] <kwrobel2008> init 1
[19:44] <ion_> I mean, multiple internal HDDs and RAID-1 or higher.
[19:44] <kwrobel2008> /usr/local/bin/bootbak
[19:44] <kwrobel2008> init 2
[19:44] <Keybuk> does that work in SysVinit?
[19:44] <kwrobel2008> ion_: Well, we want to have backups in case we mess up our configurations so bad that we can't get the server up and running again
[19:45] <kwrobel2008> Keybuk: That's exactly it. It doesn't...
[19:45] <kwrobel2008> init 1, at the end of it, kills ALL processes, including the script itselve
[19:46] <Keybuk> pretty much, yes
[19:46] <ion_> I don’t really see why you’d need to kill the services to do backups.
[19:46] <kwrobel2008> First off, inconsistencies. The backup runs for >5minutes
[19:47] <kwrobel2008> during which time many emails could have come in, etc
[19:47] <kwrobel2008> MySQL is also running on that server
[19:47] <kwrobel2008> Anyway, I know I can run the script in runlevel 2 while everything is up and running.
[19:48] <ion_> The new emails would go to the next backup.
[19:48] <kwrobel2008> Right now however, I'm the only user on that  server (it's a new box)
[19:48] <ion_> You probably should take plaintext dumps of the database.
[19:49] <kwrobel2008> ion_: I understand.
[19:51] <kwrobel2008> ion_: Let's pretend for a moment
[19:51] <kwrobel2008> Is it possible to control the system in such a way that you could switch it into a different runlevel temporarily
[19:52] <kwrobel2008> in order to do whatever maintenance tasks
[19:52] <kwrobel2008> and then bring it back up?
[19:52] <kwrobel2008> (All automated of course)
[19:55] <kwrobel2008> Maybe upstart is just not the right tool for that?
[19:55] <kwrobel2008> Here's what I had in mind: create a job in /etc/event.d that listens to trigger run-bootbak,
[19:56] <kwrobel2008> then add a crontab entry for, say, 10pm that runs initctl emit run-bootbak
[22:54] <atsampson> presumably you could have another runlevel that's like 1, but rather than sulogin runs the backup script then switches back to runlevel 2 when it's finished...