bittu2 | how to determine difference between single user mode and run level 1? | 04:38 |
---|---|---|
bittu2 | i'm using centos 6 and i'm trying to see if there is an actual difference between the levels | 04:38 |
=== elmo__ is now known as elmo | ||
=== erkules_ is now known as erkules | ||
xnox | bittu2: i'm not familiar with centos 6, but as far as I know by default it only uses init.d scripts. You can inspect those to see if there is any difference. I would not have thought there would be. | 08:28 |
xnox | elmo: upstart 1.9-0ubuntu1 is in saucy. If you are after upstart apparmor support, you might need apparmor/kernel from saucy | 08:30 |
jodh | xnox: thanks for doing the upload! | 08:31 |
jodh | xnox: ...speaking of which, could I bug you about the procenv one? :) | 08:32 |
elmo | xnox: no, I'm after the dbus bridge; thanks for letting me know | 12:15 |
xnox | elmo: than straight backport should be enough =) | 12:16 |
jodh | xnox: lp:~jamesodhunt/upstart/fix-libupstart updated. | 12:30 |
xnox | jodh: win! =) | 12:30 |
xnox | we should have done that long time ago anyway.... was on the back of my todo list =) | 12:31 |
jodh | xnox: yeah, I'd like to understand exactly what's different on 64-bit systems though. | 12:31 |
neomantra | hi, i am running on headless a Ubuntu cloud image (Raring with upstart 1.8) and want to use upstart session jobs. I don't think I'm set up properly for this as I get this error in response to `initctl --user start mjob`: | 14:24 |
neomantra | "initctl: UPSTART_SESSION isn't set in the environment. Unable to locate the Upstart instance." | 14:24 |
xnox | jodh: ^ | 14:54 |
xnox | jodh: do we spawn user sessions on servers at all yet? | 14:54 |
xnox | and how to do that? | 14:55 |
jodh | xnox / neomantra: we don't really support console login environments yet. | 14:56 |
jodh | neomantra: you could arrange for the system upstart to start a session init as your user, then "join" that session using something like 'export UPSTART_SESSION=`initctl list|awk '{print $2}'` before running 'start $job', but that assumes there is only 1 session init instance running for the user. | 15:00 |
neomantra | thanks for the responses. ah, using upstart to start the "user upstart" it makes sense | 15:03 |
neomantra | my intention is to have services run as a user on cloud servers. should i not be using upstart for this? i'm revamping my infrastructure and thought i'd use it instead of start-stop-daemon | 15:05 |
xnox | neomantra: if setuid/setgid stanzas are enough, just add system jobs. | 15:48 |
xnox | neomantra: traditionally, userids that run webapps/etal shouldn't have login accounts / shell access at all =) | 15:49 |
xnox | neomantra: such that those jobs are executed as non-priviledged users. | 15:49 |
neomantra | xnox: that's a good point. but i want users to be able to push configuration and then start/stop jobs... but not do anything privileged | 15:50 |
neomantra | their jobs | 15:50 |
xnox | neomantra: for that case, user session / jobs sounds nicer. | 15:51 |
neomantra | so i have system upstart starting the "init --user" with setuid/gid as my user. still need the upstart session variable. the "initctl list|awk" doesn't seem to work | 15:53 |
elmo | hmm | 19:22 |
elmo | configure.ac:11: option `serial-tests' not recognized | 19:22 |
elmo | autoreconf: automake failed with exit status: 1 | 19:22 |
elmo | ah, looks like I need saucy automake ; will file a bug about build-depends | 19:23 |
xnox | elmo: or you can remove "serial-tests", introduced in automake1.12. we are in discussion with automake upstream about the whole test issues. | 23:02 |
xnox | elmo: i don't think in upstream we have "serial-tests" specified, due to resulting in higher automake dependancy. | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!