anyone using Puppet for configuration management?
Federico Voges
ftc at ftc.com.ar
Thu Sep 5 11:17:40 PDT 2013
You don't have to include them there.
Puppet auto loads the modules. Let's say you have your ntp module in
whatever your modules dir is named (usually would be
/etc/puppet/modules/ntp/*).
In your default node definition, you do something like this:
node default {
class { 'ntp' }
}
The includes in site.pp are useful for when you have a lot of node
definitions. Using inclide, you can split them into multiple files so
it's easier to maintain (e.g., include webservers/*)
If you want better control over individual node configuration, then
look into using parameterized classes and hiera. At my previous job, I
used them to be able to override defaults in multiple layers:
host
role
domain
global
On 5 September 2013 18:00, Lonni J Friedman <netllama at gmail.com> wrote:
> *sigh* you're right. This is annoying behavior. This implies that
> installing any modules means that they are going to apply to every
> node.
>
> I googled for how to exclude a module from a node, and most of the
> suggestions were rather hacky:
> https://groups.google.com/forum/#!topic/puppet-users/a1muJHCs-hQ
>
> I tried to follow that one, by creating a new class which explicitly
> disables ntp, but then I was seeing duplicate service (ntp)
> declaration errors. feh.
>
> On Thu, Sep 5, 2013 at 9:09 AM, Federico Voges <ftc at ftc.com.ar> wrote:
>> This seems to say that it does get applied to all nodes:
>> http://docs.puppetlabs.com/puppet/2.7/reference/lang_import.html
>>
>> On 5 September 2013 16:36, Lonni J Friedman <netllama at gmail.com> wrote:
>>> in services/* I've got:
>>> download_files.pp hello.pp ntp.pp pkg.pp tester.pp
>>>
>>> The only place that ntp is referenced is ntp.pp which i'm not even
>>> including any longer in site.pp. So unless the import implicitly
>>> includes everything (and it doesn't seem like, since none of the
>>> others are enabled globally by default), I don't think that's the
>>> issue.
>>>
>>> On Thu, Sep 5, 2013 at 8:30 AM, Federico Voges <ftc at ftc.com.ar> wrote:
>>>> What are you adding in "import "services/*""? It looks like you're
>>>> installing, at least, snmp and apache. So heres the silly question:
>>>> are you sure that you're not including ntp somewhere in there too?
>>>>
>>>> Fed.
>>>>
>>>> On 5 September 2013 16:15, Lonni J Friedman <netllama at gmail.com> wrote:
>>>>> I'm using 2.7.x. There's nothing obvious to me in the logs. If I run
>>>>> with --debug, I see:
>>>>> #########
>>>>> debug: Failed to load library 'rubygems' for feature 'rubygems'
>>>>> debug: Puppet::Type::User::ProviderDirectoryservice: file
>>>>> /usr/bin/dscl does not exist
>>>>> debug: Puppet::Type::User::ProviderUser_role_add: file roledel does not exist
>>>>> debug: Puppet::Type::User::ProviderLdap: true value when expecting false
>>>>> debug: Puppet::Type::User::ProviderPw: file pw does not exist
>>>>> debug: Puppet::Type::File::ProviderMicrosoft_windows: feature
>>>>> microsoft_windows is missing
>>>>> debug: Failed to load library 'ldap' for feature 'ldap'
>>>>> debug: /File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring
>>>>> File[/var/lib/puppet/ssl/certs]
>>>>> debug: /File[/var/lib/puppet/ssl/public_keys]: Autorequiring
>>>>> File[/var/lib/puppet/ssl]
>>>>> debug: /File[/var/lib/puppet/ssl/crl.pem]: Autorequiring
>>>>> File[/var/lib/puppet/ssl]
>>>>> debug: /File[/var/lib/puppet/ssl/certs/cuda-linux32-cvs4.pem]:
>>>>> Autorequiring File[/var/lib/puppet/ssl/certs]
>>>>> debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
>>>>> debug: /File[/var/run/puppet/agent.pid]: Autorequiring File[/var/run/puppet]
>>>>> debug: /File[/var/lib/puppet/clientbucket]: Autorequiring File[/var/lib/puppet]
>>>>> debug: /File[/var/lib/puppet/state/state.yaml]: Autorequiring
>>>>> File[/var/lib/puppet/state]
>>>>> debug: /File[/var/lib/puppet/ssl/certificate_requests]: Autorequiring
>>>>> File[/var/lib/puppet/ssl]
>>>>> debug: /File[/var/lib/puppet/client_data]: Autorequiring File[/var/lib/puppet]
>>>>> debug: /File[/var/lib/puppet/ssl/private]: Autorequiring
>>>>> File[/var/lib/puppet/ssl]
>>>>> debug: /File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet]
>>>>> debug: /File[/var/lib/puppet/client_yaml]: Autorequiring File[/var/lib/puppet]
>>>>> debug: /File[/var/lib/puppet/state/last_run_summary.yaml]:
>>>>> Autorequiring File[/var/lib/puppet/state]
>>>>> debug: /File[/etc/puppet/puppet.conf]: Autorequiring File[/etc/puppet]
>>>>> debug: /File[/var/lib/puppet/classes.txt]: Autorequiring File[/var/lib/puppet]
>>>>> debug: /File[/var/lib/puppet/ssl/certs]: Autorequiring File[/var/lib/puppet/ssl]
>>>>> debug: /File[/var/lib/puppet/state/graphs]: Autorequiring
>>>>> File[/var/lib/puppet/state]
>>>>> debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/puppet]
>>>>> debug: /File[/var/lib/puppet/ssl/private_keys/cuda-linux32-cvs4.pem]:
>>>>> Autorequiring File[/var/lib/puppet/ssl/private_keys]
>>>>> debug: /File[/var/lib/puppet/ssl/public_keys/cuda-linux32-cvs4.pem]:
>>>>> Autorequiring File[/var/lib/puppet/ssl/public_keys]
>>>>> debug: /File[/var/lib/puppet/ssl/private_keys]: Autorequiring
>>>>> File[/var/lib/puppet/ssl]
>>>>> debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/puppet]
>>>>> debug: Finishing transaction 70066376334960
>>>>> debug: /File[/var/lib/puppet/ssl/crl.pem]: Autorequiring
>>>>> File[/var/lib/puppet/ssl]
>>>>> debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/puppet]
>>>>> debug: /File[/var/lib/puppet/ssl/public_keys/cuda-linux32-cvs4.pem]:
>>>>> Autorequiring File[/var/lib/puppet/ssl/public_keys]
>>>>> debug: /File[/var/lib/puppet/ssl/public_keys]: Autorequiring
>>>>> File[/var/lib/puppet/ssl]
>>>>> debug: /File[/var/lib/puppet/ssl/certs/cuda-linux32-cvs4.pem]:
>>>>> Autorequiring File[/var/lib/puppet/ssl/certs]
>>>>> debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
>>>>> debug: /File[/var/lib/puppet/ssl/private]: Autorequiring
>>>>> File[/var/lib/puppet/ssl]
>>>>> debug: /File[/var/lib/puppet/ssl/private_keys]: Autorequiring
>>>>> File[/var/lib/puppet/ssl]
>>>>> debug: /File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet]
>>>>> debug: /File[/var/lib/puppet/ssl/certificate_requests]: Autorequiring
>>>>> File[/var/lib/puppet/ssl]
>>>>> debug: /File[/var/lib/puppet/ssl/private_keys/cuda-linux32-cvs4.pem]:
>>>>> Autorequiring File[/var/lib/puppet/ssl/private_keys]
>>>>> debug: /File[/var/lib/puppet/ssl/certs]: Autorequiring File[/var/lib/puppet/ssl]
>>>>> debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/puppet]
>>>>> debug: /File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring
>>>>> File[/var/lib/puppet/ssl/certs]
>>>>> debug: Finishing transaction 70066375305440
>>>>> debug: Using cached certificate for ca
>>>>> debug: Using cached certificate for cuda-linux32-cvs4
>>>>> debug: Finishing transaction 70066374874040
>>>>> debug: Loaded state in 0.00 seconds
>>>>> debug: Using cached certificate for ca
>>>>> debug: Using cached certificate for cuda-linux32-cvs4
>>>>> debug: Using cached certificate_revocation_list for ca
>>>>> debug: catalog supports formats: b64_zlib_yaml dot pson raw yaml; using pson
>>>>> debug: Puppet::Type::Package::ProviderRpm: Executing '/bin/rpm --version'
>>>>> debug: Puppet::Type::Package::ProviderUrpmi: Executing '/bin/rpm -ql rpm'
>>>>> debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm --version'
>>>>> debug: Puppet::Type::Package::ProviderAptrpm: Executing '/bin/rpm -ql rpm'
>>>>> info: Caching catalog for cuda-linux32-cvs4
>>>>> debug: Puppet::Type::Package::ProviderHpux: file /usr/sbin/swlist does not exist
>>>>> debug: Puppet::Type::Package::ProviderPorts: file
>>>>> /usr/local/sbin/portupgrade does not exist
>>>>> debug: Puppet::Type::Package::ProviderAix: file /usr/bin/lslpp does not exist
>>>>> debug: Puppet::Type::Package::ProviderPortupgrade: file
>>>>> /usr/local/sbin/portinstall does not exist
>>>>> debug: Puppet::Type::Package::ProviderFink: file /sw/bin/fink does not exist
>>>>> debug: Puppet::Type::Package::ProviderUrpmi: file urpmi does not exist
>>>>> debug: Puppet::Type::Package::ProviderPortage: file
>>>>> /usr/bin/eix-update does not exist
>>>>> debug: Puppet::Type::Package::ProviderAptitude: file /usr/bin/aptitude
>>>>> does not exist
>>>>> debug: Puppet::Type::Package::ProviderSunfreeware: file pkg-get does not exist
>>>>> debug: Puppet::Type::Package::ProviderDpkg: file /usr/bin/dpkg does not exist
>>>>> debug: Puppet::Type::Package::ProviderPkg: file /usr/bin/pkg does not exist
>>>>> debug: Puppet::Type::Package::ProviderUp2date: file
>>>>> /usr/sbin/up2date-nox does not exist
>>>>> debug: Puppet::Type::Package::ProviderApt: file /usr/bin/apt-get does not exist
>>>>> debug: Puppet::Type::Package::ProviderZypper: file /usr/bin/zypper
>>>>> does not exist
>>>>> debug: Puppet::Type::Package::ProviderGem: file gem does not exist
>>>>> debug: Puppet::Type::Package::ProviderNim: file /usr/sbin/nimclient
>>>>> does not exist
>>>>> debug: Puppet::Type::Package::ProviderRug: file /usr/bin/rug does not exist
>>>>> debug: Puppet::Type::Package::ProviderAptrpm: file apt-get does not exist
>>>>> debug: Puppet::Type::Package::ProviderSun: file /usr/sbin/pkgrm does not exist
>>>>> debug: Puppet::Type::Package::ProviderFreebsd: file /usr/sbin/pkg_info
>>>>> does not exist
>>>>> debug: Puppet::Type::Package::ProviderOpenbsd: file pkg_info does not exist
>>>>> debug: Puppet::Type::Service::ProviderDebian: file
>>>>> /usr/sbin/update-rc.d does not exist
>>>>> debug: Puppet::Type::Service::ProviderLaunchd: file /bin/launchctl
>>>>> does not exist
>>>>> debug: Puppet::Type::Service::ProviderRunit: file /usr/bin/sv does not exist
>>>>> debug: Puppet::Type::Service::ProviderGentoo: file /sbin/rc-update
>>>>> does not exist
>>>>> debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svc
>>>>> does not exist
>>>>> debug: Creating default schedules
>>>>> debug: Loaded state in 0.00 seconds
>>>>> debug: Prefetching yum resources for package
>>>>> debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm --version'
>>>>> debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm -qa
>>>>> --nosignature --nodigest --qf '%{NAME} %|EPOCH?{%{EPOCH}}:{0}|
>>>>> %{VERSION} %{RELEASE} %{ARCH}
>>>>> ''
>>>>> debug: /Stage[main]/Setup_snmp/Service[snmpd]/require: requires
>>>>> Package[net-snmp]
>>>>> debug: /Stage[main]/Ntp::Config/notify: subscribes to Class[Ntp::Service]
>>>>> debug: /Stage[main]/Ntp::Install/before: requires Class[Ntp::Config]
>>>>> debug: /Stage[main]/Ntp/Anchor[ntp::begin]/before: requires Class[Ntp::Install]
>>>>> debug: /Stage[main]/Setup_httpd/Exec[/usr/bin/wget -q
>>>>> http://cuda-fs1/cuda/httpd.conf-rhel6 -O
>>>>> /etc/httpd/conf/httpd.conf]/require: requires Package[wget]
>>>>> debug: /Stage[main]/Setup_httpd/Exec[/usr/bin/wget -q
>>>>> http://cuda-fs1/cuda/httpd.conf-rhel6 -O
>>>>> /etc/httpd/conf/httpd.conf]/require: requires Package[httpd]
>>>>> debug: /Stage[main]/Setup_httpd/Service[httpd]/require: requires Package[httpd]
>>>>> debug: /Stage[main]/Ntp::Service/before: requires Anchor[ntp::end]
>>>>> debug: /Stage[main]/Setup_snmp/Exec[/usr/bin/wget -q
>>>>> http://cuda-fs1/cuda/snmpd.conf-rhel5 -O
>>>>> /etc/snmp/snmpd.conf]/require: requires Package[wget]
>>>>> debug: /Stage[main]/Setup_snmp/Exec[/usr/bin/wget -q
>>>>> http://cuda-fs1/cuda/snmpd.conf-rhel5 -O
>>>>> /etc/snmp/snmpd.conf]/require: requires Package[net-snmp]
>>>>> info: Applying configuration version '1378337701'
>>>>> debug: Service[httpd](provider=redhat): Executing '/sbin/service httpd status'
>>>>> debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig httpd'
>>>>> notice: hello test
>>>>> notice: /Stage[main]/Hello/Notify[hello test]/message: defined
>>>>> 'message' as 'hello test'
>>>>> debug: Service[snmpd](provider=redhat): Executing '/sbin/service snmpd status'
>>>>> debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig snmpd'
>>>>> debug: Service[ntp](provider=redhat): Executing '/sbin/service ntpd status'
>>>>> debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig ntpd'
>>>>> debug: Service[ntp](provider=redhat): Executing '/sbin/service ntpd start'
>>>>> debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig ntpd'
>>>>> notice: /Stage[main]/Ntp::Service/Service[ntp]/ensure: ensure changed
>>>>> 'stopped' to 'running'
>>>>> info: /Stage[main]/Ntp::Service/Service[ntp]: Unscheduling refresh on
>>>>> Service[ntp]
>>>>> debug: Finishing transaction 70066374952420
>>>>> debug: Storing state
>>>>> debug: Stored state in 0.00 seconds
>>>>> notice: Finished catalog run in 0.50 seconds
>>>>> #########
>>>>>
>>>>> On Thu, Sep 5, 2013 at 8:10 AM, Federico Voges <ftc at ftc.com.ar> wrote:
>>>>>> That doesn't make any sense.
>>>>>>
>>>>>> What version are you using? and what's in the logs? Have you tried
>>>>>> running with --debug?
>>>>>>
>>>>>>
>>>>>> On 5 September 2013 15:01, Lonni J Friedman <netllama at gmail.com> wrote:
>>>>>>> I also tried with the FQDN, but that didn't make any difference. I
>>>>>>> also tried removing the default node definition, and that also had no
>>>>>>> impact. ntp is loaded regardless.
>>>>>>>
>>>>>>> On Thu, Sep 5, 2013 at 1:56 AM, Federico Voges <ftc at ftc.com.ar> wrote:
>>>>>>>> Hi Lonni,
>>>>>>>>
>>>>>>>> Is 'cuda-farm-ljf1' the FQDN for the node? If not, put the full
>>>>>>>> hostname or use a regex.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Fed.
>>>>>>>>
>>>>>>>> On 3 September 2013 23:06, Lonni J Friedman <netllama at gmail.com> wrote:
>>>>>>>>> I'm trying to get ramped up on Puppet ( http://www.puppetlabs.com ),
>>>>>>>>> and I'm encountering some strange behavior with the node definitions.
>>>>>>>>> >From the documentation, I thought that the 'default' node was a
>>>>>>>>> catchall for any node which wasn't explicitly matched elsewhere.
>>>>>>>>> However, what I'm seeing is that the default seems to apply even where
>>>>>>>>> there is an exact match. For example, I have the following in
>>>>>>>>> site.pp:
>>>>>>>>>
>>>>>>>>> #########
>>>>>>>>> import "services/*"
>>>>>>>>> node "cuda-farm-ljf1" {
>>>>>>>>> include hello
>>>>>>>>> }
>>>>>>>>> node default {
>>>>>>>>> include ntp
>>>>>>>>> }
>>>>>>>>> #########
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> What I'd expect is that the 'ntp' class will *not* apply to the
>>>>>>>>> 'cuda-farm-ljf1' node, however that isn't the behavior that I'm
>>>>>>>>> seeing. Even if I completely uninstall ntp on that node, its
>>>>>>>>> reinstalled & started the next time it syncs with the master. Am I
>>>>>>>>> missing something obvious here?
>>>>>>> _______________________________________________
>>>>>>> Linux-users mailing list
>>>>>>> Linux-users at linux-sxs.org
>>>>>>> http://mailman.celestial.com/mailman/listinfo/linux-users
>>>>>> _______________________________________________
>>>>>> Linux-users mailing list
>>>>>> Linux-users at linux-sxs.org
>>>>>> http://mailman.celestial.com/mailman/listinfo/linux-users
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>> L. Friedman netllama at gmail.com
>>>>> LlamaLand https://netllama.linux-sxs.org
>>>>> _______________________________________________
>>>>> Linux-users mailing list
>>>>> Linux-users at linux-sxs.org
>>>>> http://mailman.celestial.com/mailman/listinfo/linux-users
>>>> _______________________________________________
>>>> Linux-users mailing list
>>>> Linux-users at linux-sxs.org
>>>> http://mailman.celestial.com/mailman/listinfo/linux-users
>>>
>>>
>>>
>>> --
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> L. Friedman netllama at gmail.com
>>> LlamaLand https://netllama.linux-sxs.org
>>> _______________________________________________
>>> Linux-users mailing list
>>> Linux-users at linux-sxs.org
>>> http://mailman.celestial.com/mailman/listinfo/linux-users
>> _______________________________________________
>> Linux-users mailing list
>> Linux-users at linux-sxs.org
>> http://mailman.celestial.com/mailman/listinfo/linux-users
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> L. Friedman netllama at gmail.com
> LlamaLand https://netllama.linux-sxs.org
> _______________________________________________
> Linux-users mailing list
> Linux-users at linux-sxs.org
> http://mailman.celestial.com/mailman/listinfo/linux-users
More information about the Linux-users
mailing list