[Puppet Users] Re: Clearing delayed job failures in dashboard
this will clean all reports, I don't know how to clean only delayed job failures but it may help rake RAILS_ENV=production reports:prune upto=0 unit=day On Oct 28, 9:32 pm, Steven L. Seed slseed1...@gmail.com wrote: I have a ton of delayed job failures in my dashboard under background tasks. They are mostly failed imports of report yaml files that were deleted. There are over 4 of them so I can't use the Mark all as read button because it causes dashboard to hang forever. Anyone know how I can clear these from the command line? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet class dependency
On Oct 29, 2:50 am, Jean Baptiste FAVRE
jean.baptiste.fa...@gmail.com wrote:
Hello Andrew,
Thanks for your answer.
Infact, pkgrepo *is* already like you suggest:
class pkgrepo {
Nginx::Vhost[website.domain.tld] - Class['Pkgrepo']
include pkgrepo::install,pkgrepo::config
}
Just forget about Nginx::Vhost[packages.iscoolapp.com] and replace it
wherever you see it with Nginx::Vhost[website.domain.tld] (my bad for
the typo).
And, that's why I don't understand because
Nginx::Vhost['website.domain.tld'] - Class['Pkgrepo'] is supposed to
make vhost applied before pkgrepo. But in my output examples, package
reprepro definied in pkgrepo::install got installed before vhosts is set up.
About setting require for pkgrepo::repository, I will try asap.
My first thought was to specify dependencies between classes in root
class (ie, in pkgrepo and not in pkgrepo::install) for readability purpose.
But, it that case, I could specify it pkgrepo::repository since it
defined in node definition. Just wonder why I did not tought about it
before :-/
Will let you updated right after my tests.
Regards,
JB
On 29/10/2011 09:26, Andrew Hendry wrote:
Hi Jean,
Is Nginx::Vhost[packages.iscoolapp.com] getting set up somewhere
else in your code?
If not should your pkgrepo be like this?
class pkgrepo {
Nginx::Vhost[website.domain.tld] - Class['Pkgrepo']
include pkgrepo::install,pkgrepo::config
}
Or
pkgrepo::repository { test:
docroot = /var/www/website.domain.tld,
gpgkeyid = C78033BD,
require = Nginx::Vhost[website.domain.tld],
}
Good luck.
On Oct 29, 12:41 am, Jean Baptiste Favre
jean.baptiste.fa...@gmail.com wrote:
Hello,
There's something I don't understand with classes dependency.
I saw many thread about this subject, but still can not figure how it
works exactly.
I'm trying to setup a debian package repository. For that, I need:
- a vhost, served by nginx
- repo managment tools as well as GPG key copied into directory tree
So, that makes 2 classes:
include nginx
include pkgrepo
nginx class install nginx package and provide a define to deal with
vhost definition:
nginx::vhost { 'website.domain.tld':
port = 80,
docroot = '/var/www',
priority = 00,
}
This define will create directory /var/www/website.domain.tld as well as
deploying vhost file in /etc/nginx/sites-enabled/00-website.domain.tld
pkgrepo class will install repo managment tools and deploy repository
GPG key in /var/www/website.domain.tld/key.gpg
Therefore, it will require vhost to be created before being able to copy
GPG key.
Here's my setup:
node nodetest {
include nginx
nginx::vhost { 'website.domain.tld':
port = 80,
docroot = '/var/www',
priority = 00,
}
include pkgrepo
pkgrepo::repository { test:
docroot = /var/www/website.domain.tld,
gpgkeyid = C78033BD,
}}
And for classes definition, I got:
class pkgrepo {
Nginx::Vhost[packages.iscoolapp.com] - Class['Pkgrepo']
include pkgrepo::install,pkgrepo::config
}
Problem is, when I try to executed it twice, I don't alway have
dependency respected. For sure, I'm doing something wrong, but can not
figure what. Bellow are the execution output.
Best regards,
Jean Baptiste Favre
Wrong behaviour:
# /usr/sbin/puppetd --no-daemonize --logdest console --onetime --verbose
--preferred_serialization_format marshal
notice: Ignoring --listen on onetime run
info: Caching catalog for nodetest
info: Applying configuration version '1319805719'
notice: /Stage[main]/Pkgrepo::Install/Package[reprepro]/ensure: ensure
changed 'purged' to 'present'
notice:
/Stage[main]//Node[nodetest]/Nginx::Vhost[website.domain.tld]/File[/etc/ngi
nx/sites-enabled/00-website.domain.tld]/ensure:
defined content as '{md5}bad3fd5741e335516e2e51aaefe2963c'
info:
/Stage[main]//Node[nodetest]/Nginx::Vhost[website.domain.tld]/File[/etc/ngi
nx/sites-enabled/00-website.domain.tld]:
Scheduling refresh of Service[nginx]
notice: /Stage[main]/Nginx::Service/Service[nginx]: Triggered 'refresh'
from 1 events
notice: Finished catalog run in 6.25 seconds
Good behaviour:
# /usr/sbin/puppetd --no-daemonize --logdest console --onetime --verbose
--preferred_serialization_format marshal
notice: Ignoring --listen on onetime run
info: Caching catalog for nodetest
info: Applying configuration version '1319805719'
notice:
/Stage[main]//Node[nodetest]/Nginx::Vhost[website.domain.tld]/File[/etc/ngi
nx/sites-enabled/00-website.domain.tld]/ensure:
defined content as '{md5}bad3fd5741e335516e2e51aaefe2963c'
info:
/Stage[main]//Node[nodetest]/Nginx::Vhost[website.domain.tld]/File[/etc/ngi
nx/sites-enabled/00-website.domain.tld]:
Scheduling
[Puppet Users] Re: Unable to define order of modules
On Oct 28, 10:07 am, Baptiste Grenier baptiste.gren...@gmail.com
wrote:
I am trying to define the modules' run order like this:
You are running up against a common source of confusion: the
difference between order of manifest evaluation (on the master) and
order of catalog application (on the client). You appear to be
conflating the two into run order, but in general there is no need
for them to be the same, and indeed, one sometimes wants them to
differ.
Evaluation order affects (only) the compilation of your manifests into
a catalog, and the key mechanisms available for influencing it are
(1) the 'require' and 'include' functions (*not* the 'require'
resource metaparameter), and
(2) lexical order within individual manifest files
Application order affects (only) the order in which resources are
applied to your nodes, but that's irrelevant if catalog compilation
fails. The user-accessible mechanisms for influencing it are
(1) the 'require' resource metaparameter and its friends,
(2) the arrow syntax for defining resource relationships,
(3) run stages, and
(4) the 'require' function (which also affects order of manifest
evaluation)
You have an evaluation order problem, and you have tried to fix it by
constraining the application order. Instead, you want something like
this:
[...]
class sudo {
# KEY CHANGE:
include aptdater::client
file { '/tmp/sudoers':
ensure = 'present',
content = template('/tmp/sudoers.erb'),
}
notify { class_sudo: message = class sudo }
}
[...]
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Duplicate exported resources
On Oct 30, 2:42 am, Galed Friedmann galed.friedm...@onavo.com wrote:
I didn't know there was such a difference between exporting the ensure and
setting it when collecting, I thought it was supposed to be the same thing
As I seem to be saying frequently of late, the effect on the client
should be the same if the catalog compiles, but the effect on catalog
compilation is not necessarily the same. Also, it's cleaner design-
wise to collect resources without overriding their properties.
Overriding has legitimate uses, but you should prefer to export the
full target state of a resource when you can do so.
...
Anyways, I fixed this but I still see the error happening from time to
time, got a few of those this morning:
Oct 30 07:34:16 ubuntu puppet-master[10501]: Exported resource Host[proxy4]
cannot override local resource on node lb2
Oct 30 07:34:16 ubuntu puppet-master[10501]: Exported resource Host[proxy4]
cannot override local resource on node lb2
Oct 30 07:34:17 ubuntu puppet-master[10337]: Exported resource Host[proxy4]
cannot override local resource on node lb5
Oct 30 07:34:17 ubuntu puppet-master[10337]: Exported resource Host[proxy4]
cannot override local resource on node lb5
Oct 30 07:34:19 ubuntu puppet-master[10337]: Exported resource Host[proxy4]
cannot override local resource on node lb3back
This is the new manifest:
proxy* servers:
@@host { $hostname:
comment = $hostname,
ip = $ec2_local_ipv4,
name = stable_host$proxy_id,
tag = production-proxy,
ensure = present,
}
lb* servers:
Host | tag == production-proxy | {
}
Host | tag ==backup-proxy | {
}
If you're not performing any actual overrides then you should remove
the empty braces, too. It seems unlikely that that would solve the
problem, but not completely out of the question. I'd remove for
clarity, though, if for no other reason.
Still no idea why this is happening. I have some hosts that sometime change
their IP address and I have to sync this with the other servers. Is it
possible that the cause is that there is already a host record in the
/etc/hosts file that has another IP address in it? (Although I'd assume
puppet should just change it and not take it as a local resource...)
It is conceivable that Puppet gets confused if in /etc/hosts it finds
separate records, one having the same host name as the collected
resource but a different address, and the other having the same IP
address but a different name. I agree, however, that that *shouldn't*
be a problem, and I would be surprised if it were. You should be able
to test that case.
Do you have hosts with duplicate hostnames (perhaps in different
domains)? Are any of the affected hosts flipping between being
primary and backup proxies, or have they done since you turned on
storeconfigs? If you clear out your storeconfig database do the
problems continue and/or come back later?
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Basic questions about puppetlabs-java
On Sun, Oct 30, 2011 at 10:40 PM, Robert Atkins snikta.tre...@gmail.com wrote:
Some progress...
On Oct 31, 1:07 pm, Robert Atkins snikta.tre...@gmail.com wrote:
I've installed puppet, rubygems, puppet-module and the puppetlabs-java
module on my OpenSUSE 11.4 system. When I do:
puppet apply java/manifests/init.pp
... nothing happens. I was expecting output telling me my system is
I've now realised I can't use the class directly, but have to
include it from my own manifest file. This I've done; I've now
gotten as far as receiving the expected error message, modifying the
java module to include OpenSuSE as an RPM-style system, and getting
zypper complain No provider of 'jdk' found.
Here's an example for how to use this class:
https://github.com/puppetlabs/puppetlabs-java/blob/master/tests/init.pp
I'm expecting OpenSuSE to fail with operating system not supported
based on the latest code:
https://github.com/puppetlabs/puppetlabs-java/blob/master/manifests/init.pp
I don't know the extracted jdk package name on SuSE. You will need to
copy the rpm to your zypper package repo first. Next I would copy the
package_redhat class to package_suse and update the init.pp file with
the following section:
case $operatingsystem {
opensuse: {
class { 'java::package_suse':
version = $version,
distribution = $distribution,
require = Anchor['java::begin'],
before = Anchor['java::end'],
}
}
...
If this works, we would love to get a merge request to add support to
this platform.
I had to manually move the java and stdlib classes into /usr/share/
puppet/modules though. Shouldn't puppet-module put them there
automatically?
There's different modulepath defaults on different platform (as well
as enterprise vs. opensource). The tool currently installs in the
current working directory. I'm not sure how best to improve this
default behavior, but it seems worthwhile to have a feature request
opened in projects.puppetlabs.com if it doesn't already exist.
Thanks,
Nan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Incorrect architecture fact value during catalog run
Hi all, Can you help me diagnose a problem please? I have Facter 1.6.2 and Puppet 2.7.6 installed and what happens is that I rely on architecture fact in my manifests and this fact looks correct when I run Facter and it is set to incorrect value during catalog run: r4:/var/log# facter -p | grep architecture architecture = amd64 r4:/var/log# puppet facts find r4.osinka.int ,architecture:amd64,... r4:/var/log# puppet agent --test --noop info: Retrieving plugin info: Loading facts in ec2_facts info: Loading facts in ec2_facts info: Caching catalog for r4.osinka.int info: Applying configuration version '1320071507' notice: /Stage[main]/Nginx/Notify[Architecture x86_64]/message: current_value absent, should be Architecture x86_64 (noop) Any ideas? Where to dig? Regards, Alexander Azarov -- 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/-/cUN13TbZXaMJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] useradd question
I am using Ubuntu LTS 10.04 with the backported puppet
2.6.1-0ubuntu2~lucid1
I am trying to create user with the following manifests but at the end
always getting the Could not find user git error message:
What am i missing, seems the manifest not creating the missing git
user.
/etc/modules/git/manifests/user.pp
class git::user {
user{'install':
name= 'install',
ensure = absent,
}
user{'git':
name= 'git',
password= 'x',
ensure = present,
comment = 'Git user for puppet',
managehome = true,
shell = '/bin/bash',
uid = '1000',
require = User['install'],
provider= 'useradd',
}
Some other classes uses this as requirement:
/etc/modules/git/manifests/ssh.pp
class git::ssh {
package{'ssh':
ensure = installed,
}
file{'dir':
ensure = directory,
path= '/home/git/.ssh',
require = User['git'],
}
file{'authkey':
path= '/home/git/.ssh/authorized_keys',
ensure = file,
source = '/etc/puppet/modules/git/files/
authorized_keys',
owner = 'git',
group = 'git',
mode= '600',
recurse = true,
require = User['git'],
}
/etc/modules/git/manifests/init.pp
class git {
package{'git-core':
ensure = installed,
}
file{'config':
path= '/etc/puppet/.git/config',
ensure = file,
source = '/etc/puppet/modules/git/files/config',
}
file{'post_receive':
path= '/etc/puppet/.git/hooks/post-receive',
ensure = file,
source = '/etc/puppet/modules/git/files/post-
receive',
}
file{'dirrights':
path= '/etc/puppet',
owner = 'git',
group = 'root',
mode= '755',
recurse = true,
require = User['git'],
}
}
Thank you
Peter
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Puppet client starting problem !!
Hi, I have installed puppet 2.7.5 from tar on open suse 10.1. My ruby version is 1.8.5 and facter version is 1.6.2. The opensuse OS is pretty minimalistic. I don't even have normal linux commands like useradd or groupadd in this OS. When I run the master it runs completely fine. *puppetmasterd --server puppetmaster.mydomain.com --verbose --no-daemon* *notice: Starting Puppet master version 2.7.5* But when I try running the puppet client, the hostname for that client is * Proc_m0_s2*, it gives me error. *puppetd --server puppetmaster.mydomain.com --verbose --no-daemon* *warning: iconv doesn't seem to support UTF-8/UTF-16 conversions* *err: Could not create resources for managing Puppet's files and directories in sections [:main, :agent, :ssl]: Could not find a default provider for user* *err: Could not create resources for managing Puppet's files and directories in sections [:main, :ssl]: Could not find a default provider for user* *info: Creating a new SSL key for proc_m0_s2.tspinternal* *err: Could not request certificate: Could not write /etc/puppet/ssl/private_keys/proc_m0_s2.tspinternal.pem to privatekeydir: Could not find a default provider for user* *info: Creating a new SSL key for proc_m0_s2.tspinternal* *err: Could not request certificate: Could not write /etc/puppet/ssl/private_keys/proc_m0_s2.tspinternal.pem to privatekeydir: Could not find a default provider for user* I tried googling for this error but without any result. Please someone help !! I have a deadline before which I need to get the master and client configuration done correctly. Thanks !! Regards, Swati Nothing is too small to know, and nothing too big to attempt. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Incorrect architecture fact value during catalog run
What operating system is this? I'm looking at the documentation for the architecture fact, and theres this: # Resolution: # On OpenBSD, Linux and Debian's kfreebsd, use the hardwaremodel fact. # Gentoo and Debian call x86_86 amd64. # Gentoo also calls i386 x86. On Mon, Oct 31, 2011 at 9:25 AM, Alexander Azarov alaz...@gmail.com wrote: Hi all, Can you help me diagnose a problem please? I have Facter 1.6.2 and Puppet 2.7.6 installed and what happens is that I rely on architecture fact in my manifests and this fact looks correct when I run Facter and it is set to incorrect value during catalog run: r4:/var/log# facter -p | grep architecture architecture = amd64 r4:/var/log# puppet facts find r4.osinka.int ,architecture:amd64,... r4:/var/log# puppet agent --test --noop info: Retrieving plugin info: Loading facts in ec2_facts info: Loading facts in ec2_facts info: Caching catalog for r4.osinka.int info: Applying configuration version '1320071507' notice: /Stage[main]/Nginx/Notify[Architecture x86_64]/message: current_value absent, should be Architecture x86_64 (noop) Any ideas? Where to dig? Regards, Alexander Azarov -- 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/-/cUN13TbZXaMJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Help using puppetlabs-mysql
I'm working to begin managing MySQL with the puppetlabs-mysql provided
module, but am not able to get very far with the README documentation.
So far, simply trying to add the server module and define the
root_password is failing like so,
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Invalid parameter root_password at /etc/puppet/manifests/
nodes.pp:882 on node puppetnode1.tld
The definition looks like this,
node 'puppetnode1.tld' {
class { 'mysql::server':
root_password = 'test'
}
database_user { 'treydock@localhost':
password_hash = mysql_password('pass')
}
database_grant { 'treydock@localhost/*':
privileges = ['ALL'],
}
mysql::db { 'zabbix':
user= 'zabbix',
password= 'zabbix',
host= 'localhost',
grant = ['ALL'],
}
}
The database_user and _grant thus far haven't actually done anything.
I'm assuming it's because mysql::server isn't working or being
applied.
There's likely something very obvious I'm missing. This is also my
first time using parameterized classes.
Thanks
- Trey
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] bug: recursive directory copy that re-copies nightly
man pre link will tell you: prelink is a program that modifies ELF shared libraries and ELF dynamically linked binaries in such a way that the time needed for the dynamic linker to perform relocations at startup significantly decreases. In short, don't use recursive copy to duplicate ELF binaries, or exempt them from pre link in some fashion. In our case it was determined that only an initial copy was necessary at this time. On Oct 26, 2011, at 9:21 PM, Jo Rhett wrote: Thank you Doug, for the clue-by-four. I overlooked that. I owe you a beer. On Oct 26, 2011, at 7:23 AM, Doug Warner wrote: On 10/26/2011 12:51 AM, Jo Rhett wrote: It happens every night around 9pm (4am UDT). EVERY night. 4am, so cron.daily? prelink? -Doug -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Help using puppetlabs-mysql
you are running into a documentation issue. All of the configuration was
moved to a new parameter called: config_hash. I can submit a patch
On Mon, Oct 31, 2011 at 10:01 AM, treydock treyd...@gmail.com wrote:
I'm working to begin managing MySQL with the puppetlabs-mysql provided
module, but am not able to get very far with the README documentation.
So far, simply trying to add the server module and define the
root_password is failing like so,
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Invalid parameter root_password at /etc/puppet/manifests/
nodes.pp:882 on node puppetnode1.tld
The definition looks like this,
node 'puppetnode1.tld' {
class { 'mysql::server':
root_password = 'test'
}
should be changed to:
class { 'mysql::server':
config_hash = { root_password = 'test'}
}
database_user { 'treydock@localhost':
password_hash = mysql_password('pass')
}
database_grant { 'treydock@localhost/*':
privileges = ['ALL'],
}
mysql::db { 'zabbix':
user= 'zabbix',
password= 'zabbix',
host= 'localhost',
grant = ['ALL'],
}
}
The database_user and _grant thus far haven't actually done anything.
I'm assuming it's because mysql::server isn't working or being
applied.
There's likely something very obvious I'm missing. This is also my
first time using parameterized classes.
Thanks
- Trey
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet class dependency
And for classes definition, I got:
class pkgrepo {
Nginx::Vhost[packages.iscoolapp.com] - Class['Pkgrepo']
include pkgrepo::install,pkgrepo::config
}
The way I understand it, all included classes are basically included
at the same time before catalog compilation. And then the resource
dependencies don't take effect until the catalog is being applied to
the node...or in short - includes aren't treated like resources.
You basically end up with a node that includes pkgrepo,
pkgrepo::install, and pkgrepo::config classes, then puppet ensures
that Nginx::Vhost[packages.iscoolapp.com] occurs before
Class[pkgrepo] - ignoring any sort of ordering for classes that
pkgrepo included.
To ensure the strict ordering when classes include other classes, you
need to specify the requirements for all the classes - something like
this should work:
class pkgrepo {
Nginx::Vhost[packages.iscoolapp.com] -
Class['pkgrepo::install'] - Class['pkgrepo::config'] -
Class['pkgrepo']
include pkgrepo::install,pkgrepo::config
}
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Incorrect architecture fact value during catalog run
This is Debian 6.0.3 On Monday, October 31, 2011 8:43:50 PM UTC+4, Adrien Thebo wrote: What operating system is this? I'm looking at the documentation for the architecture fact, and theres this: # Resolution: # On OpenBSD, Linux and Debian's kfreebsd, use the hardwaremodel fact. # Gentoo and Debian call x86_86 amd64. # Gentoo also calls i386 x86. On Mon, Oct 31, 2011 at 9:25 AM, Alexander Azarov ala...@gmail.com wrote: Hi all, Can you help me diagnose a problem please? I have Facter 1.6.2 and Puppet 2.7.6 installed and what happens is that I rely on architecture fact in my manifests and this fact looks correct when I run Facter and it is set to incorrect value during catalog run: r4:/var/log# facter -p | grep architecture architecture = amd64 r4:/var/log# puppet facts find r4.osinka.int ,architecture:amd64,... r4:/var/log# puppet agent --test --noop info: Retrieving plugin info: Loading facts in ec2_facts info: Loading facts in ec2_facts info: Caching catalog for r4.osinka.int info: Applying configuration version '1320071507' notice: /Stage[main]/Nginx/Notify[Architecture x86_64]/message: current_value absent, should be Architecture x86_64 (noop) Any ideas? Where to dig? Regards, Alexander Azarov -- 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/-/cUN13TbZXaMJ. To post to this group, send email to puppet...@googlegroups.com. To unsubscribe from this group, send email to puppet-users...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Y16JfpyutBUJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Help using puppetlabs-mysql
On Oct 31, 12:26 pm, Dan Bode d...@puppetlabs.com wrote:
you are running into a documentation issue. All of the configuration was
moved to a new parameter called: config_hash. I can submit a patch
On Mon, Oct 31, 2011 at 10:01 AM, treydock treyd...@gmail.com wrote:
I'm working to begin managing MySQL with the puppetlabs-mysql provided
module, but am not able to get very far with the README documentation.
So far, simply trying to add the server module and define the
root_password is failing like so,
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Invalid parameter root_password at /etc/puppet/manifests/
nodes.pp:882 on node puppetnode1.tld
The definition looks like this,
node 'puppetnode1.tld' {
class { 'mysql::server':
root_password = 'test'
}
should be changed to:
class { 'mysql::server':
config_hash = { root_password = 'test'}
}
database_user { 'treydock@localhost':
password_hash = mysql_password('pass')
}
database_grant { 'treydock@localhost/*':
privileges = ['ALL'],
}
mysql::db { 'zabbix':
user = 'zabbix',
password = 'zabbix',
host = 'localhost',
grant = ['ALL'],
}
}
The database_user and _grant thus far haven't actually done anything.
I'm assuming it's because mysql::server isn't working or being
applied.
There's likely something very obvious I'm missing. This is also my
first time using parameterized classes.
Thanks
- Trey
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Ah that was it! Thanks.
Is there a way to similuate or run the equivilant of
mysql_secure_installation within this module? I tried an initial
attempt with the following...but once it's added to the mysql::server
class it never seems to get called...
class mysql::server::secure {
database_user {
'':
ensure= absent,
require = Service['mysqld'];
root@${fqdn}:
ensure= absent,
require = Service['mysqld'];
}
database {
test:
ensure = absent,
require = Service['mysqld'];
}
}
Would the easier route be to just modify the mysql_secure_installation
script to be more puppet friendly?
Thanks
- Trey
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Help using puppetlabs-mysql
On Mon, Oct 31, 2011 at 10:55 AM, treydock treyd...@gmail.com wrote:
On Oct 31, 12:26 pm, Dan Bode d...@puppetlabs.com wrote:
you are running into a documentation issue. All of the configuration was
moved to a new parameter called: config_hash. I can submit a patch
On Mon, Oct 31, 2011 at 10:01 AM, treydock treyd...@gmail.com wrote:
I'm working to begin managing MySQL with the puppetlabs-mysql provided
module, but am not able to get very far with the README documentation.
So far, simply trying to add the server module and define the
root_password is failing like so,
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Invalid parameter root_password at /etc/puppet/manifests/
nodes.pp:882 on node puppetnode1.tld
The definition looks like this,
node 'puppetnode1.tld' {
class { 'mysql::server':
root_password = 'test'
}
should be changed to:
class { 'mysql::server':
config_hash = { root_password = 'test'}
}
database_user { 'treydock@localhost':
password_hash = mysql_password('pass')
}
database_grant { 'treydock@localhost/*':
privileges = ['ALL'],
}
mysql::db { 'zabbix':
user= 'zabbix',
password= 'zabbix',
host= 'localhost',
grant = ['ALL'],
}
}
The database_user and _grant thus far haven't actually done anything.
I'm assuming it's because mysql::server isn't working or being
applied.
There's likely something very obvious I'm missing. This is also my
first time using parameterized classes.
Thanks
- Trey
--
You received this message because you are subscribed to the Google
Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Ah that was it! Thanks.
Is there a way to similuate or run the equivilant of
mysql_secure_installation within this module? I tried an initial
attempt with the following...but once it's added to the mysql::server
class it never seems to get called...
what failed? How did you add it to the mysql::server class?
class mysql::server::secure {
database_user {
'':
ensure= absent,
require = Service['mysqld'];
root@${fqdn}:
ensure= absent,
require = Service['mysqld'];
}
database {
test:
ensure = absent,
require = Service['mysqld'];
}
}
Would the easier route be to just modify the mysql_secure_installation
script to be more puppet friendly?
Thanks
- Trey
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet class dependency
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Devon,
You're tight and that's the point I was looking for.
I discovered that point when doing some tests after Andrew's contribution.
So, now it works and I'll be able to deal with class ordering.
Thanks for your answer,
JB
On 31/10/2011 18:45, devon wrote:
And for classes definition, I got: class pkgrepo {
Nginx::Vhost[packages.iscoolapp.com] - Class['Pkgrepo'] include
pkgrepo::install,pkgrepo::config
}
The way I understand it, all included classes are basically
included at the same time before catalog compilation. And then the
resource dependencies don't take effect until the catalog is being
applied to the node...or in short - includes aren't treated like
resources.
You basically end up with a node that includes pkgrepo,
pkgrepo::install, and pkgrepo::config classes, then puppet ensures
that Nginx::Vhost[packages.iscoolapp.com] occurs before
Class[pkgrepo] - ignoring any sort of ordering for classes that
pkgrepo included.
To ensure the strict ordering when classes include other classes,
you need to specify the requirements for all the classes - something
like this should work:
class pkgrepo { Nginx::Vhost[packages.iscoolapp.com] -
Class['pkgrepo::install'] - Class['pkgrepo::config'] -
Class['pkgrepo'] include pkgrepo::install,pkgrepo::config }
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6u6IMACgkQM2eZoKJfKd3SwwCgi5nukmVgCL8FtbF6AVq5btbO
pRYAoITEGc4mzjAAMtYtxtE3hKKKAnjt
=1dAq
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Incorrect architecture fact value during catalog run
Just as a curiosity, what web server are you using for your puppet master? On Mon, Oct 31, 2011 at 10:55 AM, Alexander Azarov alaz...@gmail.com wrote: This is Debian 6.0.3 On Monday, October 31, 2011 8:43:50 PM UTC+4, Adrien Thebo wrote: What operating system is this? I'm looking at the documentation for the architecture fact, and theres this: # Resolution: # On OpenBSD, Linux and Debian's kfreebsd, use the hardwaremodel fact. # Gentoo and Debian call x86_86 amd64. # Gentoo also calls i386 x86. On Mon, Oct 31, 2011 at 9:25 AM, Alexander Azarov ala...@gmail.com wrote: Hi all, Can you help me diagnose a problem please? I have Facter 1.6.2 and Puppet 2.7.6 installed and what happens is that I rely on architecture fact in my manifests and this fact looks correct when I run Facter and it is set to incorrect value during catalog run: r4:/var/log# facter -p | grep architecture architecture = amd64 r4:/var/log# puppet facts find r4.osinka.int ,architecture:amd64,... r4:/var/log# puppet agent --test --noop info: Retrieving plugin info: Loading facts in ec2_facts info: Loading facts in ec2_facts info: Caching catalog for r4.osinka.int info: Applying configuration version '1320071507' notice: /Stage[main]/Nginx/Notify[Architecture x86_64]/message: current_value absent, should be Architecture x86_64 (noop) Any ideas? Where to dig? Regards, Alexander Azarov -- 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/-/cUN13TbZXaMJ. To post to this group, send email to puppet...@googlegroups.com. To unsubscribe from this group, send email to puppet-users...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Y16JfpyutBUJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Incorrect architecture fact value during catalog run
The simplest default, that is WEBrick I guess. On Monday, October 31, 2011 10:28:12 PM UTC+4, Adrien Thebo wrote: Just as a curiosity, what web server are you using for your puppet master? On Mon, Oct 31, 2011 at 10:55 AM, Alexander Azarov ala...@gmail.com wrote: This is Debian 6.0.3 On Monday, October 31, 2011 8:43:50 PM UTC+4, Adrien Thebo wrote: What operating system is this? I'm looking at the documentation for the architecture fact, and theres this: # Resolution: # On OpenBSD, Linux and Debian's kfreebsd, use the hardwaremodel fact. # Gentoo and Debian call x86_86 amd64. # Gentoo also calls i386 x86. On Mon, Oct 31, 2011 at 9:25 AM, Alexander Azarov ala...@gmail.com wrote: Hi all, Can you help me diagnose a problem please? I have Facter 1.6.2 and Puppet 2.7.6 installed and what happens is that I rely on architecture fact in my manifests and this fact looks correct when I run Facter and it is set to incorrect value during catalog run: r4:/var/log# facter -p | grep architecture architecture = amd64 r4:/var/log# puppet facts find r4.osinka.int ,architecture:amd64,... r4:/var/log# puppet agent --test --noop info: Retrieving plugin info: Loading facts in ec2_facts info: Loading facts in ec2_facts info: Caching catalog for r4.osinka.int info: Applying configuration version '1320071507' notice: /Stage[main]/Nginx/Notify[Architecture x86_64]/message: current_value absent, should be Architecture x86_64 (noop) Any ideas? Where to dig? Regards, Alexander Azarov -- 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/-/cUN13TbZXaMJ. To post to this group, send email to pupp...@googlegroups.com. To unsubscribe from this group, send email to puppet-...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Y16JfpyutBUJ. To post to this group, send email to puppet...@googlegroups.com. To unsubscribe from this group, send email to puppet-users...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/p4LKkKnYaJcJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet class dependency
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello John,
Answers inline
On 31/10/2011 15:40, jcbollinger wrote:
Your setup is a bit strange in using arrow syntax within a class to
declare a dependency of that class itself, though I'm not sure that
shouldn't work. Instead, the key problem may be capitalization: to
the best of my knowledge, when you reference a resource you must
capitalize the resource *type*, but not the resource name, thus I
think you should use
Nginx::Vhost[website.domain.tld] - Class['pkgrepo']
About dependency of a class declared in the class itself, it bascially a
matter of modules/class organization:
- - Each module should be as much independent as possible. If they need
some other modules/classes, all requirement should be setted up in
root class.
For example, it's a simple module but still relevant: pkgrepo
Its goal is to set up a debian package repository. For that, it'll
install all relevant package and configure everything it can.
But, it need nginx::vhost to set up directory tree so that it'll be able
to deploy GPG key.
To make code maintenance easier, I've choosen to put all dependancies in
root class (in my example pkgrepo and not pkgrepo::install or
pkgrepo::configure)
The example here is quite simple, but I'm working on other modules like
zabbix, which needs specific MySQL database/user.
About capitalization, it's basically an error from me :-/
Nevertheless, it shouldn't just fail silently. If you see nothing
relevant in either the master or the client's log about the
relationship not being honored, the resource not being found, or a
dependency cycle being detected, then you should file a ticket about
that.
Meanwhile, there are a couple of alternative, more conventional ways
to define your relationship. For example, you might find this to
work more reliably:
node nodetest { include nginx # NOTE relocation: include pkgrepo
nginx::vhost { 'website.domain.tld': port = 80, docroot =
'/var/www', priority = 00, # NOTE: require = Class['pkgrepo'] }
pkgrepo::repository { test: docroot =
/var/www/website.domain.tld, gpgkeyid= C78033BD, } }
This example should work, but won't for more complicated modules
(example above with zabbix module I'm working on)
Regards,
JB
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6u654ACgkQM2eZoKJfKd22yQCdFFNg2uqgBohKOOCFZmrfSuum
vdwAnAxETA97w/g7A3cZjJMpaeKcAEFR
=DI+f
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Help using puppetlabs-mysql
On Oct 31, 1:05 pm, Dan Bode d...@puppetlabs.com wrote:
On Mon, Oct 31, 2011 at 10:55 AM, treydock treyd...@gmail.com wrote:
On Oct 31, 12:26 pm, Dan Bode d...@puppetlabs.com wrote:
you are running into a documentation issue. All of the configuration was
moved to a new parameter called: config_hash. I can submit a patch
On Mon, Oct 31, 2011 at 10:01 AM, treydock treyd...@gmail.com wrote:
I'm working to begin managing MySQL with the puppetlabs-mysql provided
module, but am not able to get very far with the README documentation.
So far, simply trying to add the server module and define the
root_password is failing like so,
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Invalid parameter root_password at /etc/puppet/manifests/
nodes.pp:882 on node puppetnode1.tld
The definition looks like this,
node 'puppetnode1.tld' {
class { 'mysql::server':
root_password = 'test'
}
should be changed to:
class { 'mysql::server':
config_hash = { root_password = 'test'}
}
database_user { 'treydock@localhost':
password_hash = mysql_password('pass')
}
database_grant { 'treydock@localhost/*':
privileges = ['ALL'],
}
mysql::db { 'zabbix':
user = 'zabbix',
password = 'zabbix',
host = 'localhost',
grant = ['ALL'],
}
}
The database_user and _grant thus far haven't actually done anything.
I'm assuming it's because mysql::server isn't working or being
applied.
There's likely something very obvious I'm missing. This is also my
first time using parameterized classes.
Thanks
- Trey
--
You received this message because you are subscribed to the Google
Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Ah that was it! Thanks.
Is there a way to similuate or run the equivilant of
mysql_secure_installation within this module? I tried an initial
attempt with the following...but once it's added to the mysql::server
class it never seems to get called...
what failed? How did you add it to the mysql::server class?
class mysql::server::secure {
database_user {
'':
ensure = absent,
require = Service['mysqld'];
root@${fqdn}:
ensure = absent,
require = Service['mysqld'];
}
database {
test:
ensure = absent,
require = Service['mysqld'];
}
}
Would the easier route be to just modify the mysql_secure_installation
script to be more puppet friendly?
Thanks
- Trey
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
It didn't fail, it just simply did nothing.
This is it's inclusion in mysql::server
class mysql::server(
$service_name = $mysql::params::service_name,
$config_hash = {},
$package_name = 'mysql-server'
) inherits mysql::params {
include mysql::server::secure
# automatically create a class to deal with
# configuration
$hash = {
mysql::config = $config_hash
}
I am doing it via Exec now anyways. Though I'd prefer to do it with
the new type and provider
- Trey
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Help using puppetlabs-mysql
On Oct 31, 1:56 pm, treydock treyd...@gmail.com wrote:
On Oct 31, 1:05 pm, Dan Bode d...@puppetlabs.com wrote:
On Mon, Oct 31, 2011 at 10:55 AM, treydock treyd...@gmail.com wrote:
On Oct 31, 12:26 pm, Dan Bode d...@puppetlabs.com wrote:
you are running into a documentation issue. All of the configuration was
moved to a new parameter called: config_hash. I can submit a patch
On Mon, Oct 31, 2011 at 10:01 AM, treydock treyd...@gmail.com wrote:
I'm working to begin managing MySQL with the puppetlabs-mysql provided
module, but am not able to get very far with the README documentation.
So far, simply trying to add the server module and define the
root_password is failing like so,
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Invalid parameter root_password at /etc/puppet/manifests/
nodes.pp:882 on node puppetnode1.tld
The definition looks like this,
node 'puppetnode1.tld' {
class { 'mysql::server':
root_password = 'test'
}
should be changed to:
class { 'mysql::server':
config_hash = { root_password = 'test'}
}
database_user { 'treydock@localhost':
password_hash = mysql_password('pass')
}
database_grant { 'treydock@localhost/*':
privileges = ['ALL'],
}
mysql::db { 'zabbix':
user = 'zabbix',
password = 'zabbix',
host = 'localhost',
grant = ['ALL'],
}
}
The database_user and _grant thus far haven't actually done anything.
I'm assuming it's because mysql::server isn't working or being
applied.
There's likely something very obvious I'm missing. This is also my
first time using parameterized classes.
Thanks
- Trey
--
You received this message because you are subscribed to the Google
Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Ah that was it! Thanks.
Is there a way to similuate or run the equivilant of
mysql_secure_installation within this module? I tried an initial
attempt with the following...but once it's added to the mysql::server
class it never seems to get called...
what failed? How did you add it to the mysql::server class?
class mysql::server::secure {
database_user {
'':
ensure = absent,
require = Service['mysqld'];
root@${fqdn}:
ensure = absent,
require = Service['mysqld'];
}
database {
test:
ensure = absent,
require = Service['mysqld'];
}
}
Would the easier route be to just modify the mysql_secure_installation
script to be more puppet friendly?
Thanks
- Trey
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
It didn't fail, it just simply did nothing.
This is it's inclusion in mysql::server
class mysql::server(
$service_name = $mysql::params::service_name,
$config_hash = {},
$package_name = 'mysql-server'
) inherits mysql::params {
include mysql::server::secure
# automatically create a class to deal with
# configuration
$hash = {
mysql::config = $config_hash
}
I am doing it via Exec now anyways. Though I'd prefer to do it with
the new type and provider
- Trey
Slightly different question...is there a way to pass / store the hash
for the root password rather than the plain text password? Similar to
how the puppet user resource works?
Thanks
- Trey
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Help using puppetlabs-mysql
On Mon, Oct 31, 2011 at 12:44 PM, treydock treyd...@gmail.com wrote:
On Oct 31, 1:56 pm, treydock treyd...@gmail.com wrote:
On Oct 31, 1:05 pm, Dan Bode d...@puppetlabs.com wrote:
On Mon, Oct 31, 2011 at 10:55 AM, treydock treyd...@gmail.com wrote:
On Oct 31, 12:26 pm, Dan Bode d...@puppetlabs.com wrote:
you are running into a documentation issue. All of the
configuration was
moved to a new parameter called: config_hash. I can submit a patch
On Mon, Oct 31, 2011 at 10:01 AM, treydock treyd...@gmail.com
wrote:
I'm working to begin managing MySQL with the puppetlabs-mysql
provided
module, but am not able to get very far with the README
documentation.
So far, simply trying to add the server module and define the
root_password is failing like so,
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Invalid parameter root_password at /etc/puppet/manifests/
nodes.pp:882 on node puppetnode1.tld
The definition looks like this,
node 'puppetnode1.tld' {
class { 'mysql::server':
root_password = 'test'
}
should be changed to:
class { 'mysql::server':
config_hash = { root_password = 'test'}
}
database_user { 'treydock@localhost':
password_hash = mysql_password('pass')
}
database_grant { 'treydock@localhost/*':
privileges = ['ALL'],
}
mysql::db { 'zabbix':
user= 'zabbix',
password= 'zabbix',
host= 'localhost',
grant = ['ALL'],
}
}
The database_user and _grant thus far haven't actually done
anything.
I'm assuming it's because mysql::server isn't working or being
applied.
There's likely something very obvious I'm missing. This is also
my
first time using parameterized classes.
Thanks
- Trey
--
You received this message because you are subscribed to the
Google
Groups
Puppet Users group.
To post to this group, send email to
puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Ah that was it! Thanks.
Is there a way to similuate or run the equivilant of
mysql_secure_installation within this module? I tried an initial
attempt with the following...but once it's added to the mysql::server
class it never seems to get called...
what failed? How did you add it to the mysql::server class?
class mysql::server::secure {
database_user {
'':
ensure= absent,
require = Service['mysqld'];
root@${fqdn}:
ensure= absent,
require = Service['mysqld'];
}
database {
test:
ensure = absent,
require = Service['mysqld'];
}
}
Would the easier route be to just modify the
mysql_secure_installation
script to be more puppet friendly?
Thanks
- Trey
--
You received this message because you are subscribed to the Google
Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
It didn't fail, it just simply did nothing.
This is it's inclusion in mysql::server
class mysql::server(
$service_name = $mysql::params::service_name,
$config_hash = {},
$package_name = 'mysql-server'
) inherits mysql::params {
include mysql::server::secure
# automatically create a class to deal with
# configuration
$hash = {
mysql::config = $config_hash
}
I am doing it via Exec now anyways. Though I'd prefer to do it with
the new type and provider
- Trey
Slightly different question...is there a way to pass / store the hash
for the root password rather than the plain text password? Similar to
how the puppet user resource works?
I am not quite sure if mysql supports that. Could you open a ticket here:
http://projects.puppetlabs.com/projects/modules and explain what the
implementation would look like?
thanks
Thanks
- Trey
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You
[Puppet Users] Announce: Facter 1.6.3rc1 available
November welcomes us to another round of Release Candidates for our software. Facter 1.6.3rc1 is a maintenance release containing fixes, updates and refactoring. This release is available for download at: http://puppetlabs.com/downloads/facter/facter-1.6.3rc1.tar.gz See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads Please report feedback via the Puppet Labs Redmine site, using an affected version of 1.6.3rc1: http://projects.puppetlabs.com/projects/facter/ Full Release Notes at: https://projects.puppetlabs.com/projects/facter/wiki/Wiki -- (#7038) Validate prtdiag output in manufacturer prtdiag cannot be run inside zones, and calling Facter::Util::Resolution.exec on it will return nil. The manufacturer utility was calling split() on nil, which was raising an exception. Added validation of prtdiag output, and simplified the regex to extract values for facts. Added more coverage for the related facts as well. (#10228) Ascendos OS support for various facts. This patch will make various facts return the correct value on Ascendos (a new RHEL rebuild - http://www.ascendos.org/): * hardwareisa * lsbmajdistrelease * macaddress * operatingsystem * operatingsystemrelease * osfamily * uniqueid (#10233) Adds support for Parallels Server Bare Metal to Facter -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] useradd question
Hi Peter,
Where do you call git::user and git::ssh from?
Maybe the spots where you have require = User['git'], should they be
require = Class['Git::User']?
Andrew.
On Tue, Nov 1, 2011 at 1:21 AM, Peter Horvath
peter.horvat...@googlemail.com wrote:
I am using Ubuntu LTS 10.04 with the backported puppet
2.6.1-0ubuntu2~lucid1
I am trying to create user with the following manifests but at the end
always getting the Could not find user git error message:
What am i missing, seems the manifest not creating the missing git
user.
/etc/modules/git/manifests/user.pp
class git::user {
user{'install':
name = 'install',
ensure = absent,
}
user{'git':
name = 'git',
password = 'x',
ensure = present,
comment = 'Git user for puppet',
managehome = true,
shell = '/bin/bash',
uid = '1000',
require = User['install'],
provider = 'useradd',
}
Some other classes uses this as requirement:
/etc/modules/git/manifests/ssh.pp
class git::ssh {
package{'ssh':
ensure = installed,
}
file{'dir':
ensure = directory,
path = '/home/git/.ssh',
require = User['git'],
}
file{'authkey':
path = '/home/git/.ssh/authorized_keys',
ensure = file,
source = '/etc/puppet/modules/git/files/
authorized_keys',
owner = 'git',
group = 'git',
mode = '600',
recurse = true,
require = User['git'],
}
/etc/modules/git/manifests/init.pp
class git {
package{'git-core':
ensure = installed,
}
file{'config':
path = '/etc/puppet/.git/config',
ensure = file,
source = '/etc/puppet/modules/git/files/config',
}
file{'post_receive':
path = '/etc/puppet/.git/hooks/post-receive',
ensure = file,
source = '/etc/puppet/modules/git/files/post-
receive',
}
file{'dirrights':
path = '/etc/puppet',
owner = 'git',
group = 'root',
mode = '755',
recurse = true,
require = User['git'],
}
}
Thank you
Peter
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] severe bug in 2.6.12: Caught TERM; calling stop
Mon Oct 31 23:03:31 + 2011 Puppet (notice): Caught TERM; calling stop Ever since the 2.6.12 upgrade I've been seeing these reports reach us. As in, about a hundred of a half thou machines. Most of the time we find that $vardir/state/puppetdlock is in place and blocking further puppet runs, which requires a manual resolution. I wrote a quick cron script to look for puppetdlock files older than one hour, remove them and mail me a report and I've received several dozen in the last few hours. Something is clearly broken in 2.6.12, we are backgrading our systems to 2.6.11. No-- I have no other information than that it crosses all of our machine types, and we have had no significant changes in our modules in this time period. Many of the machines which have failed have had zero module or manifest changes which would apply to them. I cannot get this to replicate on the command line. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Variable interpolation in class parameters
FWIW, I find I agree with jcbollinger on this one -- the class parameter declaration block is not a code block, so you should not use variables defined there to define other variables in the same block. That it works at all is surprising, and probably down to the order the parameters are processes (which, as it most likely depends on hash table sequence, is going to appear random) Best practice would seem to be to make the variables default to null, and then use subsequent evaluations within the class code to perform the relevant defaulting, as he said. Steve -- 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/-/ocjQmdnOX3sJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] useradd question
I call them here.
/etc/puppet/manifests/site.pp
#Puppet Node configurationsnode eurwebtest01 { include apache2
include apache2::mods include apache2::vhost-eurwebtest}
node eurwebtest02 { include apache2 include
apache2::mods include apache2::vhost-eurwebtest include
system include git include git::ssh include
git::user include git::sudoers}
node eurwebtest03 { include apache2 include
apache2::mods include apache2::vhost-eurwebtest include
system
include git include git::ssh include git::user
include git::sudoers}
On 1 November 2011 01:19, Andrew Hendry andrew.hen...@gmail.com wrote:
Hi Peter,
Where do you call git::user and git::ssh from?
Maybe the spots where you have require = User['git'], should they be
require = Class['Git::User']?
Andrew.
On Tue, Nov 1, 2011 at 1:21 AM, Peter Horvath
peter.horvat...@googlemail.com wrote:
I am using Ubuntu LTS 10.04 with the backported puppet
2.6.1-0ubuntu2~lucid1
I am trying to create user with the following manifests but at the end
always getting the Could not find user git error message:
What am i missing, seems the manifest not creating the missing git
user.
/etc/modules/git/manifests/user.pp
class git::user {
user{'install':
name = 'install',
ensure = absent,
}
user{'git':
name = 'git',
password = 'x',
ensure = present,
comment = 'Git user for puppet',
managehome = true,
shell = '/bin/bash',
uid = '1000',
require = User['install'],
provider = 'useradd',
}
Some other classes uses this as requirement:
/etc/modules/git/manifests/ssh.pp
class git::ssh {
package{'ssh':
ensure = installed,
}
file{'dir':
ensure = directory,
path = '/home/git/.ssh',
require = User['git'],
}
file{'authkey':
path = '/home/git/.ssh/authorized_keys',
ensure = file,
source = '/etc/puppet/modules/git/files/
authorized_keys',
owner = 'git',
group = 'git',
mode = '600',
recurse = true,
require = User['git'],
}
/etc/modules/git/manifests/init.pp
class git {
package{'git-core':
ensure = installed,
}
file{'config':
path = '/etc/puppet/.git/config',
ensure = file,
source = '/etc/puppet/modules/git/files/config',
}
file{'post_receive':
path = '/etc/puppet/.git/hooks/post-receive',
ensure = file,
source = '/etc/puppet/modules/git/files/post-
receive',
}
file{'dirrights':
path = '/etc/puppet',
owner = 'git',
group = 'root',
mode = '755',
recurse = true,
require = User['git'],
}
}
Thank you
Peter
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
