[Puppet Users] Custom provider woes and questions
This email has two parts: First part Looking at "Sh*t Gary Says" seems to imply I may be going about creating custom types/providers. I am currently creating a type under lib/puppet/type/{typename}.rb without that logic doing anything with the actual logic being in lib/puppet/provider/{typename}/ruby.rb which has worked fine for me in the past. Someone confirm/deny. Second part I've created a pair of custom types/providers, one to set parameters and the other to set state. The issue I'm running into is the state provider is trying to work and the parameter provider doesn't even seem to be loading in Puppet at all without any sort of error showing up. Here is how they are being invoked in a manifest: myparmtype { 'instance': parm1=>'value1', parm2=>'value2' } -> mystatetype{'instance': state =>'mystate' } Sorry for the obfuscation, but what I'm working on is largely company proprietary. Thoughts anybody? Is there a limit to the number of types/providers a module can have? -- 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/CAArvnv022R2jX5TOdLX1MnqEyfdK8Ep51hWP%3D%2Bhqd1cLN-XaMA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Puppet Exec resource with complex Environment Variables...
On Friday, December 4, 2015 at 10:27:52 AM UTC-6, Sean wrote: > > Greetings, > > I am working on streamlining some older puppet code, that uses a lot of > Exec resources to accomplish it's purposes. It's not terribly elegant and > we're working on design to replace it with code that leverages puppet > features. One of the pieces I'm struggling with is how to set complex > environment variables that are available to use in onlyif/unless statements > as well as the command itself. I'm wondering if this just isn't possible? > > Here's an example with the aide. NOTE that we're not in a spot where I > can make puppet manage the aide config file, and thus use an aide module > and parameters instead of shell variables. All of these commands run > successfully in a bash shell for the various conditions that would apply. > I have other similar scenarios, but aide is one of the more complex ones. > > exec { 'init-aide-database': > path=> > '/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin', > environment => [ 'DBDIR=$(egrep \'^@@define DBDIR \' > /etc/aide.conf|awk \'{print $NF}\')', > 'DBFILE=$(egrep \'^database=file\' /etc/aide.conf|awk -F/ \'{print > $NF}\')', > 'DBNEW=$(egrep \'^database_out=file\' /etc/aide.conf|awk -F/ > \'{print $NF}\')', > ], > command => '/usr/sbin/aide --init >/dev/null 2>&1 && cp -p > ${DBDIR}/${DBNEW} ${DBDIR}/${DBFILE}', > unless => 'test -f ${DBDIR}/${DBNEW} && test -f > ${DBDIR}/${DBFILE}', > require => Package['aide'], > logoutput => true, > timeout => 0, > } > > When executing, puppet always runs the exec because the env var's are > empty, so the unless case always fails. Then we get a scenario where we're > running aide --init when it's not needed and the cp command throws an error > due to empty variables. > > Are you sure? I'd be inclined to suppose that the problem was that the environment variables don't have the values you expect them to have. As far as I am aware, Puppet inserts environment variables into child processes' environments via a mechanism that does not involve evaluating the value expressions via the shell (even when you use the 'shell' provider). I had thought that the same environment is presented to the 'unless' and 'onlyif' commands as is presented to the main command, but I can't immediately back that up, as the documentation is at best unclear on that point. If you could establish that it is not, then that might justify filing a ticket. > My thought at the moment is that I need to build two shell scripts as file > resources. One to call in the unless test, and another to call in the > command if the unless script fails. Perhaps that's more elegant, but we're > hoping to avoid delivering script files to the nodes wherever possible. > I'm hoping the gurus out here might point me in the best direction! > If you must determine the needed values for your environment variables at run time, by executing shell code, then I'm pretty confident that one way or another you will need to build that in to each of the commands you use. The approach you describe is a reasonable way to do that. You could also consider whether it would be worth the effort to build a full-fledged custom type. You would still need to perform some environment mangling, but you could at least avoid managing separate command scripts. 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/4cb89384-3113-4b11-ae48-a09281abc0b7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Puppetmaster compiles old catalogs
On Sunday, December 6, 2015 at 8:27:21 AM UTC-6, César wrote: > > Hi all, > > we're seeing every now and then an odd behaviour with Puppet catalog > compilation. Basically, we modify and save the node manifests and a few > seconds later we trigger a catalog run to apply the changes. > However, what we see is that sometimes the Puppet master compiles the old > version of the node manifest, leaving changes behind and requiring two > catalog runs to apply all of them. > > A sample site.pp would look like this: > > > import "/path/to/manifests/plugins/ms1.pp" > > import "/path/to/manifests/plugins/n1.pp" > > import "/path/to/manifests/plugins/n2.pp" > > node default {} > > > I would like to know if using import might be causing this? (We use Puppet > 3.3.2) > If that's not the case, do you have any hints or tips to troubleshoot the > issue? How does the Puppetmaster handle the compilation of the node > manifest? We tried to use the configuration option to avoid caching, but so > far that didn't fix it. > > Are you sure the master is running Puppet 3.3? What you're describing sounds like an effect of new-style environment caching, but I don't think that was implemented yet in Puppet 3.3. (The Puppet version on the agents doesn't matter for this purpose.) 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/b30626d2-8c22-4505-92e9-995ade55779a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Puppet 4: default value of a parameter in a module and dependency
On Friday, December 4, 2015 at 7:23:44 PM UTC-6, François Lafont wrote: > Yes, you are absolutely right and your explanations show me that I was not > precise enough when I have described my question. Sorry for that. I will > try to fix it. > > 1. My question was in fact only about _public_ classes of my modules. > > 2. These classes are _always_ called via "require" or "include", never > with parameters. (The only case where I can call sometimes classes with > parameters is when a class in a module calls another private class of > the same module.) > > So I fact my question is, for a node, the ENC will trigger this puppet > code: > > # Only "include" or "require". > include moda > include modb > include modc::fooc > include modc::barc > include modd::food > include modd::bard > include mode > etc... > > and I would like to have the default value of ::modb::param equal to > the value of the parameter ::moda::param. And I think it's possible (if > 1. and 2. are satisfied) with this code in > ./modules/modc/functions/data.pp: > > function modb::data { > > # We assume that the type expected here is a non-empty string. > $param = lookup('moda::param', String[1], 'first') > > # code... > > { > ... > modb::param => $param, > ... > } > > } > > And mabe (but I'm not completely sure on this point), it could be a good > idea to put in ./modules/modb/metadata.json a dependency ("modb depends on > moda"). But I have lot of doubts on this point...? > > John, are we agreed in these conditions? > I'm not sure where my agreement factors in. Your conditions are whatever they are, or at most what I can persuade you they should be. I still maintain that you are contemplating an inappropriately tight coupling between your modules. You likely can come up with a list of restrictions sufficient to ensure that there is a method to determine what value a parameter of class ::moda *would* take in the event that that class were declared, other than actually declaring the class and checking what value it actually *did* take. You have not yet stipulated enough conditions for that, however: you would at least need to account also for the possibility of the value depending on Hiera interpolation tokens that in turn depend on the 'calling' class or module. > > If you conceive a module to be in a position to control or even to know > > whether and how a class from a different module is declared, then that's > a > > strong signal that you should combine or refactor your modules. If you > > think one module has need for direct access to in-module data of a > > different module, then that is also a signal that you should combine or > > refactor. > > And in the conditions which I have described above, do you still think > that > a refactor is needed? > > I think the specific conditions are irrelevant to the main thrust of my position. The fact that your code and data would need to comply with a relatively complex set of conditions for what you propose to be workable at all is one of my primary arguments. I predict that taking on such a set of extra requirements will cause you grief, more likely sooner than later, and I urge you to devise another way to accomplish your objective. If you insist on proceeding in this general direction, however, then I'd suggest employing a variation on the Params Class pattern. Create a class ::moda::params and give it a parameter or ordinary class variable $::moda::params::param that will serve both as the (definite) initialization value for $::moda::param and as the default value for $::modb::param. This will require that $::moda::param be made an ordinary class variable instead of a class parameter, so that it can never take a value different from $::moda::params::param. It will also require that class ::modb inherit directly or indirectly from class ::moda::params. In Puppet 4, $::moda::params::param can receive its value in any way you see fit, including automated data binding (if you opt to make $::moda::params::param a class parameter), but you would create an evaluation-order dependency if every you used a resource-like declaration of it, either directly or via an ENC. Class ::moda::params would avoid declaring any resources so that declaring it (as classes ::moda and ::modb would both need to ensure happens) will not directly affect the target node's state. If you're following closely you will observe that that solves the problem by adding a layer of indirection. You may also recognize that class inheritance across module boundaries is considered poor practice by many; this should be taken as further support for my argument that your proposed modules are too tightly coupled. > According to me, 2 modules moda modb can be independent but sometimes it > can > be relevant (and handy) that the default value of modb::param is equal to > the value of moda::param, no? For
Re: [Puppet Users] Puppet Enterprise Installation Error on CentOS7
Hi Nikhil, please paste the log file (/var/opt/puppetlabs/puppetserver/puppetserver.log) into gist (not a screenshot). http://gist.github.com/ I assume that the error is at the end of the file. Did you run the journalctl -xn command (like mentioned in the output)? The error log snippet you have pasted indicates, that you can not reach official cents mirrors. Has your VM access to the internet? Can you run ‘yum update’ successfully on the machine? Best, Martin On 06 Dec 2015, at 00:27, Nikhil Raowrote: > > > On Saturday, 5 December 2015 11:58:58 UTC-5, Nikhil Rao wrote: > I tried to install puppet enterprise from puppet master and while selecting > monolithic installation and setting upto 500 nodes and setting up the DNS > name and the alias name and encountered an error WARNING 1: set 2 CPU cores > instead of 4 CPU cores WARNING 2: set at-least 100GB space in /Opt folder. > And i ended up in the following error "Error: Could not start > Service[pe-puppetserver]: Execution of '/bin/systemctl start pe-puppetserver' > returned 1: Job for pe-puppetserver.service failed. See 'systemctl status > pe-puppetserver.service' and 'journalctl -xn' for details. Error: > /Stage[main]/Puppetenterprise::Master::Puppetserver/Service[pe-puppetserver]/ensure: > change from stopped to running failed: Could not start > Service[pe-puppetserver]: Execution of '/bin/systemctl start pe-puppetserver' > returned 1: Job for pe-puppetserver.service failed. See 'systemctl status > pe-puppetserver.service' and 'journalctl -xn' for details." > What should i change in my vmware settings Please advice > > > > > > > > > > > > I have posted the log file and the error is as follows . But couldnt decode > what the exact error is ... Please can you advice on what the issue is > exactly and i have changed the Cores and it didnt throw a warning. But still > stuck at pe-puppetserver > > > > -- > 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/649da43e-a615-41b6-bd35-bdf4e18d18f1%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/E08A92A8-4FF8-4760-94D7-BCC4553CE810%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Custom provider woes and questions
Nevermind... figured out what was going on.. and fixed that problem and now a more bugs to squash... How do I raise a failed exception in a provider (this before I start googleing) :-) On Mon, Dec 7, 2015 at 9:53 AM Peter Bergholdwrote: > This email has two parts: > > First part > > Looking at "Sh*t Gary Says" seems to imply I may be going about creating > custom types/providers. I am currently creating a type under > lib/puppet/type/{typename}.rb without that logic doing anything with the > actual logic being in lib/puppet/provider/{typename}/ruby.rb which has > worked fine for me in the past. > > Someone confirm/deny. > > Second part > > I've created a pair of custom types/providers, one to set parameters and > the other to set state. The issue I'm running into is the state provider > is trying to work and the parameter provider doesn't even seem to be > loading in Puppet at all without any sort of error showing up. > > Here is how they are being invoked in a manifest: > > myparmtype { 'instance': > parm1=>'value1', > parm2=>'value2' > } > -> > mystatetype{'instance': >state =>'mystate' > } > > Sorry for the obfuscation, but what I'm working on is largely company > proprietary. > > Thoughts anybody? > > Is there a limit to the number of types/providers a module can have? > > -- 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/CAArvnv20aBVzYQyU5ifFJQcuVQPEaCp63VntLMMXBBmP9%3D5SRw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Puppet Exec resource with complex Environment Variables...
John, Thanks for the reply. To answer your first question, no I'm not completely sure. What I can say is that I can run the commands in a shell by hand and the result is what I hope for. When I run puppet, with this particular class included, puppet hangs for a while with no screen output. This leads me to believe that the "unless" fails and the "command" executes. I can verify that by running (in another shell): [root@desktop ~]# ps -ef|grep aide root 28085 1 0 14:42 ?00:00:00 sh -c /usr/sbin/aide --init >/dev/null 2>&1 && cp -p ${DBDIR}/${DBNEW} ${DBDIR}/${DBFILE} root 28088 28085 20 14:42 ?00:01:24 /usr/sbin/aide --init I can say when I run the various piece by hand inside an interactive shell everything comes out as expected: [root@desktop ~]# DBDIR=$(egrep '^@@define DBDIR ' /etc/aide.conf |awk '{print $NF}') [root@desktop ~]# echo $DBDIR /var/lib/aide [root@desktop ~]# DBFILE=$(egrep '^database=file' /etc/aide.conf |awk -F/ '{print $NF}') [root@desktop ~]# echo $DBFILE aide.db.gz [root@desktop ~]# DBNEW=$(egrep '^database_out=file' /etc/aide.conf |awk -F/ '{print $NF}') [root@desktop ~]# echo $DBNEW aide.db.new.gz [root@desktop ~]# test -f ${DBDIR}/${DBNEW} && test -f ${DBDIR}/${DBFILE} [root@desktop ~]# echo $? 0 [root@desktop ~]# /usr/sbin/aide --init >/dev/null 2>&1 && cp -p ${DBDIR}/${DBNEW} ${DBDIR}/${DBFILE} cp: overwrite ‘/var/lib/aide/aide.db.gz’? y The cp overwrite prompt above comes from the alias cp='cp -i ' in my shell. I'm not sure if that would be there inside puppet, but if so I'll modify to negate that option. For testing, I created a separate class for just this one exec. I modified the unless and command statements as follows: command => 'echo "/usr/sbin/aide --init >/dev/null 2>&1 && cp -p ${DBDIR}/${DBNEW} ${DBDIR}/${DBFILE}"', unless => 'echo "test -f ${DBDIR}/${DBNEW} && test -f ${DBDIR}/${DBFILE}" && test -f ${DBDIR}/${DBNEW} && test -f ${DBDIR}/${DBFILE}', So basically the "unless" echo's what it's doing, then tries to do it. The "command" just echoes what it would do. Here's the puppet agent --test --debug output for the class: Debug: Exec[init-aide-database](provider=posix): Executing check 'echo "test -f ${DBDIR}/${DBNEW} && test -f ${DBDIR}/${DBFILE}" && test -f ${DBDIR}/${DBNEW} && test -f ${DBDIR}/${DBFILE}' Debug: Executing 'echo "test -f ${DBDIR}/${DBNEW} && test -f ${DBDIR}/${DBFILE}" && test -f ${DBDIR}/${DBNEW} && test -f ${DBDIR}/${DBFILE}' Debug: /Stage[main]/Testenv/Exec[init-aide-database]/unless: test -f $(egrep '^@@define DBDIR ' /etc/aide.conf|awk '{print $NF}')/$(egrep '^database_out=file' /etc/aide.conf|awk -F/ '{print $NF}') && test -f $(egrep '^@@define DBDIR ' /etc/aide.conf|awk '{print $NF}')/$(egrep '^database=file' /etc/aide.conf|awk -F/ '{print $NF}') Debug: /Stage[main]/Testenv/Exec[init-aide-database]/unless: sh: line 0: test: too many arguments Debug: Exec[init-aide-database](provider=posix): Executing 'echo "/usr/sbin/aide --init >/dev/null 2>&1 && cp -p ${DBDIR}/${DBNEW} ${DBDIR}/${DBFILE}"' Debug: Executing 'echo "/usr/sbin/aide --init >/dev/null 2>&1 && cp -p ${DBDIR}/${DBNEW} ${DBDIR}/${DBFILE}"' Notice: /Stage[main]/Testenv/Exec[init-aide-database]/returns: /usr/sbin/aide --init >/dev/null 2>&1 && cp -p $(egrep '^@@define DBDIR ' /etc/aide.conf|awk '{print $NF}')/$(egrep '^database_out=file' /etc/aide.conf|awk -F/ '{print $NF}') $(egrep '^@@define DBDIR ' /etc/aide.conf|awk '{print $NF}')/$(egrep '^database=file' /etc/aide.conf|awk -F/ '{print $NF}') Notice: /Stage[main]/Testenv/Exec[init-aide-database]/returns: executed successfully Debug: /Stage[main]/Testenv/Exec[init-aide-database]: The container Class[ Testenv] will propagate my refresh event Debug: Class[Testenv]: The container Stage[main] will propagate my refresh event So it looks like the strings inside the environment variables aren't interpreted by the shell, they're just passed as literal strings. But notably, the the unless test fails with an error from /usr/bin/test that doesn't surface when running interactively. I will attempt to run in the shell provider instead of posix, but if that fails, I just re-code everything into shell scripts and have puppet push and execute them. If we need to make this a bug, I'll be happy to help, but I'm running on EL7 with puppet out of EPEL7, with no intent of going to Puppet 4 anytime soon. Thanks again for taking a look! On Monday, December 7, 2015 at 11:37:19 AM UTC-5, jcbollinger wrote: > > > > On Friday, December 4, 2015 at 10:27:52 AM UTC-6, Sean wrote: >> >> Greetings, >> >> I am working on streamlining some older puppet code, that uses a lot of >> Exec resources to accomplish it's purposes. It's not terribly elegant and >> we're working on design to replace it with code that leverages puppet >> features. One of the pieces I'm struggling with is how to set complex >> environment variables that are available to use in
[Puppet Users] Best way to do cross-module dependencies
Hey all, Everything I've done thusfar in creating my own custom modules has drilled some basics into my head -- these are right from the puppet web docs: "A module’s classes, defined types, and plugins *should all be related,* and the module should aim to be *as self-contained as possible.* Manifests in one module should never reference files or templates stored in another module." I've also seen it preached hard that modules should attempt in all cases to be "portable". So, with that said -- how is the best way to declare dependencies across modules? For example, I have a one-file-per-rule firewall stack, where rules are placed in /etc/firewall.d, and loaded using a standardized ordering script -- this way my "httpd" module can add (and own) an "httpd" firewall rule. How would I tell my web module that if that firewall type is in play, that it should add a file there, and reload the firewall? How do I get the web module to only do this *if* that firewall type is in play, without directly *requiring* it? I have a similar thing for syslog, where I can populate a directory and have individual packages own files in there. Same question. I also have a similar thing for logfile rotation. Same question. I don't want to build huge metaclasses all in site.pp -- nor does it seem sane to me to build meta-modules that do all the combining, although those *are* both ways forward. Thanks, -Dan -- 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/6e51be82-b270-4cb8-bf31-90e39eedd9cc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Hiera 3.X subkeys lookup
With the addition of subkeys lookup, e.g. hiera('a.b.c'), those yaml configuration files already including top level keys with a "." in the key name are rendered invalid. Is there a way to disable subkey lookup support on demand for a given backend? thanks, adrian -- 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/6d1807d9-ab03-4ae0-ab77-ca7dd864f4cc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] In puppet 3.8.3, classes are defined twice in catalog
In the module, the classes are designed like this: A::install{} class A{ A::install{} } class A::B{ A::B::install{ require -> Class[A] } } class A::C{ A::C::install{ require -> Class[A] } } The result of puppet master compile is: "classes": [ "A", "A::B", "A::C", "A::install", "A", "A::B", "A::C" ] Then the "require" function doesn't take effect. And I must change it to "require -> Class[A::install]. But in puppet 2.7.2, it looks ok. -- 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/af2d6154-bb11-4800-88c2-ff502382a675%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.