JohnFlux_Hey all09:40
=== JohnFlux_ is now known as JohnFlux
JohnFluxI come in here every month to check on the status of upstart and dbus :)09:41
JohnFluxIs it now possible to communicate via dbus to upstart to start/stop/restart/etc services?09:41
JohnFluxif not dbus, then some other method09:41
JohnFluxI know you guys are busy, but if I can communicate to upstart, then I can add this functionality to the kde task manager09:46
JohnFluxthen users can easily start and restart services09:46
atsampsonwell, trivially you can communicate with it using initctl stop/start/status/etc...10:12
JohnFluxatsampson: well, I'll need to know the pid of the process as well10:25
JohnFluxand just running initctl status   won't be very reliable.  presumably the output could change 10:25
atsampsoninitctl'll tell you that; "nmbd (start) running, process 1254"10:25
JohnFluxbetween distros, with versions etc10:25
atsampsonit looks from the man page as if the output's designed to be parsed10:26
JohnFluxalso there'd be no notification if the status changes etc10:26
JohnFluxI think someone was working on dbus interface10:26
JohnFluxdunno how far along that got10:27
atsampsonyou can say "initctl jobs" to get notifications about job state changes10:27
JohnFluxhow does that work?10:27
atsampsonwell, you run "initctl jobs", and it prints a parseable line to stdout for each state change10:27
JohnFluxhmm, it needs to be run as root?10:28
JohnFluxis that a bug?10:28
atsampsonyes, it does, and no, it would be a bug if you could modify system services as a non-root user, surely?10:28
JohnFluxwhy would monitoring them be modifying the system services?10:29
atsampsonwhy 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:30
JohnFluxatsampson: hmm10:31
JohnFluxatsampson: 'ps' doesn't require root, and you could monitor whether services start/stop through that10:32
JohnFluxalthough not very efficently10:32
atsampsonif 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 running10:32
JohnFluxI can see that there might be sensitive information10:32
JohnFluxbut for just simple status changes, that should be public knowledge10:32
JohnFluxa normal user can run 'status apache'  etc10:32
atsampsonps 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
JohnFluxhmm, wait no they can't10:33
JohnFluxa normal user can do    /etc/init.d/apache2 status10:33
JohnFluxbut not   status  apache210:33
JohnFluxthat's very strange10:33
atsampsonstart/stop/status are just symlinks to initctl; "start" = "initctl start"10:34
JohnFluxatsampson: the vast vast majority of users aren't going to be filternig ps10:34
JohnFluxatsampson: hum10:34
JohnFluxthat's really wrong10:34
atsampsonerm, no, it's not...10:34
JohnFluxchecking if apache is running should not require root10:34
JohnFluxjust check whether the pid is there10:34
JohnFluxatsampson: why would   /etc/init.d/apache2 status   not require root, but status apache2  does ?10:35
atsampsonif you want that behaviour, I think it'd be better to put it somewhere other than upstart10:35
atsampsonit 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 control10:36
JohnFluxatsampson: well, I want to be able to show the list of running services to the user in the kde task manager10:36
atsampsonso 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
JohnFluxhow does initctl work?10:37
atsampsoninit's got to be as simple, reliable and secure as possible, really10:38
JohnFluxhow does it check the status of a process?10:38
* atsampson straces10:38
atsampsonit talks over a Unix socket to init, it appears10:38
JohnFluxah hmm10:38
atsampsonthere'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:39
JohnFluxpresumably that requires root privillages as well?10:40
* atsampson decides it's a good time for tea10:42
JohnFluxit's always a good time for tea :)10:42
JohnFluxI suspect I'm going to have to make a small setuid root program that just calls initctl statu10:46
atsampsonor provide a bit of sudo config...10:47
JohnFluxwell, users aren't going to want to type in a root password just to see what is running10:47
JohnFluxi don't think any other OS does that10:47
KeybukJohnFlux: sorry, wasn't around to answer your questions earlier17:47
Keybukis it possible to communicate via dbus?  no, not today17:47
Keybukwill it be?  yes, in trunk - there's only one thing higher on the todo list now17:47
Keybukis it possible by any other method today?  yes, released versions use a custom IPC protocol17:47
Keybukyou can use that through initctl17:48
Keybukor use libupstart (which initctl is a CLI wrapper for)17:48
Keybukobviously the library is deprecated, and doesn't even exist in trunk17:48
Keybukthe initctl output is intended to be parsed by humans and machines17:48
Keybukbut obviously may change with the DBus change17:48
Keybukwhy root only?17:48
Keybuksimple: avoids local-root security exploits due to bugs in the initctl protocol17:49
Keybukdbus would solve that since non-root requests can be made through the dbus daemon17:49
JohnFluxKeybuk: hey18:27
JohnFluxKeybuk: thanks for the reply18:28
JohnFluxKeybuk: It would be awesome to get this information via dbus, as a non-root user18:28
JohnFluxKeybuk: I'll wait for that :-)18:28
kwrobel2008Hi everybody19:22
kwrobel2008I'd like to post a question here regarding switching of runlevels:19:24
kwrobel2008I'm running Ubuntu Gutsy (Server Edition), and would like to run a script I wrote19:24
kwrobel2008that backs up an entire HD to external media19:25
kwrobel2008However, I'd like to first switch to a "runlevel" that's similar to single-user mode19:25
kwrobel2008Basically, I don't want any crucial background process running while the script executes19:25
kwrobel2008And afterwards, I'd like to go back to the "runlevel" I came from (probably 2?)19:26
kwrobel2008Does anyone here know how I might accomplish that?19:26
Keybuktelinit 119:32
Keybukthat switches you to single-user mode19:32
kwrobel2008Right. No I got the general idea19:33
kwrobel2008But how do I control the flow of things?19:34
kwrobel2008can I run telinit 1, and the next call my script, and then telinit 2?19:34
KeybukI'm not sure I follow, sorry19:37
kwrobel2008Right. And I know that upstart is really an event-driven model.19:38
kwrobel2008But since it's being used as a so-called SysV Init replacement...19:38
kwrobel2008Anyway, let me try to be more specific:19:39
kwrobel2008I wrote a script, called bootbak,19:39
kwrobel2008That script reformats an external hard USB drive (250GB Maxtor)19:39
kwrobel2008and then copies the entire filesystem to that drive, modifies /etc/fstab and grub/menu.lst,19:40
kwrobel2008and writes an appropriate MBR to it so I can boot of the USB HD in case of total system failure19:40
kwrobel2008Now, the server to be backed up is an email server which receives tons of emails, especially during the night (SPAM, sigh)19:41
ion_Why not install multiple HDDs and use redundancy?19:42
kwrobel2008That aside, what I was thinking is to bring down all services, like postfix, dovecot, apache a.s.f.19:42
kwrobel2008ion_: eventually, we will install multiple USB HD on a hub and run that script each day against a different drive19:43
kwrobel2008for rotation19:43
kwrobel2008Point is, to make it short: I'd like to do this:19:43
kwrobel2008init 119:44
ion_I mean, multiple internal HDDs and RAID-1 or higher.19:44
kwrobel2008init 219:44
Keybukdoes that work in SysVinit?19:44
kwrobel2008ion_: 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 again19:44
kwrobel2008Keybuk: That's exactly it. It doesn't...19:45
kwrobel2008init 1, at the end of it, kills ALL processes, including the script itselve19:45
Keybukpretty much, yes19:46
ion_I don’t really see why you’d need to kill the services to do backups.19:46
kwrobel2008First off, inconsistencies. The backup runs for >5minutes19:46
kwrobel2008during which time many emails could have come in, etc19:47
kwrobel2008MySQL is also running on that server19:47
kwrobel2008Anyway, I know I can run the script in runlevel 2 while everything is up and running.19:47
ion_The new emails would go to the next backup.19:48
kwrobel2008Right 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:48
kwrobel2008ion_: I understand.19:49
kwrobel2008ion_: Let's pretend for a moment19:51
kwrobel2008Is it possible to control the system in such a way that you could switch it into a different runlevel temporarily19:51
kwrobel2008in order to do whatever maintenance tasks19:52
kwrobel2008and then bring it back up?19:52
kwrobel2008(All automated of course)19:52
kwrobel2008Maybe upstart is just not the right tool for that?19:55
kwrobel2008Here's what I had in mind: create a job in /etc/event.d that listens to trigger run-bootbak,19:55
kwrobel2008then add a crontab entry for, say, 10pm that runs initctl emit run-bootbak19:56
=== AndyP_ is now known as AndyP
atsampsonpresumably 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...22:54

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!