[Puppet Users] test
test -- 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 calling stat() on managed symlinks
Hi All,
We are seeing an unfortunate side effect using puppet to manage a
directory of symlinks pointing to automounted filesystems. It seems
that as well as verifying that the link matches the desired target
(readlink/lstat), it is also performing an open() on the links and
causing the filesystems to be automounted.
The pattern here is:
file { "/data":
ensure => directory,
source => "/nfsmount/links/data",
recurse => true,
force => true,
}
Imagine everything is in the steady state, i.e.:
symlink /data/fs1 -> /net/server1/fs1 exists
symlink /nfsmount/links/data/fs1 -> /net/server1/fs1 exists
Then at some point in the run (after doing lstat("/data/fs1"),
readlink("/data/fs1")), puppet appears to attempt an open("/data/fs1",
O_RDONLY).
IANAE here, but it seems that this open is unnecessary? Once the
target of the link in the managed directory is verified to match the
target of the link on the source, that should be sufficient?
(just had an idea as I was writing this) it *appears* I can work
around it by coding all of the symlinks individually as ensure=>link
into puppet itself. However I still think the behaviour is
incorrect. Thoughts?
Thanks,
Tim
--
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] How can i make a 'file' resource depend on package installation?
basically i want to add to my file resource a requirements on a pre-
installed package and if its not installed should be first installed.
file {
require => Package["SomePackage"]
}
I understand require is not supported in file resource is there any
other solution to have this dependency?
--
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] How can i make a 'file' resource depend on package installation?
- Original Message -
> From: "geog"
> To: "Puppet Users"
> Sent: Monday, April 23, 2012 10:11:30 AM
> Subject: [Puppet Users] How can i make a 'file' resource depend on package
> installation?
>
> basically i want to add to my file resource a requirements on a pre-
> installed package and if its not installed should be first installed.
>
> file {
>require => Package["SomePackage"]
> }
>
> I understand require is not supported in file resource is there any
> other solution to have this dependency?
Require is whats called a meta paramater - it's supported on all resource types
including File. Same for subscribe, notify and a few others
--
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: How can i make a 'file' resource depend on package installation?
thanks for clarifying that out! i'll give it a few more shots for some
reason did not work for me.
On Apr 23, 12:21 pm, "R.I.Pienaar" wrote:
> - Original Message -
> > From: "geog"
> > To: "Puppet Users"
> > Sent: Monday, April 23, 2012 10:11:30 AM
> > Subject: [Puppet Users] How can i make a 'file' resource depend on package
> > installation?
>
> > basically i want to add to my file resource a requirements on a pre-
> > installed package and if its not installed should be first installed.
>
> > file {
> > require => Package["SomePackage"]
> > }
>
> > I understand require is not supported in file resource is there any
> > other solution to have this dependency?
>
> Require is whats called a meta paramater - it's supported on all resource
> types
> including File. Same for subscribe, notify and a few others
--
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 calling stat() on managed symlinks
Hi Tim,
On Monday, 23 April 2012 05:41:31 UTC+1, Tim wrote:
[...]
> IANAE here, but it seems that this open is unnecessary?
>
[...]
This is not Puppet doing open on this directory (not explicitly anyway).
Have a look on this:
kwilczynski@desktop:~/Development/Sandbox/Test$ mkdir -p a/{b,c/d}
kwilczynski@desktop:~/Development/Sandbox/Test$ tree
.
└── a
├── b
└── c
└── d
4 directories, 0 files
kwilczynski@desktop:~/Development/Sandbox/Test$ strace -e
open,lstat,getdents ruby -e "Dir['./**/*']"
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/usr/lib/libruby1.8.so.1.8", O_RDONLY) = 3
open("/lib/libpthread.so.0", O_RDONLY) = 3
open("/lib/librt.so.1", O_RDONLY) = 3
open("/lib/libdl.so.2", O_RDONLY) = 3
open("/lib/libcrypt.so.1", O_RDONLY)= 3
open("/lib/libm.so.6", O_RDONLY)= 3
open("/lib/libc.so.6", O_RDONLY)= 3
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW) = 3
open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 3 entries */, 32768) = 72
lstat("./a", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
open("./a", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
getdents(4, /* 4 entries */, 32768) = 96
lstat("./a/b", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
open("./a/b", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
getdents(5, /* 2 entries */, 32768) = 48
getdents(5, /* 0 entries */, 32768) = 0
lstat("./a/c", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
open("./a/c", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
getdents(5, /* 3 entries */, 32768) = 72
lstat("./a/c/d", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
open("./a/c/d", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
getdents(6, /* 2 entries */, 32768) = 48
getdents(6, /* 0 entries */, 32768) = 0
getdents(5, /* 0 entries */, 32768) = 0
getdents(4, /* 0 entries */, 32768) = 0
getdents(3, /* 0 entries */, 32768) = 0
kwilczynski@desktop:~/Development/Sandbox/Test$
And then ...
kwilczynski@desktop:~/Development/Sandbox/Test$ strace -e
open,lstat,getdents ruby -e "Dir['./*']"
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/usr/lib/libruby1.8.so.1.8", O_RDONLY) = 3
open("/lib/libpthread.so.0", O_RDONLY) = 3
open("/lib/librt.so.1", O_RDONLY) = 3
open("/lib/libdl.so.2", O_RDONLY) = 3
open("/lib/libcrypt.so.1", O_RDONLY)= 3
open("/lib/libm.so.6", O_RDONLY)= 3
open("/lib/libc.so.6", O_RDONLY)= 3
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW) = 3
open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 3 entries */, 32768) = 72
getdents(3, /* 0 entries */, 32768) = 0
Or, an equivalent:
kwilczynski@desktop:~/Development/Sandbox/Test$ strace -e
open,lstat,getdents ruby -e "Dir.entries('.')"
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/usr/lib/libruby1.8.so.1.8", O_RDONLY) = 3
open("/lib/libpthread.so.0", O_RDONLY) = 3
open("/lib/librt.so.1", O_RDONLY) = 3
open("/lib/libdl.so.2", O_RDONLY) = 3
open("/lib/libcrypt.so.1", O_RDONLY)= 3
open("/lib/libm.so.6", O_RDONLY)= 3
open("/lib/libc.so.6", O_RDONLY)= 3
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW) = 3
open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 3 entries */, 32768) = 72
getdents(3, /* 0 entries */, 32768) = 0
kwilczynski@desktop:~/Development/Sandbox/Test$
Also, two more examples:
kwilczynski@desktop:~/Development/Sandbox/Test$ cat > ftw.c
#include
#include
#include
int callback(const char *name, const struct stat *status, int type);
int main(int argc, char *argv[])
{
char *root = ".";
ftw((char *) root, callback, 1);
return 0;
}
int callback(const char *name, const struct stat *status, int type)
{
if (type == FTW_NS)
return 0;
if (type == FTW_F || type == FTW_SL || type == FTW_D)
printf("%s\n", name);
return 0;
}
kwilczynski@desktop:~/Development/Sandbox/Test$ gcc -o ftw ftw.c
kwilczynski@desktop:~/Development/Sandbox/Test$ ./ftw
.
./a
./a/b
./a/c
./a/c/d
./readdir.c
./readdir
./ftw.c
./ftw
kwilczynski@desktop:~/Development/Sandbox/Test$ strace -e
open,lstat,getdents ./ftw
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib/libc.so.6", O_RDONLY)= 3
open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
.
getdents(3, /* 7 entries */, 32768) = 192
getdents(3, /* 0 entries */, 32768) = 0
open("./a", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
./a
getdents(3, /* 4 entries */, 32768) = 96
getdents(3, /* 0 entries */, 32768) = 0
open("./a/b", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
./a/b
getdents(3, /* 2 entries */, 32768) = 48
getdents(3, /* 0 entries */, 32768) = 0
open("./a/c", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
./a/c
getdents(3, /* 3 entries */, 32768) = 72
getdents(3, /* 0 entries */, 32768) = 0
open("./a/c/d", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
./a/c/d
getdents(3, /* 2 entries */, 32768) = 48
[Puppet Users] Re: puppet calling stat() on managed symlinks
[...] I forgot to add ... You probably do not want Puppet to follow symbolic links which in conjunction with the "recurse => true" is leading to open() done on each new directory during traversal. Perhaps setting "links => ignore" will help, not sure, thought. KW -- 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/-/-ZEF7r2mrzAJ. 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 Dashboard 1.2.7 Classes tab is missing
Hello everybody. After several days going in circles and following the explanations of the book Pro-Puppet and docs.puppetlabs.com/dashboard/ manual/1.2/bootstrapping.html (Using Dashboard for Node Clssification), I find myself unable to explain why I cannot move forward. This is where I am at the moment: Master RHEL 6.2 Test nodes: 5.8 with same Puppet version. No firewall, no SELinux Puppet Server 2.7.13 Puppet Dashboard 1.2.7 running in port 80, no SSL Both working fine under passenger, if I use node_terminus = plain only. I can only use the Dashboard for reporting. It can see the nodes' facts too. What I cannot do: * Assign classes to nodes (the classes tab is not even there). * Load the existing nodes and modules from site.pp file >> I expected this to be trivial, it is not apparently. *Use Dashboard as external node classifier. If I enable 'node_terminus exec' and 'external_nodes = /usr/bin/env PUPPET_DASHBOARD_URL=http://puppetserver.mydomain.com /usr/share/ puppet-dashboard/bin/external-node In external node I have changed: The DASHBOARD_URL to point to http://puppetserver.mydomain.com (i tried including the port as well) The certs are pointing to existing puppetserver certs. If I enable all this and run a test from a node, I get that: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find node 'testnode.mydomain.com' ; cannot compile. If I run it manually from the master: sudo -u puppet = /usr/bin/env PUPPET_DASHBOARD_URL=http:// puppetserver.mydomain.com /usr/share/puppet-dashboard/bin/external- node Then I get: Error 403 Forbidden Node Classification has been disabled ___ What I was expecting: 1. Puppet Dashboard to 'see' what it is in plain site.pp and import it into the nodes list, and from there move on and be able to use both sources of information as the node classifier. As I understand in the manual: "You can use Dashboard's external node classifier (ENC) alongside traditional Puppet DSL definitions." What am I missing? 2. Puppet Dashbord to load modules classes from a given module path in puppet.conf. Again, if puppet agent can do this, why doesn't the Dashboard do it too? Would it be naive to say that what I was expecting was to be able to discover nodes and classes, add nodes, add groups, collect and view reports from the dashboard, and keep my site.pp where I have nodes with parametrized classes and also keep editing my modules from the command line and vi and i have done so far? I would appreciate your replies. Regards, Guillem -- 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: How can i make a 'file' resource depend on package installation?
To make this work you need to have:
file { '/etc/foo':
ensure => present,
require => Package['SomePackage'],
}
as well as:
package { 'SomePackage':
ensure => present,
}
The require always has to have something in Puppet to match to. By saying
"ensure => present" you're just telling puppet "hey if this package is
installed then don't worry, otherwise install the latest version you can
find through the package manager". As long as you have both pieces you
should be in good shape!
On Mon, Apr 23, 2012 at 5:27 AM, geog wrote:
> thanks for clarifying that out! i'll give it a few more shots for some
> reason did not work for me.
>
> On Apr 23, 12:21 pm, "R.I.Pienaar" wrote:
> > - Original Message -
> > > From: "geog"
> > > To: "Puppet Users"
> > > Sent: Monday, April 23, 2012 10:11:30 AM
> > > Subject: [Puppet Users] How can i make a 'file' resource depend on
> package installation?
> >
> > > basically i want to add to my file resource a requirements on a pre-
> > > installed package and if its not installed should be first installed.
> >
> > > file {
> > >require => Package["SomePackage"]
> > > }
> >
> > > I understand require is not supported in file resource is there any
> > > other solution to have this dependency?
> >
> > Require is whats called a meta paramater - it's supported on all
> resource types
> > including File. Same for subscribe, notify and a few others
>
> --
> 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 calling stat() on managed symlinks
On Apr 22, 11:41 pm, Tim wrote:
> Hi All,
>
> We are seeing an unfortunate side effect using puppet to manage a
> directory of symlinks pointing to automounted filesystems. It seems
> that as well as verifying that the link matches the desired target
> (readlink/lstat), it is also performing an open() on the links and
> causing the filesystems to be automounted.
>
> The pattern here is:
>
> file { "/data":
> ensure => directory,
> source => "/nfsmount/links/data",
> recurse => true,
> force => true,
>
> }
>
> Imagine everything is in the steady state, i.e.:
>
> symlink /data/fs1 -> /net/server1/fs1 exists
> symlink /nfsmount/links/data/fs1 -> /net/server1/fs1 exists
>
> Then at some point in the run (after doing lstat("/data/fs1"),
> readlink("/data/fs1")), puppet appears to attempt an open("/data/fs1",
> O_RDONLY).
>
> IANAE here, but it seems that this open is unnecessary? Once the
> target of the link in the managed directory is verified to match the
> target of the link on the source, that should be sufficient?
That sounds sensible, but I don't know whether it's practical; some of
Puppet's behaviors are constrained by the underlying Ruby libraries.
In any case, the first thing to try is to set "links => manage" on
your File resource (not "links => ignore", which cannot work when the
desired links are not yet present).
The bottom line, however, is that recursive File management has always
been a sore spot for Puppet, and it probably always will be. It is
not remotely possible to provide enough information in the parameters
of a single File resource to cover all the possible permutations of
desired behavior. Puppet does a fairly good job of coping with that
when asked to do so, but generally you are better off finding a
different approach.
If you have a large number of files, then you may be better off
wrapping the whole thing into a custom package (e.g. an RPM), putting
that in a local repository or on a network filesystem, and managing
that package instead of the individual files. If there are only a few
files (that you want to manage) then by all means set up individual
file resources for them.
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: Only write file if copy on master is present
Thanks, this looks like it will do the trick. The lack of puppet:// support probably means I will have to hard-code a path to a directory somewhere but that shouldn't be to big of a deal. On Sunday, April 22, 2012 8:49:50 PM UTC+2, matti wrote: > > Hi, > > On Sunday, 22 April 2012 02:15:19 UTC+1, Dennis Jacobfeuerborn wrote: > > [...] > >> The twist I need to add though is that I only want to do this if a copy >> of that file for the node exists on the server. If this file doesn't >> > exists then I want puppet to not replace the file on the client and not >> restart the service. >> >> Is there a way to accomplish this sort of conditional execution? >> > > Have a look on: > https://github.com/kwilczynski/puppet-functions/blob/master/lib/puppet/parser/functions/exists.rb > > > Maybe it will be of any use to you in this case. > > KW > -- 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/-/5HEbo-N91H8J. 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! Please Delete message
test -- 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/-/9MYQWVUm6sEJ. 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] Testing a single module
Thanks for your reply. I do not have reliable access to an internet connection at the moment. Just to flesh out my problem a bit more: I need to update my sendmail module, but want to test it first. I have two puppet environments (dev and prod), but mail is critical in both. Ideally I would choose a single host on which to test if my changes worked, then push it everywhere if everything works. I tried your puppet apply command, but this failed (probably because I only have the modules on the puppet master, and modulepath is empty). Copying the puppet module to a specific host seems like I am going in the wrong direction. I considered adding testing flag to my module, which would pull in "module::testing" instead of "module", but this seems hacky and a replacement for versioning (does puppet do module versioning?). So I suppose I am asking for a nicer way to do what you suggest, or am I approaching this from the wrong direction? Thanks. -- James Patterson [1]jamespatter...@operamail.com On Thu, Apr 12, 2012, at 10:10 AM, Gary Larizza wrote: James, If the modules are in your modulepath and environments are defined in puppet.conf, you can actually use puppet apply to declare classes from the command line. For example, if you just wanted to test the nginx::config class you could run: puppet apply -v -e 'include nginx::config' This (specifically the -e flag with the code you want to pass in quotes) allows you to 'test' a specific class out-of-band from your regular Puppet runs. DO NOTE, HOWEVER, that 'test' in this sense means that it will ACTUALLY DECLARE THE CLASS AND PERFORM THE ACTION! If this is not what you want, you'll still need to add the --noop flag to SIMULATE the code. You can also create individual files in your modules 'tests' directory and declare them with puppet apply too (if you need more than just one line to test your code - a la Defined Resource Types). Note that you can ALSO pass the environment from the command line with '--environment test'. Does this help? On Thu, Apr 12, 2012 at 7:00 AM, James Patterson <[2]jamespatter...@operamail.com> wrote: Hello, I have a production puppet environment that is working well. Now more people are developing modules for it we are using a test environment using environment=test in the puppet.conf file. This prevents changes to modules in the production environment being affected by changes in the test environment. So far so good. By module I mean class, in case it's the wrong class. 1. I need to test a change to a single module on a production server, without breaking all other production servers. I could put this single production server into the test environment, but this has the danger of pulling in changes from other people's modules as well. Should I create yet another environment to do this? 2. Can I define certain modules as being taken from another environment, the "test" environment, for example? Thanks in advance, -- James Patterson [3]jamespatter...@operamail.com -- [4]http://www.fastmail.fm - Same, same, but different... -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [5]puppet-users@googlegroups.com. To unsubscribe from this group, send email to [6]puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at [7]http://groups.google.com/group/puppet-users?hl=en. -- Gary Larizza Professional Services Engineer Puppet Labs -- 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. References 1. mailto:jamespatter...@operamail.com 2. mailto:jamespatter...@operamail.com 3. mailto:jamespatter...@operamail.com 4. http://www.fastmail.fm/ 5. mailto:puppet-users@googlegroups.com 6. mailto:puppet-users%2bunsubscr...@googlegroups.com 7. http://groups.google.com/group/puppet-users?hl=en -- http://www.fastmail.fm - Send your email first class -- 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 and FreeBSD
Hello all,
Wondering if any of you could help me.
We've been using puppet on our CentOS servers for a while now with no
problems at all, very much out of the box but we do have some MySQL
servers running FreeBSD (for the slightly better memory utilisation). I've
taken up the challenge to get these FreeBSD servers talking to our puppet
master but I'm having no ends of trouble with trying to get the manifests
working. Forgetting the operating system variables and just going for a
straight install of a package such as mytop this is what I have tried in
our manifest:
This didn't seem to work at all:
package { 'mytop': ensure => installed }
>
Gave me this message on the server: *puppet-agent[3232]:
(/Stage[main]/Node[###]/Package[mytop]/ensure) change from absent
to present failed: mytop: not in required origin format:
.*//*
So instead I tried listing the full port name even with the provider:
package { '.*/databases/mytop':
> ensure => installed,
> provider => freebsd,
> }
>
Now it is giving me this message: *puppet-agent[3232]: (/Stage[main]//Node[*
*###**]/Package[.*/databases/mytop]/ensure) change from absent to
present failed: Could not fetch ports INDEX: 500 Illegal PORT range
rejected.*
Even with specifiying a source:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/ I don't
seem to be getting very far!
Here is a print out of the debug log:
debug: Puppet::Type::Package::ProviderFreebsd: Executing
> '/usr/sbin/pkg_info -aoQ'
> debug: Package: .*/databases/mytop: origin => {:port_name=>"mytop",
> :port_category=>"databases"}
> debug: Package: .*/databases/mytop: source => # URL:ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/>
> debug: Fetching INDEX: # URL:ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/INDEX.bz2>
> err:
> /Stage[main]//Node[boomer.sov.m-w.co.uk]/Package[.*/databases/mytop]/ensure:
> change from absent to present failed: Could not fetch ports INDEX: 500
> Illegal PORT range rejected.
>
Some odd behaviour I've noticed as well, when packages are already
installed it doesn't seem to register as them being there.
Looking for information about puppet on FreeBSD is like trying to find a
needle in a haystack. I hope someone can help, any input would be
appreciated!
--
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/-/Bzhfr9UMSNEJ.
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] Puppet and FreeBSD
Howdy:
On Mon, Apr 23, 2012 at 06:29:38AM -0700, Jamie Scott wrote:
> Hello all,
>
> Wondering if any of you could help me.
>
> We've been using puppet on our CentOS servers for a while now with no
> problems at all, very much out of the box but we do have some MySQL
> servers running FreeBSD (for the slightly better memory utilisation). I've
> taken up the challenge to get these FreeBSD servers talking to our puppet
> master but I'm having no ends of trouble with trying to get the manifests
> working. Forgetting the operating system variables and just going for a
> straight install of a package such as mytop this is what I have tried in
> our manifest:
>
> This didn't seem to work at all:
>
> package { 'mytop': ensure => installed }
> >
>
> Gave me this message on the server: *puppet-agent[3232]:
> (/Stage[main]/Node[###]/Package[mytop]/ensure) change from absent
> to present failed: mytop: not in required origin format:
> .*//*
>
To get rid of this error you have to build the puppet from ports
on the freebsd client host and uncheck the PACKAGE_ORIGIN option.
I don't pretend to understand why.
cd /usr/ports/sysutils/puppet ; make install
# cat /var/db/ports/puppet/options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for puppet-2.7.12
_OPTIONS_READ=puppet-2.7.12
WITHOUT_MONGREL=true
WITHOUT_PACKAGE_ORIGIN=true
WITHOUT_PACKAGE_ROOT=true
The below package stanza looks correct.
-dkw
>
> So instead I tried listing the full port name even with the provider:
>
> package { '.*/databases/mytop':
> > ensure => installed,
> > provider => freebsd,
> > }
> >
>
> Now it is giving me this message: *puppet-agent[3232]: (/Stage[main]//Node[*
> *###**]/Package[.*/databases/mytop]/ensure) change from absent to
> present failed: Could not fetch ports INDEX: 500 Illegal PORT range
> rejected.*
>
> Even with specifiying a source:
> ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/ I don't
> seem to be getting very far!
>
> Here is a print out of the debug log:
>
> debug: Puppet::Type::Package::ProviderFreebsd: Executing
> > '/usr/sbin/pkg_info -aoQ'
> > debug: Package: .*/databases/mytop: origin => {:port_name=>"mytop",
> > :port_category=>"databases"}
> > debug: Package: .*/databases/mytop: source => # > URL:ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/>
> > debug: Fetching INDEX: # > URL:ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/INDEX.bz2>
> > err:
> > /Stage[main]//Node[boomer.sov.m-w.co.uk]/Package[.*/databases/mytop]/ensure:
> >
> > change from absent to present failed: Could not fetch ports INDEX: 500
> > Illegal PORT range rejected.
> >
>
> Some odd behaviour I've noticed as well, when packages are already
> installed it doesn't seem to register as them being there.
>
> Looking for information about puppet on FreeBSD is like trying to find a
> needle in a haystack. I hope someone can help, any input would be
> appreciated!
>
> --
> 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/-/Bzhfr9UMSNEJ.
> 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: Only write file if copy on master is present
Hi, On Monday, 23 April 2012 13:59:00 UTC+1, Dennis Jacobfeuerborn wrote: > Thanks, this looks like it will do the trick. The lack of puppet:// > support probably means I will have to hard-code a path to a directory > somewhere but that shouldn't be to big of a deal. > [...] Apologies for that :-( Adding support for "puppet://" is quite tricky (there is a lot going on under-the-hood with this one), and I never have the time to do it (unless somebody is willing to help out and/or sponsor). For the time being, please bare with fully-qualified paths ... KW -- 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/-/EkfQJ_W21WUJ. 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] Puppet and FreeBSD
dkw, that worked!
Now I only need to use: package { 'mytop': ensure => installed }
I can't tell you how happy I am!
Thank you!!!
Jamie
On Monday, 23 April 2012 14:54:03 UTC+1, dkw wrote:
>
> Howdy:
>
> On Mon, Apr 23, 2012 at 06:29:38AM -0700, Jamie Scott wrote:
> > Hello all,
> >
> > Wondering if any of you could help me.
> >
> > We've been using puppet on our CentOS servers for a while now with no
> > problems at all, very much out of the box but we do have some MySQL
> > servers running FreeBSD (for the slightly better memory utilisation).
> I've
> > taken up the challenge to get these FreeBSD servers talking to our
> puppet
> > master but I'm having no ends of trouble with trying to get the
> manifests
> > working. Forgetting the operating system variables and just going for a
> > straight install of a package such as mytop this is what I have tried in
> > our manifest:
> >
> > This didn't seem to work at all:
> >
> > package { 'mytop': ensure => installed }
> > >
> >
> > Gave me this message on the server: *puppet-agent[3232]:
> > (/Stage[main]/Node[###]/Package[mytop]/ensure) change from
> absent
> > to present failed: mytop: not in required origin format:
> > .*//*
> >
>
> To get rid of this error you have to build the puppet from ports
> on the freebsd client host and uncheck the PACKAGE_ORIGIN option.
> I don't pretend to understand why.
>
> cd /usr/ports/sysutils/puppet ; make install
>
> # cat /var/db/ports/puppet/options
> # This file is auto-generated by 'make config'.
> # No user-servicable parts inside!
> # Options for puppet-2.7.12
> _OPTIONS_READ=puppet-2.7.12
> WITHOUT_MONGREL=true
> WITHOUT_PACKAGE_ORIGIN=true
> WITHOUT_PACKAGE_ROOT=true
>
> The below package stanza looks correct.
>
> -dkw
>
> >
> > So instead I tried listing the full port name even with the provider:
> >
> > package { '.*/databases/mytop':
> > > ensure => installed,
> > > provider => freebsd,
> > > }
> > >
> >
> > Now it is giving me this message: *puppet-agent[3232]:
> (/Stage[main]//Node[*
> > *###**]/Package[.*/databases/mytop]/ensure) change from absent
> to
> > present failed: Could not fetch ports INDEX: 500 Illegal PORT range
> > rejected.*
> >
> > Even with specifiying a source:
> > ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/ I
> don't
> > seem to be getting very far!
> >
> > Here is a print out of the debug log:
> >
> > debug: Puppet::Type::Package::ProviderFreebsd: Executing
> > > '/usr/sbin/pkg_info -aoQ'
> > > debug: Package: .*/databases/mytop: origin => {:port_name=>"mytop",
> > > :port_category=>"databases"}
> > > debug: Package: .*/databases/mytop: source => # > > URL:ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/
> >
> > > debug: Fetching INDEX: # > > URL:
> ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/INDEX.bz2
> >
> > > err:
> > > /Stage[main]//Node[boomer.sov.m-w.co.uk]/Package[.*/databases/mytop]/ensure:
> > >
>
> > > change from absent to present failed: Could not fetch ports INDEX: 500
> > > Illegal PORT range rejected.
> > >
> >
> > Some odd behaviour I've noticed as well, when packages are already
> > installed it doesn't seem to register as them being there.
> >
> > Looking for information about puppet on FreeBSD is like trying to find a
> > needle in a haystack. I hope someone can help, any input would be
> > appreciated!
> >
> > --
> > 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/-/Bzhfr9UMSNEJ.
> > 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 view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/IXZpcVO-beAJ.
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] Puppet and FreeBSD
On Mon, Apr 23, 2012 at 07:08:48AM -0700, Jamie Scott wrote:
> dkw, that worked!
>
> Now I only need to use: package { 'mytop': ensure => installed }
How have you been handling the differences between centos/rhel and
fbsd? If statements? I am going the other way where I have manifests
written mostly for fbsd and now will add rhel/debian specific stuff.
Augeas has been a great help mangling text files. The devs on IRC
#augeas are helpful too.
Regards,
-dkw
>
> I can't tell you how happy I am!
>
> Thank you!!!
> Jamie
>
>
>
> On Monday, 23 April 2012 14:54:03 UTC+1, dkw wrote:
> >
> > Howdy:
> >
> > On Mon, Apr 23, 2012 at 06:29:38AM -0700, Jamie Scott wrote:
> > > Hello all,
> > >
> > > Wondering if any of you could help me.
> > >
> > > We've been using puppet on our CentOS servers for a while now with no
> > > problems at all, very much out of the box but we do have some MySQL
> > > servers running FreeBSD (for the slightly better memory utilisation).
> > I've
> > > taken up the challenge to get these FreeBSD servers talking to our
> > puppet
> > > master but I'm having no ends of trouble with trying to get the
> > manifests
> > > working. Forgetting the operating system variables and just going for a
> > > straight install of a package such as mytop this is what I have tried in
> > > our manifest:
> > >
> > > This didn't seem to work at all:
> > >
> > > package { 'mytop': ensure => installed }
> > > >
> > >
> > > Gave me this message on the server: *puppet-agent[3232]:
> > > (/Stage[main]/Node[###]/Package[mytop]/ensure) change from
> > absent
> > > to present failed: mytop: not in required origin format:
> > > .*//*
> > >
> >
> > To get rid of this error you have to build the puppet from ports
> > on the freebsd client host and uncheck the PACKAGE_ORIGIN option.
> > I don't pretend to understand why.
> >
> > cd /usr/ports/sysutils/puppet ; make install
> >
> > # cat /var/db/ports/puppet/options
> > # This file is auto-generated by 'make config'.
> > # No user-servicable parts inside!
> > # Options for puppet-2.7.12
> > _OPTIONS_READ=puppet-2.7.12
> > WITHOUT_MONGREL=true
> > WITHOUT_PACKAGE_ORIGIN=true
> > WITHOUT_PACKAGE_ROOT=true
> >
> > The below package stanza looks correct.
> >
> > -dkw
> >
> > >
> > > So instead I tried listing the full port name even with the provider:
> > >
> > > package { '.*/databases/mytop':
> > > > ensure => installed,
> > > > provider => freebsd,
> > > > }
> > > >
> > >
> > > Now it is giving me this message: *puppet-agent[3232]:
> > (/Stage[main]//Node[*
> > > *###**]/Package[.*/databases/mytop]/ensure) change from absent
> > to
> > > present failed: Could not fetch ports INDEX: 500 Illegal PORT range
> > > rejected.*
> > >
> > > Even with specifiying a source:
> > > ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/ I
> > don't
> > > seem to be getting very far!
> > >
> > > Here is a print out of the debug log:
> > >
> > > debug: Puppet::Type::Package::ProviderFreebsd: Executing
> > > > '/usr/sbin/pkg_info -aoQ'
> > > > debug: Package: .*/databases/mytop: origin => {:port_name=>"mytop",
> > > > :port_category=>"databases"}
> > > > debug: Package: .*/databases/mytop: source => # > > > URL:ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/
> > >
> > > > debug: Fetching INDEX: # > > > URL:
> > ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/INDEX.bz2
> > >
> > > > err:
> > > > /Stage[main]//Node[boomer.sov.m-w.co.uk]/Package[.*/databases/mytop]/ensure:
> > > >
> >
> > > > change from absent to present failed: Could not fetch ports INDEX: 500
> > > > Illegal PORT range rejected.
> > > >
> > >
> > > Some odd behaviour I've noticed as well, when packages are already
> > > installed it doesn't seem to register as them being there.
> > >
> > > Looking for information about puppet on FreeBSD is like trying to find a
> > > needle in a haystack. I hope someone can help, any input would be
> > > appreciated!
> > >
> > > --
> > > 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/-/Bzhfr9UMSNEJ.
> > > 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 view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/IXZpcVO-beAJ.
> 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.
>
Re: [Puppet Users] Testing a single module
In your situation I would set up a virtual machine on my laptop where I would merrily munge mail service at will. (Or a VM anywhere else for similar fun.) If you break something you can roll back to your known good snapshot and try again. On Mon, Apr 23, 2012 at 06:10:59AM -0700, James Patterson wrote: >Thanks for your reply. I do not have reliable access to an internet >connection at the moment. > >Just to flesh out my problem a bit more: I need to update my sendmail >module, but want to test it first. I have two puppet environments (dev and >prod), but mail is critical in both. Ideally I would choose a single host >on which to test if my changes worked, then push it everywhere if >everything works. > >I tried your puppet apply command, but this failed (probably because I >only have the modules on the puppet master, and modulepath is empty). >Copying the puppet module to a specific host seems like I am going in the >wrong direction. > >I considered adding testing flag to my module, which would pull in >"module::testing" instead of "module", but this seems hacky and a >replacement for versioning (does puppet do module versioning?). > >So I suppose I am asking for a nicer way to do what you suggest, or am I >approaching this from the wrong direction? > >Thanks. > >-- >James Patterson >[1]jamespatter...@operamail.com > > >On Thu, Apr 12, 2012, at 10:10 AM, Gary Larizza wrote: > > James, > > If the modules are in your modulepath and environments are defined in > puppet.conf, you can actually use puppet apply to declare classes from > the command line. For example, if you just wanted to test the > nginx::config class you could run: puppet apply -v -e 'include > nginx::config' This (specifically the -e flag with the code you want > to pass in quotes) allows you to 'test' a specific class out-of-band > from your regular Puppet runs. DO NOTE, HOWEVER, that 'test' in this > sense means that it will ACTUALLY DECLARE THE CLASS AND PERFORM THE > ACTION! If this is not what you want, you'll still need to add the > --noop flag to SIMULATE the code. You can also create individual files > in your modules 'tests' directory and declare them with puppet apply too > (if you need more than just one line to test your code - a la Defined > Resource Types). Note that you can ALSO pass the environment from the > command line with '--environment test'. > > Does this help? > > On Thu, Apr 12, 2012 at 7:00 AM, James Patterson > <[2]jamespatter...@operamail.com> wrote: > >Hello, > >I have a production puppet environment that is working well. > >Now more people are developing modules for it we are using a test >environment using environment=test in the puppet.conf file. >This prevents changes to modules in the production environment being >affected by changes in the test environment. So far so good. > >By module I mean class, in case it's the wrong class. > >1. I need to test a change to a single module on a production server, >without breaking all other production servers. >I could put this single production server into the test environment, >but >this has the danger of pulling in changes from other people's modules >as >well. >Should I create yet another environment to do this? > >2. Can I define certain modules as being taken from another >environment, >the "test" environment, for example? > >Thanks in advance, > >-- > James Patterson > [3]jamespatter...@operamail.com > >-- >[4]http://www.fastmail.fm - Same, same, but different... > >-- >You received this message because you are subscribed to the Google >Groups "Puppet Users" group. >To post to this group, send email to [5]puppet-users@googlegroups.com. >To unsubscribe from this group, send email to >[6]puppet-users+unsubscr...@googlegroups.com. >For more options, visit this group at >[7]http://groups.google.com/group/puppet-users?hl=en. > > > > -- > > Gary Larizza > Professional Services Engineer > Puppet Labs > > > > -- > 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. > > > > -- > http://www.fastmail.fm - Send your email first class > >-- >You received this message because
Re: [Puppet Users] Puppet and FreeBSD
Breaking in late... I use some defaults to ensure I get binary packages out of
my local mirror. (I'm not terribly fussed about binary-only packages, possibly
because I come from a Linux background.)
case $::operatingsystem {
freebsd: {
# For this we still have to specify freebsd'ish names. Instead of
# 'ntp', we have to use 'net/ntp'.
Package {
provider => 'freebsd',
source => 'http://repos/pub/FreeBSD/ports/amd64/packages-9.0-release/',
}
}
}
Then as mentioned above:
package { 'net/ntp': }
I found that if I specified other styles of package names with the freebsd
package provider they would be reinstalled with every puppet run.
For some modules I use the 'include "module::$operatingsystem"' syntax, for
others I use a case statement. I'm still undecided which is better, but so far
it depends how much systems diverge from each other on a per-module basis.
On Mon, Apr 23, 2012 at 07:08:48AM -0700, Jamie Scott wrote:
>dkw, that worked!
>
>Now I only need to use: package { 'mytop': ensure => installed }
>
>I can't tell you how happy I am!
>
>Thank you!!!
>Jamie
>
>On Monday, 23 April 2012 14:54:03 UTC+1, dkw wrote:
>
> Howdy:
>
> On Mon, Apr 23, 2012 at 06:29:38AM -0700, Jamie Scott wrote:
> > Hello all,
> >
> > Wondering if any of you could help me.
> >
> > We've been using puppet on our CentOS servers for a while now with no
> > problems at all, very much out of the box but we do have some
> MySQL
> > servers running FreeBSD (for the slightly better memory utilisation).
> I've
> > taken up the challenge to get these FreeBSD servers talking to our
> puppet
> > master but I'm having no ends of trouble with trying to get the
> manifests
> > working. Forgetting the operating system variables and just going for
> a
> > straight install of a package such as mytop this is what I have tried
> in
> > our manifest:
> >
> > This didn't seem to work at all:
> >
> > package { 'mytop': ensure => installed }
> > >
> >
> > Gave me this message on the server: *puppet-agent[3232]:
> > (/Stage[main]/Node[###]/Package[mytop]/ensure) change from
> absent
> > to present failed: mytop: not in required origin format:
> > .*//*
> >
>
> To get rid of this error you have to build the puppet from ports
> on the freebsd client host and uncheck the PACKAGE_ORIGIN option.
> I don't pretend to understand why.
>
> cd /usr/ports/sysutils/puppet ; make install
>
> # cat /var/db/ports/puppet/options
> # This file is auto-generated by 'make config'.
> # No user-servicable parts inside!
> # Options for puppet-2.7.12
> _OPTIONS_READ=puppet-2.7.12
> WITHOUT_MONGREL=true
> WITHOUT_PACKAGE_ORIGIN=true
> WITHOUT_PACKAGE_ROOT=true
>
> The below package stanza looks correct.
>
> -dkw
>
> >
> > So instead I tried listing the full port name even with the provider:
> >
> > package { '.*/databases/mytop':
> > > ensure => installed,
> > > provider => freebsd,
> > > }
> > >
> >
> > Now it is giving me this message: *puppet-agent[3232]:
> (/Stage[main]//Node[*
> > *###**]/Package[.*/databases/mytop]/ensure) change from absent
> to
> > present failed: Could not fetch ports INDEX: 500 Illegal PORT range
> > rejected.*
> >
> > Even with specifiying a source:
> > [1]ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/
> I don't
> > seem to be getting very far!
> >
> > Here is a print out of the debug log:
> >
> > debug: Puppet::Type::Package::ProviderFreebsd: Executing
> > > '/usr/sbin/pkg_info -aoQ'
> > > debug: Package: .*/databases/mytop: origin => {:port_name=>"mytop",
> > > :port_category=>"databases"}
> > > debug: Package: .*/databases/mytop: source => # > >
>
> URL:[2]ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/>
> > > debug: Fetching INDEX: # > >
>
> URL:[3]ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/INDEX.bz2>
> > > err:
> > >
>
> /Stage[main]//Node[[4]boomer.sov.m-w.co.uk]/Package[.*/databases/mytop]/ensure:
> > > change from absent to present failed: Could not fetch ports INDEX:
> 500
> > > Illegal PORT range rejected.
> > >
> >
> > Some odd behaviour I've noticed as well, when packages are already
> > installed it doesn't seem to register as them being there.
> >
> > Looking for information about puppet on FreeBSD is like trying to find
> a
> > needle in a haystack. I hope someone can help, any input would be
> > appreciated!
> >
> > --
> > You received this mes
[Puppet Users] How to check if an MSI has not been removed in Windows?
Hello, I'm using the Package feature to perform the installation of MSI files on Windows. However, if the user performing the uninstall the MSI, I'm not having as require you to reinstall automatically. How can I do this? Thank you. -- 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] access variables from calling ressource
My previous understanding on what hiera is trying to accomplish was simply wrong. I moved all data to hiera and am now a happy camper :) -- 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/-/cfIPS2lE4fYJ. 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: Only write file if copy on master is present
I didn't mean to imply that this was your fault and I already knew that the puppet support probably was missing because it's quite tricky to implement. Since I've started looking into writing my own functions and modules and get a bit deeper into puppet I might actually look into this myself if I find the time. If I make any progress there you can expect a pull request for the changes :) On Monday, April 23, 2012 3:57:08 PM UTC+2, matti wrote: > > Hi, > > On Monday, 23 April 2012 13:59:00 UTC+1, Dennis Jacobfeuerborn wrote: > >> Thanks, this looks like it will do the trick. The lack of puppet:// >> support probably means I will have to hard-code a path to a directory >> somewhere but that shouldn't be to big of a deal. >> > [...] > > Apologies for that :-( > > Adding support for "puppet://" is quite tricky (there is a lot going on > under-the-hood with this one), and I never have the time to do it (unless > somebody is willing to help out and/or sponsor). > > For the time being, please bare with fully-qualified paths ... > > KW > -- 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/-/NAMjjrnooXwJ. 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] Puppet and FreeBSD
On Mon, Apr 23, 2012 at 10:42:53AM -0400, Christopher Wood wrote:
> Breaking in late... I use some defaults to ensure I get binary packages out
> of my local mirror. (I'm not terribly fussed about binary-only packages,
> possibly because I come from a Linux background.)
>
> case $::operatingsystem {
> freebsd: {
> # For this we still have to specify freebsd'ish names. Instead of
> # 'ntp', we have to use 'net/ntp'.
> Package {
> provider => 'freebsd',
> source => 'http://repos/pub/FreeBSD/ports/amd64/packages-9.0-release/',
> }
> }
> }
That repository source statement is pretty powerful stuff and will
help us out extremely here. Have you tried to get puppet to do
make install? The outcome is probably too variable anyhow.
That is pretty clear case syntax too. I have seen that on the
puppetlabs site too.
Here is some background on the freebsd provider giving the error:
"not in required origin format: .*//"
http://www.mail-archive.com/puppet-dev@googlegroups.com/msg13765.html
>
> Then as mentioned above:
>
> package { 'net/ntp': }
>
> I found that if I specified other styles of package names with the freebsd
> package provider they would be reinstalled with every puppet run.
>
I have been OK specifying only the package and not half of the ports
directory tree so far.
> For some modules I use the 'include "module::$operatingsystem"' syntax, for
> others I use a case statement. I'm still undecided which is better, but so
> far it depends how much systems diverge from each other on a per-module basis.
>
>
> On Mon, Apr 23, 2012 at 07:08:48AM -0700, Jamie Scott wrote:
> >dkw, that worked!
> >
> >Now I only need to use: package { 'mytop': ensure => installed }
> >
> >I can't tell you how happy I am!
> >
> >Thank you!!!
> >Jamie
> >
> >On Monday, 23 April 2012 14:54:03 UTC+1, dkw wrote:
> >
> > Howdy:
> >
> > On Mon, Apr 23, 2012 at 06:29:38AM -0700, Jamie Scott wrote:
> > > Hello all,
> > >
> > > Wondering if any of you could help me.
> > >
> > > We've been using puppet on our CentOS servers for a while now with no
> > > problems at all, very much out of the box but we do have some
> > MySQL
> > > servers running FreeBSD (for the slightly better memory utilisation).
> > I've
> > > taken up the challenge to get these FreeBSD servers talking to our
> > puppet
> > > master but I'm having no ends of trouble with trying to get the
> > manifests
> > > working. Forgetting the operating system variables and just going for
> > a
> > > straight install of a package such as mytop this is what I have tried
> > in
> > > our manifest:
> > >
> > > This didn't seem to work at all:
> > >
> > > ? ? ?package { 'mytop': ensure => installed } ? ?
> > > >
> > >
> > > ?Gave me this message on the server: *puppet-agent[3232]:
> > > (/Stage[main]/Node[###]/Package[mytop]/ensure) change from
> > absent
> > > to present failed: mytop: not in required origin format:
> > > .*//*
> > >
> >
> > To get rid of this error you have to build the puppet from ports
> > on the freebsd client host and uncheck the PACKAGE_ORIGIN option.
> > I don't pretend to understand why.
> >
> > cd /usr/ports/sysutils/puppet ; make install
> >
> > # cat /var/db/ports/puppet/options
> > # This file is auto-generated by 'make config'.
> > # No user-servicable parts inside!
> > # Options for puppet-2.7.12
> > _OPTIONS_READ=puppet-2.7.12
> > WITHOUT_MONGREL=true
> > WITHOUT_PACKAGE_ORIGIN=true
> > WITHOUT_PACKAGE_ROOT=true
> >
> > The below package stanza looks correct.
> >
> > -dkw
> >
> > >
> > > So instead I tried listing the full port name even with the provider:
> > >
> > > ? ? package { '.*/databases/mytop':
> > > > ? ? ? ? ? ? ensure => installed,
> > > > ? ? ? ? ? ? provider => freebsd,
> > > > ? ? ? ? ? ? } ? ?
> > > >
> > > ?
> > > Now it is giving me this message: *puppet-agent[3232]:
> > (/Stage[main]//Node[*
> > > *###**]/Package[.*/databases/mytop]/ensure) change from
> > absent
> > to
> > > present failed: Could not fetch ports INDEX: 500 Illegal PORT range
> > > rejected.*
> > >
> > > Even with specifiying a source:
> > > [1]ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/
> > ?I don't
> > > seem to be getting very far!
> > >
> > > Here is a print out of the debug log:
> > >
> > > debug: Puppet::Type::Package::ProviderFreebsd: Executing
> > > > '/usr/sbin/pkg_info -aoQ'
> > > > debug: Package: .*/databases/mytop: origin => {:port_name=>"mytop",
> > > > :port_category=>"databases"}
> > > > debug: Package: .*/databases/mytop: source => # > > >
> >
> > URL:
Re: [Puppet Users] Puppet and FreeBSD
(inline)
On Mon, Apr 23, 2012 at 03:22:37PM +, Darryl Wisneski wrote:
> On Mon, Apr 23, 2012 at 10:42:53AM -0400, Christopher Wood wrote:
> > Breaking in late... I use some defaults to ensure I get binary packages out
> > of my local mirror. (I'm not terribly fussed about binary-only packages,
> > possibly because I come from a Linux background.)
> >
> > case $::operatingsystem {
> > freebsd: {
> > # For this we still have to specify freebsd'ish names. Instead of
> > # 'ntp', we have to use 'net/ntp'.
> > Package {
> > provider => 'freebsd',
> > source =>
> > 'http://repos/pub/FreeBSD/ports/amd64/packages-9.0-release/',
> > }
> > }
> > }
>
>
> That repository source statement is pretty powerful stuff and will
> help us out extremely here. Have you tried to get puppet to do
> make install? The outcome is probably too variable anyhow.
I've never tried this, but in my environment I wouldn't want the divergence. I
also need to shorten maintenance windows, so I can't wait for the compilation
to finish on a production machine.
> That is pretty clear case syntax too. I have seen that on the
> puppetlabs site too.
>
> Here is some background on the freebsd provider giving the error:
> "not in required origin format: .*//"
>
> http://www.mail-archive.com/puppet-dev@googlegroups.com/msg13765.html
>
> >
> > Then as mentioned above:
> >
> > package { 'net/ntp': }
> >
> > I found that if I specified other styles of package names with the freebsd
> > package provider they would be reinstalled with every puppet run.
> >
>
> I have been OK specifying only the package and not half of the ports
> directory tree so far.
Now I'm really wondering how I managed that.
> > For some modules I use the 'include "module::$operatingsystem"' syntax, for
> > others I use a case statement. I'm still undecided which is better, but so
> > far it depends how much systems diverge from each other on a per-module
> > basis.
> >
> >
> > On Mon, Apr 23, 2012 at 07:08:48AM -0700, Jamie Scott wrote:
> > >dkw, that worked!
> > >
> > >Now I only need to use: package { 'mytop': ensure => installed }
> > >
> > >I can't tell you how happy I am!
> > >
> > >Thank you!!!
> > >Jamie
> > >
> > >On Monday, 23 April 2012 14:54:03 UTC+1, dkw wrote:
> > >
> > > Howdy:
> > >
> > > On Mon, Apr 23, 2012 at 06:29:38AM -0700, Jamie Scott wrote:
> > > > Hello all,
> > > >
> > > > Wondering if any of you could help me.
> > > >
> > > > We've been using puppet on our CentOS servers for a while now with
> > > no
> > > > problems at all, very much out of the box but we do have some
> > > MySQL
> > > > servers running FreeBSD (for the slightly better memory
> > > utilisation).
> > > I've
> > > > taken up the challenge to get these FreeBSD servers talking to our
> > > puppet
> > > > master but I'm having no ends of trouble with trying to get the
> > > manifests
> > > > working. Forgetting the operating system variables and just going
> > > for
> > > a
> > > > straight install of a package such as mytop this is what I have
> > > tried
> > > in
> > > > our manifest:
> > > >
> > > > This didn't seem to work at all:
> > > >
> > > > ? ? ?package { 'mytop': ensure => installed } ? ?
> > > > >
> > > >
> > > > ?Gave me this message on the server: *puppet-agent[3232]:
> > > > (/Stage[main]/Node[###]/Package[mytop]/ensure) change from
> > > absent
> > > > to present failed: mytop: not in required origin format:
> > > > .*//*
> > > >
> > >
> > > To get rid of this error you have to build the puppet from ports
> > > on the freebsd client host and uncheck the PACKAGE_ORIGIN option.
> > > I don't pretend to understand why.
> > >
> > > cd /usr/ports/sysutils/puppet ; make install
> > >
> > > # cat /var/db/ports/puppet/options
> > > # This file is auto-generated by 'make config'.
> > > # No user-servicable parts inside!
> > > # Options for puppet-2.7.12
> > > _OPTIONS_READ=puppet-2.7.12
> > > WITHOUT_MONGREL=true
> > > WITHOUT_PACKAGE_ORIGIN=true
> > > WITHOUT_PACKAGE_ROOT=true
> > >
> > > The below package stanza looks correct.
> > >
> > > -dkw
> > >
> > > >
> > > > So instead I tried listing the full port name even with the
> > > provider:
> > > >
> > > > ? ? package { '.*/databases/mytop':
> > > > > ? ? ? ? ? ? ensure => installed,
> > > > > ? ? ? ? ? ? provider => freebsd,
> > > > > ? ? ? ? ? ? } ? ?
> > > > >
> > > > ?
> > > > Now it is giving me this message: *puppet-agent[3232]:
> > > (/Stage[main]//Node[*
> > > > *###**]/Package[.*/databases/mytop]/ensure) change from
> > > absent
> > > to
> > > > present failed: Could not fetch ports INDEX: 500 Illegal PORT ran
Re: [Puppet Users] Puppet and FreeBSD
>How have you been handling the differences between centos/rhel and >fbsd? If statements? I am going the other way where I have manifests >written mostly for fbsd and now will add rhel/debian specific stuff. A lot of it is hack and slash with modules for the net, we've been adding in the operatingsystem variable for path and package names where needed. I've come into a company that uses puppet and I only started using it 4 weeks ago, hoping to make a lot of improvements as time goes on. We've used augeas a lot for our my.cnf files and it's proved very useful! -- 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/-/13nRwlHHzWYJ. 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] RSpec test to verify variable/parameter declaration
I have a module in which parameterized classes inherit regular (non- parameterized) 'params' class. I am writing RSpec tests for this module and would like to make sure that required variables have been declared in the params class. Also, is it possible to write RSpec test to make sure that these variables/parameters are accepted by the required parameterized classes? Any pointers will be really helpful. -- Thanks, Shantanu Pavgi -- 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] HA with BIG-IP?
Hi, Is there anyone using BIG-IP to load balance client side connections to multiple puppet masters? I'm looking for advice on a configuration, specifically: * How to handle SSL. Should I try to decrypt client side traffic at the BIG-IP? If so, should LB <-> BIG-IP traffic be unencrypted via HTTP? I have seen this scenario described in Pro Puppet. I would think I would run into problems verifying clients at the PM if I decrypt at the load balancers. * How are you deploying health monitors for the PM's? Thanks, Josh -- 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] How to check if an MSI has not been removed in Windows?
2012/4/23 André Luiz : > I'm using the Package feature to perform the installation of MSI files > on Windows. However, if the user performing the uninstall the MSI, I'm > not having as require you to reinstall automatically. How can I do > this? This is on the roadmap for things to improve for windows platform: https://projects.puppetlabs.com/issues/11868 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.
Re: [Puppet Users] HA with BIG-IP?
Hi Josh, It would depend on whether an F5 can be made to write the necessary information into an HTTP header. What I would do to is look at how Apache populates the SSL_CLIENT_S_DN and SSL_CLIENT_VERIFY headers when you use it as a Puppet Master front end and see if you can replicate that on an F5. F5 iRules are quite powerful so I'd say it might be possible but probably not straight out of the box. As for a health monitor I'm not sure... Puppet Masters are RESTful so you might be able to come up with something tricky with that. -Luke On 23/04/12 16:53, Josh wrote: Hi, Is there anyone using BIG-IP to load balance client side connections to multiple puppet masters? I'm looking for advice on a configuration, specifically: * How to handle SSL. Should I try to decrypt client side traffic at the BIG-IP? If so, should LB<-> BIG-IP traffic be unencrypted via HTTP? I have seen this scenario described in Pro Puppet. I would think I would run into problems verifying clients at the PM if I decrypt at the load balancers. * How are you deploying health monitors for the PM's? Thanks, Josh -- Luke Bigum Information Systems Ph: +44 (0) 20 3192 2520 luke.bi...@lmax.com | http://www.lmax.com LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN FX and CFDs are leveraged products that can result in losses exceeding your deposit. They are not suitable for everyone so please ensure you fully understand the risks involved. The information in this email is not directed at residents of the United States of America or any other jurisdiction where trading in CFDs and/or FX is restricted or prohibited by local laws or regulations. The information in this email and any attachment is confidential and is intended only for the named recipient(s). The email may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not the intended recipient please notify the sender immediately and delete any copies of this message. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. LMAX operates a multilateral trading facility. Authorised and regulated by the Financial Services Authority (firm registration number 509778) and is registered in England and Wales (number 06505809). Our registered address is Yellow Building, 1A Nicholas Road, London, W11 4AN. -- 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] How to check if an MSI has not been removed in Windows?
Hi André, On Mon, Apr 23, 2012 at 9:12 AM, Nan Liu wrote: > 2012/4/23 André Luiz : > > I'm using the Package feature to perform the installation of MSI files > > on Windows. However, if the user performing the uninstall the MSI, I'm > > not having as require you to reinstall automatically. How can I do > > this? > > This is on the roadmap for things to improve for windows platform: > > https://projects.puppetlabs.com/issues/11868 > > Thanks, > > Nan I have a branch that uses the Windows Installer automation interfaces install, query, etc the state of installed MSIs. We're looking at getting this merged soon. https://github.com/joshcooper/puppet/tree/ticket/2.7.x/11868-msi-provider Josh -- Josh Cooper Developer, Puppet Labs -- 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: Only write file if copy on master is present
Hi, On Monday, 23 April 2012 16:14:59 UTC+1, Dennis Jacobfeuerborn wrote: [...] > If I make any progress there you can expect a pull request for the changes > :) > [...] Thank you! That's very kind :) Let me know if I can help and/or we can join efforts. KW -- 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/-/FSqkMxG3cyEJ. 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] Install module
Hi!! When i install or copy a module with the extra name "username-mymodule-version" in my module path, Puppet can't find the classes inside the module when node make a request. I don't know if i should rename the module into "mymodule" for that works!!! Thx. -- 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/-/oUp7TYHlU90J. 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] RSpec test to verify variable/parameter declaration
On 23/04/2012 16:51, Shantanu wrote: I have a module in which parameterized classes inherit regular (non- parameterized) 'params' class. I am writing RSpec tests for this module and would like to make sure that required variables have been declared in the params class. Also, is it possible to write RSpec test to make sure that these variables/parameters are accepted by the required parameterized classes? Any pointers will be really helpful. Funnily enough I was asking a similar thing on IRC the other day but didn't get much luck. We're implementing Hiera across modules that require significant amounts of variables. We have a lot of environments (>20) and we often get problems where someone introduces a new variable, adds it to a template and tests it in dev but dont add a default, or add it to each environment, therefore catalog compilation fails in non-dev environments. Ideally I'd like to be able to catch this with rspec-puppet but can't see an easy way to say "class bar should have variable foo and it shouldn't be undefined", or something when sourcing variables from other classes or hiera. Craig -- Craig Dunn | http://www.craigdunn.org Yahoo/Skype: craigrdunn | Twitter: @crayfishX -- 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] Regression in SUSE package for puppet-dashboard-1.2.7
Actually ruby(abi) is defined as a Provides in ruby.spec for SuSE, see
link below, but I don't know why it fails to pick it up. You can
simply force the puppet-dashboard package with --nodeps and it works
just fine.
https://build.opensuse.org/package/view_file?file=ruby.spec&package=ruby&project=openSUSE%3A12.1%3AUpdate&rev=dbf21799e3d1bb8b3b21b5aa109d7530
--
Later,
Darin
On Fri, Apr 20, 2012 at 11:54 AM, Jeffrey Watts
wrote:
> SuSE doesn't use the ruby(abi) dependencies. That's a Red Hat thing. The
> good news is that it's trivial to rebuild the RPM so that it works with
> SLES. I posted a diff a while back on this list - it's what I use.
>
> Keep in mind that this was for an older version, so YMMV. Good luck.
> Jeffrey.
>
> $ diff puppet-dashboard.spec puppet-dashboard.spec-sles
> 2c2
> < %global initrddir /etc/rc.d/init.d
> ---
>> %global initrddir /etc/init.d
> 9c9
> < Release: 1%{?dist}
> ---
>> Release: 2%{?dist}
> 17,18c17,18
> < Requires: ruby(abi) = 1.8, rubygems, ruby-mysql
> < Requires: ruby > 1.8.7, rubygem(rake)
> ---
>> Requires: rubygems, ruby-mysql
>> Requires: ruby > 1.8.7, rubygem-rake
> 22,25d21
> < Requires(post): chkconfig
> < Requires(preun): chkconfig
> < Requires(preun): initscripts
> < Requires(postun): initscripts
> 137a134,136
>> * Wed Dec 07 2011 Jeffrey Watts - 1.2.3-2
>> - Modified it to work on SLES
>>
>
> On Fri, Apr 20, 2012 at 2:44 AM, Julien C. wrote:
>>
>> Hi,
>>
>> I'm using the following repository :
>>
>> http://download.opensuse.org/repositories/home:/eclipseagent:/puppet/openSUSE_12.1/
>>
>> And I'm having a weird error when I try to update puppet-dashboard :
>> Problem: nothing provides ruby(abi) = 1.8.7 needed by
>> puppet-dashboard-1.2.7-6.1.noarch
>>
>> My ruby (1.8.7.p357-2.3.1.i586) seems up-to-date and I didn't have this
>> message when I installed 1.2.6
>> Any idea what I'm missing ?
>
> --
> 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] Trying to build Ruby 1.8.7 on a RHEL5 systems
http://www.ruby-lang.org/ I think is what he meant. On Thu, Apr 19, 2012 at 3:54 PM, Dan White wrote: > - Jo Rhett wrote: >> For ruby, go to ruby.org and find the latest patchlevel for 1.8.7 and put >> that number at the top of the spec file. >> > > FYI: ruby.org is a parked domain. > > “Sometimes I think the surest sign that intelligent life exists elsewhere in > the universe is that none of it has tried to contact us.” > Bill Waterson (Calvin & Hobbes) > > -- > 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: Install module
On Apr 23, 11:41 am, Yves Ntonfo wrote: > Hi!! > > When i install or copy a module with the extra name > "username-mymodule-version" in my module path, Puppet can't find the > classes inside the module when node make a request. I don't know if i > should rename the module into "mymodule" for that works!!! Class and module names should not contain hyphens (-). They may contain underscores (_), however, so you could try switching to those. 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: How to check if an MSI has not been removed in Windows?
Thank you for your collaboration. I will seek some way to solve this problem until now has this native on Puppet. If I get a satisfactory solution, to give back to the community collaboration. On 23 abr, 13:27, Josh Cooper wrote: > Hi André, > > On Mon, Apr 23, 2012 at 9:12 AM, Nan Liu wrote: > > 2012/4/23 André Luiz : > > > I'm using the Package feature to perform the installation of MSI files > > > on Windows. However, if the user performing the uninstall the MSI, I'm > > > not having as require you to reinstall automatically. How can I do > > > this? > > > This is on the roadmap for things to improve for windows platform: > > >https://projects.puppetlabs.com/issues/11868 > > > Thanks, > > > Nan > > I have a branch that uses the Windows Installer automation interfaces > install, query, etc the state of installed MSIs. We're looking at getting > this merged soon. > > https://github.com/joshcooper/puppet/tree/ticket/2.7.x/11868-msi-prov... > > Josh > > -- > Josh Cooper > Developer, Puppet Labs -- 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] Regression in SUSE package for puppet-dashboard-1.2.7
I should have clarified - I'm using SLES10 and 11 and ruby(abi) isn't provided See here: > rpm -q ruby --provides /usr/bin/ruby bigdecimal.so()(64bit) bubblebabble.so()(64bit) cparse.so()(64bit) curses.so()(64bit) dbm.so()(64bit) digest.so()(64bit) dl.so()(64bit) etc.so()(64bit) fcntl.so()(64bit) gdbm.so()(64bit) iconv.so()(64bit) libruby.so.1.8()(64bit) md5.so()(64bit) nkf.so()(64bit) openssl.so()(64bit) pty.so()(64bit) readline.so()(64bit) rmd160.so()(64bit) sdbm.so()(64bit) sha1.so()(64bit) sha2.so()(64bit) socket.so()(64bit) stringio.so()(64bit) strscan.so()(64bit) syck.so()(64bit) syslog.so()(64bit) thread.so()(64bit) wait.so()(64bit) zlib.so()(64bit) ruby = 1.8.7.p72-5.30.5 Jeffrey. On Mon, Apr 23, 2012 at 1:38 PM, Darin Perusich wrote: > Actually ruby(abi) is defined as a Provides in ruby.spec for SuSE, see > link below, but I don't know why it fails to pick it up. You can > simply force the puppet-dashboard package with --nodeps and it works > just fine. > > > https://build.opensuse.org/package/view_file?file=ruby.spec&package=ruby&project=openSUSE%3A12.1%3AUpdate&rev=dbf21799e3d1bb8b3b21b5aa109d7530 > > -- 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: HA with BIG-IP?
Thanks, Luke. I'm going to pipe HTTPS straight thru the BIG-IP's to the PM's for now. Josh On Apr 23, 12:19 pm, Luke Bigum wrote: > Hi Josh, > > It would depend on whether an F5 can be made to write the necessary > information into an HTTP header. What I would do to is look at how > Apache populates the SSL_CLIENT_S_DN and SSL_CLIENT_VERIFY headers when > you use it as a Puppet Master front end and see if you can replicate > that on an F5. F5 iRules are quite powerful so I'd say it might be > possible but probably not straight out of the box. > > As for a health monitor I'm not sure... Puppet Masters are RESTful so > you might be able to come up with something tricky with that. > > -Luke > > On 23/04/12 16:53, Josh wrote: > > > > > > > > > > > Hi, > > > Is there anyone using BIG-IP to load balance client side connections > > to multiple puppet masters? I'm looking for advice on a > > configuration, specifically: > > > * How to handle SSL. Should I try to decrypt client side traffic at > > the BIG-IP? If so, should LB<-> BIG-IP traffic be unencrypted via > > HTTP? I have seen this scenario described in Pro Puppet. I would > > think I would run into problems verifying clients at the PM if I > > decrypt at the load balancers. > > > * How are you deploying health monitors for the PM's? > > > Thanks, > > > Josh > > -- > Luke Bigum > > Information Systems > Ph: +44 (0) 20 3192 2520 > luke.bi...@lmax.com |http://www.lmax.com > LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN > > FX and CFDs are leveraged products that can result in losses exceeding > your deposit. They are not suitable for everyone so please ensure you > fully understand the risks involved. The information in this email is not > directed at residents of the United States of America or any other > jurisdiction where trading in CFDs and/or FX is restricted or prohibited > by local laws or regulations. > > The information in this email and any attachment is confidential and is > intended only for the named recipient(s). The email may not be disclosed > or used by any person other than the addressee, nor may it be copied in > any way. If you are not the intended recipient please notify the sender > immediately and delete any copies of this message. Any unauthorised > copying, disclosure or distribution of the material in this e-mail is > strictly forbidden. > > LMAX operates a multilateral trading facility. Authorised and regulated > by the Financial Services Authority (firm registration number 509778) and > is registered in England and Wales (number 06505809). > Our registered address is Yellow Building, 1A Nicholas Road, London, W11 > 4AN. -- 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] Creating a system module path (starting with Telly)
There was some discussion and concern about moving the Nagios types/providers out of the core area of Puppet for Telly. We made a mistake of talking about a point solution to a problem rather than the vision on where we’d like it to go, and why. We’ve attempted to outline this a bit more so you can hopefully have a better understanding of our ideas. As always, feel free to comment and voice concerns. This isn’t set in stone and at this point is a proposal. == The Problem == Bundling types and providers into the core of Puppet has a few problems. The most important problem is that it ties releases of the types or providers to releases of core Puppet. That is a pretty slow moving (for stability) system, and it is also a system where most of the investment goes into supporting new releases rather than improving older releases. We want to keep our core stable, while allowing the community platform experts, distro maintainers and other users to enhance the experience with certain aspects of Puppet without having to wait for the next major release. The secondary problem is that it plays favourites - some platform types are in core, others are not. Some monitoring systems, or disk management systems are in core, others are not. That doesn't reflect the real importance of those types, or that some are more special or more stable than others - just happenstance of time. On the other hand, having Puppet work out of the box is awesome. You should be able to install Puppet and immediately get started, managing your platform and generally doing awesome things. Puppet with no types, and no providers, is not awesome. It can't do anything - and "install twenty things, then ..." is not a good introductory experience. == Proposed Solution == We want to take some of the great lessons from other platforms - Perl, Python, and Ruby - and apply them to this problem: We are proposing to pull more types and providers out of Puppet, so they get the benefit of an independent release cycle, and the advantages of full forge integration. We also propose to have a "system" module path: a set of modules that ship with core Puppet, taken from the forge, and available by default at install time. They will ensure that Puppet is still awesome out of the box - but that you can list modules and their versions, and can update freely. We also plan a "vendor" module path, and a "site" module path. Other platforms have shown the value of this: when distributions package Puppet, they might want more or different modules to support their systems better. Allowing them to drop into the vendor module path and operate in the same way as our system modules makes it easy to use normal modules in an awesome way. Finally, the "site" module path allows for easy deployment of modules through other packaging systems like yum and apt, internally to companies and sites that want a different path for versioning modules. They separate the mutable path used by the local tool and the managed path for self-packaged modules. This seems to offer the best of both worlds: we can take full advantage of the strengths of modules, but without giving up the awesomeness of Puppet that does great things out of the box. -- 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] Announce: Facter 1.6.8 Available
Facter 1.6.8 is a maintenance release candidate with bug fixes and
improvements.
It includes contributions from the following people: Stefan Schulte, Ken
Barber.
This release is available for download at:
http://downloads.puppetlabs.com/facter/facter-1.6.8.tar.gz
http://downloads.puppetlabs.com/mac/facter-1.6.8.dmg
http://apt.puppetlabs.com
http://yum.puppetlabs.com
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.8:
http://projects.puppetlabs.com/projects/facter/
Full Release Notes at:
https://projects.puppetlabs.com/projects/facter/wiki/Wiki
Facter 1.6.8 Release Notes
==
(#12831) Add rspec tests to have_which method in Resolution
Tests cases were originally provided by Ken Barber:
Previously we had no coverage of this important method. This adds very
basic
testing, including failure testing for Windows.
(#12831) Fix recursion on first kernel fact resolution
We encounter a recursion if we want to detect the kernel fact for the
first
time:
The kernel codeblock calls
Facter::Util::Resolution.exec("uname -s")
and Facter::Util::Resolution#exec wants to detect if we can use `which`
to get the full path of the command. But the method
Facter::Util::Resolution#have_which tries to query the kernel fact again
to check if we are on windows.
Change the check in have_which so we dont have to query the kernel fact.
Facter 1.6.8 Changelog
===
Stefan Shulte (2):
b86fe4c (#12831) Add rspec tests to have_which method in Resolution
70be957 (#12831) Fix recursion on first kernel fact resolution
--
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] Announce: Puppet 2.7.14rc2 Available
Puppet 2.7.14rc2 is a maintenance release candidate for Puppet in the 2.7.x series. Downloads are available: * Source http://downloads.puppetlabs.com/puppet/puppet-2.7.14rc2.tar.gz ## Bug Fixes ## (#14060) Fix quoting of commands to interpolate inside the shell. The `shell` exec provider was supposed to emulate the behaviour of 0.25 exec, which was to pass the content through the default shell to get it executed. Unfortunately, it got quoting a bit wrong, and ended up interpolating variables at the wrong point - it used double quotes where single quotes were really what was desired. Thanks to Matthew Byng-Maddick for the report, and a fix to the quoting; in the end we should not be in this position - we shouldn't be using string execution where we can pass an array instead. That avoids any chance that there is more than one round of shell interpolation entirely. As a bonus, this fixes the base exec type to support specifying the command to run that very way, and making it good. (#14101) Improve deprecation warning for dynamic lookup The new message will tell the user how to get more information about what is occuring. More information will be provided at debug level so that a user can see what the change to the lookup will be. It includes contributions from the following people: Andrew Parker and Daniel Pittman 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 2.7.14rc2: http://projects.puppetlabs.com/projects/puppet Full Release Notes at: http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.14rc2 Puppet 2.7.14rc2 Changelog === Andrew Parker (1): 934ec89 Improve deprecation warning for dynamic lookup Daniel Pittman (2): 796a072 Modernize the style of the shell exec provider tests. 74e462f (#14060) Fix quoting of commands to interpolate inside the shell. -- 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] RSpec test to verify variable/parameter declaration
So, rspec-puppet can't and won't ever work this way. What it's testing is the resulting catalogue of Puppet resources that your host executes (the behaviour of Puppet). Instead of testing that a variable is defined, you should be testing the resource(s) that those variables control/adjust. For example, if your variable changes the templated contents of a file resource, then you should be testing the contents of that file resource. On Monday, 23 April 2012 at 10:06 AM, Craig Dunn wrote: > On 23/04/2012 16:51, Shantanu wrote: > > > > I have a module in which parameterized classes inherit regular (non- > > parameterized) 'params' class. I am writing RSpec tests for this > > module and would like to make sure that required variables have been > > declared in the params class. Also, is it possible to write RSpec test > > to make sure that these variables/parameters are accepted by the > > required parameterized classes? Any pointers will be really helpful. > > > > > Funnily enough I was asking a similar thing on IRC the other day but > didn't get much luck. We're implementing Hiera across modules that > require significant amounts of variables. We have a lot of environments > (>20) and we often get problems where someone introduces a new variable, > adds it to a template and tests it in dev but dont add a default, or add > it to each environment, therefore catalog compilation fails in non-dev > environments. > > Ideally I'd like to be able to catch this with rspec-puppet but can't > see an easy way to say "class bar should have variable foo and it > shouldn't be undefined", or something when sourcing variables from other > classes or hiera. > > Craig > > -- > Craig Dunn | http://www.craigdunn.org > Yahoo/Skype: craigrdunn | Twitter: @crayfishX > > -- > 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 > (mailto:puppet-users@googlegroups.com). > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com > (mailto: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-dev] Creating a system module path (starting with Telly)
I've noticed that nobody else has replied to this but as one of the more vocal people in the original discussion I'd like to state that I love the idea of a vendor and site module path and think this is an ideal way to move these things out of the core. This proposal is much less scary than the previous conversations and at this point is actually a pretty big improvement over the current situation. So, +1 from this guy! On Mon, Apr 23, 2012 at 5:03 PM, Michael Stahnke wrote: > There was some discussion and concern about moving the Nagios > types/providers out of the core area of Puppet for Telly. We made a > mistake of talking about a point solution to a problem rather than the > vision on where we’d like it to go, and why. We’ve attempted to > outline this a bit more so you can hopefully have a better > understanding of our ideas. As always, feel free to comment and voice > concerns. This isn’t set in stone and at this point is a proposal. > > == The Problem == > > Bundling types and providers into the core of Puppet has a few problems. > > The most important problem is that it ties releases of the types or > providers to releases of core Puppet. That is a pretty slow moving > (for stability) system, and it is also a system where most of the > investment goes into supporting new releases rather than improving > older releases. > > We want to keep our core stable, while allowing the community platform > experts, distro maintainers and other users to enhance the experience > with certain aspects of Puppet without having to wait for the next > major release. > > The secondary problem is that it plays favourites - some platform > types are in core, others are not. Some monitoring systems, or disk > management systems are in core, others are not. That doesn't reflect > the real importance of those types, or that some are more special or > more stable than others - just happenstance of time. > > On the other hand, having Puppet work out of the box is awesome. You > should be able to install Puppet and immediately get started, managing > your platform and generally doing awesome things. > > Puppet with no types, and no providers, is not awesome. It can't do > anything - and "install twenty things, then ..." is not a good > introductory experience. > > == Proposed Solution == > > We want to take some of the great lessons from other platforms - Perl, > Python, and Ruby - and apply them to this problem: > > We are proposing to pull more types and providers out of Puppet, so > they get the benefit of an independent release cycle, and the > advantages of full forge integration. > > We also propose to have a "system" module path: a set of modules that > ship with core Puppet, taken from the forge, and available by default > at install time. They will ensure that Puppet is still awesome out of > the box - but that you can list modules and their versions, and can > update freely. > > We also plan a "vendor" module path, and a "site" module path. Other > platforms have shown the value of this: when distributions package > Puppet, they might want more or different modules to support their > systems better. Allowing them to drop into the vendor module path and > operate in the same way as our system modules makes it easy to use > normal modules in an awesome way. > > Finally, the "site" module path allows for easy deployment of modules > through other packaging systems like yum and apt, internally to > companies and sites that want a different path for versioning modules. > They separate the mutable path used by the local tool and the managed > path for self-packaged modules. > > This seems to offer the best of both worlds: we can take full > advantage of the strengths of modules, but without giving up the > awesomeness of Puppet that does great things out of the box. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to puppet-...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?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] Analysing some puppetmaster logs to find out what's happening on an agent
Hi all, in an unfortunate incident, I managed to lock myself out of a client's server. Basically an openssh module that by default disabled remote root logins did that on a server that was only accessed by remote root login (no other use raccounts present on that server). Unfortunately, this is a colocated server and next trip to the dc is scheduled for next thursday. No KVM over IP, no remote hands, pretty much the ideal situation :P. The Xen server is still running, and so are the domU's on it, but this is less then ideal. If any of the domU's goes down, there's nothing we can do :) Now, the puppet agent is running every 30 minutes, but something seems to make it not execute the catalog. I have set the puppetmaster to debug in order to see what's happening, but I can't figure it out. Here's a gist of the puppet master log: https://gist.github.com/2475554 x7 is the offending server, x6 has exactly the same puppet definition. Can anyone tell me why the log for x7 just stops, with no error or nothing? What does that indicate is happening on x7? Any help is much appreciated :) cheers, -- Walter Heck -- follow @walterheck on twitter to see what I'm up to! -- Check out my new startup: Server Monitoring as a Service @ http://tribily.com Follow @tribily on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/tribily -- 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] Analysing some puppetmaster logs to find out what's happening on an agent
I admit I've never read puppetmaster logs like that so what I'm about to say may be very bad advice. Since resources removed from your manifests become unmanaged rather than deleted, why not swap the node's current manifest for one which only re-enables ssh root login? Once you have access you can return to the desired manifest, and use your existing socket to see what gives. This might also be time to consider remote syslog, that way you can see what the node itself is doing. On Tue, Apr 24, 2012 at 10:43:04AM +0800, Walter Heck wrote: > Hi all, > > in an unfortunate incident, I managed to lock myself out of a client's > server. Basically an openssh module that by default disabled remote > root logins did that on a server that was only accessed by remote root > login (no other use raccounts present on that server). Unfortunately, > this is a colocated server and next trip to the dc is scheduled for > next thursday. No KVM over IP, no remote hands, pretty much the ideal > situation :P. The Xen server is still running, and so are the domU's > on it, but this is less then ideal. If any of the domU's goes down, > there's nothing we can do :) > > Now, the puppet agent is running every 30 minutes, but something seems > to make it not execute the catalog. I have set the puppetmaster to > debug in order to see what's happening, but I can't figure it out. > Here's a gist of the puppet master log: > https://gist.github.com/2475554 > > x7 is the offending server, x6 has exactly the same puppet definition. > Can anyone tell me why the log for x7 just stops, with no error or > nothing? What does that indicate is happening on x7? Any help is much > appreciated :) > > cheers, > > -- > Walter Heck > > -- > follow @walterheck on twitter to see what I'm up to! > -- > Check out my new startup: Server Monitoring as a Service @ http://tribily.com > Follow @tribily on Twitter and/or 'Like' our Facebook page at > http://www.facebook.com/tribily > > -- > 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] Analysing some puppetmaster logs to find out what's happening on an agent
In my test environment, I managed to make puppet agent stop working when I update facter package, without restarting puppet. Somehow, when facter updated, puppet is not able to continue working, maybe because the expected version of facter is different or something. It was resolved when I restarted puppet agent. On troubleshooting, did you enable reporting in puppet agent config? If you do, you might want to see the output of the report in /var/lib/puppet/reports/ I noticed my previous issue when I go through the report in that folder. On Tue, Apr 24, 2012 at 10:43 AM, Walter Heck wrote: > Hi all, > > in an unfortunate incident, I managed to lock myself out of a client's > server. Basically an openssh module that by default disabled remote > root logins did that on a server that was only accessed by remote root > login (no other use raccounts present on that server). Unfortunately, > this is a colocated server and next trip to the dc is scheduled for > next thursday. No KVM over IP, no remote hands, pretty much the ideal > situation :P. The Xen server is still running, and so are the domU's > on it, but this is less then ideal. If any of the domU's goes down, > there's nothing we can do :) > > Now, the puppet agent is running every 30 minutes, but something seems > to make it not execute the catalog. I have set the puppetmaster to > debug in order to see what's happening, but I can't figure it out. > Here's a gist of the puppet master log: > https://gist.github.com/2475554 > > x7 is the offending server, x6 has exactly the same puppet definition. > Can anyone tell me why the log for x7 just stops, with no error or > nothing? What does that indicate is happening on x7? Any help is much > appreciated :) > > cheers, > > -- > Walter Heck > > -- > follow @walterheck on twitter to see what I'm up to! > -- > Check out my new startup: Server Monitoring as a Service @ > http://tribily.com > Follow @tribily on Twitter and/or 'Like' our Facebook page at > http://www.facebook.com/tribily > > -- > 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. > > -- Sharuzzaman Ahmat Raslan -- 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 calling stat() on managed symlinks
I've ended up doing as John said and creating file resources for all
of these directories and links instead of syncing from an existing
source.
Works a treat :) Thanks for your help all.
Cheers,
Tim
On Apr 23, 10:58 pm, jcbollinger wrote:
> On Apr 22, 11:41 pm, Tim wrote:
>
>
>
>
>
>
>
>
>
> > Hi All,
>
> > We are seeing an unfortunate side effect using puppet to manage a
> > directory of symlinks pointing to automounted filesystems. It seems
> > that as well as verifying that the link matches the desired target
> > (readlink/lstat), it is also performing an open() on the links and
> > causing the filesystems to be automounted.
>
> > The pattern here is:
>
> > file { "/data":
> > ensure => directory,
> > source => "/nfsmount/links/data",
> > recurse => true,
> > force => true,
>
> > }
>
> > Imagine everything is in the steady state, i.e.:
>
> > symlink /data/fs1 -> /net/server1/fs1 exists
> > symlink /nfsmount/links/data/fs1 -> /net/server1/fs1 exists
>
> > Then at some point in the run (after doing lstat("/data/fs1"),
> > readlink("/data/fs1")), puppet appears to attempt an open("/data/fs1",
> > O_RDONLY).
>
> > IANAE here, but it seems that this open is unnecessary? Once the
> > target of the link in the managed directory is verified to match the
> > target of the link on the source, that should be sufficient?
>
> That sounds sensible, but I don't know whether it's practical; some of
> Puppet's behaviors are constrained by the underlying Ruby libraries.
> In any case, the first thing to try is to set "links => manage" on
> your File resource (not "links => ignore", which cannot work when the
> desired links are not yet present).
>
> The bottom line, however, is that recursive File management has always
> been a sore spot for Puppet, and it probably always will be. It is
> not remotely possible to provide enough information in the parameters
> of a single File resource to cover all the possible permutations of
> desired behavior. Puppet does a fairly good job of coping with that
> when asked to do so, but generally you are better off finding a
> different approach.
>
> If you have a large number of files, then you may be better off
> wrapping the whole thing into a custom package (e.g. an RPM), putting
> that in a local repository or on a network filesystem, and managing
> that package instead of the individual files. If there are only a few
> files (that you want to manage) then by all means set up individual
> file resources for them.
>
> 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] Analysing some puppetmaster logs to find out what's happening on an agent
Hiya, On Tue, Apr 24, 2012 at 10:56, Christopher Wood wrote: > I admit I've never read puppetmaster logs like that so what I'm about to say > may be very bad advice. Any advice is welcome :) > Since resources removed from your manifests become unmanaged rather than > deleted, why not swap the node's current manifest for one which only > re-enables ssh root login? Once you have access you can return to the desired > manifest, and use your existing socket to see what gives. We already have only an exec there (nothing else) that is supposed to copy the sshd config file to an nfs share, which we are 100% certain is mounted. The gist is the output from that. > This might also be time to consider remote syslog, that way you can see what > the node itself is doing. Yes, as soon as we have access back, that is on the todo :) -- Walter Heck -- follow @walterheck on twitter to see what I'm up to! -- Check out my new startup: Server Monitoring as a Service @ http://tribily.com Follow @tribily on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/tribily -- 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] Analysing some puppetmaster logs to find out what's happening on an agent
Hi Sharuzzaman, On Tue, Apr 24, 2012 at 10:59, Sharuzzaman Ahmat Raslan wrote: > In my test environment, I managed to make puppet agent stop working when I > update facter package, without restarting puppet. > > Somehow, when facter updated, puppet is not able to continue working, maybe > because the expected version of facter is different or something. > > It was resolved when I restarted puppet agent. We run puppet off of a cron job, so no restarting is involved. > On troubleshooting, did you enable reporting in puppet agent config? If you > do, you might want to see the output of the report in > /var/lib/puppet/reports/ > > I noticed my previous issue when I go through the report in that folder. I checked and it seems the last report in there is from July 18th. It contains a bunch of errors from when it had the full puppet manifests enabled, but that should be irrelevant now as we only have a single exec in there. Any idea as to why it's not creating new reports? cheers, -- Walter Heck -- follow @walterheck on twitter to see what I'm up to! -- Check out my new startup: Server Monitoring as a Service @ http://tribily.com Follow @tribily on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/tribily -- 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] Recovering deleted modules
Hello, I accidentally deleted a module from my puppetmaster modules directory. Sadly, I didn't have a recent backup or use version control. :( (Live and learn) Is there a way to recover the module from one of the clients or the master? Thanks. -- Alex -- 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] read server certificate B: certificate verify failed error is driving people crazy
It seems like there must be a better way of dealing with these errors in a puppermaster-agent setup. I currently have one master and one agent that work, running on ubuntu 10.10 (maverick meerkat server). On another machine, same os and hardware, I try installing with the same steps and when I run sudo puppet agent --test --verbose --debug --server , it is constantly hitting: read server certificate B: certificate verify failed I tried all sorts of solutions to this. Cleaning every trace of puppet on the non-working agent, then reinstalling it and trying again. Checked that times agreed and that certificates appeared valid at the given times. The only thing which finally worked was completely wiping both the master and the agent nodes, then reinstalling and starting them up gingerly. I think the problem with this error message is that it is somewhat obtuse, and occurs in far too many cases. It also appears the system with certificates is fragile. Some of the items which may be messing up the certificate chain and ability to straighten it out are: 1. If an agent is running, then running a one-shot puppet agent --test to try and figure out what is happening. Perhaps there needs to be a lock check here even if a user is running puppet agent off the command line if only one agent can run at a time. 2. If the server name is something like rm16 and there is a CNAME from puppet to rm16, is the system still generating proper certificate names for all checks that will be executed? To make the system run and install I've had to first set servname=rm16 in the puppet.conf before starting up the agent. -- 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] Analysing some puppetmaster logs to find out what's happening on an agent
Hi Walter, Ok, I think that narrows it down to cron issue possibility, as you mentioned the other server with the same puppet configurations works well. Reports only generated if puppet is running, even if there are errors. When there are no reports, it could mean that puppet is not running, or things that should execute puppet (eg. cron) is not running. It looks like nothing you can do remotely right now, other than physical access to the server. Maybe others will have better suggestion. On Tue, Apr 24, 2012 at 1:12 PM, Walter Heck wrote: > Hi Sharuzzaman, > > On Tue, Apr 24, 2012 at 10:59, Sharuzzaman Ahmat Raslan > wrote: > > In my test environment, I managed to make puppet agent stop working when > I > > update facter package, without restarting puppet. > > > > Somehow, when facter updated, puppet is not able to continue working, > maybe > > because the expected version of facter is different or something. > > > > It was resolved when I restarted puppet agent. > We run puppet off of a cron job, so no restarting is involved. > > > On troubleshooting, did you enable reporting in puppet agent config? If > you > > do, you might want to see the output of the report in > > /var/lib/puppet/reports/ > > > > I noticed my previous issue when I go through the report in that folder. > I checked and it seems the last report in there is from July 18th. It > contains a bunch of errors from when it had the full puppet manifests > enabled, but that should be irrelevant now as we only have a single > exec in there. Any idea as to why it's not creating new reports? > > cheers, > > -- > Walter Heck > > -- > follow @walterheck on twitter to see what I'm up to! > -- > Check out my new startup: Server Monitoring as a Service @ > http://tribily.com > Follow @tribily on Twitter and/or 'Like' our Facebook page at > http://www.facebook.com/tribily > > -- > 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. > > -- Sharuzzaman Ahmat Raslan -- 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.
