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. 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 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.
Before I start writing this provider is there any kind of generic SSH
wrapper for this something i could start from?
Thank you very much for your help in advance!
Best wishes
Hannes
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
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 factsBy 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Aaron Grewell
2012-Jul-23 16:06 UTC
Re: [Puppet Users] Re: Best practice for calling commands
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.Bollinger@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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.grewell@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.Bollinger@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.