| sadmac | Keybuk: ping | 02:28 |
|---|---|---|
| === Md_ is now known as Md | ||
| Keybuk | sadmac: pong | 12:26 |
| sadmac | Keybuk: I was wanting to ask about your current thoughts for the profiles system | 16:57 |
| Keybuk | sadmac: sure | 17:44 |
| sadmac | Keybuk: What does your design for it look lik? | 17:51 |
| Keybuk | I don't have one | 17:51 |
| sadmac | s/lik/\0e/ | 17:51 |
| Keybuk | AlexExtreme has been doing one, iirc | 17:51 |
| Keybuk | the idea being to define profiles in a file | 17:51 |
| Keybuk | that look something like | 17:51 |
| Keybuk | disable apache | 17:51 |
| Keybuk | disable squid | 17:51 |
| Keybuk | or | 17:51 |
| Keybuk | disable * | 17:51 |
| Keybuk | enable foo | 17:51 |
| Keybuk | enable bar | 17:51 |
| sadmac | hmm | 17:52 |
| sadmac | I had another idea for it | 17:52 |
| sadmac | my idea was to add a stanza to the job definitions, one of either "disable unless" or "disable if" | 17:53 |
| sadmac | followed by a series of flag names. | 17:53 |
| sadmac | we could then load a list of set flags off the filesystem at boot time. | 17:53 |
| sadmac | that does get kind of messy if you have flags with large effects, like single user mode. | 17:59 |
| Keybuk | yeah, that's more in line with the "flags" idea | 18:08 |
| Keybuk | flags and profiles are two competing ideas for the same functionality | 18:09 |
| Keybuk | profiles implies that profile is a first-class object which includes or excludes jobs | 18:09 |
| Keybuk | and maybe that you only have one profile active at one time | 18:09 |
| Keybuk | flags is that jobs disable/enable themselves in their own configuration depending on which flags are set | 18:09 |
| Keybuk | with the implication that multiple flags can be set at one time | 18:09 |
| Keybuk | the profiles idea is better for a sysadmin, since they don't need to edit the job definitions | 18:10 |
| Keybuk | flags is vaguely better for a distro | 18:10 |
| sadmac | Keybuk: with enough flags built into the jobs they become logically equivalent | 18:22 |
| Keybuk | that's somewhat true | 18:23 |
| Keybuk | one of the other inits has a feature whereby kernel arguments turn on/off jobs | 18:23 |
| sadmac | thats easy to do. Doesn't even have to be done in code. | 18:24 |
| sadmac | an early job definition that takes a peak at /proc could do it. | 18:25 |
| Torne | does upstart work if it's not PID 1? | 19:59 |
| Torne | as the child of another init? | 19:59 |
| Keybuk | no | 20:00 |
| Torne | aw. how come? :) | 20:01 |
| Keybuk | you can run it as another pid by disabling a couple of its features | 20:03 |
| Keybuk | (supervision of forking daemons, mostly) | 20:03 |
| Torne | nothing i run forks anyway :) | 20:04 |
| Torne | is that compile time? | 20:04 |
| Keybuk | why do you want to run it under another init? | 20:04 |
| Torne | i'm switching distribution | 20:05 |
| Keybuk | it's "edit the source and recompile" time | 20:05 |
| Keybuk | basically comment out the getpid() check | 20:05 |
| Torne | ah, right. i'll experiment in a bit then | 20:06 |
| Torne | thanks. was just wondering if there was an easier way | 20:06 |
| Keybuk | not really | 20:07 |
| Keybuk | it's not something I want to support | 20:07 |
| Keybuk | since people will complain when things don't work because they're not init | 20:07 |
| Torne | hm. if it's just a matter of turnign a few thigns off and disabling the check, surely that's a reasonable compile time option | 20:08 |
| Torne | and anyone who builds one with that on will presumably know what they're getting | 20:08 |
| Keybuk | adding an option means supporting it ;) | 20:09 |
| Keybuk | "blah doesn't work when not pid 1" ... "so run as pid 1" ... "but there's an option to not run as pid 1" | 20:09 |
| Torne | i think you're overestimating the chance of that happening, but hey :) | 20:10 |
| Keybuk | perhaps | 20:12 |
| Torne | thanks anyway. i'll fiddle with it. | 20:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!