Puppet devices provide an ssh and telnet transport, so you can reuse
them for this purpose. In the resource type, you just need to specify
'apply_to_device'. The device connectivity information is stored in
device.conf, and both transport behaves similar to an expect script.
There's a few limitation to keep in mind:
1. One certificate per device, since each device is a puppet node.
2. You can only specify relationship between resources for that device.
3. The existing implementation is somewhat brittle since it's just
waiting for the next prompt to issue the next command.
Regardless of whether you implement a host or device resource, the
existing transport should give you a good idea how to do this.
Thanks,
Nan
On Mon, Jul 23, 2012 at 9:06 AM, Aaron Grewell <aaron.grew...@gmail.com> wrote:
> This sounds similar to how the router type works so that might be a good
> place to start looking for ideas.
>
> On Jul 23, 2012 6:20 AM, "jcbollinger" <john.bollin...@stjude.org> wrote:
>>
>>
>>
>> On Monday, July 23, 2012 4:16:15 AM UTC-5, Hannes Schaller wrote:
>>>
>>> Hello!
>>>
>>> I hope someone might be able to give me some directions on this
>>> problem. The search didn't come up with something useful because it's
>>> some kind of a corner case i think...
>>>
>>> I am trying to implement an integration of HP System Insight Manager
>>> into Puppet. Unfortunately the HP SIM is running on a windows box to
>>> which I only have SSH access and cannot install puppet on it (otherwise
>>> Exec would be easy).
>>>
>>> My idea was to write a provider and type that i could do something like
>>>
>>> node server1 {
>>> simnode {"$hostname":
>>> ensure => present,
>>> simserver => "hpsim.example.com",
>>> }
>>> }
>>>
>>> In the background the provider issues an command over ssh to make sure
>>> it is in SIM:
>>>
>>> <snip>
>>> Puppet::Type.type(:simnode).provide(:ssh) do
>>> confine :manufacturer => [ "HP", "Compaq" ]
>>> commands :ssh => "ssh"
>>>
>>> def create
>>> ssh @resource[:simserver] "mxnode -a @resource[:name]"
>>> end
>>>
>>> def exists?
>>> output = ssh @resource[:simserver] "mxnode -ld
>>> @resource[:name]"
>>> if output =~ /The node specified does not represent a node in
>>> this system/i
>>> false
>>> else
>>> true
>>> end
>>> end
>>>
>>> def destroy
>>> ssh @resource[:simserver] "mxnode -r @resource[:name]"
>>> end
>>> end
>>> <snap>
>>>
>>>
>>> Of course this is more or less pseudocode but I guess you see what I am
>>> intending to do.
>>
>>
>> I think something along those lines could be made to work, but it's very
>> unusual. The resource you're managing doesn't actually belong to the node
>> being managed. That may be the best you can do with the constraints you're
>> working under, but be aware that it will be shakier than most Puppet
>> resources.
>>
>>
>>>
>>> On the other hand the "mxnode -ld" command also spits
>>> out some very interesting information about support status and features
>>> that I would like to put into facts
>>
>>
>> By the time your provider (or your type) enters the picture, fact
>> collection is long since over and done. If you want to make facts out of
>> that information then you need to write separate custom facts. Note,
>> however, that doing so makes your setup a little bit shakier still, for then
>> you have not only managed resources, but also facts that don't belong to the
>> node being managed.
>>
>>>
>>> respectively there is an XML Output
>>> of mxnode which I could use to cache the state if a node has already
>>> been added to SIM.
>>
>>
>> I advise against doing that, as it introduces a cache validity problem.
>> Puppet providers generally prefer to use the system's tools directly.
>>
>>>
>>>
>>> Before I start writing this provider is there any kind of generic SSH
>>> wrapper for this something i could start from?
>>
>>
>> I am not aware of one, but perhaps someone else can help you out. On the
>> other hand, what you're trying to do is very unusual, as I already said, so
>> you may be on your own.
>>
>>
>> John
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/puppet-users/-/4VEF0zAzBQEJ.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
