more crankd. supporting multiple actions per key. layout?
Nigel Kersten
key, and for the sake of argument, lets assume I'm triggering external
commands as it makes the examples simpler.
let's say on SystemConfiguration:State:/Network/Global/IPv4 I want to
trigger two scripts:
/usr/local/bin/one
/usr/local/bin/two
There are lots of ways we could do this, but all of them are going to
require re-factoring the code.
I feel like this functionality is a pretty strong requirement for
releasing crankd in a pkg.
The question is, how do we lay it out? I'm removing the
encoding/doctype bits from the plist for sanity.
I offer up some examples.
<dict>
<key>SystemConfiguration</key>
<array>
<dict>
<key>State:/Network/Global/IPv4</key>
<dict>
<key>command</key>
<string>/usr/local/sbin/one</string>
</dict>
</dict>
<dict>
<key>State:/Network/Global/IPv4</key>
<dict>
<key>command</key>
<string>/usr/local/sbin/two</string>
</dict>
</dict>
</array>
</dict>
<dict>
<key>SystemConfiguration</key>
<dict>
<key>State:/Network/Global/IPv4</key>
<array>
<dict>
<key>command</key>
<string>/usr/local/sbin/one</string>
</dict>
<dict>
<key>command</key>
<string>/usr/local/sbin/two</string>
</dict>
</dict>
</dict>
<dict>
<key>SystemConfiguration</key>
<dict>
<key>State:/Network/Global/IPv4</key>
<array>
<dict>
<key>command</key>
<array>
<string>/usr/local/sbin/one</string>
<string>/usr/local/sbin/two</string>
</array>
</dict>
</dict>
</dict>
At the moment I'm leaning towards the latter, but would like to
probably not enforce an array, but convert internally to a single
element array if only one element is specified. (and obviously for all
of command, module, etc)
Can anyone think of any good reasons why we'd want to make the array
higher up at State:/Network/Global/IPv4 or even SystemConfiguration ?
Greg Neagle
write a wrapper script that runs both things.
Sent from my iPhone
On Aug 19, 2009, at 6:23 PM, Nigel Kersten <ni...@explanatorygap.net>
wrote:
Nigel Kersten
>
> You can't do this with launchd, so why should crankd support it? Just
> write a wrapper script that runs both things.
not the more sophisticated options where you can trigger a method in a
class. Do we really want to be adding another layer of
partials/callables?
Writing wrapper scripts sucks.
I wouldn't draw an analogy between an individual launchd job and the
crankd plist. Instead the relationship is closer to the whole
Launch{Agents,Daemons} folder. You're configuring multiple instances
in the one plis.
That's actually an option I hadn't thought of, separating every job
out into a new plist.
Preston Holmes
On Aug 19, 2009, at 6:23 PM, Nigel Kersten wrote:
> let's say on SystemConfiguration:State:/Network/Global/IPv4 I want to
> trigger two scripts:
>
> /usr/local/bin/one
> /usr/local/bin/two
>
> There are lots of ways we could do this, but all of them are going to
> require re-factoring the code.
>
> I feel like this functionality is a pretty strong requirement for
> releasing crankd in a pkg.
In situations where you are specifying both scripts, why not write a
wrapper? (I'm guessing you have a reason - just not sure what it is)
In situations where you have independent workflows that each want to
tap crankd, it would seem easier to just have multiple instances of
crankd each started with their own config file.
I'm thinking the latter applies to something that someone might write
that builds on crankd. The setup might contain a config, a set of
scripts (or module) and a launchd item. hmm - doing a quick test of
this seems like crankd is using 20mb of real memory - that may be a
limitation of this approach.
Of course making the changes you are suggesting doesn't prevent either
of the above approaches - it just may add complexity rarely used.
As a tool to be built upon - I think the idea of all independently
developed consumers of crankd events trying to share a single config
gets messy.
As far as making the change - I don't think any one way stands out as
the clear winner, so since you are doing the work - I think you should
just pick the one that makes the most sense as you implement the code
changes.
-P
Nigel Kersten
>
>
> On Aug 19, 2009, at 6:23 PM, Nigel Kersten wrote:
>
>> let's say on SystemConfiguration:State:/Network/Global/IPv4 I want to
>> trigger two scripts:
>>
>> /usr/local/bin/one
>> /usr/local/bin/two
>>
>> There are lots of ways we could do this, but all of them are going to
>> require re-factoring the code.
>>
>> I feel like this functionality is a pretty strong requirement for
>> releasing crankd in a pkg.
>
> In situations where you are specifying both scripts, why not write a
> wrapper? (I'm guessing you have a reason - just not sure what it is)
thing I've become convinced of is that wrapper scripts are
problematic.
It becomes difficult to insert and remove items atomically, and it's
too easy to accidentally break working items when modifying the set of
items.
Plus ultimately I want to take advantage of threading and not execute
tasks in a serial manner, and I don't think it makes sense to
implement separate threads in the wrapper scripts :)
This is why .d directories are better than single files for
configuration ie /etc/apt/sources.list.d , /etc/manpath.d
/Library/LaunchAgents etc.
I think individual config files ends up being the simplest and most
logical solution after Greg's email. This also makes sharing of crankd
addons much much easier.
Of course that opens up another whole can of worms about naming
them... but it seems like reverse domain notation is the defacto
standard on OS X these days.
I don't really want to just plow ahead and annoy others here. I'm not
trying to browbeat you all.
I realize I'm the main one actually deploying this across lots and
lots of machines, but I need to be able to bounce ideas off people who
can provide intelligent responses as you may have noticed... :)
Greg Neagle
configuration all in one big monolithic file, but rather separate
files in a 'crankd.d' directory.
-Greg
Chris Adams
On Aug 19, 2009, at 9:23 PM, Nigel Kersten wrote:
> <dict>
> <key>SystemConfiguration</key>
> <dict>
> <key>State:/Network/Global/IPv4</key>
> <array>
> <dict>
> <key>command</key>
> <string>/usr/local/sbin/one</string>
> </dict>
> <dict>
> <key>command</key>
> <string>/usr/local/sbin/two</string>
> </dict>
> </dict>
> </dict>
I could have sworn I had syntax like that working at some point
(although it might have been #1) - but the above is my preference
since it avoids duplication while allowing you to easily have multiple
action types (e.g. run this command and that function).
I strongly agree on the idea of converting any input into lists - it'd
really complicate the code everywhere else to have to test whether you
have a single item or a list.
Chris
Nigel Kersten
>
> On Aug 19, 2009, at 9:23 PM, Nigel Kersten wrote:
>>
>> <dict>
>> <key>SystemConfiguration</key>
>> <dict>
>> <key>State:/Network/Global/IPv4</key>
>> <array>
>> <dict>
>> <key>command</key>
>> <string>/usr/local/sbin/one</string>
>> </dict>
>> <dict>
>> <key>command</key>
>> <string>/usr/local/sbin/two</string>
>> </dict>
>> </dict>
>> </dict>
>
>
> I could have sworn I had syntax like that working at some point (although it
> might have been #1) - but the above is my preference since it avoids
> duplication while allowing you to easily have multiple action types (e.g.
> run this command and that function).
I'm pretty sure it was only working for two different classes of
trigger, ie a module/function + a command.
>
> I strongly agree on the idea of converting any input into lists - it'd
> really complicate the code everywhere else to have to test whether you have
> a single item or a list.
absolutely.
Chris Adams
> I think you've made your own argument for not having crankd's
> configuration all in one big monolithic file, but rather separate
> files in a 'crankd.d' directory.
Oh, and while we're on the subject: stick with plists in their
familiar but inelegant syntax or switch to something simple? There's a
certain argument that a crankd.d file should be as simple as this:
source=SystemConfiguration
key=State:/Network/Global/IPv4
command=/foo/bar
Chris
Greg Neagle
good tools for working with them, and they're ubiquitous on Mac OS X.
Certainly, there are other configuration file formats (YAML and INI-
style come to mind as well), but nothing says "Designed for Mac OS X"
like a plist...
-Greg
Nigel Kersten
plists really do mean you never have to worry about escaping special
characters :)
Clay Caviness
On Thu, Aug 20, 2009 at 6:29 PM, Chris Adams<ch...@improbable.org> wrote:
>> I could have sworn I had syntax like that working at some point (although it
> might have been #1) - but the above is my preference since it avoids
> duplication while allowing you to easily have multiple action types (e.g.
> run this command and that function).
I'm pretty sure it was only working for two different classes of
trigger, ie a module/function + a command.
Nigel Kersten
Yes, clay really did send this months ago and we didn't moderate it...
I've added clay as another owner now that chris and I are both pretty much absent...
A few more people at puppet camp expressed interest, so if anyone else wants to own the list....
One day I will write that article...
> You received this message because you are subscribed to the Google Groups "PyMacAdmin" group.
> To post to this group, send email to pymac...@googlegroups.com.
> To unsubscribe from this group, send email to pymacadmin+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pymacadmin?hl=en.
>