[Puppet Users] RPM is not getting installed for PE3.2
I want to install Puppet Enterprise 3.2 with automated answer file and by creating a rpm. When I am trying to install this rpm by using yum install rpm name= , it gets stuck because this yum command get lock of yum and when installer implicitly calls for yum to install another packages, it is not able to get hold of yum. To resolve this, I tried to install this rpm with rpm -ivh rpm name= . It got installed successfully once but later on it is giving me following warning and gets stuck. Warning: RPMDB altered outside of yum. Any help is appreciated. Thanks, -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/535f743b-b6d7-436d-be19-39cad446f9bb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Creating scope object in Puppet v3.x
Hi all, I wrote a neat little script for Puppet 2.x to test custom functions without needing to do a Puppet run. This involved creating a Scope object using `Puppet::Parser::Scope.new` then calling `send` to send a function call to it. In Puppet 3 however, creating a Scope instance this way does not work. Now a Compiler object is a required argument of the Scope constructor, and a Node argument is a required argument of the Compiler constructor, and the list goes on. Does anyone know how I can most simply create a Scope object like I did before? Many thanks, Dave -- Notice: This email is confidential and may contain copyright material of Ocado Limited (the Company). Opinions and views expressed in this message may not necessarily reflect the opinions and views of the Company. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. Company reg. no. 3875000. Ocado Limited Titan Court 3 Bishops Square Hatfield Business Park Hatfield Herts AL10 9NE -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e94a2171-d0b8-4284-96fe-f863d22adcf9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] vcsrepo module: is my patch faulty or are the test failures unjustified?
Hi, I have some vcsrepo resources that check out out a revision specified by SHA1 hash. However, on every run 'git fetch' is run to verify that the correct revision is checked out. I think that shouldn't be necessary, so I tried to patch vcsrepo to avoid such fetches in that case: https://github.com/mheistermann/puppetlabs-vcsrepo/commit/68cf48ec624dddfd1cdd034638131829fd2d46fb After this change, several spec tests fail: https://gist.github.com/anonymous/11399436 You can find the source of the failing tests (current HEAD) here: https://github.com/puppetlabs/puppetlabs-vcsrepo/blob/46588aa62d444c5f0a538cccec357a80cd191b93/spec/unit/puppet/provider/vcsrepo/git_spec.rb#L173 The test checking the revision property when its SHA1 is not different than the current SHA should return the ref, which fits my setup, seems to fails because the changed code does not do some git invocations required by the test, which i believe to be superfluous. If I understand it correctly (I'm new to ruby and rspec), the other failing tests hand the string 'currentsha' to the tested code both as resource revision as well as 'git rev-parse HEAD' output (L176, L178). I think that 'currentsha' would be the correct method return value, with no git invocations except for 'git rev-parse HEAD'. I am not sure if my code actually introduces wrong behavior (how?) or if the tests failures are actually not justified and would be glad about your comments. Thanks in advance! Martin -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/72d53153-fba6-4ff9-9588-d3c134e97c68%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Database and user not created (Puppetlabs mysql module)
I think you have to enable pluginssync option in the [main] section in puppet.conf On Wednesday, 11 April 2012 14:12:03 UTC+1, Moteo wrote: Hi Luca, sadly I left nice puppet way for a while for Mysql management and did everything manuallly :( Best regards M. 2012/3/28 Luca Spiller lu...@stackednotion.com javascript:: Moteo, did you get this issue resolved? I've used the Puppetlabs MySql module in the past, but I'm now getting these issues setting up a new machine with Ubuntu 11.10. I've used the same Puppet scripts on other Ubuntu 11.10 machines previously with no issues. On Thursday, 15 March 2012 10:51:04 UTC, Moteo wrote: I will try this module. Thank You Adam. 2012/3/14 Adam Heinz a...@metricwise.net javascript:: I don't know anything about that particular module, but I have been using github.com/camptocamp/puppet-mysql for over a year without much trouble. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet...@googlegroups.comjavascript: . To unsubscribe from this group, send email to puppet-users...@googlegroups.com javascript:. 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 view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ZwavJYd6jwMJ. To post to this group, send email to puppet...@googlegroups.comjavascript: . To unsubscribe from this group, send email to puppet-users...@googlegroups.com javascript:. 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/d3af5373-21c2-4ee5-a3d3-8e6ab74a6c4e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources
On Monday, April 28, 2014 2:34:43 PM UTC-5, Alex Scoble wrote: Hi All, I'm working on a module that builds KVM/libvirt hosts and populates them with predefined VMs. So far I have the module to where it can create any number of virtual nets, storage pools and volumes using virsh, but it isn't pretty. I've read on various threads here that create_resources is not a good function to use. This was stated quite emphatically by R.I. Pienaar and others. If anyone has been vocal (here) about Puppet functions not to use then it's me, and create_resources() is not one I rant about. As a general rule I do prefer expressing configuration in DSL where that's feasible, and you can, in fact, do the job of create_resources() almost entirely with ordinary Puppet DSL (you need to add only stdlib's keys() function). Nevertheless, I'm not persuaded that going to substantial effort and length to avoid create_resources() is necessarily a win. On the other hand, I have come out rather strongly against the ensure_resource() function. Were you perhaps thinking of that? Already I've run into the situation where it's hard to control order in which two separate create_resources functions are run and I've seen some kludges to fix it, but I'm looking for a better way and hoping that it doesn't involve the use of custom types because that's currently more than I want to deal with. Indeed, one of the issues that does exist with create_resources() is that you cannot express resource references in Hiera data (though I have seen one recent report that claims otherwise). When part of the point of using that function in the first place is that you don't want to have to know exactly which resources you are actually declaring, that can present a challenge. It is, nevertheless, a challenge that can be worked around. In some cases, the workaround is a mechanism, such as collector chaining, that you might reasonably have used anyway. It would be super helpful if anyone could point me to a puppet module on github that presents me with a better pattern to use with the hiera data. [...] Any other help or criticisms are also welcome. That looks pretty clean to me already. It does appear that maybe you want to express relationships between your Kvm::Virtpool and Kvm::Virtvol instances, but Garrett appears already to have gotten you pointed in a useful direction with that (collector chaining). If you want responses to particular commentary about the create_resources() function then it would be helpful to provide a pointer to that commentary. R.I. is a pretty smart guy, and he has thought a lot about how Puppet can and should use data, so I'm not remotely going to try to respond to anything he may have said on the topic without actually reading it for myself Additional, minor comments about your code: 1. For any but the most simple Execs, I recommend using descriptive resource titles, and expressing the commands themselves via Exec's 'command' property. It is much, much easier that way to understand their purpose, especially in log output. 2. There are only two reasons for using class inheritance: to make a variable of the inherited class reliably available for use as a class parameter default, and to enable overriding properties of a resource declared by the inherited class. The latter is the original purpose, and the former is merely a side effect, but the former is by far the more common reason for class inheritance these days. In all other cases, an ordinary class declaration (include 'foo') can and should be used instead, if indeed anything of the sort is needed at all. Avoid class inheritance where it is unneeded. Especially avoid inheriting from a parameterized class. 3. Your class kvm has the strung 'undef' as the defined default value for a bunch of parameters. That's quite different from the undef keyword; is it what you really mean? If it were then I would expect to see some kind of test for those values, but I don't. 4. More generally, don't define class and type parameter default values unless you really mean it. If you forget to declare a needed resource or class parameter then Puppet will diagnose the issue if and only if the parameter has no defined default value. Do not write definitions or classes such that failure to declare all the needed parameters will silently yield an invalid configuration, as appears may be the case for some of your defined parameters. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/cf039141-1935-4380-bfc5-65cc99410726%40googlegroups.com. For more options,
[Puppet Users] Enable puppet agent by default
Hello I am trying puppet 3.5.1 on a Debian Jessie. How can I enable Puppet by default on new installations ? I need to do that, for Debian deployment. I use Debian FAI to install Debian on my workstations. After the deployment, Puppet is launched. I just have to sign them on Puppet Master in order to launch the post install with puppet (AD integration, CUPS configuration...). So now, I can't do that because the /etc/default/puppet file is not read by the system. The only solution I see, is to add a cron task @reboot. Am I wrong ? Thanks for your help Marc -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/03699c7c-510a-4ecd-8977-9bfc760f221e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Enable puppet agent by default
Hi! On Tue, Apr 29, 2014 at 9:13 AM, Marc marcol...@gmail.com wrote: Hello I am trying puppet 3.5.1 on a Debian Jessie. How can I enable Puppet by default on new installations ? It looks like it is. I need to do that, for Debian deployment. I use Debian FAI to install Debian on my workstations. After the deployment, Puppet is launched. I just have to sign them on Puppet Master in order to launch the post install with puppet (AD integration, CUPS configuration...). So now, I can't do that because the /etc/default/puppet file is not read by the system. I don't think there is any need to read /etc/default/puppet on Debian Jessie. The Jessie puppet package does not install /etc/default/puppet and the init script doesn't make use of anything in the file either - thought it does make an attempt to read it: [ -r /etc/default/puppet ] . /etc/default/puppet The only solution I see, is to add a cron task @reboot. Am I wrong ? I don't follow what you want to have done. What exactly would you put in the cron task? -mz -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAOLfK3VA77zDVbXW0wN%3Dg%2Bj9jznGKoxKUtd9LQB-N1chM-_jRg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Enable puppet agent by default
On 4/29/14, 10:45 AM, Matt Zagrabelny wrote: Hi! On Tue, Apr 29, 2014 at 9:13 AM, Marc marcol...@gmail.com wrote: Hello I am trying puppet 3.5.1 on a Debian Jessie. How can I enable Puppet by default on new installations ? It looks like it is. I need to do that, for Debian deployment. I use Debian FAI to install Debian on my workstations. After the deployment, Puppet is launched. I just have to sign them on Puppet Master in order to launch the post install with puppet (AD integration, CUPS configuration...). So now, I can't do that because the /etc/default/puppet file is not read by the system. I don't think there is any need to read /etc/default/puppet on Debian Jessie. The Jessie puppet package does not install /etc/default/puppet and the init script doesn't make use of anything in the file either - thought it does make an attempt to read it: [ -r /etc/default/puppet ] . /etc/default/puppet The only solution I see, is to add a cron task @reboot. Am I wrong ? I don't follow what you want to have done. What exactly would you put in the cron task? -mz Hi, Recommend that you do not run the agent as a service at all and instead use cron. You can then have each system randomize when they check in to prevent thundering herd[1]. I still run the puppet agent by default at boot time which is handled as you mentioned by cron with @reboot. If you bring up all your systems at the same time, this could pose an issue for you. Here my puppet module[2] that can manage your agent with cron or as a service. [1] - http://en.wikipedia.org/wiki/Thundering_herd_problem [2] - https://github.com/ghoneycutt/puppet-module-puppet Best regards, -g -- Garrett Honeycutt @learnpuppet Puppet Training with LearnPuppet.com Mobile: +1.206.414.8658 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/535FC0D2.1090807%40garretthoneycutt.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Enable puppet agent by default
(inline) On Tue, Apr 29, 2014 at 11:10:10AM -0400, Garrett Honeycutt wrote: On 4/29/14, 10:45 AM, Matt Zagrabelny wrote: Hi! On Tue, Apr 29, 2014 at 9:13 AM, Marc marcol...@gmail.com wrote: Hello I am trying puppet 3.5.1 on a Debian Jessie. How can I enable Puppet by default on new installations ? It looks like it is. I need to do that, for Debian deployment. I use Debian FAI to install Debian on my workstations. After the deployment, Puppet is launched. I just have to sign them on Puppet Master in order to launch the post install with puppet (AD integration, CUPS configuration...). So now, I can't do that because the /etc/default/puppet file is not read by the system. I don't think there is any need to read /etc/default/puppet on Debian Jessie. The Jessie puppet package does not install /etc/default/puppet and the init script doesn't make use of anything in the file either - thought it does make an attempt to read it: [ -r /etc/default/puppet ] . /etc/default/puppet The only solution I see, is to add a cron task @reboot. Am I wrong ? I don't follow what you want to have done. What exactly would you put in the cron task? -mz Hi, Recommend that you do not run the agent as a service at all and instead use cron. You can then have each system randomize when they check in to prevent thundering herd[1]. I still run the puppet agent by default at boot time which is handled as you mentioned by cron with @reboot. If you bring up all your systems at the same time, this could pose an issue for you. Can't hosts already stagger their agent checkin times by using per-host runinterval settings? At some point, sure, agents may not be the best path forward but I don't see when I'd reach that point. Here my puppet module[2] that can manage your agent with cron or as a service. [1] - http://en.wikipedia.org/wiki/Thundering_herd_problem [2] - https://github.com/ghoneycutt/puppet-module-puppet Best regards, -g -- Garrett Honeycutt @learnpuppet Puppet Training with LearnPuppet.com Mobile: +1.206.414.8658 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/535FC0D2.1090807%40garretthoneycutt.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20140429151535.GA6209%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Puppetmaster Logrotate isn't working
Hello,
we have an issue that the Puppetmaster logrotate isn't working.
We are using the following default Logrotate:
/var/log/puppet/*log {
missingok
sharedscripts
create 0644 puppet puppet
compress
rotate 4
postrotate
pkill -USR2 -u puppet -f 'puppet master' || true
[ -e /etc/init.d/puppet ] /etc/init.d/puppet reload /dev/null 21 ||
true
endscript
}
After running the logrotate script we have this message in syslog:
Apr 29 09:36:12 puppet1 puppet-master[3109]: Caught USR2; calling reopen_logs
Apr 29 09:36:12 puppet1 puppet-master[3109]: Reopening log files
The problem is that the logrotate does not create a new masterhttp.log. We
tried it with Puppet-3.4.2, 3.4.3 and 3.5.1.
Regards - Willi
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/88975a2c-d3c6-436e-825e-1e579d45a2b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Best practice for creating resources out of Hiera?
On Monday, 28 April 2014 20:55:30 UTC+12, Felix.Frank wrote: Hi, this is really, really meta (http://xkcd.com/917/). Nevertheless, I nailed it? I'm a little cautious of building something like this: http://thedailywtf.com/Articles/The_Enterprise_Rules_Engine.aspx Oh, come on. If you didn't like domain specific languages you'd be avoiding this puppet manifest muck and use Chef, instead. The point of them, and configuration files to some extent, is to achieve greater brevity, safety and maintainability than a general purpose language. They only turn into Enterprise Rules Engines when the result is a verbose, obfuscated, mess. I'd have to play with your module though in order to get a feel about wether it is rather useful or over the top. With this, I get to separate resource configuration data from manifest code by writing short, pithy YAML, so I think I'm winning. And admittedly, I could have called it something like resource_map and made the primary hiera data a simple mapping of resource types to keys, rather than the more recursive and distastefully named solution I've published, but kind of the point is, shouldn't there be an easier way? Baked into the hiera/puppet bindings? One remark about your README - it's true that the adoption of functions is not mentioned in the current documentation, but please note that you can trace past documentations and easily bisect the origin of any specific feature: http://docs.puppetlabs.com/references/3.2.2/function.html http://docs.puppetlabs.com/references/2.7.20/function.html etc. Also, git. :-) Right now, having documentation at all puts me head and shoulders above the long tail of Puppet Forge module authors. Now I guess I could be motivated to go through the last half dozen references and annotate the functions with version introductions, and changes, but only if I believed the pull request would be accepted, and the trend continued. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ce455318-90da-488d-aaae-c62b817daa9b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources
Hi John, Thanks so much for your feedback. It's extremely useful for me at this stage of my education in the Puppet DSL. Here is the Puppet Users group thread where R.I. Pienaar said that he felt that using create_resources() was bad: https://groups.google.com/forum/?fromgroups#!searchin/puppet-users/create_resources$20pienaar/puppet-users/lxYDKf7dgc0/TppS_7BFB9IJ Responses to comments: 1. That makes perfect sense. I'll do that from now on. Thanks. 2. As far as I can see, I'm using class inheritance solely to make sure that class parameters are available to the main and sub classes. Maybe you are seeing that I'm using inheritance where it's not yet strictly needed? I'll have to look more closely at my code and fix any instances of inheritance where it's unnecessary. Thanks. 3. You are right. I'm using the wrong kind of 'undef' here. 4. Yep, I'll have to look at the parameters and clean this up as well. Thanks much! Alex On Tuesday, April 29, 2014 7:10:36 AM UTC-7, jcbollinger wrote: On Monday, April 28, 2014 2:34:43 PM UTC-5, Alex Scoble wrote: Hi All, I'm working on a module that builds KVM/libvirt hosts and populates them with predefined VMs. So far I have the module to where it can create any number of virtual nets, storage pools and volumes using virsh, but it isn't pretty. I've read on various threads here that create_resources is not a good function to use. This was stated quite emphatically by R.I. Pienaar and others. If anyone has been vocal (here) about Puppet functions not to use then it's me, and create_resources() is not one I rant about. As a general rule I do prefer expressing configuration in DSL where that's feasible, and you can, in fact, do the job of create_resources() almost entirely with ordinary Puppet DSL (you need to add only stdlib's keys() function). Nevertheless, I'm not persuaded that going to substantial effort and length to avoid create_resources() is necessarily a win. On the other hand, I have come out rather strongly against the ensure_resource() function. Were you perhaps thinking of that? Already I've run into the situation where it's hard to control order in which two separate create_resources functions are run and I've seen some kludges to fix it, but I'm looking for a better way and hoping that it doesn't involve the use of custom types because that's currently more than I want to deal with. Indeed, one of the issues that does exist with create_resources() is that you cannot express resource references in Hiera data (though I have seen one recent report that claims otherwise). When part of the point of using that function in the first place is that you don't want to have to know exactly which resources you are actually declaring, that can present a challenge. It is, nevertheless, a challenge that can be worked around. In some cases, the workaround is a mechanism, such as collector chaining, that you might reasonably have used anyway. It would be super helpful if anyone could point me to a puppet module on github that presents me with a better pattern to use with the hiera data. [...] Any other help or criticisms are also welcome. That looks pretty clean to me already. It does appear that maybe you want to express relationships between your Kvm::Virtpool and Kvm::Virtvol instances, but Garrett appears already to have gotten you pointed in a useful direction with that (collector chaining). If you want responses to particular commentary about the create_resources() function then it would be helpful to provide a pointer to that commentary. R.I. is a pretty smart guy, and he has thought a lot about how Puppet can and should use data, so I'm not remotely going to try to respond to anything he may have said on the topic without actually reading it for myself Additional, minor comments about your code: 1. For any but the most simple Execs, I recommend using descriptive resource titles, and expressing the commands themselves via Exec's 'command' property. It is much, much easier that way to understand their purpose, especially in log output. 2. There are only two reasons for using class inheritance: to make a variable of the inherited class reliably available for use as a class parameter default, and to enable overriding properties of a resource declared by the inherited class. The latter is the original purpose, and the former is merely a side effect, but the former is by far the more common reason for class inheritance these days. In all other cases, an ordinary class declaration (include 'foo') can and should be used instead, if indeed anything of the sort is needed at all. Avoid class inheritance where it is unneeded. Especially avoid inheriting from a parameterized class. 3. Your class kvm has the strung 'undef' as the defined default value for a bunch of
[Puppet Users] puppet sub-folders
My manifests folder is getting pretty full and a little messy. Can I create directories in my manifests folder for my main module? Does puppet understand to look in the folders or will this mess everything up? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e383440a-fc89-40cb-905a-b5f9b23df029%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: puppet sub-folders
I suppose I should have mentioned that I'm using a Puppetmaster server to dish out all of my manifests. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1c86f951-4d4a-4885-a395-02516b2bd404%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppet sub-folders
Sounds like it's time for you to start using modules:
http://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.html
For interest's sake, my manifest has only a two-line site.pp. Everything else
is modules or hiera.
Yumrepo | | - Package | |
hiera_include('hclasses')
On Tue, Apr 29, 2014 at 11:41:50AM -0700, Jason Hatman wrote:
My manifests folder is getting pretty full and a little messy. Can I
create directories in my manifests folder for my main module? Does puppet
understand to look in the folders or will this mess everything up?
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [1]puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
[2]https://groups.google.com/d/msgid/puppet-users/e383440a-fc89-40cb-905a-b5f9b23df029%40googlegroups.com.
For more options, visit [3]https://groups.google.com/d/optout.
References
Visible links
1. mailto:puppet-users+unsubscr...@googlegroups.com
2.
https://groups.google.com/d/msgid/puppet-users/e383440a-fc89-40cb-905a-b5f9b23df029%40googlegroups.com?utm_medium=emailutm_source=footer
3. https://groups.google.com/d/optout
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20140429191024.GA7423%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppet sub-folders
I'm using modules right now. However, I have 90% of my manifests in one module. My site.pp is also very small. Should I break them up into different modules? I really haven't put much thought into that because I didn't have very many manifests at first. Now, my library is growing rapidly. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e209ce43-c017-4cdc-ae16-e5d50b78b071%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppet sub-folders
The answer is a qualified yes, since little chunks of functionality are going to be easier for you to maintain than a single large module. Later on you can look into hiera and other useful stuff. On Tue, Apr 29, 2014 at 12:13:56PM -0700, Jason Hatman wrote: I'm using modules right now. However, I have 90% of my manifests in one module. My site.pp is also very small. Should I break them up into different modules? I really haven't put much thought into that because I didn't have very many manifests at first. Now, my library is growing rapidly. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to [1]puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit [2]https://groups.google.com/d/msgid/puppet-users/e209ce43-c017-4cdc-ae16-e5d50b78b071%40googlegroups.com. For more options, visit [3]https://groups.google.com/d/optout. References Visible links 1. mailto:puppet-users+unsubscr...@googlegroups.com 2. https://groups.google.com/d/msgid/puppet-users/e209ce43-c017-4cdc-ae16-e5d50b78b071%40googlegroups.com?utm_medium=emailutm_source=footer 3. https://groups.google.com/d/optout -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20140429191821.GA7530%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Custom facts variables coming out empty on manifest
Hi all.
I have a very simple Custom Fact
in /etc/puppet/modules/facts/lib/facter/php_version.rb :
Facter.add(:php_version) do
setcode do
Facter::Util::Resolution.exec('php-config --version|awk -F . \'{print
$1$2}\'')
end
end
It gets deployed and if I run facter -p |grep php on the slave server
I get:
php_version = 54
Now, if I try to use the variable on my manifest like this:
file { /usr/local/lib/php.ini:
owner = root,
group = root,
mode = 0644,
source = puppet:///files/php${::php_version}.ini,
require = Exec['install_cpanel']
}
I always get on the slave log :
(/Stage[main]/Cpanel::Cpanel/File[/usr/local/lib/php.ini]) Could not
evaluate: Could not retrieve information from environment production
source(s) puppet:///files/php.ini
As it is obvious, it's not replacing the variable ${::php_version} as it
should return php54.ini and not php.ini .
What am I doing wrong here ?
Best regards,
--
Paulo
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/89d00ab1-018a-447f-a95f-3b804b25c85c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: puppet apply stops with message Killed
I managed to solve the problem :) First we added more memory to the
machine. With 1GB of memory the script ran further but still failed. In
this case it became apparent that it's doing something with file
permissions. It was setting group 70 (don't even know what kind of group
that is) to some scripts it was supposed to copy for execution. It was
doing this very slowly - tens of seconds for each file - and eating more
and more memory in the process, until it reached 1GB and the vserver killed
it.
The fix was very simple, but I'm still intrigued as to what went wrong,
especially since it was such a hard-to-debug issue. I changed this resource:
file { 'migration-scripts':
path = $scriptPath,
ensure = directory,
source = 'puppet:///modules/ks/migration',
recurse = true,
owner = 'root'
}
to this:
file { 'migration-scripts':
path = $scriptPath,
ensure = directory,
source = 'puppet:///modules/ks/migration',
recurse = true
}
If someone can give an explanation I would be very happy to read it. Also
because I only got 1GB of memory on the server temporarily and I'm
suspecting another similar problem in my manifest since with 512GB memory
the execution didn't get to the part where I now spotted the group
permission setting.
On Monday, April 21, 2014 12:01:24 PM UTC+2, Ádám Sándor wrote:
Hi,
I'm having a problem with my puppet script hanging for a while then dying
with the message Killed printed to the console. There is no further
explanation of what happened but I'm suspecting some event propagation
might get stuck and puppet may have some mechanism to kill the process if
it hangs for too long. That's just a guess though, so please let me know if
anyone has some insight on this problem. Thanks!
I'm running on Debian 7, Puppet 3.5.1.
Tail of the output of puppet apply --verbose --debug
--modulepath=/root/puppet/modules /root/puppet/ks-prod.pp is:
...
Notice: /Stage[main]/Ks::Database/Exec[create-blog-db]/returns: executed
successfully
Debug: /Stage[main]/Ks::Database/Exec[create-blog-db]: The container
Class[Ks::Database] will propagate my refresh event
Debug: Class[Ks::Database]: The container Stage[main] will propagate my
refresh event
Debug: Class[Ks::Database]: The container Class[Ks::Server] will propagate
my refresh event
Debug:
/Stage[main]/Apache::Mod::Autoindex/Apache::Mod[autoindex]/File[autoindex.load
symlink]/mode: Not managing symlink mode
Debug:
/Stage[main]/Apache::Mod::Autoindex/Apache::Mod[autoindex]/File[autoindex.conf
symlink]/mode: Not managing symlink mode
Debug: Exec[concat_/etc/apache2/ports.conf](provider=posix): Executing
check '/var/lib/puppet/concat/bin/concatfragments.sh -o
/var/lib/puppet/concat/_etc_apache2_ports.conf/fragments.concat.out -d
/var/lib/puppet/concat/_etc_apache2_ports.conf -t'
Debug: Executing '/var/lib/puppet/concat/bin/concatfragments.sh -o
/var/lib/puppet/concat/_etc_apache2_ports.conf/fragments.concat.out -d
/var/lib/puppet/concat/_etc_apache2_ports.conf -t'
Debug:
/Stage[main]/Apache::Mod::Prefork/Apache::Mpm[prefork]/File[/etc/apache2/mods-enabled/prefork.conf]/mode:
Not managing symlink mode
Debug: /Stage[main]/Apache::Mod::Php/Apache::Mod[php5]/File[php5.conf
symlink]/mode: Not managing symlink mode
Debug: Exec[own apache log directory](provider=posix): Executing 'chown -R
-f www-data:www-data /var/log/apache2'
Debug: Executing 'chown -R -f www-data:www-data /var/log/apache2'
Notice: /Stage[main]/Ks::Web/Exec[own apache log directory]/returns:
executed successfully
Debug: /Stage[main]/Ks::Web/Exec[own apache log directory]: The container
Class[Ks::Web] will propagate my refresh event
Debug: Class[Ks::Web]: The container Stage[main] will propagate my refresh
event
Debug: Class[Ks::Web]: The container Class[Ks::Server] will propagate my
refresh event
Debug: Class[Ks::Server]: The container Stage[main] will propagate my
refresh event
Killed
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/86de9efc-4c62-4eb6-856e-1a3916cb2beb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Error 400 on Server: 0 is not a string. It looks to be a Fixnum on node example.test.net
So I realized that I was running 3.4.2 when using puppet apply and 3.5.1 on puppetmaster. I am thinking that might have caused the problem? Is there anyway to download a previous release of puppet? Thanks On Monday, April 28, 2014 8:51:35 AM UTC-4, Ken Barber wrote: Can you paste the full error in a gist (with surrounding content as well) instead of just putting it in a subject line? If you can run the failing component with --debug so we can see more verbose output next to the error that might be also useful. If this error is being logged by your master, you should run the master using --no-daemonize and --debug perhaps. ken. On Mon, Apr 28, 2014 at 3:38 AM, Tony Zhao yut...@gmail.com javascript: wrote: This is the error I got running puppetlab's puppetdb module trying to setup puppetdb and postgresql. I was able to run it locally with puppet apply. I am running puppet 3.5.1 on both master and agent with hiera. Master is running Apache+Passenger. Has anyone encounter similar issue before and can provide some insights? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/461d498b-22d6-4b39-bc44-1e4d94a1e75b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fc0cef4a-fc13-48e3-a630-ea55bf9fb31b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppet sub-folders
Moreover you may create subdirectories, for example if you declare the class: namex::namey::namez The autolader would look for the manifest: $moduledir/namex/manifests/namey/namez.pp Regards, El 29/04/2014 21:18, Christopher Wood christopher_w...@pobox.com escribió: The answer is a qualified yes, since little chunks of functionality are going to be easier for you to maintain than a single large module. Later on you can look into hiera and other useful stuff. On Tue, Apr 29, 2014 at 12:13:56PM -0700, Jason Hatman wrote: I'm using modules right now. However, I have 90% of my manifests in one module. My site.pp is also very small. Should I break them up into different modules? I really haven't put much thought into that because I didn't have very many manifests at first. Now, my library is growing rapidly. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to [1]puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit [2] https://groups.google.com/d/msgid/puppet-users/e209ce43-c017-4cdc-ae16-e5d50b78b071%40googlegroups.com . For more options, visit [3]https://groups.google.com/d/optout. References Visible links 1. mailto:puppet-users+unsubscr...@googlegroups.com 2. https://groups.google.com/d/msgid/puppet-users/e209ce43-c017-4cdc-ae16-e5d50b78b071%40googlegroups.com?utm_medium=emailutm_source=footer 3. https://groups.google.com/d/optout -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20140429191821.GA7530%40iniquitous.heresiarch.ca . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAF_B3ddcSzv5rdX3uNAAWOuGE9qr%2Bo0FN47EK81N2%3DcGTf1NEQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Custom facts variables coming out empty on manifest
Hi,
Perhaps there is an environment diference between the command line and the
puppet agent process. The first one I think is the path one.
I would try to launch the php-config --version and the awk with the
full-path.
If that doesn't work, I would check if the php-config-version needs any
environment variable.
Regards,
El 29/04/2014 21:49, Paulo Pinto paulo.p.azev...@gmail.com escribió:
Hi all.
I have a very simple Custom Fact
in /etc/puppet/modules/facts/lib/facter/php_version.rb :
Facter.add(:php_version) do
setcode do
Facter::Util::Resolution.exec('php-config --version|awk -F .
\'{print $1$2}\'')
end
end
It gets deployed and if I run facter -p |grep php on the slave server
I get:
php_version = 54
Now, if I try to use the variable on my manifest like this:
file { /usr/local/lib/php.ini:
owner = root,
group = root,
mode = 0644,
source = puppet:///files/php${::php_version}.ini,
require = Exec['install_cpanel']
}
I always get on the slave log :
(/Stage[main]/Cpanel::Cpanel/File[/usr/local/lib/php.ini]) Could not
evaluate: Could not retrieve information from environment production
source(s) puppet:///files/php.ini
As it is obvious, it's not replacing the variable ${::php_version} as it
should return php54.ini and not php.ini .
What am I doing wrong here ?
Best regards,
--
Paulo
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/89d00ab1-018a-447f-a95f-3b804b25c85c%40googlegroups.comhttps://groups.google.com/d/msgid/puppet-users/89d00ab1-018a-447f-a95f-3b804b25c85c%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAF_B3dcp_dQHR%2Bqi7%3D_K7x5iSm8kCV3foqEE8PZZEzsYpTgDJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Custom facts variables coming out empty on manifest
Hello Jose.
That was spot on ! Changed the script using the full path to both binaries
did the trick:
Facter.add(:php_version) do
setcode do
Facter::Util::Resolution.exec('/usr/local/bin/php-config
--version|/bin/awk -F . \'{print $1$2}\'')
end
end
Thanks ! That made my day :-)
--
Paulo
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/9b48c83d-a829-4368-a174-9a6dc8b8df6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] PuppetDB / inventory service configuration problem
I'm having this issue as well. did we ever find an answer for this problem? On Monday, April 22, 2013 9:26:44 AM UTC-5, Ken Barber wrote: Lets take a look at the following files on your puppetmaster: /etc/puppet/puppet.conf /etc/puppet/puppetdb.conf /etc/puppet/routes.yaml /etc/puppet/auth.conf On the dashboard: /usr/share/puppet-dashboard/config/settings.yml (at least thats the normal path for our package on RHEL 6) And on your puppetdb server show me the contents of: /etc/puppetdb/conf.d/jetty.ini You can probably paste this into gist or pastie. Also you if you can provide the version of puppetdb puppetdb-terminus that might be useful. Usually I would recommend running version 1.2.0 of both puppetdb puppetdb-terminus and its important to try and keep the version in-sync for both packages. As far as your log: 2013-04-20 18:11:32,909 WARN [qtp1655388819-40] [io.nio] javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection? Does this occur at the same time as when you click the link inventory services link on Puppet Dashboard? ken. On Sat, Apr 20, 2013 at 6:15 PM, David Gordon dcgor...@gmail.comjavascript: wrote: Hi, I've just been configuring my new Puppet 3.1.1 / Dashboard setup with Passenger to use PuppetDB for the inventory service. I configured it via the puppetdb forge module, and it all seems to be configured correctly as far as the docs describe. When I look at a node in the dashboard, under the inventory section, I just see: Could not retrieve facts from inventory service: 404 Could not find facts myhost.domain.com I've quoted the log excerpts from puppetdb.log and masterhttp.log below. It sounds ssl-related, or that it's using http instead of https - but don't really know how to work out what's wrong. Anyone got any pointers for trying to debug this? Thanks, Dave --- /var/log/puppetdb/puppetdb log: 2013-04-20 18:11:32,909 WARN [qtp1655388819-40] [io.nio] javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection? 2013-04-20 18:11:55,089 WARN [qtp1655388819-39] [http.server] Use of unversioned APIs is deprecated; please use /v1/metrics/mbean/java.lang:type=Memory 2013-04-20 18:35:43,518 INFO [command-proc-45] [puppetdb.command] [db173bb5-a2ea-486e-8dd2-46abf737f975] [replace facts] puppetmaster.domain.com 2013-04-20 18:35:48,999 INFO [command-proc-45] [puppetdb.command] [b8cc3c17-7812-45f1-b833-452ff7bf9cf5] [replace catalog] puppetmaster.domain.com 2013-04-20 18:35:53,944 WARN [qtp1655388819-39] [http.server] Use of unversioned APIs is deprecated; please use /v1/metrics/mbean/java.lang:type=Memory /var/log/puppet/masterhttp.log [2013-04-20 18:54:52] puppetmaster.domain.com - - [20/Apr/2013:18:54:51 MEST] GET /production/facts/myhost.domain.com? HTTP/1.1 404 51 [2013-04-20 18:54:52] - - /production/facts/myhost.domain.com? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com javascript:. To post to this group, send email to puppet...@googlegroups.comjavascript:. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b57a6b74-3826-4f1d-a836-362a4570283e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Puppet and Windows ACLs (Access Control Lists)
What is most important to me is to have the ability to set ACLS on existing resources, such as file, service, and registry (and other objects). For now, it would be an immediate boon to apply the, oh so ugly, SDDL for a given resource, like a service. Later, we can have an SDDL builder, that has some comfortable readable language, ala subinacle styled ACEs, that builds the SDDL that will be applied to the attribute level. This can be similar to how ERB is used in the content(stuff). I think if you take this approach, you avoid gross complexity of trying to merge how Windows works and how Puppet works, and avoid feature-scope creep. It also gives the opportunity to add immediate value to existing puppet, and and more robust features later. If a particular resource that needs an ACL applied, such as certificate store or active directory OU, one needs to implement an actual resource for that type in PuppetForce. If you have ACL resource modifying various objects, it will get overly complex, and you are just re-implementing the wheel as far as existing resources already, and you are breaking the whole model. You'll be doing an anti-pattern for Puppet, and making a lot of future hurt, especially from the crowd that may bicker that Puppet should work like Windows... By having an attribute for the SDDL, one can manage resources in the scope of how puppet currently managers resources, rather than having two cross scopes from opposing models of maintaining resources. Also, if there is a utility function, like like ERB's content( ), then sys admins around the world will rejoice, as they no longer have to do nasties like this below: sc sdset SERVICE_NAME D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;RPWPCR;;;S-1-5-21-2103278432-2794320136-1883075150-1000)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD) cacl c:\tools /s D:PAI(D;OICI;FA;;;BG)(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;FA;;;BU) setprinter \\”Print_Server_Name”\printer1 3 pSecurityDescriptor=O:BAG:DUD:(A;;LCSWSDRCWDWO;;;BA)(A;OIIO;RPWPSDRCWDWO;;;BA)(A;;SWRC;;;S-1-5-21-329599412-2737779004-1408050790-2604)(A;CIIO;RC;;;CO)(A;OIIO;RPWPSDRCWDWO;;;CO)(A;CIIO;RC;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;OIIO;RPWPSDRCWDWO;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;;SWRC;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;;LCSWSDRCWDWO;;;PU)(A;OIIO;RPWPSDRCWDWO;;;PU) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/aa39f4f3-a1aa-405f-8307-3c4f08fba2de%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] DMZ Hosts/SSH Tunneling
I read the presentation at http://stroessenreuther.info/pub/Puppet_getting_started.pdf, which was very insightful. With regard to using puppet in the DMZ and resources (slides 31-32), instead of the complication of a custom ruby script and modifications to all the modules I have, I opted to instead list puppet as a name for the loopback interface in /etc/hosts for node that hosts a puppet agent in that (and other) sections of my network. Does anyone see any issues with the hosts approach? The implementation seems to be much simpler and achieves the same thing. The advantages look to be many, but I want to make sure I am not missing something. Thanks, Axton Grams -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAJeeBBwMExAfQL1U1MJNiq9Bv2g2bNqwPdPU%3Ddoz2nxAtndmWg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] DMZ Hosts/SSH Tunneling
I have not experience with puppet in the DMZ, but it seems a better solution without any doubt. Regards, El 30/04/2014 06:08, Axton axton.gr...@gmail.com escribió: I read the presentation at http://stroessenreuther.info/pub/Puppet_getting_started.pdf, which was very insightful. With regard to using puppet in the DMZ and resources (slides 31-32), instead of the complication of a custom ruby script and modifications to all the modules I have, I opted to instead list puppet as a name for the loopback interface in /etc/hosts for node that hosts a puppet agent in that (and other) sections of my network. Does anyone see any issues with the hosts approach? The implementation seems to be much simpler and achieves the same thing. The advantages look to be many, but I want to make sure I am not missing something. Thanks, Axton Grams -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAJeeBBwMExAfQL1U1MJNiq9Bv2g2bNqwPdPU%3Ddoz2nxAtndmWg%40mail.gmail.comhttps://groups.google.com/d/msgid/puppet-users/CAJeeBBwMExAfQL1U1MJNiq9Bv2g2bNqwPdPU%3Ddoz2nxAtndmWg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAF_B3dedwp6sDcnCPoH24Rc8cSh%3DemrJu15otAQ%2BpdyL3KL75w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
