| JohnFlux_ | Hey all | 09:40 |
|---|---|---|
| === JohnFlux_ is now known as JohnFlux | ||
| 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:41 |
| 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 | 09:46 |
| atsampson | well, trivially you can communicate with it using initctl stop/start/status/etc... | 10:12 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| JohnFlux | why would monitoring them be modifying the system services? | 10:29 |
| 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:30 |
| JohnFlux | atsampson: hmm | 10:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| JohnFlux | presumably that requires root privillages as well? | 10:40 |
| atsampson | yes | 10:40 |
| JohnFlux | hum | 10:40 |
| * atsampson decides it's a good time for tea | 10:42 | |
| JohnFlux | it's always a good time for tea :) | 10:42 |
| atsampson | :) | 10:44 |
| 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:46 |
| 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 | 10: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:47 |
| 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:48 |
| 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 | 17:49 |
| JohnFlux | Keybuk: hey | 18:27 |
| 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 :-) | 18:28 |
| kwrobel2008 | Hi everybody | 19:22 |
| 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:24 |
| 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:25 |
| 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:26 |
| Keybuk | telinit 1 | 19:32 |
| Keybuk | that switches you to single-user mode | 19:32 |
| kwrobel2008 | HI | 19:33 |
| kwrobel2008 | Right. No I got the general idea | 19:33 |
| 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:34 |
| Keybuk | I'm not sure I follow, sorry | 19:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| kwrobel2008 | Now, 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 |
| kwrobel2008 | That aside, what I was thinking is to bring down all services, like postfix, dovecot, apache a.s.f. | 19:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| kwrobel2008 | ion_: I understand. | 19:49 |
| 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:51 |
| 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:52 |
| 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:55 |
| kwrobel2008 | then add a crontab entry for, say, 10pm that runs initctl emit run-bootbak | 19:56 |
| === AndyP_ is now known as AndyP | ||
| 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... | 22:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!