I have been working on full feature syslog type and providers. I
have a few questions about how to do things.
1) How do I have a type ''implement'' functionality from another
type.
For example, I have these 2 types:
file {"/var/log/ipfw.log":
ensure => present,
mode => 600,
owner => root,
group => wheel,
}
syslog { "/var/log/ipfw.log":
selector => ''security.info'''',
ensure => present,
notify => [ Service[syslog] ]
mode => 600,
owner => root,
group => wheel,
}
I''d like not to have the first file{} type and have the provider
''touch'' the file if it does not exist.
2) Is there an ''autonotify'' feature like there is autorequire?
Seems
like I should be able to have it notify the syslog service every time
I update the syslog.conf file.
Thanks
- JimP
--- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $
__o jim@pirzyk.org -------------------------------------------
_''\<,_
(*)/ (*) I''d rather be out biking.
On Mar 18, 2009, at 1:23 PM, Jim Pirzyk wrote:> I have been working on full feature syslog type and providers. I > have a few questions about how to do things. > > 1) How do I have a type ''implement'' functionality from another type. > > For example, I have these 2 types: > > file {"/var/log/ipfw.log": > ensure => present, > mode => 600, > owner => root, > group => wheel, > } > syslog { "/var/log/ipfw.log": > selector => ''security.info'''', > ensure => present, > notify => [ Service[syslog] ] > mode => 600, > owner => root, > group => wheel, > } > > I''d like not to have the first file{} type and have the provider > ''touch'' the file if it does not exist.You could have the syslog type generate the file resource: def generate Puppet::Type.type(:file).create(:path => self[:name], :mode => ....) unless catalog.resource(:file, self[:name]) end Something like that, anyway.> > 2) Is there an ''autonotify'' feature like there is autorequire? Seems > like I should be able to have it notify the syslog service every time > I update the syslog.conf file.There is not; I''ve never had anyone ask for it. I''d accept a patch for it, but you can hack it in the initialize method in the meantime. Just do something like: def initialize(*args) super self[:notify] = [:service, "syslog"] end Yes, hackish, but that''s what you get for being special. :) OTOH, if you''re generating the file as above, then include the ''notify'' value in the arguments to it. -- I object to doing things that computers can do. --Olin Shivers --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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 Mar 19, 2009, at 6:23 PM, Luke Kanies wrote:> > On Mar 18, 2009, at 1:23 PM, Jim Pirzyk wrote: > >> I have been working on full feature syslog type and providers. I >> have a few questions about how to do things. >> >> 1) How do I have a type ''implement'' functionality from another type. >> >> For example, I have these 2 types: >> >> file {"/var/log/ipfw.log": >> ensure => present, >> mode => 600, >> owner => root, >> group => wheel, >> } >> syslog { "/var/log/ipfw.log": >> selector => ''security.info'''', >> ensure => present, >> notify => [ Service[syslog] ] >> mode => 600, >> owner => root, >> group => wheel, >> } >> >> I''d like not to have the first file{} type and have the provider >> ''touch'' the file if it does not exist. > > You could have the syslog type generate the file resource: > > def generate > Puppet::Type.type(:file).create(:path => self[:name], :mode > => ....) unless catalog.resource(:file, self[:name]) > end > > Something like that, anyway. > >> >> 2) Is there an ''autonotify'' feature like there is autorequire? Seems >> like I should be able to have it notify the syslog service every time >> I update the syslog.conf file. > > There is not; I''ve never had anyone ask for it. I''d accept a patch > for it, but you can hack it in the initialize method in the meantime.I''ll take a crack at it. I just though of another case where this would be useful, running ''newaliases'' after /etc/mail/aliases has been updated. What do other people do? I have mailalias { foo: ... notify => [ Exec[newaliases] ] } on each mailalias type. I thought last night that: Mailalias { notify => [ Exec[newaliases] ] } would work, but it does not seem to.> Just do something like: > > def initialize(*args) > super > self[:notify] = [:service, "syslog"] > end > > Yes, hackish, but that''s what you get for being special. :) > > OTOH, if you''re generating the file as above, then include the > ''notify'' value in the arguments to it.Adding the notify to the file creation is not the same. Usually the file only get created once, but I need syslog HUP''ed everytime that / etc/[r]syslog.conf is updated, regardless of the destination log file existing or not. - JimP --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ __o jim@pirzyk.org ------------------------------------------- _''\<,_ (*)/ (*) I''d rather be out biking.
Hi> I just though of another case where this would be useful, running > ''newaliases'' after /etc/mail/aliases has been updated. What do > other people do? I have > > mailalias { foo: > ... > notify => [ Exec[newaliases] ] > } > > on each mailalias type. I thought last night that: > > Mailalias { > notify => [ Exec[newaliases] ] > } > > would work, but it does not seem to.this should do it. but this definition should be included as first, before any the other Mailalias definitions. I have plenty of such statements, and they work fine. Another thing is to add a wrapper define, which will set the appropriate defaults on your exec. Actually for the alias type I do it that way. cheers pete --~--~---------~--~----~------------~-------~--~----~ 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 Mar 20, 2009, at 10:00 AM, Peter Meier wrote:> > Hi > >> I just though of another case where this would be useful, running >> ''newaliases'' after /etc/mail/aliases has been updated. What do >> other people do? I have >> >> mailalias { foo: >> ... >> notify => [ Exec[newaliases] ] >> } >> >> on each mailalias type. I thought last night that: >> >> Mailalias { >> notify => [ Exec[newaliases] ] >> } >> >> would work, but it does not seem to. > > this should do it. but this definition should be included as first, > before any the other Mailalias definitions. I have plenty of such > statements, and they work fine. > Another thing is to add a wrapper define, which will set the > appropriate defaults on your exec. Actually for the alias type I do it > that way.What version? I''m running 0.24.7. I have other resource defaults, and they did work. I have not tested it lately. I have defined the Mailalias within the ''mail'' class and I''m testing in my ''ssh::client'' class. The mail is imported before ssh and the mail class is included before the ssh::client class. - JimP --- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $ __o jim@pirzyk.org ------------------------------------------- _''\<,_ (*)/ (*) I''d rather be out biking.
On Mar 20, 2009, at 9:27 AM, Jim Pirzyk wrote:> > On Mar 20, 2009, at 10:00 AM, Peter Meier wrote: > >> >> Hi >> >>> I just though of another case where this would be useful, running >>> ''newaliases'' after /etc/mail/aliases has been updated. What do >>> other people do? I have >>> >>> mailalias { foo: >>> ... >>> notify => [ Exec[newaliases] ] >>> } >>> >>> on each mailalias type. I thought last night that: >>> >>> Mailalias { >>> notify => [ Exec[newaliases] ] >>> } >>> >>> would work, but it does not seem to. >> >> this should do it. but this definition should be included as first, >> before any the other Mailalias definitions. I have plenty of such >> statements, and they work fine. >> Another thing is to add a wrapper define, which will set the >> appropriate defaults on your exec. Actually for the alias type I do >> it >> that way. > > What version? I''m running 0.24.7. I have other resource defaults, > and they did work. I have not tested it lately. I have defined the > Mailalias within the ''mail'' class and I''m testing in my > ''ssh::client'' class. The mail is imported before ssh and the mail > class is included before the ssh::client class.It''s scope, not order, that matters. It basically has to be in your site.pp, outside of any class. Yes, suckage, 0.25 has a better way (collections that modify resources). -- Risk! Risk anything! Care no more for the opinions of others, for those voices. Do the hardest thing on earth for you. Act for yourself. Face the truth. -- Katherine Mansfield --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---