[Puppet Users] Re: How to delete users from groups ?
Hi eduardo,
Is there another way to do it ?.
user { $username:
ensure = present,
key_membership = inclusive,
groups = ['all', 'groups', 'except', '$group'], # full listing of all
groups $username belongs to
}
or
group { $group,
ensure = present,
attribute_membership = inclusive,
members = ['all', 'members', 'except', '$username'], # full listing of
all members of $group
}
Cheers,
Paul
--
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/-/vByKYwcuRhoJ.
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: RemoteAdmin 0.6 ( Foreman / Puppet Mobile App ) Now in appstores
I am proud to release the next version of Remote Admin version 0.6. The first mobile app for your puppet environment. What is RemoteAdmin you ask? RemoteAdmin is a mobile (Android / iOS) and desktop (Win / Mac) app written in Flex that controls your puppet infrastructure via foreman. For more information visit: http://www.remoteadmin.co Full Feature List HostGroups (Similar to Roles in puppet) -- Create Host Groups -- Assign and remove hosts to hostgroups -- Assign and remove puppet modules from hostgroups Facts -- Fact viewer for entire environment -- Dynamic graphs based on any fact -- Sort facts by hostgroup(s) -- Email facts Certificate Management (Coming back in 0.7) -- Validate certificate requests -- Revoke certificates -- View revoked certificates -- Search for certificates Reports -- View Latest Puppet Generated Reports -- View report metrics as charts -- Drill down into individual report logs to find issues with puppet runs -- Sort reports by recent, eventful and failed categories Hosts -- View Individual Host puppet reports -- Assign or remove puppet modules from host -- View facts for each host Misc -- Create multiple profiles for different datacenters or foreman hosts -- SSL Support (Recommended) -- User Authentication Support (Recommended) -- Clickable Quickview Dashboard Whats New in 0.6: -- Communication Subsystem (native notifications, alerts) -- Support for Ipad 3 -- iOS inspired Theme -- Clickable Dashboard Graph and Fact Graph -- Swipe to view legend (FactViewer) -- Now Open source! (GPLv3) -- Test Client (if you don't have a foreman host yet) Whats Fixed: -- Too many to list Whats Removed: -- Certificates (Will add back in version 0.7) Future Releases (See http://www.remoteadmin.co) for full roadmap: -- Certificates -- Bookmark integration with entire app (Bookmark and group filters) -- Horizontal (large screen) layouts for tablets and Desktop -- IPMI and Mcollective integration -- More Share Buttons (CSV, Screenshot, ...) -- Badge Integration and Notifications when app is in background Note: Remote Admin Version 0.6 only works with the Foreman 1.0 or latest develop branch. Look in the appstores for RemoteAdmin or click the links below -- iOS Version: http://bit.ly/MojULg Android Version: http://bit.ly/NkRR3M Desktop App: http://www.remoteadmin.co/desktop (Install via Web) OSX and Windows Only For more information please visit http://www.remoteadmin.co Corey Osman co...@logicminds.biz Green IT and Datacenter Automation Specialist -- 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] hiera and dynamic variables
On 07/20/2012 03:55 PM, asq wrote:
class { nagios::host: ip = $ipaddress_bond0_1234 }
but... we'll need to include this on every single node (now we use node
inheritance and just set $nagiosip on top node level for group of hosts
that share the same vlan).
This end could be trivially met by putting this class declaration in a
scope that is present for all your nodes. Perhaps a default class or
similar.
The class parameter should be assigned directly from hiera. Failing
that, just assign a nagiosip value in hiera an put a
class { nagios::host: ip = hiera(nagiosip) }
in your global scope.
--
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] Puppet template tags and Java JSP tags
Hi, On 07/22/2012 04:02 AM, Yanis Guenane wrote: Hi All, I was trying to templatize some JSP page I would like to dynamically generates but it looks like puppet doesn't like it. Common JSP tags are % ... % so I guess it's getting confused between regular tags and jsp's one. This is an example of the trace it is givin me : /etc/puppet/modules/xxx/templates/webapps/xxx/yyy/Mantle.jsp:1:in `result': compile error (SyntaxError) /etc/puppet/modules/xxx/templates/webapps/xxx/yyy/Mantle.jsp:1: syntax error, unexpected tIDENTIFIER, expecting $end Is there any know way to deal with JSP pages ? I don't know of a simple way. You probably need to escape all JSP tags (which doesn't seem to be worth the hassle, really ;) Cheers, Felix -- 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] Problems granting privileges with puppetlabs/mysql
On Saturday, 21 July 2012 16:34:20 UTC+2, Walter Heck wrote:
A quick look into mysql/lib/puppet/provider/database_grant/mysql.rb
teaches me this module grants permissions only on db and user level.
Repl_slave is only available at global level.
Aha. Thanks for pointing this out.
Imho this module is doing it wrong by messing with the mysql table.
Instead, it should generate proper GRANT statements and execute those to
update permissions.
Yeah, that's what I thought, too.
cheers,
Walter
On Thu, Jul 19, 2012 at 11:23 PM, thijso thi...@gmail.com wrote:
First off, I'm not sure if I should be asking questions about puppetlabs
modules here, if not, I apologise...
I'm trying to at least setup my mysql replication user through the mysql
module, but I seem to be unable to divine the correct way to do this. I've
tried a number of different variations, but my user doesn't get the
repl_slave_priv on my user table... This is the relevant part of my
manifest:
-
database_user { repl_slave@%:
password_hash = mysql_password(' ... '),
}
database_grant { repl_slave@%/*.*:
privileges = ['repl_slave_priv'],
}
The puppet run doesn't raise an error, it says:
notice:
/Stage[main]/Db::Repl_user/Database_grant[repl_slave@%/*.*]/privileges:
privileges changed '' to 'repl_slave_priv'
But it does so at each puppet run, so clearly it's actually NOT changing
privileges to 'repl_slave_priv'. This seems like a pretty big bug to me. If
it fails, it should tell me it fails, not pretend it worked. Also, when I
check on the actual user table I indeed see no repl_slave_priv granted to
this user...
I've also tried 'replication slave' (which is what you do in a GRANT x
incantation) and 'repl_slave'. A little more documentation for the module
would be a great help here...
Thanks for any pointers,
Thijs
--
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/-/v7NNyzpAPJ0J.
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.
--
Walter Heck
--
Check out my startup: Puppet training and consulting @
http://www.olindata.com
Follow @olindata on Twitter and/or 'Like' our Facebook page at
http://www.facebook.com/olindata
--
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/-/7v-GNnzBhDAJ.
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] Best practice for calling commands
Hello!
I hope someone might be able to give me some directions on this
problem. The search didn't come up with something useful because it's
some kind of a corner case i think...
I am trying to implement an integration of HP System Insight Manager
into Puppet. Unfortunately the HP SIM is running on a windows box to
which I only have SSH access and cannot install puppet on it (otherwise
Exec would be easy).
My idea was to write a provider and type that i could do something like
node server1 {
simnode {$hostname:
ensure = present,
simserver = hpsim.example.com,
}
}
In the background the provider issues an command over ssh to make sure
it is in SIM:
snip
Puppet::Type.type(:simnode).provide(:ssh) do
confine :manufacturer = [ HP, Compaq ]
commands :ssh = ssh
def create
ssh @resource[:simserver] mxnode -a @resource[:name]
end
def exists?
output = ssh @resource[:simserver] mxnode -ld
@resource[:name]
if output =~ /The node specified does not represent a node in
this system/i
false
else
true
end
end
def destroy
ssh @resource[:simserver] mxnode -r @resource[:name]
end
end
snap
Of course this is more or less pseudocode but I guess you see what I am
intending to do. On the other hand the mxnode -ld command also spits
out some very interesting information about support status and features
that I would like to put into facts respectively there is an XML Output
of mxnode which I could use to cache the state if a node has already
been added to SIM.
Before I start writing this provider is there any kind of generic SSH
wrapper for this something i could start from?
Thank you very much for your help in advance!
Best wishes
Hannes
--
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 template tags and Java JSP tags
On Saturday, July 21, 2012 9:02:50 PM UTC-5, Yanis Guenane wrote: Hi All, I was trying to templatize some JSP page I would like to dynamically generates but it looks like puppet doesn't like it. Common JSP tags are % ... % so I guess it's getting confused between regular tags and jsp's one. This is an example of the trace it is givin me : /etc/puppet/modules/xxx/templates/webapps/xxx/yyy/Mantle.jsp:1:in `result': compile error (SyntaxError) /etc/puppet/modules/xxx/templates/webapps/xxx/yyy/Mantle.jsp:1: syntax error, unexpected tIDENTIFIER, expecting $end Is there any know way to deal with JSP pages ? ERB is the Ruby analog to the templating aspects of JSP, even sporting overlapping syntax (as you discovered). If you must create a JSP page by processing a template with ERB, then any literal JSP tag delimiters in the ERB template must be escaped. The Ruby docs for class ERB give the syntax: %% maps to %, and %% maps to %. You'll have to decide whether that's worthwhile, or whether to look for a better way. For sure, if there are many JSP tags or much scriptlet code in your JSP, then it is already difficult enough to read and maintain before you convert it into an ERB template. 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/-/lc4vIc2XSPIJ. 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 delete users from groups ?
Hi Paul, I found note in http://projects.puppetlabs.com/issues/7241.
So I can do it using membership = inclusive (instead of
key_membership)
I appreciate your help.
Regards,
eduardo.
On 23 jul, 02:05, Paul Tötterman paul.totter...@gmail.com wrote:
Hi eduardo,
Is there another way to do it ?.
user { $username:
ensure = present,
key_membership = inclusive,
groups = ['all', 'groups', 'except', '$group'], # full listing of all
groups $username belongs to
}
or
group { $group,
ensure = present,
attribute_membership = inclusive,
members = ['all', 'members', 'except', '$username'], # full listing of
all members of $group
}
Cheers,
Paul
--
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: Foreman 1.0 released!
Congrats on the release, I've been really looking forward to this one : D On Sunday, July 22, 2012 8:02:06 AM UTC-5, ohad wrote: Hello, I'm very excited and pleased to share the release of Foreman 1.0 Since the change log is quite extensive, I would simply refer you to the change log [1] and would highly suggest to read it if you are upgrading. About Foreman: Foreman is an opensource management tool, design to help you to manage your infrastructure. Foreman takes over provisioning(bare metal, virtual or in the cloud)[2], interfacing with puppet to configure your servers, and provides an easy to use UI / API to control and review your server state. I'm also very happy to see that Foreman users, contributes (thanks guys!!) and ecosystem is growing, that includes a mobile app [3] and a CLI that was contributed by our community. I'm assuming packages would be available shortly. have fun, Ohad [1] http://theforeman.org/projects/foreman/wiki/ReleaseNotes#Release-Notes-for-10 [2] http://theforeman.org/projects/foreman/wiki/Screencasts [3] http://www.remoteadmin.co -- 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/-/c3PWfi5qPJ4J. 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: Best practice for calling commands
On Monday, July 23, 2012 4:16:15 AM UTC-5, Hannes Schaller wrote:
Hello!
I hope someone might be able to give me some directions on this
problem. The search didn't come up with something useful because it's
some kind of a corner case i think...
I am trying to implement an integration of HP System Insight Manager
into Puppet. Unfortunately the HP SIM is running on a windows box to
which I only have SSH access and cannot install puppet on it (otherwise
Exec would be easy).
My idea was to write a provider and type that i could do something like
node server1 {
simnode {$hostname:
ensure = present,
simserver = hpsim.example.com,
}
}
In the background the provider issues an command over ssh to make sure
it is in SIM:
snip
Puppet::Type.type(:simnode).provide(:ssh) do
confine :manufacturer = [ HP, Compaq ]
commands :ssh = ssh
def create
ssh @resource[:simserver] mxnode -a @resource[:name]
end
def exists?
output = ssh @resource[:simserver] mxnode -ld
@resource[:name]
if output =~ /The node specified does not represent a node in
this system/i
false
else
true
end
end
def destroy
ssh @resource[:simserver] mxnode -r @resource[:name]
end
end
snap
Of course this is more or less pseudocode but I guess you see what I am
intending to do.
I think something along those lines could be made to work, but it's very
unusual. The resource you're managing doesn't actually belong to the node
being managed. That may be the best you can do with the constraints you're
working under, but be aware that it will be shakier than most Puppet
resources.
On the other hand the mxnode -ld command also spits
out some very interesting information about support status and features
that I would like to put into facts
By the time your provider (or your type) enters the picture, fact
collection is long since over and done. If you want to make facts out of
that information then you need to write separate custom facts. Note,
however, that doing so makes your setup a little bit shakier still, for
then you have not only managed resources, but also facts that don't belong
to the node being managed.
respectively there is an XML Output
of mxnode which I could use to cache the state if a node has already
been added to SIM.
I advise against doing that, as it introduces a cache validity problem.
Puppet providers generally prefer to use the system's tools directly.
Before I start writing this provider is there any kind of generic SSH
wrapper for this something i could start from?
I am not aware of one, but perhaps someone else can help you out. On the
other hand, what you're trying to do is very unusual, as I already said, so
you may be on your own.
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/-/4VEF0zAzBQEJ.
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: Stop aptitude package provider from using '-y'
On Sunday, July 22, 2012 5:58:01 PM UTC-5, David Banks wrote: Hi all, I like to use the aptitude provider to install packages -- all my systems are Debian and it's consistent with what I use manually. However, the aptitude provider seems to pass the '-y' option to aptitude, which causes aptitude to simply assume yes for all prompts. I understand that this might be necessary to avoid puppet hanging due to the subprocess prompting, but in some cases aptitude can prompt because of conflicts. In the case of conflicts, I would want puppet to just return an error and let me handle the situation manually. Because sometimes aptitude's first solution to a conflict is very suboptimal. Does anyone know how I can configure this? You would probably need to modify the code for the aptitude provider, or else to write an alternative package provider that has the behavior you want. Given that for the latter you could start from the built-in aptitude provider, those options are roughly comparable in difficulty. Before you consider that, however, I suggest you look at whether there is any combination of options that would elicit the desired behavior from aptitude. If there is, then the job would be fairly straightforward, but if not, then you're looking at rather a hard problem, both in interacting with the aptitude text UI and in interfacing that interaction with Puppet. John 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/-/fVac8wwRgu4J. 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: Stop aptitude package provider from using '-y'
On Monday, July 23, 2012 8:28:20 AM UTC-5, jcbollinger wrote: Before you consider that, however, I suggest you look at whether there is any combination of options that would elicit the desired behavior from aptitude. And by that I mean to that aptitude should never prompt, but instead fail (returning a non-zero exit code) under those circumstances where you want it to do. Looking at the aptitude provider, you might be able to get around the exit code by parsing the standard error text, which is already done to cover one case. Also, I was a bit quick to deny the possibility of configuring your desired behavior: you cannot configure *Puppet* to change the behavior of the apitude provider, short of modifying the provider, but you may be able to configure *aptitude* to provide satisfactory default behavior. You could then use Puppet to ensure that the desired aptitude configuration is in place before you start managing packages. 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/-/FbE2VGS1ThoJ. 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] Live management and manifests
Hi all, I have this question which have been nagging me for a while now. The live management features in the PE allows one to manage the resources on the fly without having to the need to write manifests. The users can clone / update / manage resources in any way permitted they want. How does this works with the manifests that are written by the users? Lets say my site.pp have node definition that says to include the nginx class for node A. Then I would use the live management to clone the resources for the nginx class from node A to node B and C. How will this reflect into my manifests as I already have node A, B and C defined in my site.pp? Hope this is clear enough. -- 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/-/w30A9URz9A0J. 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] fedoar 17 and puppet dashboard
Hello, I add a node Fedora 17. The reports are a aperture in puppet-server in /var/ lib/puppet/reports but not in Dashboard. While all other Fedra (16, 15, 14) are visible in Dashboard. Do you have an idea? Thank you. mauris -- 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/-/jwBW5rWsEzMJ. 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] Hiera problem: Can't convert Symbol into String
All,
I have found very few references to this error so I'm guessing I must be
doing something wrong. I have just started using hiera and am trying to use
it in the simplest way possible, I have a class that looks like this:
class app_users2($compresslogs = hiera('compresslogs')) {
#Setup Cronjob for compressing app logs
if $compresslogs == true {
file { /etc/cron.daily/copyLogs.cron:
mode = 750,
ensure = present,
alias = compresslogscron,
source = puppet:///modules/app_users2/copyLogs.sh
}
}
}
For the node I'm running this on, hiera returns 'true' for that value when
I test it out:
$ hiera -c hiera.yaml compresslogs loc=sd type=app
true
I am using the yaml hiera backend and the yaml file this is configured in
looks like this:
---
family : prod
cluster : prod
compresslogs : true
However, when I try to execute the manifests either on the host or test
them using cucumber-puppet I get the following error:
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
can't convert Symbol into String at
/etc/puppet/modules/app_users2/manifests/init.pp:2 on node xyz
I have tried quoting, unquoting the data in the yaml file in the
conditional in the class. I've tried calling hiera as a parameter to the
class, also just as part of the conditional ( if hiera('compresslogs') ==
true ) etc. It appears that anytime I try to reference that value from
puppet it throws this error.
I have found a few references in IRC logs to others having this problem but
they all stated Oh, I figured it out without explaining how - so I'm a
bit stuck.
I am running the following hiera versions on the puppetmaster:
hiera-puppet-1.0.0-0.1rc1.el5
hiera-1.0.0-0.1rc3.el5
And the puppetmaster is running puppet v. 2.7.6.-2. I also tried updating
the puppet version on my host running cucumber-puppet to 2.7.18 and it
continues to throw this error.
Any help would be greatly appreciated.
Thanks,
Aaron
--
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/-/T9w4ZPprI-QJ.
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] Stop aptitude package provider from using '-y'
On 23.07.2012 00:58, David Banks wrote: In the case of conflicts, I would want puppet to just return an error and let me handle the situation manually. Just say no to manual interventions. Because sometimes aptitude's first solution to a conflict is very suboptimal. Does anyone know how I can configure this? If you are experiencing conflicts in aptitutes package resolver, you're the victim of an underspecified manifest. You need to explicitely tell puppet to install AND remove the packages which are part of the resolution before installing the final package. If you instead solve it manually, you'll loose the repeatability and stability of your installation. A very good example are apache MPMs. For some modules you need a specific one and relying only on package dependencies might lead to a flip-flop situation where installing A removes B and vice-versa. Having an explicit resolution in place will already fail when compiling the catalog, pointing you directly to the collision. Best Regards, David -- 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] Live management and manifests
We make a distinction between resources managed with Puppet manifests and resources managed with Live Management. Puppet manifests enforce a particular state whenever puppet is run, while Live Management enforces a state once--when cloning is performed. There isn't any overlap. Live Management cannot be used to clone resources that are already managed with Puppet manifests, and the manifests themselves aren't changed when resources are cloned. Hope this helps! - Daniel On Sun, Jul 22, 2012 at 9:46 PM, Choon Ming Goh choonming2...@gmail.comwrote: Hi all, I have this question which have been nagging me for a while now. The live management features in the PE allows one to manage the resources on the fly without having to the need to write manifests. The users can clone / update / manage resources in any way permitted they want. How does this works with the manifests that are written by the users? Lets say my site.pp have node definition that says to include the nginx class for node A. Then I would use the live management to clone the resources for the nginx class from node A to node B and C. How will this reflect into my manifests as I already have node A, B and C defined in my site.pp? Hope this is clear enough. -- 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/-/w30A9URz9A0J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Best practice for calling commands
Puppet devices provide an ssh and telnet transport, so you can reuse
them for this purpose. In the resource type, you just need to specify
'apply_to_device'. The device connectivity information is stored in
device.conf, and both transport behaves similar to an expect script.
There's a few limitation to keep in mind:
1. One certificate per device, since each device is a puppet node.
2. You can only specify relationship between resources for that device.
3. The existing implementation is somewhat brittle since it's just
waiting for the next prompt to issue the next command.
Regardless of whether you implement a host or device resource, the
existing transport should give you a good idea how to do this.
Thanks,
Nan
On Mon, Jul 23, 2012 at 9:06 AM, Aaron Grewell aaron.grew...@gmail.com wrote:
This sounds similar to how the router type works so that might be a good
place to start looking for ideas.
On Jul 23, 2012 6:20 AM, jcbollinger john.bollin...@stjude.org wrote:
On Monday, July 23, 2012 4:16:15 AM UTC-5, Hannes Schaller wrote:
Hello!
I hope someone might be able to give me some directions on this
problem. The search didn't come up with something useful because it's
some kind of a corner case i think...
I am trying to implement an integration of HP System Insight Manager
into Puppet. Unfortunately the HP SIM is running on a windows box to
which I only have SSH access and cannot install puppet on it (otherwise
Exec would be easy).
My idea was to write a provider and type that i could do something like
node server1 {
simnode {$hostname:
ensure = present,
simserver = hpsim.example.com,
}
}
In the background the provider issues an command over ssh to make sure
it is in SIM:
snip
Puppet::Type.type(:simnode).provide(:ssh) do
confine :manufacturer = [ HP, Compaq ]
commands :ssh = ssh
def create
ssh @resource[:simserver] mxnode -a @resource[:name]
end
def exists?
output = ssh @resource[:simserver] mxnode -ld
@resource[:name]
if output =~ /The node specified does not represent a node in
this system/i
false
else
true
end
end
def destroy
ssh @resource[:simserver] mxnode -r @resource[:name]
end
end
snap
Of course this is more or less pseudocode but I guess you see what I am
intending to do.
I think something along those lines could be made to work, but it's very
unusual. The resource you're managing doesn't actually belong to the node
being managed. That may be the best you can do with the constraints you're
working under, but be aware that it will be shakier than most Puppet
resources.
On the other hand the mxnode -ld command also spits
out some very interesting information about support status and features
that I would like to put into facts
By the time your provider (or your type) enters the picture, fact
collection is long since over and done. If you want to make facts out of
that information then you need to write separate custom facts. Note,
however, that doing so makes your setup a little bit shakier still, for then
you have not only managed resources, but also facts that don't belong to the
node being managed.
respectively there is an XML Output
of mxnode which I could use to cache the state if a node has already
been added to SIM.
I advise against doing that, as it introduces a cache validity problem.
Puppet providers generally prefer to use the system's tools directly.
Before I start writing this provider is there any kind of generic SSH
wrapper for this something i could start from?
I am not aware of one, but perhaps someone else can help you out. On the
other hand, what you're trying to do is very unusual, as I already said, so
you may be on your own.
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/-/4VEF0zAzBQEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
[Puppet Users] Passing multiple arrays to define
I'm trying to make a defined type with two parameters and pass an array for
each parameter.
My first try was something like this:
init.pp
define mything ($user, $version) {
exec {$user_$version:
command = something needing both $user and $version
}
}
in the node file:
$user = [ A, B, C, D]
$version = [ 1.5, 2.0, 4.2, 0.01 ]
mything { thing:
user = $user,
version = $version,
}
Now of course this didn't do what I want it to do (give all the users in
$users all of the versions in $version)
Searching I came across a post that said do something using $title like
init.pp
define mything ($version) {
exec {$version:
command = something using $foo and $title
}
}
and the node file
$user = [ A, B, C, D ]
mything { $user:
version = 1.5
}
However this still means I'd have to do one for each version (and figure
out how to avoid a Duplicate definition problem.
Is there an easy or a right way to do what I'm trying to do?
Thanks in advance.
--
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/-/9_zxAPURFbIJ.
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] sshkey type purge
So, I'm sure this has been covered somewhere, but I can't seem to find it. Is there no 'purge' ability on the 'sshkey' type? It would be nice to be able to get rid of entries for hosts that are no longer present without actually having to write out a node declaration for each one. Thanks, Trevor -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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: Foreman 1.0 released!
this is still development release not stable release? -- 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/-/4K8fEWOhwsIJ. 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: [foreman-users] Re: Foreman 1.0 released!
On Mon, Jul 23, 2012 at 9:23 PM, Clay clay...@gmail.com wrote: this is still development release not stable release? nope, thats a stable 1.0 release. Ohad -- You received this message because you are subscribed to the Google Groups Foreman users group. To view this discussion on the web visit https://groups.google.com/d/msg/foreman-users/-/4K8fEWOhwsIJ. To post to this group, send email to foreman-us...@googlegroups.com. To unsubscribe from this group, send email to foreman-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/foreman-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] Lookup another node's hiera data - fqdn hierarchy
On Saturday, July 21, 2012 9:57:13 PM UTC-5, Garrett Honeycutt wrote:
On 7/21/12 4:13 AM, treydock wrote:
I've begun using Hiera in combination with Foreman, primarily storing
data that is best left in Array/Hash form. I'd like to be able to have
a module, in this case BackupPC, query all the Hiera data for each node
where the backup directories/databases are stored. Then use all that
information on the BackupPC server to generate proper configuration
files for each node's backups. Here's what I have so far...
$ cat /etc/puppet/hiera.yaml
---
:hierarchy:
- %{fqdn}
- common
:backends:
- yaml
- puppet
:yaml:
:datadir: '/etc/puppet/hieradata'
:puppet:
:datasource: data
An example of the BackupPC information in hiera
$ cat /etc/puppet/hieradata/dc-ctrl.tamu.edu.yaml
---
backuppc_db_dumps:
foreman:
backup_dir: '/usr/share/foreman'
mysql:
backup_dir: '/etc'
I am currently using that data to create dump scripts on each node, and
would like to re-use the same information to automatically configure the
backup server to grab those locations.
This attempt may work, but it doesn't 'feel' right to me by overriding
the fqdn fact.
/etc/puppet/modules/test $ cat manifests/hiera_lookup.pp
class test::hiera_lookup {
$nodes = foreman('fact_values', 'fact = fqdn')
if $nodes {
create_resources('test::hiera_lookup::get_data', $nodes)
}
}
define test::hiera_lookup::get_data (
$fqdn
) {
$data = hiera(backuppc_db_dumps, false)
if $data { notify { $data: } }
}
Is there a better approach to override scope and grab what data from
hiera that would normally not be available to a node?
Thanks
- Trey
This would be a great place to use exported resources[1]. Each node
could still use Hiera to determine if they should be backed up (or what
should be backed up) and export a resource and the backup server could
collect.
[1] - http://docs.puppetlabs.com/guides/exported_resources.html
-g
--
Garrett Honeycutt
206.414.8658
http://puppetlabs.com
Looking at some of online documentation I see no means to either export the
hash variable pulled into the modules from hiera or to export the defines
called with create_resources.
Is there a way to do something like @@$backuppc_db_dumps =
hiera('backuppc_db_dumps') ? Or possibly a way to export a custom define
with all the parameters passed to it?
Thanks
- Trey
--
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/-/_mh8ipqsZ-EJ.
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: Any one interested attending a puppetcamp in Israel?
I'm just beginning to use Puppet but I would love to participate in such event, I'm sure I can get 3-4 people from my team to join as well -- 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/-/zTIntLVT8AYJ. 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] Adding file dependencies to existing service
Hi all,
I'm trying to configure Puppet to allow the creation of multiple memcached
instances on a system. However, I'm running into the message that only
subclasses can override parameters. Perhaps I'm going about this the wrong
way, or maybe I just have something slightly wrong. Any advice is welcome.
class memcached {
package { 'memcached': ensure = present }
# do not want basic configuration
file { '/etc/memcached.conf': ensure = absent }
service { 'memcached':
ensure = running,
enable = true,
require = Package['memcached'],
}
}
define memcached::instance () {
include memcached
$conf = /etc/memcached_${name}.conf
file { $conf: ensure = present }
*Service['memcached'] { require + File[$conf] }*
}
# create first instance in file /etc/memcached_en.conf
memcached::instance { 'en': }
The other thing I'd like to do is have Service['memcached'] set to NOT
start unless there is at least one instance, i.e. not start until after the
first instance's config file is in place, but that's not a showstopper.
Thanks,
Justin
--
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/-/fic-AkDAfAoJ.
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] Adding file dependencies to existing service
(inline)
On Mon, Jul 23, 2012 at 02:09:01PM -0700, Justin wrote:
Hi all,
I'm trying to configure Puppet to allow the creation of multiple memcached
instances on a system. However, I'm running into the message that only
subclasses can override parameters. Perhaps I'm going about this the wrong
way, or maybe I just have something slightly wrong. Any advice is welcome.
class memcached {
package { 'memcached': ensure = present }
# do not want basic configuration
file { '/etc/memcached.conf': ensure = absent }
service { 'memcached':
ensure = running,
enable = true,
require = Package['memcached'],
}
}
define memcached::instance () {
include memcached
$conf = /etc/memcached_${name}.conf
file { $conf: ensure = present }
Service['memcached'] { require + File[$conf] }
This bit is a problem because all defines will declare Service['memcached'] and
thus you'll get spammed with duplicate definitions. I solved this by using
multiple daemons, useful to me because I want to be able to kill a daemon in an
emergency without affecting more than one service. Another generic technique
I've found useful is to have several classes in my module, for instance:
1) thing::software class (installs the defaults file per below, installs the
package, installs the init script)
2) thing::extraconfig define (includes thing::software, throw a config file in
/etc/thing.d/, something inside this notifies the service)
3) thing::service class (includes thing:;software, declares service { 'thing':
}, basically exists so the service is separate from the software)
In your manifest where you call all these, you would have to ensure that
thing::extraconfig is declared before thing::service.
(Just food for thought.)
}
# create first instance in file /etc/memcached_en.conf
memcached::instance { 'en': }
The other thing I'd like to do is have Service['memcached'] set to NOT
start unless there is at least one instance, i.e. not start until after
the first instance's config file is in place, but that's not a
showstopper.
By my experimentation, memcached will be started by the postinstall scripts
when you install the deb/rpm. One technique I've found useful (on
Ubuntu/Debian) is to declare file { /etc/default/$software: content =
start=no } before installing said software. Apt won't overwrite the defaults
file so the daemon won't start, and you can lay down a custom init script
(which doesn't check the defaults file) after your config files are installed.
Here's how I solved the memcached thing to pop up multiple memcached daemons
(obviously derived from https://github.com/saz/puppet-memcached):
class memcached::orig_off {
$classname = 'memcached'
package { $classname:
ensure = installed,
}
service { $classname:
ensure = stopped,
enable = false,
hasrestart = true,
hasstatus = true,
require = Package['memcached'],
}
}
define memcached::daemon ( $max_memory = false, $listen_ip = '0.0.0.0', $port =
'11211', $max_connections = '8192' ) {
$classname = 'memcached'
$filesource = puppet:///modules/$classname
case $::operatingsystem {
ubuntu, debian: {
$user = 'nobody'
$mconfdir = '/etc/monit/conf.d'
}
centos, redhat: {
$user = 'memcached'
$mconfdir = '/etc/monit.d'
}
default: {
fail(Unsupported platform: ${::operatingsystem})
}
}
$service1 = memcached${port}
$config1 = /etc/memcached${port}.conf
$config1template = $classname/memcached_sp.conf.erb
$init1 = /usr/local/sbin/start-memcached${port}
$init1template = $classname/start_memcached.erb
$init2 = /etc/init.d/memcached${port}
$init2template = $classname/init_memcached.erb
$mfile1 = $mconfdir/${classname}${port}
$mfile1template = $classname/memcached_monit.erb
$logfile = /var/log/memcached${port}.log
include memcached::orig_off
file { $init1:
content = template($init1template),
mode = 744,
}
file { $init2:
content = template($init2template),
mode = 744,
}
file { $config1:
content = template($config1template),
require = Class['memcached::orig_off'],
}
service { $service1:
ensure = running,
enable = true,
hasrestart = true,
hasstatus = false,
require = [File[$init1], File[$init2], File[$config1]],
subscribe = File[$config1],
}
file { $mfile1:
content = template($mfile1template),
mode = 600,
require = Service[$service1],
}
}
Thanks,
Justin
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
[1]https://groups.google.com/d/msg/puppet-users/-/fic-AkDAfAoJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
[Puppet Users] librarian-puppet vs git superproject?
Can anyone comment on their experiences with librarian-puppet or using git superproject with per puppet module repositories? We are in the midst of determining which route is optimal for our environment. It seems like using git superprojects would mean one less new tool for everyone to learn. What then would be the advantages of librarian-puppet? Thanks, Ryan Bowlby -- 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/-/4Kf47PY2sIwJ. 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] access facts in ENC
Hi, As the only paramater we can pass to the ENC is the hostname, I wonder if there is a way to access a node's fact in the ENC script? I know a workaround is to query my Fact database ( I am using Mysql), but I like to know if I can use a variable directly, for example, $ipaddress? Thanks. Hai T. -- 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 facts in ENC
On Jul 23, 2012, at 4:07 PM, Hai Tao wrote: Hi, As the only paramater we can pass to the ENC is the hostname, I wonder if there is a way to access a node's fact in the ENC script? I know a workaround is to query my Fact database ( I am using Mysql), but I like to know if I can use a variable directly, for example, $ipaddress? $hostname should work $fqdn is an option but that will likely carry a domain name with it. Craig -- 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 facts in ENC
I am talking about facts other than hostname, such as ipaddress, custom facts. On Mon, Jul 23, 2012 at 4:47 PM, Craig White craig.wh...@ttiltd.com wrote: On Jul 23, 2012, at 4:07 PM, Hai Tao wrote: Hi, As the only paramater we can pass to the ENC is the hostname, I wonder if there is a way to access a node's fact in the ENC script? I know a workaround is to query my Fact database ( I am using Mysql), but I like to know if I can use a variable directly, for example, $ipaddress? $hostname should work $fqdn is an option but that will likely carry a domain name with it. Craig -- 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. -- Hai Tao -- 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] Adding file dependencies to existing service
Chris,
Thanks for your response. Your post got me thinking about a different
approach that I'm surprised I didn't think of in the first place. I do
prefer to have a single service handling multiple daemons, but I also
realized I should be using Hiera for this. So I'm now defining a hash in
Hiera on a per-node basis (i.e. %{fqdn}.yaml) like so:
memcached_instances:
xx: { tcp_port: '11211', max_memory: '512' }
yy: { tcp_port: '11212', max_memory: '512' }
zz: { tcp_port: '11213', max_memory: '512' }
and here's what I've boiled my class down to:
class memcached {
$instances = hiera_hash('memcached_instances')
$instance_names = split(inline_template('%= instances.keys.join(,)
%'), ',')
package { 'memcached':
ensure = present
}
file { '/etc/memcached.conf':
ensure = absent,
require = Package['memcached'],
}
define memcached::instance ( $instance_name = $title ) {
$log_file= /var/log/memcached-${instance_name}.log
$user= 'memcache'
$max_connections = '1024'
$tcp_port= $memcached::instances[$instance_name]['tcp_port']
$max_memory =
$memcached::instances[$instance_name]['max_memory']
file { /etc/memcached_${instance_name}.conf:
ensure = present,
content = template('memcached/etc/memcached.conf.erb'),
}
}
memcached::instance { $instance_names:
require = Package['memcached'],
notify = Service['memcached'],
}
service { 'memcached':
ensure = running,
enable = true,
hasrestart = true,
hasstatus = false,
require= Package['memcached'],
}
}
It could use some work in how it handles other values in the templates, but
it seems to work nicely so far and should scale well.
Thanks again for taking the time to post your thoughts and code!
Justin
On Monday, July 23, 2012 2:33:31 PM UTC-7, Christopher Wood wrote:
(inline)
On Mon, Jul 23, 2012 at 02:09:01PM -0700, Justin wrote:
Hi all,
I'm trying to configure Puppet to allow the creation of multiple
memcached
instances on a system. However, I'm running into the message that
only
subclasses can override parameters. Perhaps I'm going about this the
wrong
way, or maybe I just have something slightly wrong. Any advice is
welcome.
class memcached {
package { 'memcached': ensure = present }
# do not want basic configuration
file { '/etc/memcached.conf': ensure = absent }
service { 'memcached':
ensure = running,
enable = true,
require = Package['memcached'],
}
}
define memcached::instance () {
include memcached
$conf = /etc/memcached_${name}.conf
file { $conf: ensure = present }
Service['memcached'] { require + File[$conf] }
This bit is a problem because all defines will declare
Service['memcached'] and thus you'll get spammed with duplicate
definitions. I solved this by using multiple daemons, useful to me because
I want to be able to kill a daemon in an emergency without affecting more
than one service. Another generic technique I've found useful is to have
several classes in my module, for instance:
1) thing::software class (installs the defaults file per below, installs
the package, installs the init script)
2) thing::extraconfig define (includes thing::software, throw a config
file in /etc/thing.d/, something inside this notifies the service)
3) thing::service class (includes thing:;software, declares service {
'thing': }, basically exists so the service is separate from the software)
In your manifest where you call all these, you would have to ensure that
thing::extraconfig is declared before thing::service.
(Just food for thought.)
}
# create first instance in file /etc/memcached_en.conf
memcached::instance { 'en': }
The other thing I'd like to do is have Service['memcached'] set to
NOT
start unless there is at least one instance, i.e. not start until
after
the first instance's config file is in place, but that's not a
showstopper.
By my experimentation, memcached will be started by the postinstall
scripts when you install the deb/rpm. One technique I've found useful (on
Ubuntu/Debian) is to declare file { /etc/default/$software: content =
start=no } before installing said software. Apt won't overwrite the
defaults file so the daemon won't start, and you can lay down a custom init
script (which doesn't check the defaults file) after your config files are
installed.
Here's how I solved the memcached thing to pop up multiple memcached
daemons (obviously derived from https://github.com/saz/puppet-memcached):
class memcached::orig_off {
$classname = 'memcached'
package { $classname:
Re: [Puppet Users] Live management and manifests
Is there anyway to make it overlap or there simply isnt any? From what I can assume, if a user manages a resource via Live Management and wants it to be in the manifests, the user must remember or must put it in on their own accord? On Monday, July 23, 2012 11:58:26 PM UTC+8, Daniel Sauble wrote: We make a distinction between resources managed with Puppet manifests and resources managed with Live Management. Puppet manifests enforce a particular state whenever puppet is run, while Live Management enforces a state once--when cloning is performed. There isn't any overlap. Live Management cannot be used to clone resources that are already managed with Puppet manifests, and the manifests themselves aren't changed when resources are cloned. Hope this helps! - Daniel On Sun, Jul 22, 2012 at 9:46 PM, Choon Ming Goh choonming2...@gmail.comwrote: Hi all, I have this question which have been nagging me for a while now. The live management features in the PE allows one to manage the resources on the fly without having to the need to write manifests. The users can clone / update / manage resources in any way permitted they want. How does this works with the manifests that are written by the users? Lets say my site.pp have node definition that says to include the nginx class for node A. Then I would use the live management to clone the resources for the nginx class from node A to node B and C. How will this reflect into my manifests as I already have node A, B and C defined in my site.pp? Hope this is clear enough. -- 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/-/w30A9URz9A0J. 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/-/7fb_U12tIykJ. 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] librarian-puppet vs git superproject?
On Mon, Jul 23, 2012 at 3:43 PM, Ryan Bowlby rbowlb...@gmail.com wrote: Can anyone comment on their experiences with librarian-puppet or using git superproject with per puppet module repositories? I tried using git submodules for a long time. I found that I just could not keep up with updating changed modules in two places (the module repo and the superproject repo). I wound up with projects that were never quite in sync. My other problem is that the puppet ecosystem (the forge, etc) does not really have a concept of a super project. All that it has is modules. I wound up switching to yaml files that specify dependencies with a rake task. This way, I can have superprojects that are themselves puppet modules. It also allows me to only check in the fact that master of all modules should work with master of its dependencies (which is almost always the state that I want checked-in) For an example, have a look at the rake tasks for the puppetlabs-openstack modules: https://github.com/puppetlabs/puppetlabs-openstack/blob/master/Rakefile I would love to see something like this eventually expanded into the Modulefile. I havent really looked at librarian yet, but I am interested. We are in the midst of determining which route is optimal for our environment. It seems like using git superprojects would mean one less new tool for everyone to learn. What then would be the advantages of librarian-puppet? Thanks, Ryan Bowlby -- 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/-/4Kf47PY2sIwJ. 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.
