AW: [Puppet Users] Undo
I'm not aware of any undo functions in Puppet. I think the only thing you can do is do create a proper user configuration for your Suse and Solaris boxes and let Puppet fix it. Bernd Von: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] Im Auftrag von root Gesendet: Dienstag, 17. April 2012 20:55 An: puppet-users@googlegroups.com Betreff: [Puppet Users] Undo So.. I am evaluating Puppet Enterprise 2.5. I was messing with Live Management and I cloned a user account to all my nodes instead of just one. This overwrote the account settings on all my Solaris and SUSE with the account data from a RHEL server. I'd like to know how I would undo this, please. -- 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/-/bFlN11NuA3sJ. To post to this group, send email to puppet-users@googlegroups.commailto:puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.commailto: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] Looking for solution on working configuration for new testing Puppet servers in existing environments
Hello folks, After some conversation on #puppet on Freenode IRC, Eric Sorenson requested I repost the information and question here, so I am doing so and hopefully it will all make sense... We currently have a well-established and relatively complex Puppet setup in place at my company and I'm in the process of trying to streamline changes as well as implement better testing to ensure minimal disruption or issues when making those changes. Some information on the current situation: - There are currently three environments: development, staging, production. These are controlled via the '--environment' setting for puppet in each client. All clients only belong to one environment and do not move between them. - We have a single Puppet configuration to manage all environments. Various conditional statements based on environment, application type, hostname, etc. control what each client receives for its configuration. - There are separate servers for each environment for security reasons (primarily sensitive information that can only exist in the production environment). - The Puppet configuration maintained via a Git repo, currently on a single branch. - Each person on the admin team checks out own copy of the repo, make changes, commits the changes, then updates each environment on the Puppet servers for the changes to take effect. There are several issues with this process, unfortunately: - Every so often a configuration mistake will adversely affect an entire environment, and much of the time is only noticed _after_ the changes are pushed out. As a result, local changes tend to be made in the development environment for testing and sometimes aren't committed for a long time, leaving discrepancies between the environments which can lead to other subtle issues. - Less frequent but still occuring often enough, changes can still have subtle issues which cause things to work in one environment and break horribly in another; this is especially bad when the broken environment is the production one. - The configuration for a given type of client is complex enough that to change a client to a different application type (what we primarily key most of our configuration off of, followed by the environment) to test against a server would require rebuilding the client, which is a 25-45 minute process; too slow for simple changes and even too slow for all but the most complex changes, given how many changes we make in a single day. - We allow our users to create local VMs that the development Puppet server can key off their names to create a given configuration, but since the configuration for the various environments is shared in a Puppet configuration, potential for users point their puppet agents to the production environment is a concern (due to the sensitive information there). After discussion with a few coworkers, the following process was laid out to try to implement to resolve these issues: - Create separate branches for each of the environments and have only the matching branch checked out on the primary Puppet servers; changes will be merged into the various branches one at a time to prevent unintentional changes in a given environment before testing can be done on that environment. - Ensure a client in a given environment can ONLY run against that configuration (e.g. disallow a client in the development environment requesting the production configuration). - Each person on the admin team will have a test server where they can create their own branches from the Git repo for the changes they're working and use their test server to test changes against existing clients in the various environments (preventing the need to build out a new test client(s) to validate each change). The existing clients would only be run in no-op mode against the test servers. The reason for each person on the admin team to have their own test server that has access to all the environments is considered since: - Having a different server for each environment would be affected by the tight hardware resources currently. - The need for having separate test servers would prevent needing to use the primary servers for testing, which is difficult due to multiple admins continuously making changes and needing to test them without disturbing the other admins' work, along with not affecting the current primary servers from being able to properly handle their existing clients. What this all boils down to is I'm trying to find a way to deal with a single test server trying to be able to communicate with existing clients in all the environments; most of the current configuration would work fine except for the cert issue, which is the sticking point at this time. Any solution on how to handle this in the most straightforward manner would greatly be appreciated, as my research has been leading to solutions far more complex than what I would like (such as load balancing for the CA or trying to synchronize the certs across the various
[Puppet Users] Puppet agent hostname/domain change
Hi Everybody, I have a puppet setup working, but run into issue, which couldn't figure out how to solve. Say I have puppet agent generated certificate and signed it on puppet master. If somehow puppet agent's hostname has been changed it will stop communication with puppet master. I would like to know if there is a way to be able to change hostname of puppet agent, without interruption of communication between master and agent. Thanks, Artyom -- 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/-/59luyETIc-0J. 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] Generating dhcp/pxe configuration from puppet
Hello, I want to generate my infrastructure's dhcp/pxe config from puppet, but to go through the node definitions? Btw. we only use explicit definitions, no regexp. So everything is explicit. I thought about using Puppet::Parser...something ... any hints? Thanks for you help! Christian -- 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: AW: [Puppet Users] Undo
If you're really really lucky you can look in ${vardir}/clientbucket on
an Agent (usually /var/lib/puppet/clientbucket) and ${vardir}/bucket on
the Master. They are backup directories of files that Puppet replaces,
keyed on the MD5 sum of the file. Unfortunately I don't think the User
providers file bucket /etc/passwd and /etc/shadow though, but you can
always check.
You're only other option is to Bernd's suggestion of Puppetify the
Solaris and SUSE versions of the account and change them back.
On 18/04/12 07:58, Bernd Adamowicz wrote:
I'm not aware of any undo functions in Puppet. I think the only thing
you can do is do create a proper user configuration for your Suse and
Solaris boxes and let Puppet fix it.
Bernd
*Von:*puppet-users@googlegroups.com
[mailto:puppet-users@googlegroups.com] *Im Auftrag von *root
*Gesendet:* Dienstag, 17. April 2012 20:55
*An:* puppet-users@googlegroups.com
*Betreff:* [Puppet Users] Undo
So.. I am evaluating Puppet Enterprise 2.5. I was messing with Live
Management and I cloned a user account to all my nodes instead of just
one. This overwrote the account settings on all my Solaris and SUSE
with the account data from a RHEL server. I'd like to know how I
would undo this, please.
--
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/-/bFlN11NuA3sJ.
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.
--
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] Generating dhcp/pxe configuration from puppet
If you wanted to do this all in Puppet, you could take the same approach that people do with Nagios an use exported resources. Have each of your nodes export some kind of resource that describes what it's DHCP configuration would be based on it's IP and MAC address Facts, then collect those resources on your DHCP server and write out your config file(s). http://docs.puppetlabs.com/guides/exported_resources.html If you wanted to do this outside of Puppet then you could parse all of your node's Facts cache (/var/lib/puppet/yaml/facts on my machine) but that assumes all the information you need is in Facter. On 18/04/12 08:22, Christian Requena wrote: Hello, I want to generate my infrastructure's dhcp/pxe config from puppet, but to go through the node definitions? Btw. we only use explicit definitions, no regexp. So everything is explicit. I thought about using Puppet::Parser...something ... any hints? Thanks for you help! Christian -- 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. -- 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] Virtual resources for a list of server ip addresses in Apache config
I have an internal web site that can only be accessed from other servers.
It seems to me that I should pass an array of the addresses to the class
that instantiates the template for the Apache configuration. That seems
easy.
The hard part is getting every node to register itself so that it's IP
address is added to the array.
I imagine using virtual resources, e.g. something like
define website::client {
$website::clients += [ $title ]
}
and in each node definition (specifically outside the node { ... }
declaration)
@website::client{ $ip_address_of_node: }
and somewhere else
Website::Client | |
I would expect that for every node, it's ip address would be added to the
array. But this doesn't seem to work. In the website class, the $clients
array is never changed from what it is initialized to.
What are the best practices for doing something like this?
Thanks,
Robert
--
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/-/9xKEBi6ZyTcJ.
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] WG: Could not send report: Error 400 on SERVER: execution expired
No ideas? -Ursprüngliche Nachricht- Von: Bernd Adamowicz Gesendet: Montag, 16. April 2012 13:32 An: 'puppet-users@googlegroups.com' Betreff: Could not send report: Error 400 on SERVER: execution expired Hi all! One of my Puppet masters has to compile some 3800 stored configurations which takes a very long time to proceed. Example log: Apr 16 13:17:13 mymaster puppet-agent[15249]: Finished catalog run in 954.58 seconds Apr 16 13:18:35 mymaster puppet-master[11422]: execution expired Apr 16 13:18:35 mymaster puppet-agent[15249]: Could not send report: Error 400 on SERVER: execution expired Seems, this long run leads to the 'execution expired' error. Is there a way to change the timeout for reports? Thanks Bernd -- 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: Virtual resources for a list of server ip addresses in Apache config
I should add that I am using a masterless puppet environment, so a global
list of all nodes is not available.
Some Googling suggested the use of multiple files that are concatenated,
but I think that's a messy kluge, and would like to avoid doing that.
On Wednesday, April 18, 2012 12:38:08 PM UTC+1, Robert Rothenberg wrote:
I have an internal web site that can only be accessed from other servers.
It seems to me that I should pass an array of the addresses to the class
that instantiates the template for the Apache configuration. That seems
easy.
The hard part is getting every node to register itself so that it's IP
address is added to the array.
I imagine using virtual resources, e.g. something like
define website::client {
$website::clients += [ $title ]
}
and in each node definition (specifically outside the node { ... }
declaration)
@website::client{ $ip_address_of_node: }
and somewhere else
Website::Client | |
I would expect that for every node, it's ip address would be added to the
array. But this doesn't seem to work. In the website class, the $clients
array is never changed from what it is initialized to.
What are the best practices for doing something like this?
Thanks,
Robert
--
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/-/tP9dLmF-A74J.
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 agent hostname/domain change
Been there, done that, got a link for you: http://infrastructure.fedoraproject.org/infra/docs/infra-hostrename.txt Basically, clean out the certificate info on the client/agent, clear the old info from the master, and then re-certify the agent/client with the new info. “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) - Artyom Krilov orya...@gmail.com wrote: Hi Everybody, I have a puppet setup working, but run into issue, which couldn't figure out how to solve. Say I have puppet agent generated certificate and signed it on puppet master. If somehow puppet agent's hostname has been changed it will stop communication with puppet master. I would like to know if there is a way to be able to change hostname of puppet agent, without interruption of communication between master and agent. Thanks, Artyom -- 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/-/59luyETIc-0J. 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] $lsbdistcodename stays the same after dist-upgrade
Dear List,
i was running a few natty systems and upgraded one of them to oneiric.
Facter shows the right lsbdistcodename, lsbdistrelease, etc.
parameters, but when i'm running puppet agent the modules has access
to the previous (natty, etc.) values. As i see on puppetmaster in /var/
lib/puppet/yaml/{facts,node} the output from facter and the agent is
cached and won't update (even after 24 hours). How could i update
these values so my templates will have the right values from the
parameters?
Best regards,
Mate
--
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: file type with links = follow uses wrong permissions if not explicit
On Apr 17, 10:42 am, Adam Heinz a...@metricwise.net wrote:
I think I've hit a minor permissions bug using
puppet-2.6.13-2.el6.noarch from EPEL on CentOS 6. In order to
reproduce production bugs on a test environment, I use puppet to copy
the latest backup to a test server, followed by the remainder of the
puppet-driven configuration necessary. I just started using symlinks,
so I added links = follow to the file type.
File {
group = root,
owner = root,
}
file { /var/lib/mysql/backups/current.sql.gz:
backup = false,
links = follow,
source = puppet:///files/backups/current.sql.gz,
}
When I kicked puppet on the test machine, it set the file permissions
to the permissions of the link itself, not the file the link pointed
to.
Apr 17 10:55:37 test1 puppet-agent[1807]:
(/Stage[main]/Testserver/File[/var/lib/mysql/backups/current.sql.gz]/mode)
mode changed '644' to '777'
So the obvious workaround is to explicitly set the permissions on the
file type, instead of relying on puppet to preserve the permissions of
the source file.
puppetmaster # ls -l /var/lib/mysql/backups
-rw-r--r-- 1 root root 4330512 Apr 17 00:22 2012-04-17.sql.gz
lrwxrwxrwx 1 root root 14 Apr 17 10:45 current.sql.gz -
2012-04-17.sql.gz
Put in a bug for this? (I don't currently appear to have permissions to do
so.)
At minimum the documentation should be improved here, so I would
suggest you file a ticket.
Puppet does not document what mode is applied when the manifest does
not specify one, however, so I wouldn't characterize this as a bug per
se. Nevertheless, the behavior you expected would be reasonable, and
perhaps a feature request on this subject would be accepted.
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: Undo
On Apr 18, 3:17 am, Luke Bigum luke.bi...@lmax.com wrote:
If you're really really lucky you can look in ${vardir}/clientbucket on
an Agent (usually /var/lib/puppet/clientbucket) and ${vardir}/bucket on
the Master. They are backup directories of files that Puppet replaces,
keyed on the MD5 sum of the file. Unfortunately I don't think the User
providers file bucket /etc/passwd and /etc/shadow though, but you can
always check.
As far as I know, Puppet only filebuckets files managed by File
resources. These are potentially irreplaceable otherwise, whereas
file modifications performed indirectly via other resource types are
-- at least in principle -- undoable by managing the affected resource
back to the original state, as Bernd suggests.
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: Puppet agent hostname/domain change
On Apr 17, 11:34 pm, Artyom Krilov orya...@gmail.com wrote: Hi Everybody, I have a puppet setup working, but run into issue, which couldn't figure out how to solve. Say I have puppet agent generated certificate and signed it on puppet master. If somehow puppet agent's hostname has been changed it will stop communication with puppet master. I would like to know if there is a way to be able to change hostname of puppet agent, without interruption of communication between master and agent. You may be able to use the 'certname' parameter in the client's puppet.conf to cause it to continue to present the old certificate, but that's a hack, especially if your nodes generally identify themselves to the master (via their cerificates) according to their (current) hostnames. Note that the certname is what gets matched to node declarations, but the $::hostname fact is always the actual hostname, so mucking with certnames on an ad hoc basis may produce surprises later. Note especially that if there is any chance that the original hostname will be re-used by a different node, then the original and new nodes cannot both identify themselves to the master by the same identifier unless you copy the certificate from one to the other. In that case, the two will always receive the same configuration, their reports will be conflated on the master, and other badness may ensue. If you want always to be able to change nodes' hostnames without re- certifying them to the master, then you should make *all* your nodes use certnames based on some unchanging node property, such as asset number or MAC address. Changing over to such a policy will require you to re-certify every node, of course, and you will need to adjust your ENC and / or nodes.pp correspondingly, but afterward you will be able to change any node's hostname without interrupting its communication with the master. If changing hostnames is generally a one-off for you, then you are much better off simply re-certifying the modified node to the master afterwards. Be sure to revoke the old certificate and clean it from the master (in that order). 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: Having trouble getting puppet to set users/groups to a defined state
On Apr 17, 5:04 pm, Steve Roberts strob...@strobe.net wrote: On Apr 17, 6:25 am, jcbollinger john.bollin...@stjude.org wrote: well, allowdupe doesn't fix the issue only masks it. I knew about taht attribute but it just adds a duped group instead of making right the user/group. Indeed, but that's what you asked about. That is possible. That general class of problems is one of many reasons to avoid sharing management responsibilities for any given set of resources among multiple agents (including humans). If it does happen, then the failure is probably good, because it signals admins that there is something they need to investigate. Well, I'm not worried about when the human has been told they can make changes but rather when a human (or bad tool) makes a change nad it slips through the cracks initially and goes boom later. I don't understand what you're looking for. You started off dissatisfied that Puppet goes boom immediately, yet you don't want the system to go boom later, either. You understandably don't want to create groups with duplicate gids. What behavior would you actually like to see? Puppet gives the appearance of a lot of intelligence, but it has a long way to go before it can pass a Turing test. Until then, it's unreasonable to expect DWIM. :) Puppet also has a mechanism by which you can ensure that otherwise- unmanaged resources of some types are all ensured absent. That's both very powerful and very dangerous, and I advise you to avoid it at least until you have more experience with Puppet. To that end, I'm leaving it as an exercise to determine just what the mechanism is. I may have to poke on how puppet does that. we actually do an absolute /etc/passwd (and friends) in our current conf man system. and yes it does have its pitfalls too. You can do that with Puppet as well, if you prefer, but you cannot safely mix that approach with using User and Group resources. 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: Puppet agent hostname/domain change
Thanks for detailed explanation. Using certname seems to be fine. I'll create some unchanging property as a fact and will use it in manifests. Thanks, Artyom On Wednesday, April 18, 2012 5:29:24 PM UTC+4, jcbollinger wrote: On Apr 17, 11:34 pm, Artyom Krilov orya...@gmail.com wrote: Hi Everybody, I have a puppet setup working, but run into issue, which couldn't figure out how to solve. Say I have puppet agent generated certificate and signed it on puppet master. If somehow puppet agent's hostname has been changed it will stop communication with puppet master. I would like to know if there is a way to be able to change hostname of puppet agent, without interruption of communication between master and agent. You may be able to use the 'certname' parameter in the client's puppet.conf to cause it to continue to present the old certificate, but that's a hack, especially if your nodes generally identify themselves to the master (via their cerificates) according to their (current) hostnames. Note that the certname is what gets matched to node declarations, but the $::hostname fact is always the actual hostname, so mucking with certnames on an ad hoc basis may produce surprises later. Note especially that if there is any chance that the original hostname will be re-used by a different node, then the original and new nodes cannot both identify themselves to the master by the same identifier unless you copy the certificate from one to the other. In that case, the two will always receive the same configuration, their reports will be conflated on the master, and other badness may ensue. If you want always to be able to change nodes' hostnames without re- certifying them to the master, then you should make *all* your nodes use certnames based on some unchanging node property, such as asset number or MAC address. Changing over to such a policy will require you to re-certify every node, of course, and you will need to adjust your ENC and / or nodes.pp correspondingly, but afterward you will be able to change any node's hostname without interrupting its communication with the master. If changing hostnames is generally a one-off for you, then you are much better off simply re-certifying the modified node to the master afterwards. Be sure to revoke the old certificate and clean it from the master (in that order). John -- 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/-/lG8CuX8nyCsJ. 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 agent hostname/domain change
In this case if hostname changes are frequent I'll get too much unnecessary traffic. On Wednesday, April 18, 2012 4:35:43 PM UTC+4, Ygor wrote: Been there, done that, got a link for you: http://infrastructure.fedoraproject.org/infra/docs/infra-hostrename.txt Basically, clean out the certificate info on the client/agent, clear the old info from the master, and then re-certify the agent/client with the new info. “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) - Artyom Krilov orya...@gmail.com wrote: Hi Everybody, I have a puppet setup working, but run into issue, which couldn't figure out how to solve. Say I have puppet agent generated certificate and signed it on puppet master. If somehow puppet agent's hostname has been changed it will stop communication with puppet master. I would like to know if there is a way to be able to change hostname of puppet agent, without interruption of communication between master and agent. Thanks, Artyom -- 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/-/59luyETIc-0J. 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/-/dhJiviFbymcJ. 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: Looking for solution on working configuration for new testing Puppet servers in existing environments
Hi Ken, thanks for posting. It seems like you have introduced some tension between the security requirements (clients which are in a particular environment must not be able to retrieve other environments) and the need to have widespread testing with good coverage. From what I understand you've managed this now by having different CA certificates for each environment, but -- as it sounds like you realise -- that is pretty problematic. I'd suggest you can end-run around a lot of this trouble by using an external node classifier to set and enforce client environment, so regardless of what the --environment string says from the client, each of the masters will consistently enforce policy. You don't have to go all-in to node class/parameter assignment in the ENC because static configs are merged with the output. A prerequisite is that you need to have some source of truth which the ENCs can consult to determine the disposition of each node that connects, but that source-of-truth could be an access-controlled database (maybe you already have one?) that is, in general, going to be a better place to put business logic (which nodes should be able to access each environment, and even perhaps some of the conditional logic in your manifests) than Puppet itself. This isn't without its own set of problems and might not be a panacea but I think would help a lot of your use case. Some relevant reading: http://docs.puppetlabs.com/guides/external_nodes.html https://projects.puppetlabs.com/issues/3910 https://projects.puppetlabs.com/issues/12869 Hope this helps - Eric Sorenson - N37 17.255 W121 55.738 - http://twitter.com/ahpook - On Tuesday, April 17, 2012 7:34:43 PM UTC-7, Ken Lareau wrote: Hello folks, After some conversation on #puppet on Freenode IRC, Eric Sorenson requested I repost the information and question here, so I am doing so and hopefully it will all make sense... We currently have a well-established and relatively complex Puppet setup in place at my company and I'm in the process of trying to streamline changes as well as implement better testing to ensure minimal disruption or issues when making those changes. Some information on the current situation: - There are currently three environments: development, staging, production. These are controlled via the '--environment' setting for puppet in each client. All clients only belong to one environment and do not move between them. - We have a single Puppet configuration to manage all environments. Various conditional statements based on environment, application type, hostname, etc. control what each client receives for its configuration. - There are separate servers for each environment for security reasons (primarily sensitive information that can only exist in the production environment). - The Puppet configuration maintained via a Git repo, currently on a single branch. - Each person on the admin team checks out own copy of the repo, make changes, commits the changes, then updates each environment on the Puppet servers for the changes to take effect. There are several issues with this process, unfortunately: - Every so often a configuration mistake will adversely affect an entire environment, and much of the time is only noticed _after_ the changes are pushed out. As a result, local changes tend to be made in the development environment for testing and sometimes aren't committed for a long time, leaving discrepancies between the environments which can lead to other subtle issues. - Less frequent but still occuring often enough, changes can still have subtle issues which cause things to work in one environment and break horribly in another; this is especially bad when the broken environment is the production one. - The configuration for a given type of client is complex enough that to change a client to a different application type (what we primarily key most of our configuration off of, followed by the environment) to test against a server would require rebuilding the client, which is a 25-45 minute process; too slow for simple changes and even too slow for all but the most complex changes, given how many changes we make in a single day. - We allow our users to create local VMs that the development Puppet server can key off their names to create a given configuration, but since the configuration for the various environments is shared in a Puppet configuration, potential for users point their puppet agents to the production environment is a concern (due to the sensitive information there). After discussion with a few coworkers, the following process was laid out to try to implement to resolve these issues: - Create separate branches for each of the environments and have only the matching branch checked out on the primary Puppet servers; changes will be merged into the various branches one at a time to prevent
[Puppet Users] Re: Looking for solution on working configuration for new testing Puppet servers in existing environments
I'll take a stab at some of this. Hopefully I'm correctly understanding your issue. Am I correct in the following? : You define 3 environments development, staging, and production. These environments are defined as such in Puppet but they are also separate environments within your network, for the sake of clarity I'll call them zones from here out? Each zone has a Puppet Master server. Each Puppet Master server has three environments defined development, staging, and production. Each environment has the full git repository with the applicable branch checked out. The clients in each zone connect to the Puppet Master in their zone and pull their configs from the corresponding environment. So a staging_zone_client connects to staging_zone_master and pulls from the staging_environment. If that's correct then: You already have three separate Puppet Masters so the environments are redundant. As configured staging_zone_client can pull from production_environment using --environment. One fix could be to define only the production environment on each zone's Puppet Master and check out the applicable branch in only the production environment. As long as you never check out the production branch in development or staging then clients from those zones couldn't pull the settings for production zone as it's just not available. As long as they cannot connect to the other zone's Puppet Master, preventable by network segmentation, certs etc... Within each zone you could then define environments such as development and testing for conducting those activities within each zone. So you'd have staging/dev and staging/test branches checked out in those environments. I guess you could extend that and create environments for each admin within each zone that would allow the admin to use the --environment option for clients to test their work within a zone. This would result in a lot of environments, and probably a lot of branches, but you wouldn't need a test Puppet Master for each admin. I'd think this would introduce the problem of making it difficult to reuse modules between zones as I'd think you'd end up basically managing three completely different branches. Unless the sensitive data you're worried about is not being stored in your puppet repo and you have no issues merging changes made to the production branch into the development and testing branches, plus your admins will have a lot of different topic branches to deal with. Long run you'd probably want to move zone specific settings out of your modules and use something like hiera so you can standardize your modules across zones and just pull in the location settings using hiera. Hope I understood your problems correctly and this is helpful.. On Tuesday, April 17, 2012 10:34:43 PM UTC-4, Ken Lareau wrote: Hello folks, After some conversation on #puppet on Freenode IRC, Eric Sorenson requested I repost the information and question here, so I am doing so and hopefully it will all make sense... We currently have a well-established and relatively complex Puppet setup in place at my company and I'm in the process of trying to streamline changes as well as implement better testing to ensure minimal disruption or issues when making those changes. Some information on the current situation: - There are currently three environments: development, staging, production. These are controlled via the '--environment' setting for puppet in each client. All clients only belong to one environment and do not move between them. - We have a single Puppet configuration to manage all environments. Various conditional statements based on environment, application type, hostname, etc. control what each client receives for its configuration. - There are separate servers for each environment for security reasons (primarily sensitive information that can only exist in the production environment). - The Puppet configuration maintained via a Git repo, currently on a single branch. - Each person on the admin team checks out own copy of the repo, make changes, commits the changes, then updates each environment on the Puppet servers for the changes to take effect. There are several issues with this process, unfortunately: - Every so often a configuration mistake will adversely affect an entire environment, and much of the time is only noticed _after_ the changes are pushed out. As a result, local changes tend to be made in the development environment for testing and sometimes aren't committed for a long time, leaving discrepancies between the environments which can lead to other subtle issues. - Less frequent but still occuring often enough, changes can still have subtle issues which cause things to work in one environment and break horribly in another; this is especially bad when the broken environment is the production one. - The configuration for a given
[Puppet Users] Tighter Puppet Dashboard and MCollective integration
I was just thinking about the problem of host groups and such trying to set up our puppet infrastructure properly and came to the realization that using MCollective better in puppet dashboard would allow for more cloud like scaling of infrastructure services. Here is the concept: Right now in puppet dashboard groups can have nodes, facts (parameters) and Classes. What I am suggesting would be the reverse of this -- dynamic groups. Dynamic groups, instead of deciding what nodes get certain facts or classes, would contain an MCollective Query to decide what nodes are applicable for this group. It should also save the results of the last query. If there is a difference between the last query and this query, then these nodes should be added to the group and then an audit entry should be saved to the database. If an agent times out, then it should not be added or removed as it may just be too busy to respond. Doing this will allow external applications to update facts assigned to a specific node and then have puppet dashboard automatically adjust its groups. Obviously things to think about are, what groups does it query when a node gets added? This would have to be groups dependent on the facts, classes or agents that get updated for that node. The point of this is to create an event that could be fired and acted upon by a listening application to perform some action (how would have to be thought about). One of my favorite examples being that it could get added to a load-balancer pool via this event. In concept the dynamic group is just a representation of the pool within puppet-dashboard. But the dynamic group can be the shared representation of this group, as it might be used by a load-balancer and an application deployment system which each have groups of some kind in created in their own program, which have the same nodes, preform the same role, but act on those nodes differently. This would be an add event, there should also be a remove event etc... Events might also be applicable for regular groups as well so that the communication goes both ways. I believe this would extend the use case for puppet in many enterprises by giving them a central repository to group nodes in different ways once, and provide that information to downstream systems. Thoughts? -- 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/-/jUTnJeOvd_sJ. 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: Looking for solution on working configuration for new testing Puppet servers in existing environments
Eric, Thank you for the response, and yes, our current configuration and security requirements have made things a bit difficult at the moment. Fortunately we do already have an ENC which does access an access-controlled database and does have the environment information in it, though we still do pass '--environment' due to this not working long ago... and looking at the first issue ticket you mention, this could be a problem as our developers are allowed to connect their own VMs to the development Puppet server but can easily choose to point '--environment' to whatever they please. In actuality, they can do that now (and it would probably work), so the problem is already there, though I would definitely not want to make it worse. :) Right now our ENC only has a minimal amount of information in it, but the plan is to eventually populate it with more and reduce the amount of work the Puppet configuration has to do itself, as you suggested below. From the brief exchange on IRC this morning, the indication seems to be moving to a single CA should be the follow-up to this, and I think this is doable, though I'm still uncertain what the best path is to handle this. Once that's done, I can then look into improving the security of our systems (as in actually making it secure rather than what it really is right now). Thank you for your input. - Ken Lareau On Wed, Apr 18, 2012 at 7:56 AM, Eric Sorenson eric.soren...@me.com wrote: Hi Ken, thanks for posting. It seems like you have introduced some tension between the security requirements (clients which are in a particular environment must not be able to retrieve other environments) and the need to have widespread testing with good coverage. From what I understand you've managed this now by having different CA certificates for each environment, but -- as it sounds like you realise -- that is pretty problematic. I'd suggest you can end-run around a lot of this trouble by using an external node classifier to set and enforce client environment, so regardless of what the --environment string says from the client, each of the masters will consistently enforce policy. You don't have to go all-in to node class/parameter assignment in the ENC because static configs are merged with the output. A prerequisite is that you need to have some source of truth which the ENCs can consult to determine the disposition of each node that connects, but that source-of-truth could be an access-controlled database (maybe you already have one?) that is, in general, going to be a better place to put business logic (which nodes should be able to access each environment, and even perhaps some of the conditional logic in your manifests) than Puppet itself. This isn't without its own set of problems and might not be a panacea but I think would help a lot of your use case. Some relevant reading: http://docs.puppetlabs.com/guides/external_nodes.html https://projects.puppetlabs.com/issues/3910 https://projects.puppetlabs.com/issues/12869 Hope this helps - Eric Sorenson - N37 17.255 W121 55.738 - http://twitter.com/ahpook - On Tuesday, April 17, 2012 7:34:43 PM UTC-7, Ken Lareau wrote: Hello folks, After some conversation on #puppet on Freenode IRC, Eric Sorenson requested I repost the information and question here, so I am doing so and hopefully it will all make sense... We currently have a well-established and relatively complex Puppet setup in place at my company and I'm in the process of trying to streamline changes as well as implement better testing to ensure minimal disruption or issues when making those changes. Some information on the current situation: - There are currently three environments: development, staging, production. These are controlled via the '--environment' setting for puppet in each client. All clients only belong to one environment and do not move between them. - We have a single Puppet configuration to manage all environments. Various conditional statements based on environment, application type, hostname, etc. control what each client receives for its configuration. - There are separate servers for each environment for security reasons (primarily sensitive information that can only exist in the production environment). - The Puppet configuration maintained via a Git repo, currently on a single branch. - Each person on the admin team checks out own copy of the repo, make changes, commits the changes, then updates each environment on the Puppet servers for the changes to take effect. There are several issues with this process, unfortunately: - Every so often a configuration mistake will adversely affect an entire environment, and much of the time is only noticed _after_ the changes are pushed out. As a result, local changes tend to be made in the development environment for testing and sometimes aren't committed for a long time, leaving discrepancies between the environments which can lead
Re: [Puppet Users] Re: Looking for solution on working configuration for new testing Puppet servers in existing environments
Trevor, Thank you for the response; I believe you got the idea pretty well and while your suggestion makes sense, it is something we definitely can't follow through with right now; our configuration is massive and complex and having to maintain three different yet similar sets of configuration would be difficult and reduce our response time to necessary user changes (of which we get anywhere from 5-10 a day). It's just not feasible without a complete reworking of how we do things right now, and not at the top of our priority lists. I do appreciate the input, however. Thank you. - Ken Lareau On Wed, Apr 18, 2012 at 12:28 PM, Trevor Smith trevor.c.sm...@gmail.comwrote: I'll take a stab at some of this. Hopefully I'm correctly understanding your issue. Am I correct in the following? : You define 3 environments development, staging, and production. These environments are defined as such in Puppet but they are also separate environments within your network, for the sake of clarity I'll call them zones from here out? Each zone has a Puppet Master server. Each Puppet Master server has three environments defined development, staging, and production. Each environment has the full git repository with the applicable branch checked out. The clients in each zone connect to the Puppet Master in their zone and pull their configs from the corresponding environment. So a staging_zone_client connects to staging_zone_master and pulls from the staging_environment. If that's correct then: You already have three separate Puppet Masters so the environments are redundant. As configured staging_zone_client can pull from production_environment using --environment. One fix could be to define only the production environment on each zone's Puppet Master and check out the applicable branch in only the production environment. As long as you never check out the production branch in development or staging then clients from those zones couldn't pull the settings for production zone as it's just not available. As long as they cannot connect to the other zone's Puppet Master, preventable by network segmentation, certs etc... Within each zone you could then define environments such as development and testing for conducting those activities within each zone. So you'd have staging/dev and staging/test branches checked out in those environments. I guess you could extend that and create environments for each admin within each zone that would allow the admin to use the --environment option for clients to test their work within a zone. This would result in a lot of environments, and probably a lot of branches, but you wouldn't need a test Puppet Master for each admin. I'd think this would introduce the problem of making it difficult to reuse modules between zones as I'd think you'd end up basically managing three completely different branches. Unless the sensitive data you're worried about is not being stored in your puppet repo and you have no issues merging changes made to the production branch into the development and testing branches, plus your admins will have a lot of different topic branches to deal with. Long run you'd probably want to move zone specific settings out of your modules and use something like hiera so you can standardize your modules across zones and just pull in the location settings using hiera. Hope I understood your problems correctly and this is helpful.. On Tuesday, April 17, 2012 10:34:43 PM UTC-4, Ken Lareau wrote: Hello folks, After some conversation on #puppet on Freenode IRC, Eric Sorenson requested I repost the information and question here, so I am doing so and hopefully it will all make sense... We currently have a well-established and relatively complex Puppet setup in place at my company and I'm in the process of trying to streamline changes as well as implement better testing to ensure minimal disruption or issues when making those changes. Some information on the current situation: - There are currently three environments: development, staging, production. These are controlled via the '--environment' setting for puppet in each client. All clients only belong to one environment and do not move between them. - We have a single Puppet configuration to manage all environments. Various conditional statements based on environment, application type, hostname, etc. control what each client receives for its configuration. - There are separate servers for each environment for security reasons (primarily sensitive information that can only exist in the production environment). - The Puppet configuration maintained via a Git repo, currently on a single branch. - Each person on the admin team checks out own copy of the repo, make changes, commits the changes, then updates each environment on the Puppet servers for the changes to take effect. There are several issues with this process, unfortunately: - Every
[Puppet Users] Re: Case statements in a file directive
So there were two gotchas :-) One, my mis-typed / and the other the missing ? in the evaluation ;-) Thanks again, guys, I appreciate the feedback. -- 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] Change location of puppet config files
Hi everyone; I am trying to change the location of where the ssl cert files are stored. I have changed this in the puppet.conf file but, when I start the puppetmaster, the only certs being created are still in /etc/ puppet. Can someone tell me what I am missing here? 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] Change location of puppet config files
On Wed, Apr 18, 2012 at 22:33, Jax01 atkins.jac...@gmail.com wrote: Hi everyone; I am trying to change the location of where the ssl cert files are stored. I have changed this in the puppet.conf file but, when I start the puppetmaster, the only certs being created are still in /etc/ puppet. Can someone tell me what I am missing here? 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. Where in puppet.conf did you put the directive and what did you put? 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] Change location of puppet config files
# Vardir similarly moved to /app for space issues vardir = /app/puppet/var # The Puppet log directory. # The default value is '$vardir/log'. logdir = /app/puppet/log # Where Puppet PID files are kept. # The default value is '$vardir/run'. rundir = /var/run/puppet # Where SSL certificates are kept. # The default value is '$confdir/ssl'. ssldir = $vardir/ssl On Wed, Apr 18, 2012 at 5:39 PM, John Kennedy skeb...@gmail.com wrote: On Wed, Apr 18, 2012 at 22:33, Jax01 atkins.jac...@gmail.com wrote: Hi everyone; I am trying to change the location of where the ssl cert files are stored. I have changed this in the puppet.conf file but, when I start the puppetmaster, the only certs being created are still in /etc/ puppet. Can someone tell me what I am missing here? 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. Where in puppet.conf did you put the directive and what did you put? 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. -- 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
On Apr 16, 2012, at 6:51 PM, Dan White wrote: I got a bunch of error complaining about rpaths, and in the output was a suggestion to prepend an environment setting to the command -- like this: QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild -ba ~/rpmbuild/SPECS/ruby.spec When I ran this, the previous errors were now warnings, and I got a set of RPM's. Is this The Way It Works ? Is it possible to eliminate the errors/warnings ? Would a link to a PatchBin of the build output help ? Yes, this is the way it works. Read up on what those particular rpath errors mean, and I think you'll come to understand why they don't matter. But it's best to read for yourself ;-) FYI, go edit that spec file and put the latest ruby patch release in there. There's some important fixes in the latest ruby patches, and the spec file and patches work just great with the latest ruby release. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Trying to build Ruby 1.8.7 on a RHEL5 systems
On Apr 18, 2012, at 6:08 PM, Jo Rhett wrote: On Apr 16, 2012, at 6:51 PM, Dan White wrote: I got a bunch of error complaining about rpaths, and in the output was a suggestion to prepend an environment setting to the command -- like this: QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild -ba ~/rpmbuild/SPECS/ruby.spec When I ran this, the previous errors were now warnings, and I got a set of RPM's. Is this The Way It Works ? Is it possible to eliminate the errors/warnings ? Would a link to a PatchBin of the build output help ? Yes, this is the way it works. Read up on what those particular rpath errors mean, and I think you'll come to understand why they don't matter. But it's best to read for yourself ;-) FYI, go edit that spec file and put the latest ruby patch release in there. There's some important fixes in the latest ruby patches, and the spec file and patches work just great with the latest ruby release. Might you be able to provide a few links or pointers to documentation and patches ? -- 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] custom functions
Hello, So I'm working my way through writing custom functions for puppet 2.7.6, and what I think is valid seems not to be, and unfortunately I can't find any additional help in the docs. I've got a pastebin link (http://pastebin.com/HimPyWHh) that shows my function, site.pp, and the file I'm trying to manipulate with my function. It's fairly basic as you can tell. I'm getting the following error from the client: err: Could not retrieve catalog from remote server: Error 400 on SERVER: can't convert nil into String at /etc/puppet/manifests/site.pp:81 on node thing I've been through the troubleshooting stages, ruby -rpuppet fileModify.rb, irb etc. and those work fine. If I make a syntax error in the function, puppet quite happily complains about it, so it can certainly read the function file. any suggestions? questions? help? :) ohh, and I'm following this guide here: http://docs.puppetlabs.com/guides/custom_functions.html Chris- -- 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/-/Fd-wqOv1dBIJ. 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] custom functions
At first glance (on phone), Check this line:
1. file = File.open(file, 'r+')
Don't you want filename as the argument?
n Wednesday, April 18, 2012, Chris Donovan wrote:
Hello,
So I'm working my way through writing custom functions for puppet 2.7.6,
and what I think is valid seems not to be, and unfortunately I can't find
any additional help in the docs. I've got a pastebin link (
http://pastebin.com/HimPyWHh) that shows my function, site.pp, and the
file I'm trying to manipulate with my function. It's fairly basic as you
can tell.
I'm getting the following error from the client: err: Could not retrieve
catalog from remote server: Error 400 on SERVER: can't convert nil into
String at /etc/puppet/manifests/site.pp:81 on node thing
I've been through the troubleshooting stages, ruby -rpuppet fileModify.rb,
irb etc. and those work fine.
If I make a syntax error in the function, puppet quite happily complains
about it, so it can certainly read the function file.
any suggestions? questions? help? :)
ohh, and I'm following this guide here:
http://docs.puppetlabs.com/guides/custom_functions.html
Chris-
--
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/-/Fd-wqOv1dBIJ.
To post to this group, send email to
puppet-users@googlegroups.comjavascript:_e({}, 'cvml',
'puppet-users@googlegroups.com');
.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com javascript:_e({}, 'cvml',
'puppet-users%2bunsubscr...@googlegroups.com');.
For more options, visit this group at
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.
Re: [Puppet Users] custom functions
Hi, Yes, filename is what is supposed to be there. That's not my issue however though, my issue is that it doesn't load / run properly. If puppet 2.7.6 still does not run functions on the client then that's great, and I'll write a provider, and possibly a type. Chris- On Thu, Apr 19, 2012 at 1:21 PM, Gary Larizza g...@puppetlabs.com wrote: At first glance (on phone), Check this line: file = File.open(file, 'r+') Don't you want filename as the argument? n Wednesday, April 18, 2012, Chris Donovan wrote: Hello, So I'm working my way through writing custom functions for puppet 2.7.6, and what I think is valid seems not to be, and unfortunately I can't find any additional help in the docs. I've got a pastebin link (http://pastebin.com/HimPyWHh) that shows my function, site.pp, and the file I'm trying to manipulate with my function. It's fairly basic as you can tell. I'm getting the following error from the client: err: Could not retrieve catalog from remote server: Error 400 on SERVER: can't convert nil into String at /etc/puppet/manifests/site.pp:81 on node thing I've been through the troubleshooting stages, ruby -rpuppet fileModify.rb, irb etc. and those work fine. If I make a syntax error in the function, puppet quite happily complains about it, so it can certainly read the function file. any suggestions? questions? help? :) ohh, and I'm following this guide here: http://docs.puppetlabs.com/guides/custom_functions.html Chris- -- 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/-/Fd-wqOv1dBIJ. 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. -- 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. -- 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] custom functions
On Wednesday, April 18, 2012, Chris Donovan wrote: Hi, Yes, filename is what is supposed to be there. That's not my issue however though, my issue is that it doesn't load / run properly. If puppet 2.7.6 still does not run functions on the client then that's great, and I'll write a provider, and possibly a type. Puppet only executes functions on the master - that's by design. Custom facts are executed in the client. You might want to look at the file_line type ( https://github.com/puppetlabs/puppetlabs-stdlib/blob/11156fd29a6ccee64663a5a32cf0b37d1867cfb0/lib/puppet/type/file_line.rb) or Augeas to modify lines in a file. Chris- On Thu, Apr 19, 2012 at 1:21 PM, Gary Larizza g...@puppetlabs.comjavascript:; wrote: At first glance (on phone), Check this line: file = File.open(file, 'r+') Don't you want filename as the argument? n Wednesday, April 18, 2012, Chris Donovan wrote: Hello, So I'm working my way through writing custom functions for puppet 2.7.6, and what I think is valid seems not to be, and unfortunately I can't find any additional help in the docs. I've got a pastebin link (http://pastebin.com/HimPyWHh) that shows my function, site.pp, and the file I'm trying to manipulate with my function. It's fairly basic as you can tell. I'm getting the following error from the client: err: Could not retrieve catalog from remote server: Error 400 on SERVER: can't convert nil into String at /etc/puppet/manifests/site.pp:81 on node thing I've been through the troubleshooting stages, ruby -rpuppet fileModify.rb, irb etc. and those work fine. If I make a syntax error in the function, puppet quite happily complains about it, so it can certainly read the function file. any suggestions? questions? help? :) ohh, and I'm following this guide here: http://docs.puppetlabs.com/guides/custom_functions.html Chris- -- 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/-/Fd-wqOv1dBIJ. To post to this group, send email to puppet-users@googlegroups.comjavascript:; . To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com javascript:;. For more options, visit this group at 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.comjavascript:; . To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com javascript:;. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.comjavascript:; . To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com javascript:;. For more options, visit this group at 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.
Re: [Puppet Users] custom functions
OK, so now that I understand where the functions run, I'll write a type / provider. The reason I need to get something custom run on the client is to learn how puppet works at that level. Then once I'm happy with the level of knowledge I will get with customizing puppet, I'll be able to figure out what to use, and / or what I'll need to write. With regards to augeas, I think it's horrible and would never use that. The syntax alone is cringe worthy to me. On the type that you sent me via the link, where does it actually write IO to the file to insert / append the line?? Is there some additional function that the type uses? I'm still reading up on types right now. Chris- On Thu, Apr 19, 2012 at 1:34 PM, Gary Larizza g...@puppetlabs.com wrote: On Wednesday, April 18, 2012, Chris Donovan wrote: Hi, Yes, filename is what is supposed to be there. That's not my issue however though, my issue is that it doesn't load / run properly. If puppet 2.7.6 still does not run functions on the client then that's great, and I'll write a provider, and possibly a type. Puppet only executes functions on the master - that's by design. Custom facts are executed in the client. You might want to look at the file_line type ( https://github.com/puppetlabs/puppetlabs-stdlib/blob/11156fd29a6ccee64663a5a32cf0b37d1867cfb0/lib/puppet/type/file_line.rb ) or Augeas to modify lines in a file. Chris- On Thu, Apr 19, 2012 at 1:21 PM, Gary Larizza g...@puppetlabs.com wrote: At first glance (on phone), Check this line: file = File.open(file, 'r+') Don't you want filename as the argument? n Wednesday, April 18, 2012, Chris Donovan wrote: Hello, So I'm working my way through writing custom functions for puppet 2.7.6, and what I think is valid seems not to be, and unfortunately I can't find any additional help in the docs. I've got a pastebin link (http://pastebin.com/HimPyWHh) that shows my function, site.pp, and the file I'm trying to manipulate with my function. It's fairly basic as you can tell. I'm getting the following error from the client: err: Could not retrieve catalog from remote server: Error 400 on SERVER: can't convert nil into String at /etc/puppet/manifests/site.pp:81 on node thing I've been through the troubleshooting stages, ruby -rpuppet fileModify.rb, irb etc. and those work fine. If I make a syntax error in the function, puppet quite happily complains about it, so it can certainly read the function file. any suggestions? questions? help? :) ohh, and I'm following this guide here: http://docs.puppetlabs.com/guides/custom_functions.html Chris- -- 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/-/Fd-wqOv1dBIJ. 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. -- 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. -- 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. -- 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. -- 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.
