Re: [Puppet Users] Re: Error sending reports to dashboard
On 04/11/2011 06:55 PM, Mohamed Lrhazi wrote: I did not find any reference I just added a second apache virtual server to do http on port 80. On Mon, Apr 11, 2011 at 12:14 PM, Patrick kc7...@gmail.com wrote: Bump. Anyone know the answer? Can puppet use https to post reports? I'm having trouble sending reports using https too, although I haven't yet found anything useful in the logs. Hi, I'm clueless, but from a technical angle, you can use another workaround if you need your reports to be encrypted en route. Use a local HTTP reporturl, have stunnel listen to the local HTTP port and connect to the remote HTTPS. The agent can speak HTTP while the dashboard should dutifully receive HTTPS. HTH, 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] Re: Problem with pushing ssh_authorized_keys
Forrie [Mon, Apr 11, 2011 at 02:22:03PM -0700]: Thanks, this was the problem. Sounds like a bug to me.. ? How can I go through my systems and remove all the 10's of redundant SSH-DSS keys that have the comment in them? I dread doing that by hand :-) In cdist[0] we've a type __removeline that ensures a given line is not in a file. In puppet creating a new file[] with the content you want to have is probably the easiest solution and afterwards to populate it again in the normal way. Cheers, Nico [0] http://www.nico.schottelius.org/software/cdist/ -- PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0 -- 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] extlookup == bad?
- Original Message - On Mon, Apr 11, 2011 at 9:25 PM, John Warburton jwarbur...@gmail.com wrote: OK, I'll bite In the newly published Style Guide ( http://docs.puppetlabs.com/guides/style_guide.html ), right at the end it says Modules should avoid the use of extlookup() in favor of ENCs or other alternatives For clarity, this should read: in favor of ENCs in combination with parameterized classes But there is no reason as to why. that is partly my fault. the following is my opinion, and may or may not express the opinions of PuppetLabs, although I can be pretty persuasive :) Extlookup provided some necessary pre-2.6.x functionality, namely, a sane way to get around dynamic scoping. This is not what extlookup is for. Yes it effectively works around the Wacky Scope problems but that is not its reason for existing. It exists primarily to: - allow the data - lets call it the model - to live separate from the code (controller?) and the templates (view?) - it is easy to grasp, easy to train members of a team and with a bit of discipline its trivial to look at a class and know how you can configure it. - It doesnt require any code changes to change the way the data behaves which is great for shared code like those found on the forge. Unlike the layered class approach - To replace almost all case statements - To be an appropriate level of complexity for the average Puppet user. Compare experiences in #puppet with newbies learning extlookup vs the layered classes approach. Yes the layered classes approach is elegant and less hacky but it is by no means understandable by newbies. The last point is the big one, Puppet has always been a language for sysadmins who want to automate their infrastructure. The layered class approach is something that you only get once sat in a class and taught. In this regard Puppet has lost its way. It is not awesome though, there are limits to how you can configure the data the approach it takes isn't flexible enough really but it solves most of the problems it set out to solve. You cant programatically figure out what a class requires like you can with param classes if you dig deep enough. So an alternative was proposed - Puppet Data Language[1] that combines with param classes to address this properly. given the option between parameterized class combined with an ENC vs. extlookup, I choose parameterized classes+ENC. The reason is readability and encapsulation. In order to understand an implementation of Puppet using extlookup, you have to understand all of your code in its entirety. After all, any code anywhere in your modulepath could be calling extlookup and accessing data. (I would be very interested to hear if anyone has a good pattern for this) With param classes, you can build a layered architecture of classes that pass data to each other through their explicit interfaces. How easy is it to adjust how you layer these classes? How sharable is this set of layered classes with other teams, other business or event entirely unrelated 3rd parties via the forge? How many inheritance related bugs have gone reported but never fixed? How will the often mooted changes to puppets internal scoping affect already written code? How does layered classes sit with modules already on the forge? In my experience all of these are either unknown or very hard to answer, its difficult to explain as a concept and it is not as flexible or readable as extlookup is in the majority of the cases. These are the problems extlookup exist to address, not a scoping solution. Extlookup replaces a case statement, its trivial to understand, its easy to use and easy to configure. I think it's a much more suitable solution for the average puppet user - a sysadmin - than a complex layered almost OO approach that is favored by seasoned programmer. Our user base simply isn't programmers and understanding complex OO concepts is hard and we should do more to make it easier not harder. This is a known problem, and so Puppet Labs have spec'd the PDL[1] to address these problems, without the PDL I do not consider param classes very user friendly at all. The PDL is a *much* more desirable solution than either layered classes or extlookup, why it has gone un-implemented I dont know and why the current suggestion is that layered classes somehow represents an effective alternative to the PDL I do not understand at all - since surely why bother with the PDL at all then? Because a solution to creating easy to share, document and tweak - without changing the code in the module - is needed and that is what extlookup and the PDL aims to provide. It's a real shame that the PDL has fallen off the wagon and not getting any attention since without it people are stuck with either spending months becoming seasoned Puppet coders or just using extlookup. And without the goal of getting a sharable set of modules
[Puppet Users] Re: puppet dashboard performance issue
I have increase the mysql like this but the queries takes still more than 9sec for the first page. any other suggestions for the mysql tuning ? key_buffer=64M sort_buffer=4M query_cache_size = 20M read_buffer_size=1M Node Load (9090.5ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id Node Load (9082.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status = 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id On Apr 11, 4:19 pm, Vincent vlouvi...@gmail.com wrote: Thanks I have make the rake RAILS_ENV=production db:raw:optimize and in the my.cnf query_cache_size = 2000 Its really better Vincent On 11 avr, 14:26, Mohamed Lrhazi lrh...@gmail.com wrote: There's some rake tasks, and other things, suggested here:https://github.com/puppetlabs/puppet-dashboard On Mon, Apr 11, 2011 at 5:29 AM, Vincent vlouvi...@gmail.com wrote: Hello, since the last upgrade to V1.1.0 The dashboard is very slow I notice this slow queries in the log : Node Load (14178.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id Node Load (13149.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status = 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id How can i optimize the DB ? Vincent -- 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 athttp://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: How to setup database for Inventory Service
Heya, I've merged both approaches. First, I dropped the db on my development server, and then let puppet recreate it. Since I don;t want to lose my historical data in production, I then dumped and compared the schema's from the dev (2.6.7) and prod (2.6.2) environments. I then upgraded prod to 2.6.7 and applied the diff. For what it's worth, here's the SQL I had to execute. Usual disclaimers on you mileage here :) ALTER TABLE resources ADD KEY `exported_restype_title` (`exported`,`restype`,`title`(50)); CREATE TABLE `inventory_facts` ( `node_id` int(11) NOT NULL, `name` varchar(255) NOT NULL, `value` text NOT NULL, UNIQUE KEY `index_inventory_facts_on_node_id_and_name` (`node_id`,`name`) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `inventory_nodes` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `timestamp` datetime NOT NULL, `updated_at` datetime DEFAULT NULL, `created_at` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `index_inventory_nodes_on_name` (`name`) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8; I can see data going into the DB from the latest runs, and I can curl the inventory service, so it seems ok. Setting up Dashboard 1.1.0 as we speak :) HTH, Greg -- 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 dashboard performance issue
query on nodes or reports table are very quick, it s with this join that the query is slow Is an index missing ? On Apr 12, 12:25 pm, Vincent vlouvi...@gmail.com wrote: I have increase the mysql like this but the queries takes still more than 9sec for the first page. any other suggestions for the mysql tuning ? key_buffer=64M sort_buffer=4M query_cache_size = 20M read_buffer_size=1M Node Load (9090.5ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id Node Load (9082.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status = 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id On Apr 11, 4:19 pm, Vincent vlouvi...@gmail.com wrote: Thanks I have make the rake RAILS_ENV=production db:raw:optimize and in the my.cnf query_cache_size = 2000 Its really better Vincent On 11 avr, 14:26, Mohamed Lrhazi lrh...@gmail.com wrote: There's some rake tasks, and other things, suggested here:https://github.com/puppetlabs/puppet-dashboard On Mon, Apr 11, 2011 at 5:29 AM, Vincent vlouvi...@gmail.com wrote: Hello, since the last upgrade to V1.1.0 The dashboard is very slow I notice this slow queries in the log : Node Load (14178.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id Node Load (13149.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status = 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id How can i optimize the DB ? Vincent -- 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 athttp://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppet dashboard performance issue
What indexes do you have on the respective tables? On Tue, Apr 12, 2011 at 5:25 AM, Vincent vlouvi...@gmail.com wrote: I have increase the mysql like this but the queries takes still more than 9sec for the first page. any other suggestions for the mysql tuning ? key_buffer=64M sort_buffer=4M query_cache_size = 20M read_buffer_size=1M Node Load (9090.5ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id Node Load (9082.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status = 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id On Apr 11, 4:19 pm, Vincent vlouvi...@gmail.com wrote: Thanks I have make the rake RAILS_ENV=production db:raw:optimize and in the my.cnf query_cache_size = 2000 Its really better Vincent On 11 avr, 14:26, Mohamed Lrhazi lrh...@gmail.com wrote: There's some rake tasks, and other things, suggested here: https://github.com/puppetlabs/puppet-dashboard On Mon, Apr 11, 2011 at 5:29 AM, Vincent vlouvi...@gmail.com wrote: Hello, since the last upgrade to V1.1.0 The dashboard is very slow I notice this slow queries in the log : Node Load (14178.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id Node Load (13149.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status = 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id How can i optimize the DB ? Vincent -- 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 athttp:// groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: puppet dashboard performance issue
I have noticed thaht when I remove ((reports.kind = ‘apply’ AND reports.status = ‘failed’) part from the query, the query is very quick. mysql show index from reports from dashboard; +-++-- +--+-+---+-+-- ++--++-+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | +-++-- +--+-+---+-+-- ++--++-+ | reports | 0 | PRIMARY |1 | id | A | 112252 | NULL | NULL | | BTREE | | | reports | 1 | index_reports_on_node_id |1 | node_id | A | 652 | NULL | NULL | YES | BTREE | | | reports | 1 | index_reports_on_time_and_node_id_and_status |1 | time| A | 112252 | NULL | NULL | YES | BTREE | | | reports | 1 | index_reports_on_time_and_node_id_and_status |2 | node_id | A | 112252 | NULL | NULL | YES | BTREE | | | reports | 1 | index_reports_on_time_and_node_id_and_status |3 | status | A | 112252 | NULL | NULL | YES | BTREE | | +-++-- +--+-+---+-+-- ++--++-+ 5 rows in set (0.01 sec) On Apr 12, 4:04 pm, Charles Johnson gm.johns...@gmail.com wrote: What indexes do you have on the respective tables? On Tue, Apr 12, 2011 at 5:25 AM, Vincent vlouvi...@gmail.com wrote: I have increase the mysql like this but the queries takes still more than 9sec for the first page. any other suggestions for the mysql tuning ? key_buffer=64M sort_buffer=4M query_cache_size = 20M read_buffer_size=1M Node Load (9090.5ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id Node Load (9082.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status = 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id On Apr 11, 4:19 pm, Vincent vlouvi...@gmail.com wrote: Thanks I have make the rake RAILS_ENV=production db:raw:optimize and in the my.cnf query_cache_size = 2000 Its really better Vincent On 11 avr, 14:26, Mohamed Lrhazi lrh...@gmail.com wrote: There's some rake tasks, and other things, suggested here: https://github.com/puppetlabs/puppet-dashboard On Mon, Apr 11, 2011 at 5:29 AM, Vincent vlouvi...@gmail.com wrote: Hello, since the last upgrade to V1.1.0 The dashboard is very slow I notice this slow queries in the log : Node Load (14178.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id Node Load (13149.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status = 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id How can i optimize the DB ? Vincent -- 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 athttp:// groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] extlookup == bad?
On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar r...@devco.net wrote: The PDL is a *much* more desirable solution than either layered classes or extlookup, why it has gone un-implemented I dont know and why the current suggestion is that layered classes somehow represents an effective alternative to the PDL I do not understand at all - since surely why bother with the PDL at all then? I'll answer this one. The obvious, and correct, answer is, because it's a lot of work to do this. For Puppetlabs to do this, they're going to have to invest a lot of time and energy, because their implementation *must* be backwards-compatible or else provide an automated tool for doing the conversion. Further, the PDL proposal hasn't actually been around all that long. Puppetlabs isn't Microsoft and doesn't have a thousand developers on hand to write stuff up. Their staff is small and no matter how talented they are, there is limited time with each day. Even a user-contributed patch set probably will take time to vet simply because of the compatibility requirements. Caveat: I don't work with or for Puppetlabs, and while I may occasionally complain about X or Y, I respect the work they are doing and their efforts to provide a quality product. -- 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] Multiple file path for single module in the fileserver.conf
Is it possible to have multiple file paths defined for a single module in the fileserver.conf? For example [files] path /first/path/files path /second/path/files allow * [modules] allow * [plugins] allow * The here described configuration did not work as i tried it already. Any idea if this is possible. Thanks a lot 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: [Puppet Users] extlookup == bad?
On 04/12/2011 04:41 PM, R.I.Pienaar wrote: - Original Message - On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar r...@devco.net wrote: The PDL is a *much* more desirable solution than either layered classes or extlookup, why it has gone un-implemented I dont know and why the current suggestion is that layered classes somehow represents an effective alternative to the PDL I do not understand at all - since surely why bother with the PDL at all then? I'll answer this one. The obvious, and correct, answer is, because it's a lot of work to do this. For Puppetlabs to do this, they're going to have to invest a lot of time and energy, because their implementation *must* be backwards-compatible or else provide an automated tool for doing the conversion. Further, the PDL proposal hasn't actually been around all that long. Puppetlabs isn't Microsoft and doesn't have a thousand developers on hand to write stuff up. Their staff is small and no matter how talented they are, there is limited time with each day. Even a user-contributed patch set probably will take time to vet simply because of the compatibility requirements. I get that, I wasnt intending to say 'why has it not been coded yet' but more wondering why extlookup is being downplayed in the absence of a solution that solves the same problem as effectively. Many big users out there today says they cant live without extlookup, simply because it's effective at solving the problem. So I think the original question is very valid - why tell people not to use a feature that is available in the core language? if it sux, remove it. Hi, I can see how this is a soft spot for you, but it wasn't suggested that extlookup was doing a poor job. We're talking the *Style* guide here. So extlookup is being effectively deprecated. You consented that PDL was going to be the superior solution. extlookup may even be going to be obsoleted (it definitely isn't yet). While I believe that it's a bit early to deprecate features when their successor is not even beta yet, I don't see a big issue with it, either. After all, ENC+param classes are available if clumsy (as you put it). 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] Re: puppet dashboard performance issue
You have a partial (i.e., three-part) index 'time', 'node_id', 'status' from which you appear to be selecting against only two parts. On the mysql command line run the query by hand preceded by the keywprd explain explain select nodes blah blah blah You should get back a listing that will let you see how the indexes are being used (or abused!). You may discover that in addition to the composite index you have that two additional indexes will help. ~Charles~ On Tue, Apr 12, 2011 at 9:15 AM, Vincent vlouvi...@gmail.com wrote: I have noticed thaht when I remove ((reports.kind = ‘apply’ AND reports.status = ‘failed’) part from the query, the query is very quick. mysql show index from reports from dashboard; +-++-- +--+-+---+-+-- ++--++-+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | +-++-- +--+-+---+-+-- ++--++-+ | reports | 0 | PRIMARY |1 | id | A | 112252 | NULL | NULL | | BTREE | | | reports | 1 | index_reports_on_node_id |1 | node_id | A | 652 | NULL | NULL | YES | BTREE | | | reports | 1 | index_reports_on_time_and_node_id_and_status |1 | time| A | 112252 | NULL | NULL | YES | BTREE | | | reports | 1 | index_reports_on_time_and_node_id_and_status |2 | node_id | A | 112252 | NULL | NULL | YES | BTREE | | | reports | 1 | index_reports_on_time_and_node_id_and_status |3 | status | A | 112252 | NULL | NULL | YES | BTREE | | +-++-- +--+-+---+-+-- ++--++-+ 5 rows in set (0.01 sec) On Apr 12, 4:04 pm, Charles Johnson gm.johns...@gmail.com wrote: What indexes do you have on the respective tables? On Tue, Apr 12, 2011 at 5:25 AM, Vincent vlouvi...@gmail.com wrote: I have increase the mysql like this but the queries takes still more than 9sec for the first page. any other suggestions for the mysql tuning ? key_buffer=64M sort_buffer=4M query_cache_size = 20M read_buffer_size=1M Node Load (9090.5ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id Node Load (9082.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status = 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id On Apr 11, 4:19 pm, Vincent vlouvi...@gmail.com wrote: Thanks I have make the rake RAILS_ENV=production db:raw:optimize and in the my.cnf query_cache_size = 2000 Its really better Vincent On 11 avr, 14:26, Mohamed Lrhazi lrh...@gmail.com wrote: There's some rake tasks, and other things, suggested here: https://github.com/puppetlabs/puppet-dashboard On Mon, Apr 11, 2011 at 5:29 AM, Vincent vlouvi...@gmail.com wrote: Hello, since the last upgrade to V1.1.0 The dashboard is very slow I notice this slow queries in the log : Node Load (14178.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id Node Load (13149.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status = 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id How can i optimize the DB ? Vincent -- 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 athttp:// 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] Re: extlookup == bad?
On Apr 12, 12:45 am, Dan Bode d...@puppetlabs.com wrote: On Mon, Apr 11, 2011 at 9:25 PM, John Warburton jwarbur...@gmail.comwrote: OK, I'll bite In the newly published Style Guide ( http://docs.puppetlabs.com/guides/style_guide.html), right at the end it says Modules should avoid the use of extlookup() in favor of ENCs or other alternatives For clarity, this should read: in favor of ENCs in combination with parameterized classes But there is no reason as to why. that is partly my fault. the following is my opinion, and may or may not express the opinions of PuppetLabs, although I can be pretty persuasive :) Extlookup provided some necessary pre-2.6.x functionality, namely, a sane way to get around dynamic scoping. given the option between parameterized class combined with an ENC vs. extlookup, I choose parameterized classes+ENC. The reason is readability and encapsulation. I seem to be the person here to most vocally express reservations about parameterized classes in general, but am I really the only one who isn't buying in? I do understand that Puppet Labs put considerable effort into developing the feature, and that they now tout it as one of the key improvements in 2.6, and that it furthermore serves as the foundation for run stages. But none of that makes it technically superior in its current form. Among parameterized classes' problems are 1) parameterized classes can be included only once, unlike unparameterized ones. This tends to require modules to have an hierarchical structure, which isn't very suitable in many circumstances. (More on that below.) It does, however, sort of address 2) parameterized classes present the opportunity to include the same class with different parameters in different places. It's quite reasonable that doing so constitutes an error, but it is unfortunate that the DSL provides the opportunity to commit such an error in the first place. On the other hand, 3) parameterized classes not only permit, but tend to require this: With param classes, you can build a layered architecture of classes that pass data to each other through their explicit interfaces. Talk about losing encapsulation! Every parameter a class exposes constitutes a reduction in the encapsulation it provides. That's even more the case when classes expose parameters solely to pass them on to other classes they include. That sort of parameter forwarding is likely to become necessary because the only sane way to manage an architecture wherein parameterized classes include other parameterized classes is to structure it hierarchically. A hierarchical manifest architecture isn't particularly suitable, however, because real system configurations aren't hierarchical. The Style Guide seems to poo-poo that last problem when it says classes which require other classes should not directly declare them and should instead allow the system to fail if they are not declared by some other means. (Or at least I think that's what it's doing -- I find the Guide's usage of the term declare to be a bit ambiguous.) Really, the Guide's recommendation here is a practical necessity, not a stylistic issue, once you're committed to a hierarchy of parameterized classes. But why is it presented as if it were a good approach? It creates points of failure that shouldn't be needed, and it constitutes another encapsulation violation wherever it applies. Furthermore, 4) parameterized classes make configurations harder to maintain because changes to a class's parameterization require corresponding changes wherever that class is included. This is a symptom of the loss of encapsulation inherent in parameterization (3, above), but I call it out specifically because it's more concrete. Additionally, 5) parameterized classes, and especially the term parameter passing have a bit of code smell in declarative Puppet DSL. I'm satisfied that the implementation is appropriately declarative, but the concept evidently influences people toward thinking along imperative lines, which typically doesn't fit well with Puppet, and which is already a big enough trap for the unwary. As I understand it, the main objectives of parameterized classes are (a) to provide an alternative to dynamically-scoped variables for influencing classes, and (b) to better document classes' data dependencies. Indeed, the feature does achieve those objectives. I tend to discount the documentation aspect, however, for I don't find class parameters adequate without ordinary text documentation, whereas text documentation can be adequate without parameterization. As for feeding data to classes, parameters certainly aren't the only way, and with all their disadvantages, they usually aren't the best way. 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
Re: [Puppet Users] extlookup == bad?
- Original Message - On 04/12/2011 04:41 PM, R.I.Pienaar wrote: - Original Message - On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar r...@devco.net wrote: The PDL is a *much* more desirable solution than either layered classes or extlookup, why it has gone un-implemented I dont know and why the current suggestion is that layered classes somehow represents an effective alternative to the PDL I do not understand at all - since surely why bother with the PDL at all then? I'll answer this one. The obvious, and correct, answer is, because it's a lot of work to do this. For Puppetlabs to do this, they're going to have to invest a lot of time and energy, because their implementation *must* be backwards-compatible or else provide an automated tool for doing the conversion. Further, the PDL proposal hasn't actually been around all that long. Puppetlabs isn't Microsoft and doesn't have a thousand developers on hand to write stuff up. Their staff is small and no matter how talented they are, there is limited time with each day. Even a user-contributed patch set probably will take time to vet simply because of the compatibility requirements. I get that, I wasnt intending to say 'why has it not been coded yet' but more wondering why extlookup is being downplayed in the absence of a solution that solves the same problem as effectively. Many big users out there today says they cant live without extlookup, simply because it's effective at solving the problem. So I think the original question is very valid - why tell people not to use a feature that is available in the core language? if it sux, remove it. Hi, I can see how this is a soft spot for you, but it wasn't suggested that extlookup was doing a poor job. We're talking the *Style* guide here. I think you miss understand me, I dont care for extlookup one way or the other, I've never really run the one in the core distro as I have some other enhancements that isn't in Puppet. I do care what recommendations are made to the community - not just those who pay for training so they can understand complex data modeling with OO like inheritance. I care for a simple to understand, simple to explain CM language, one suitable for traditional systems adminis - the kind of guys I care for and who I want to help - and I think we're failing them with ever more complex recommendations. After all, ENC+param classes are available if clumsy (as you put it). Rather than use a feature that exist and solve the problem, the recommendation is that each user should *write their own ENC that models their data* and this is somehow more effective than just using the existing extlookup while the PDL is being developed? -- R.I.Pienaar -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Puppet dashboard ap_content_length_filter error
I'm running puppet dashboard on a SLES10 system. I'm using apache2 included with SLES10 and everything is custom compiles: apache2-2.2.3-16.29.2 ruby-augeas-0.3.0-1.sles10 ruby-1.8.7-1.sles10 ruby-gem-rake-0.8.7-1.sles10 ruby-gem-rack-1.2.1-1.sles10 ruby-gem-passenger-3.0.2-1.sles10 ruby-gem-sys-admin-1.5.4-1.sles10 puppetmaster-2.6.4-1.sles10 ruby-gem-mysql-2.8.1-1.sles10 puppet-dashboard-1.0.4-1.sles10 rubygems-1.4.1-1.sles10 facter-1.5.8-1.sles10 The error I get in my apache logfile is: [Tue Apr 12 10:18:23 2011] [error] [client xxx.xxx.xxx.xxx] (104)Connection reset by peer: ap_content_length_filter: apr_bucket_read() failed If I edit my puppet.conf on the puppetmaster from (which was set per https://github.com/puppetlabs/puppet-dashboard): reporturl = http://hostname/reports/upload to (found reference to this older path somewhere, don't remember where): reporturl = http://hostname/reports Everything works fine. From what I've read, '/reports' is old/ deprecated and 'reports/upload' is what should be used ... so I was wondering if this has been seen before and/or if I'm doing something wrong. If you want more information, let me know and I can provide. Thanks, Jake -- 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 dashboard ap_content_length_filter error
On Apr 12, 2011, at 8:41 AM, Jake - USPS wrote: puppet-dashboard-1.0.4-1.sles10 Everything works fine. From what I've read, '/reports' is old/ deprecated and 'reports/upload' is what should be used ... so I was wondering if this has been seen before and/or if I'm doing something wrong. As far as I can tell, the quick answer is: The replacement was only added in 1.1.0. If your version is less than 1.1.0, you need to use the old URL. -- 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: extlookup == bad?
On Apr 12, 2011, at 8:03 AM, jcbollinger wrote: 1) parameterized classes can be included only once, unlike unparameterized ones. This tends to require modules to have an hierarchical structure, which isn't very suitable in many circumstances. (More on that below.) It does, however, sort of address My understanding is that there's no difference between parameterized classes you can include more than once and defines. If you disagree, please enlighten me. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: How to setup database for Inventory Service
On Apr 12, 2011, at 4:16 AM, Greg Sutcliffe wrote: Since I don;t want to lose my historical data in production, What's that mean exactly? Are you saying you don't want to drop reports while the DB is being migrated? -- 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] noob question - How to manage uid/gid changes outside home directory with puppet?
If I create a user resource and specify UID and a group resource and specify GID where the user and group may or may not already exist, in the case where the user or group does exist would it be best practice to: 1) Have puppet change the uid/gid values, then post this change, trawl through logs to find old new uid/gid values and manually run find to recursively change files and directories outside the users home directory, or 2) Use some type of exec to trigger on user/group resource refesh only to run the same thing automatically? I'm in two minds, in that the second option means I don't have to do anything manually but I also wouldn't want the exec triggered if I just change something like the user comment for example. If an exec is okay to use in these cases, then how would I get the 'old' uid/gid value into a puppet variable before I make the change, as I would need to know this in order to run the chown/chgrp automatically. Thanks for your time. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: How to setup database for Inventory Service
Actually that is the good way to do that on a fresh installation I suppose, but I wonder, and ask, if there's a way to create the needed schema for the Inventory service without destroying the current database. My case is that I've a Puppet Master with storeconfigs activated and a lot of data already stored. I've just updated it from 0.25.x (btw, now it's 2.6 times ... slower :-) and want to activate the inventory service and I face Mohamed's same error. I'd prefer to avoid to drop everything and wait for convergence. While writing I just realized that I can just dump a fresh db on a test puppetmaster and import the relevant inventory tables, but, well, if there's an official way to do that, or just a rake script or whatever, it would be better. Hints? al -- 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] spec tests for puppet modules
Hi,
I was curious if anyone out there could point me in the right direction to best
practices in writing (spec) tests for modules. My #{search provider}-fu is
failing this morning and I'd like to get beyond the basic pre/post commit hooks
of basic syntax checking.
Cheers,
Ryan
--
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] augtool/augeas -- clearly missing something...
context = /etc/network/interfaces, Shouldn't this be /files/etc/network/interfaces? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: How to setup database for Inventory Service
Hi Luke, thanks for reply. I'm already using (thin) storeconfigs, and I would prefer to avoid deleting the currently stored data just to inizialize a clean db schema (I think the inventory service uses extra tables). There are 2 reasons why I'd prefer to avoid trashing stored configs data, even if I know that everything will be recreated: - First time data is stored, afaik, it make much more sql queries and this could kill the (production) puppetmaster. - Store confis are used in monitoring systems and it would take a bit of time to reach convergence. None of them are really blocking reasons, since we can work around them, but since I suppose is just a matter of creating some empty tables to store inventory data I would prefer a less disruptive approach. Still, and I ask to Brice or other storeconfigs/inventory experts, if you think it would be better to clean up everything from scrath, I could follow that path. Regards, Al On Apr 12, 3:06 am, Luke Baker bake...@missouri.edu wrote: Hey there, I used the storeconfigs database. Here is a condensed version of the storeconfigs setup,http://linux-collective.blogspot.com/2011/04/puppet-storeconfigs.html. You shouldn't need to migrate anything, the data will be populated when the clients check in. On Apr 11, 10:07 am, Alessandro Franceschi a...@lab42.it wrote: Actually that is the good way to do that on a fresh installation I suppose, but I wonder, and ask, if there's a way to create the needed schema for the Inventory service without destroying the current database. My case is that I've a Puppet Master with storeconfigs activated and a lot of data already stored. I've just updated it from 0.25.x (btw, now it's 2.6 times ... slower :-) and want to activate the inventory service and I face Mohamed's same error. I'd prefer to avoid to drop everything and wait for convergence. While writing I just realized that I can just dump a fresh db on a test puppetmaster and import the relevant inventory tables, but, well, if there's an official way to do that, or just a rake script or whatever, it would be better. Hints? al -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppet dashboard performance issue
here is the result , I don't know what to do :( mysql explain SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id; ++-+-+---+--+--+-++--+-+ | id | select_type | table | type | possible_keys| key | key_len | ref| rows | Extra | ++-+-+---+--+--+-++--+-+ | 1 | SIMPLE | nodes | index | PRIMARY | PRIMARY | 4 | NULL | 573 | Using where | | 1 | SIMPLE | reports | ref | index_reports_on_node_id | index_reports_on_node_id | 5 | dashboard.nodes.id | 167 | Using where | ++-+-+---+--+--+-++--+-+ 2 rows in set (0.00 sec) http://nodes.id/ 2011/4/12 Charles Johnson gm.johns...@gmail.com You have a partial (i.e., three-part) index 'time', 'node_id', 'status' from which you appear to be selecting against only two parts. On the mysql command line run the query by hand preceded by the keywprd explain explain select nodes blah blah blah You should get back a listing that will let you see how the indexes are being used (or abused!). You may discover that in addition to the composite index you have that two additional indexes will help. ~Charles~ On Tue, Apr 12, 2011 at 9:15 AM, Vincent vlouvi...@gmail.com wrote: I have noticed thaht when I remove ((reports.kind = ‘apply’ AND reports.status = ‘failed’) part from the query, the query is very quick. mysql show index from reports from dashboard; +-++-- +--+-+---+-+-- ++--++-+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | +-++-- +--+-+---+-+-- ++--++-+ | reports | 0 | PRIMARY |1 | id | A | 112252 | NULL | NULL | | BTREE | | | reports | 1 | index_reports_on_node_id |1 | node_id | A | 652 | NULL | NULL | YES | BTREE | | | reports | 1 | index_reports_on_time_and_node_id_and_status |1 | time| A | 112252 | NULL | NULL | YES | BTREE | | | reports | 1 | index_reports_on_time_and_node_id_and_status |2 | node_id | A | 112252 | NULL | NULL | YES | BTREE | | | reports | 1 | index_reports_on_time_and_node_id_and_status |3 | status | A | 112252 | NULL | NULL | YES | BTREE | | +-++-- +--+-+---+-+-- ++--++-+ 5 rows in set (0.01 sec) On Apr 12, 4:04 pm, Charles Johnson gm.johns...@gmail.com wrote: What indexes do you have on the respective tables? On Tue, Apr 12, 2011 at 5:25 AM, Vincent vlouvi...@gmail.com wrote: I have increase the mysql like this but the queries takes still more than 9sec for the first page. any other suggestions for the mysql tuning ? key_buffer=64M sort_buffer=4M query_cache_size = 20M read_buffer_size=1M Node Load (9090.5ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id Node Load (9082.9ms) SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status = 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id On Apr 11, 4:19 pm, Vincent vlouvi...@gmail.com wrote: Thanks I have make the rake RAILS_ENV=production db:raw:optimize and in the my.cnf query_cache_size = 2000 Its really better Vincent On 11 avr, 14:26, Mohamed Lrhazi lrh...@gmail.com wrote: There's some rake tasks, and other things, suggested here: https://github.com/puppetlabs/puppet-dashboard On Mon, Apr 11, 2011 at 5:29 AM, Vincent vlouvi...@gmail.com wrote: Hello, since the last upgrade to V1.1.0 The dashboard is very slow I notice this
[Puppet Users] Re: Puppet dashboard ap_content_length_filter error
Arg, I didn't even realize I was already using an old version ... I'll update to 1.1.0 and give it another shot. Thanks for the reply. On Apr 12, 10:48 am, Patrick kc7...@gmail.com wrote: On Apr 12, 2011, at 8:41 AM, Jake - USPS wrote: puppet-dashboard-1.0.4-1.sles10 Everything works fine. From what I've read, '/reports' is old/ deprecated and 'reports/upload' is what should be used ... so I was wondering if this has been seen before and/or if I'm doing something wrong. As far as I can tell, the quick answer is: The replacement was only added in 1.1.0. If your version is less than 1.1.0, you need to use the old URL. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet dashboard ap_content_length_filter error
On Apr 12, 2011, at 9:57 AM, Jake - USPS wrote: Arg, I didn't even realize I was already using an old version ... I'll update to 1.1.0 and give it another shot. Thanks for the reply. As a quick reminder if you're skimming release notes, or not reading them at all, you'll need to do two migrates for that upgrade. The first (normal) one took me about 10 minutes. During that time, dashboard didn't work. The second one took me 4 hours, but you can run dashboard while it's running. Until you finish the second migrate, you can't use any old reports. -- 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 dashboard ap_content_length_filter error
What release notes are you referring to? The puppet-dashboard page mentions 1 upgrade, as does the README.markdown in the source/ package. There is a RELEASE_NOTES.md file, but that seems to be a copy of CHANGELOG. Please let me know if I missed something or if there is a better place to look for this type of information so I know where to look for these type of oddities. Thanks, Jake On Apr 12, 12:13 pm, Patrick kc7...@gmail.com wrote: On Apr 12, 2011, at 9:57 AM, Jake - USPS wrote: Arg, I didn't even realize I was already using an old version ... I'll update to 1.1.0 and give it another shot. Thanks for the reply. As a quick reminder if you're skimming release notes, or not reading them at all, you'll need to do two migrates for that upgrade. The first (normal) one took me about 10 minutes. During that time, dashboard didn't work. The second one took me 4 hours, but you can run dashboard while it's running. Until you finish the second migrate, you can't use any old reports. -- 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] extlookup == bad?
Hi all, Thanks for the input On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar r...@devco.net wrote: - Original Message - On Mon, Apr 11, 2011 at 9:25 PM, John Warburton jwarbur...@gmail.com wrote: OK, I'll bite In the newly published Style Guide ( http://docs.puppetlabs.com/guides/style_guide.html ), right at the end it says Modules should avoid the use of extlookup() in favor of ENCs or other alternatives For clarity, this should read: in favor of ENCs in combination with parameterized classes But there is no reason as to why. that is partly my fault. the following is my opinion, and may or may not express the opinions of PuppetLabs, although I can be pretty persuasive :) Extlookup provided some necessary pre-2.6.x functionality, namely, a sane way to get around dynamic scoping. This is not what extlookup is for. Yes it effectively works around the Wacky Scope problems but that is not its reason for existing. It exists primarily to: - allow the data - lets call it the model - to live separate from the code (controller?) and the templates (view?) Let me clarify this: I understand this is not what extlookup is for, I was saying here that this is why is was 'necessary' pre 2.6.x (as a sane alternative to dynamic scoping), I apologize, because obviously my intent here was not clear . The kind of data modeling you mention has been possible with an ENC for as long as I have been using Puppet. - it is easy to grasp, easy to train members of a team and with a bit of discipline its trivial to look at a class and know how you can configure it. The fact that you have to look at the class to understand what data it accepts is my main complaint. I have not found parameterized classes problematic to teach, do you have some specific experiences around this? - It doesnt require any code changes to change the way the data behaves which is great for shared code like those found on the forge. Unlike the layered class approach I am not sue what you mean here - To replace almost all case statements I also agree that Puppet should have as little conditional logic as possible, I have recently been solving this with a combination of an ENC and ::param namespaced classes (an entirely different topic). - To be an appropriate level of complexity for the average Puppet user. Compare experiences in #puppet with newbies learning extlookup vs the layered classes approach. I don't have any data related to this, but would be interested on further perspective. Yes the layered classes approach is elegant and less hacky but it is by no means understandable by newbies. The last point is the big one, Puppet has always been a language for sysadmins who want to automate their infrastructure. The layered class approach is something that you only get once sat in a class and taught. In this regard Puppet has lost its way. That is a really strong assertion RI. We are doing our best to create reasonable practices that 'we' can use to create modules, we have shared our first reasonable version of those with the community so that we can work to make it better. It is not awesome though, there are limits to how you can configure the data the approach it takes isn't flexible enough really but it solves most of the problems it set out to solve. You cant programatically figure out what a class requires like you can with param classes if you dig deep enough. I hope we do a better job of exposing those APIs in the future So an alternative was proposed - Puppet Data Language[1] that combines with param classes to address this properly. given the option between parameterized class combined with an ENC vs. extlookup, I choose parameterized classes+ENC. The reason is readability and encapsulation. In order to understand an implementation of Puppet using extlookup, you have to understand all of your code in its entirety. After all, any code anywhere in your modulepath could be calling extlookup and accessing data. (I would be very interested to hear if anyone has a good pattern for this) With param classes, you can build a layered architecture of classes that pass data to each other through their explicit interfaces. How easy is it to adjust how you layer these classes? I do not understand this question How sharable is this set of layered classes with other teams, other business or event entirely unrelated 3rd parties via the forge? this is one of the main reasons that I like param classes, explicit interfaces should make sharing/collaboration easier. How many inheritance related bugs have gone reported but never fixed? inheritance is not something that I recommend in general, although I would appreciate a short list of these are the broken things about inheritance. How will the often mooted changes to puppets internal scoping affect already written code? How
Re: [Puppet Users] extlookup == bad?
On Tue, Apr 12, 2011 at 8:00 AM, R.I.Pienaar r...@devco.net wrote: - Original Message - On 04/12/2011 04:41 PM, R.I.Pienaar wrote: - Original Message - On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar r...@devco.net wrote: The PDL is a *much* more desirable solution than either layered classes or extlookup, why it has gone un-implemented I dont know and why the current suggestion is that layered classes somehow represents an effective alternative to the PDL I do not understand at all - since surely why bother with the PDL at all then? I'll answer this one. The obvious, and correct, answer is, because it's a lot of work to do this. For Puppetlabs to do this, they're going to have to invest a lot of time and energy, because their implementation *must* be backwards-compatible or else provide an automated tool for doing the conversion. Further, the PDL proposal hasn't actually been around all that long. Puppetlabs isn't Microsoft and doesn't have a thousand developers on hand to write stuff up. Their staff is small and no matter how talented they are, there is limited time with each day. Even a user-contributed patch set probably will take time to vet simply because of the compatibility requirements. I get that, I wasnt intending to say 'why has it not been coded yet' but more wondering why extlookup is being downplayed in the absence of a solution that solves the same problem as effectively. Many big users out there today says they cant live without extlookup, simply because it's effective at solving the problem. So I think the original question is very valid - why tell people not to use a feature that is available in the core language? if it sux, remove it. Hi, I can see how this is a soft spot for you, but it wasn't suggested that extlookup was doing a poor job. We're talking the *Style* guide here. I think you miss understand me, I dont care for extlookup one way or the other, I've never really run the one in the core distro as I have some other enhancements that isn't in Puppet. I do care what recommendations are made to the community - not just those who pay for training so they can understand complex data modeling with OO like inheritance. I care for a simple to understand, simple to explain CM language, one suitable for traditional systems adminis - the kind of guys I care for and who I want to help - and I think we're failing them with ever more complex recommendations. After all, ENC+param classes are available if clumsy (as you put it). Rather than use a feature that exist and solve the problem, the recommendation is that each user should *write their own ENC that models their data* and this is somehow more effective than just using the existing extlookup while the PDL is being developed? I agree with this. One huge problem with this recommendation is that we have still not shipped a feature complete ENC that can serve as a replacement to the data modeling that extlookup provides. This argument would be a lot more compeling if it was use param classes, and Puppetlabs super cool ENC. I have spent some time working with customers to explain how to build these, and I have been working on one that supports the model that I have in mind... -- R.I.Pienaar -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet dashboard ap_content_length_filter error
I just finished getting my 1.1.0rc3 package created and as you thought my issues disappeared ... /reports/upload works fine now. Thanks, Jake On Apr 12, 12:33 pm, Jake - USPS jacob.m.mcc...@usps.gov wrote: What release notes are you referring to? The puppet-dashboard page mentions 1 upgrade, as does the README.markdown in the source/ package. There is a RELEASE_NOTES.md file, but that seems to be a copy of CHANGELOG. Please let me know if I missed something or if there is a better place to look for this type of information so I know where to look for these type of oddities. Thanks, Jake On Apr 12, 12:13 pm, Patrick kc7...@gmail.com wrote: On Apr 12, 2011, at 9:57 AM, Jake - USPS wrote: Arg, I didn't even realize I was already using an old version ... I'll update to 1.1.0 and give it another shot. Thanks for the reply. As a quick reminder if you're skimming release notes, or not reading them at all, you'll need to do two migrates for that upgrade. The first (normal) one took me about 10 minutes. During that time, dashboard didn't work. The second one took me 4 hours, but you can run dashboard while it's running. Until you finish the second migrate, you can't use any old reports. -- 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] extlookup == bad?
- Original Message - Hi all, Thanks for the input On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar r...@devco.net wrote: - Original Message - On Mon, Apr 11, 2011 at 9:25 PM, John Warburton jwarbur...@gmail.com wrote: OK, I'll bite In the newly published Style Guide ( http://docs.puppetlabs.com/guides/style_guide.html ), right at the end it says Modules should avoid the use of extlookup() in favor of ENCs or other alternatives For clarity, this should read: in favor of ENCs in combination with parameterized classes But there is no reason as to why. that is partly my fault. the following is my opinion, and may or may not express the opinions of PuppetLabs, although I can be pretty persuasive :) Extlookup provided some necessary pre-2.6.x functionality, namely, a sane way to get around dynamic scoping. This is not what extlookup is for. Yes it effectively works around the Wacky Scope problems but that is not its reason for existing. It exists primarily to: - allow the data - lets call it the model - to live separate from the code (controller?) and the templates (view?) Let me clarify this: I understand this is not what extlookup is for, I was saying here that this is why is was 'necessary' pre 2.6.x (as a sane alternative to dynamic scoping), I apologize, because obviously my intent here was not clear . The kind of data modeling you mention has been possible with an ENC for as long as I have been using Puppet. Solving this problem with an ENC is suitable for people who can program. You are saying 'puppet cannot do this on its own, please write a whole bunch of code in $language to address the shortcoming' is this the message to send people who do not want to pay someone to come write that ENC? In the context of the question: do we use extlookup to solve this problem or do we use an ENC to solve the problem. Your answer here is extlookup isnt needed, just write your own ENC. I am saying this is a very un newbie friendly message to send to the user base when there is a way to solve the problem now while puppetlabs works on either a good ENC that we can download or work on finishing the PDL. - it is easy to grasp, easy to train members of a team and with a bit of discipline its trivial to look at a class and know how you can configure it. The fact that you have to look at the class to understand what data it accepts is my main complaint. today, the day your recommendations are up there for everyone to adhere to and the scope of the question from the OP, this is no different with parametrized classes. There is no released introspection tool, there is no ability in dashboard to just ask the information it needs, to use a paramterized module, u need to open its classes and look at its params. Is this not the case? You seem to say here's a set of recommendations for how to use puppet, we think this is how you should do it and our reasons for saying so is that there's a bunch of unreleased features that makes it awesome. I have not found parameterized classes problematic to teach, do you have some specific experiences around this? No hard evidence, gut feel is if you go ask in #puppet or get together a representative group of people who have not been trained by PL you will probably find param classes are in very minimal use because they are a solution looking for a problem today - because the full picture isnt clear without PDL and so forth - It doesnt require any code changes to change the way the data behaves which is great for shared code like those found on the forge. Unlike the layered class approach I am not sue what you mean here You can just configure your data source to behave in line with local policies - not change the code. Which means if you cloned code from elsewhere the fork is a clean clone rather than a fork. Changing data vs rewriting code is very important from a change control point of view etc The last point is the big one, Puppet has always been a language for sysadmins who want to automate their infrastructure. The layered class approach is something that you only get once sat in a class and taught. In this regard Puppet has lost its way. That is a really strong assertion RI. We are doing our best to create reasonable practices that 'we' can use to create modules, we have shared our first reasonable version of those with the community so that we can work to make it better. the recurring recommendation is to use a ENC. There is no decent ready to use ENC that people can just download - dashboard isnt great yet. So in order to use Puppet today and get strong data modeling you have to be a team who can *program* an ENC, the kind of team who can think about abstract concepts like layered data and modeling of real world objects into data. Turning this model into a full featured ENC that
Re: [Puppet Users] Re: puppet dashboard performance issue
I have add an index ALTER TABLE `reports` ADD INDEX `index_reports_on_kind_and_status` ( `kind` , `status` ) it s better but maybe not perfect as the query is performed on each pages in the dashboard Thanks Vincent mysql explain SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id; ++-+-++---+--+-+---+---+--+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra| ++-+-++---+--+-+---+---+--+ | 1 | SIMPLE | reports | ref| index_reports_on_node_id,index_reports_on_kind_and_status | index_reports_on_kind_and_status | 768 | const | 19483 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | nodes | eq_ref | PRIMARY | PRIMARY | 4 | dashboard.reports.node_id | 1 | Using where | ++-+-++---+--+-+---+---+--+ 2 rows in set (0.00 sec) 2011/4/12 Charles Johnson gm.johns...@gmail.com A couple of things to notice. First, only the nodes.id index and index_reports_on_node_id index are used, and since index_reports_on_node_id is used as a ref type you will have 573 x 167 rows to examine (95,651 more or less) to produce the rows your sql finally fetches. You might --important: might-- be able to do better. There is an index: index_reports_on_time_and_node_id_and_status, which includes node_id and status, but is not used. Without hurting anything, and without changing the query you could create an index on reports.kind and reports.status. This might help if there are lots of different values for kind and status. For example, you generally do not want to create an index for a column where the only values are 'true' and 'false', say. That effectively divides the table in half, and if you have a million rows, reducing a full scan to 500,000 may not help much. But anyway, if you know how to create indexes, this is what I would try first. Others probably have much better ideas. You might ping a mysql list as well. On Tue, Apr 12, 2011 at 11:26 AM, vincent vinc...@louviaux.com wrote: here is the result , I don't know what to do :( mysql explain SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id ; ++-+-+---+--+--+-++--+-+ | id | select_type | table | type | possible_keys| key | key_len | ref| rows | Extra | ++-+-+---+--+--+-++--+-+ | 1 | SIMPLE | nodes | index | PRIMARY | PRIMARY | 4 | NULL | 573 | Using where | | 1 | SIMPLE | reports | ref | index_reports_on_node_id | index_reports_on_node_id | 5 | dashboard.nodes.id | 167 | Using where | ++-+-+---+--+--+-++--+-+ 2 rows in set (0.00 sec) http://nodes.id/ 2011/4/12 Charles Johnson gm.johns...@gmail.com You have a partial (i.e., three-part) index 'time', 'node_id', 'status' from which you appear to be selecting against only two parts. On the mysql command line run the query by hand preceded by the keywprd explain explain select nodes blah blah blah You should get back a listing that will let you see how the indexes are being used (or abused!). You may discover that in addition to the composite index you have that two additional indexes will help. ~Charles~ On Tue, Apr 12, 2011 at 9:15 AM, Vincent vlouvi...@gmail.com wrote: I have noticed thaht when I remove ((reports.kind = ‘apply’ AND reports.status = ‘failed’) part from the query, the query is very quick. mysql show index from reports from dashboard; +-++--
Re: [Puppet Users] extlookup == bad?
On Tue, Apr 12, 2011 at 11:24 AM, R.I.Pienaar r...@devco.net wrote: - Original Message - Hi all, Thanks for the input On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar r...@devco.net wrote: - Original Message - On Mon, Apr 11, 2011 at 9:25 PM, John Warburton jwarbur...@gmail.com wrote: OK, I'll bite In the newly published Style Guide ( http://docs.puppetlabs.com/guides/style_guide.html ), right at the end it says Modules should avoid the use of extlookup() in favor of ENCs or other alternatives For clarity, this should read: in favor of ENCs in combination with parameterized classes But there is no reason as to why. that is partly my fault. the following is my opinion, and may or may not express the opinions of PuppetLabs, although I can be pretty persuasive :) Extlookup provided some necessary pre-2.6.x functionality, namely, a sane way to get around dynamic scoping. This is not what extlookup is for. Yes it effectively works around the Wacky Scope problems but that is not its reason for existing. It exists primarily to: - allow the data - lets call it the model - to live separate from the code (controller?) and the templates (view?) Let me clarify this: I understand this is not what extlookup is for, I was saying here that this is why is was 'necessary' pre 2.6.x (as a sane alternative to dynamic scoping), I apologize, because obviously my intent here was not clear . The kind of data modeling you mention has been possible with an ENC for as long as I have been using Puppet. Solving this problem with an ENC is suitable for people who can program. You are saying 'puppet cannot do this on its own, please write a whole bunch of code in $language to address the shortcoming' is this the message to send people who do not want to pay someone to come write that ENC? In the context of the question: do we use extlookup to solve this problem or do we use an ENC to solve the problem. Your answer here is extlookup isnt needed, just write your own ENC. I am saying this is a very un newbie friendly message to send to the user base when there is a way to solve the problem now while puppetlabs works on either a good ENC that we can download or work on finishing the PDL. I completely agree that this recommendation is a little lacking without an existing ENC to back it up. - it is easy to grasp, easy to train members of a team and with a bit of discipline its trivial to look at a class and know how you can configure it. The fact that you have to look at the class to understand what data it accepts is my main complaint. today, the day your recommendations are up there for everyone to adhere to and the scope of the question from the OP, this is no different with parametrized classes. There is no released introspection tool, It is a little rough around the edges, but there I have released (or at publised code for) an introspection tool (its just not very well advertised), It probably has a few bugs, and I am happy to address those via github issues. https://github.com/puppetlabs/interface-utils have a look at parser get_classes it needs a little polish, but it works against 2.6.5 or higher this tool relies on an existing indirector (resource_type) which should have this functionality built-in in Statler http://projects.puppetlabs.com/issues/6851 there is no ability in dashboard to just ask the information it needs, to use a paramterized module, u need to open its classes and look at its params. Is this not the case? have a look at: puppet dashboard import_classes --dashboard_path-/usr/local/dev/puppet-dashboard from the same repo. This is admittedly a prototype and something not ready for prime-time, I just want to highlight that I understand these concerns and am actively working to address them. You seem to say here's a set of recommendations for how to use puppet, we think this is how you should do it and our reasons for saying so is that there's a bunch of unreleased features that makes it awesome. This may be the major point of confusion. This document was written internally to specify how we will be writing modules. We are sharing it with the outside world b/c we try to be open. As we develop our internal modules, it is reasonable that we can write tools to make the process easier or improve Puppet to make the process easier. There is perhaps one point that we missed in this process: if we choose a path that is forward looking and not how people currently develop modules, then how are they going to use these modules, this is something that needs a little more effort. I have not found parameterized classes problematic to teach, do you have some specific experiences around this? No hard evidence, gut feel is if you go ask in #puppet or get together a representative group
Re: [Puppet Users] extlookup == bad?
- Original Message - On Tue, Apr 12, 2011 at 12:54 AM, R.I.Pienaar r...@devco.net wrote: - Original Message - On Mon, Apr 11, 2011 at 9:25 PM, John Warburton jwarbur...@gmail.com wrote: OK, I'll bite In the newly published Style Guide ( http://docs.puppetlabs.com/guides/style_guide.html ), right at the end it says Modules should avoid the use of extlookup() in favor of ENCs or other alternatives For clarity, this should read: in favor of ENCs in combination with parameterized classes But there is no reason as to why. that is partly my fault. the following is my opinion, and may or may not express the opinions of PuppetLabs, although I can be pretty persuasive :) Extlookup provided some necessary pre-2.6.x functionality, namely, a sane way to get around dynamic scoping. This is not what extlookup is for. Yes it effectively works around the Wacky Scope problems but that is not its reason for existing. It exists primarily to: - allow the data - lets call it the model - to live separate from the code (controller?) and the templates (view?) Let me clarify this: I understand this is not what extlookup is for, I was saying here that this is why is was 'necessary' pre 2.6.x (as a sane alternative to dynamic scoping), I apologize, because obviously my intent here was not clear . The kind of data modeling you mention has been possible with an ENC for as long as I have been using Puppet. Solving this problem with an ENC is suitable for people who can program. You are saying 'puppet cannot do this on its own, please write a whole bunch of code in $language to address the shortcoming' is this the message to send people who do not want to pay someone to come write that ENC? In the context of the question: do we use extlookup to solve this problem or do we use an ENC to solve the problem. Your answer here is extlookup isnt needed, just write your own ENC. I am saying this is a very un newbie friendly message to send to the user base when there is a way to solve the problem now while puppetlabs works on either a good ENC that we can download or work on finishing the PDL. I completely agree that this recommendation is a little lacking without an existing ENC to back it up. lots snipped where you mostly agree with me that the style guide should be a roadmap doc so whats the recommendation today for the user base then? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppet dashboard performance issue
Good try! But I was not clear. Try an index just for kind, and another separate index just for status. You are down to 4 x 768 (3072) from 95691. That is much better. Again, drop the create separate indexes for kind and status and index_reports_on_kind_and_status . On Tue, Apr 12, 2011 at 2:11 PM, vincent vinc...@louviaux.com wrote: I have add an index ALTER TABLE `reports` ADD INDEX `index_reports_on_kind_and_status` ( `kind` , `status` ) it s better but maybe not perfect as the query is performed on each pages in the dashboard Thanks Vincent mysql explain SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id ; ++-+-++---+--+-+---+---+--+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra| ++-+-++---+--+-+---+---+--+ | 1 | SIMPLE | reports | ref| index_reports_on_node_id,index_reports_on_kind_and_status | index_reports_on_kind_and_status | 768 | const | 19483 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | nodes | eq_ref | PRIMARY | PRIMARY | 4 | dashboard.reports.node_id | 1 | Using where | ++-+-++---+--+-+---+---+--+ 2 rows in set (0.00 sec) 2011/4/12 Charles Johnson gm.johns...@gmail.com A couple of things to notice. First, only the nodes.id index and index_reports_on_node_id index are used, and since index_reports_on_node_id is used as a ref type you will have 573 x 167 rows to examine (95,651 more or less) to produce the rows your sql finally fetches. You might --important: might-- be able to do better. There is an index: index_reports_on_time_and_node_id_and_status, which includes node_id and status, but is not used. Without hurting anything, and without changing the query you could create an index on reports.kind and reports.status. This might help if there are lots of different values for kind and status. For example, you generally do not want to create an index for a column where the only values are 'true' and 'false', say. That effectively divides the table in half, and if you have a million rows, reducing a full scan to 500,000 may not help much. But anyway, if you know how to create indexes, this is what I would try first. Others probably have much better ideas. You might ping a mysql list as well. On Tue, Apr 12, 2011 at 11:26 AM, vincent vinc...@louviaux.com wrote: here is the result , I don't know what to do :( mysql explain SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id; ++-+-+---+--+--+-++--+-+ | id | select_type | table | type | possible_keys| key | key_len | ref| rows | Extra | ++-+-+---+--+--+-++--+-+ | 1 | SIMPLE | nodes | index | PRIMARY | PRIMARY | 4 | NULL | 573 | Using where | | 1 | SIMPLE | reports | ref | index_reports_on_node_id | index_reports_on_node_id | 5 | dashboard.nodes.id | 167 | Using where | ++-+-+---+--+--+-++--+-+ 2 rows in set (0.00 sec) http://nodes.id/ 2011/4/12 Charles Johnson gm.johns...@gmail.com You have a partial (i.e., three-part) index 'time', 'node_id', 'status' from which you appear to be selecting against only two parts. On the mysql command line run the query by hand preceded by the keywprd explain explain select nodes blah blah blah You should get back a listing that will let you see how the indexes are being used (or abused!). You may discover that in addition to the composite index you have that two additional indexes will help. ~Charles~
Re: [Puppet Users] Re: puppet dashboard performance issue
the rows are respectively 19450 and 1 So I have down from 95691 to 19450 with one index on kind and one on status , it s worst it use only index_reports_on_kind and 1 X 58631 rows .. mysql explain SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id; ++-+-+++---+-+---+---+--+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra| ++-+-+++---+-+---+---+--+ | 1 | SIMPLE | reports | ref| index_reports_on_node_id,index_reports_on_kind,index_reports_on_status | index_reports_on_kind | 768 | const | 58631 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | nodes | eq_ref | PRIMARY | PRIMARY | 4 | dashboard.reports.node_id | 1 | Using where | ++-+-+++---+-+---+---+--+ 2 rows in set (0.00 sec) 2011/4/12 Charles Johnson gm.johns...@gmail.com Good try! But I was not clear. Try an index just for kind, and another separate index just for status. You are down to 4 x 768 (3072) from 95691. That is much better. Again, drop the create separate indexes for kind and status and index_reports_on_kind_and_status . On Tue, Apr 12, 2011 at 2:11 PM, vincent vinc...@louviaux.com wrote: I have add an index ALTER TABLE `reports` ADD INDEX `index_reports_on_kind_and_status` ( `kind` , `status` ) it s better but maybe not perfect as the query is performed on each pages in the dashboard Thanks Vincent mysql explain SELECT `nodes`.* FROM `nodes` INNER JOIN `reports` ON reports.node_id = nodes.id WHERE ((reports.kind = 'apply' AND reports.status != 'failed') AND (`nodes`.`hidden` = 0)) GROUP BY nodes.id; ++-+-++---+--+-+---+---+--+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra| ++-+-++---+--+-+---+---+--+ | 1 | SIMPLE | reports | ref| index_reports_on_node_id,index_reports_on_kind_and_status | index_reports_on_kind_and_status | 768 | const | 19483 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | nodes | eq_ref | PRIMARY | PRIMARY | 4 | dashboard.reports.node_id | 1 | Using where | ++-+-++---+--+-+---+---+--+ 2 rows in set (0.00 sec) 2011/4/12 Charles Johnson gm.johns...@gmail.com A couple of things to notice. First, only the nodes.id index and index_reports_on_node_id index are used, and since index_reports_on_node_id is used as a ref type you will have 573 x 167 rows to examine (95,651 more or less) to produce the rows your sql finally fetches. You might --important: might-- be able to do better. There is an index: index_reports_on_time_and_node_id_and_status, which includes node_id and status, but is not used. Without hurting anything, and without changing the query you could create an index on reports.kind and reports.status. This might help if there are lots of different values for kind and status. For example, you generally do not want to create an index for a column where the only values are 'true' and 'false', say. That effectively divides the table in half, and if you have a million rows, reducing a full scan to 500,000 may not help much. But anyway, if you know how to create indexes, this is what I would try first. Others probably have much better ideas. You might ping a mysql list as well.
Re: [Puppet Users] Re: puppet dashboard performance issue
What seems the best set of indexes to you? Next, you need to read your mysql docs to optimize table and to reindex a table, especially if there have been lots of writes and/or lots of deletes. ~Charles~ -- 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] Templating question
OK, I'm trying to do something (apparently) stupid. Here's the relevant fragment of my manifest: /jumpstart/Begin/rootmirror.beg: require = File[/jumpstart/Begin], content = template(jumpstart/standard.beg.erb); /jumpstart/Begin/standard.beg: require = File[/jumpstart/Begin], content = template(jumpstart/standard.beg.erb); So the key thing here is that I've got two different files, but I'm using the same template for them. I had assumed that inside the template I could access name or path to figure out what the current resource was, and thereby choose the correct contents of the script. Sadly, my introspection-fu seems to be lacking and I'm unable to figure it out. Any help? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet dashboard ap_content_length_filter error
On Apr 12, 2011, at 10:33 AM, Jake - USPS wrote: What release notes are you referring to? The puppet-dashboard page mentions 1 upgrade, as does the README.markdown in the source/ package. There is a RELEASE_NOTES.md file, but that seems to be a copy of CHANGELOG. Please let me know if I missed something or if there is a better place to look for this type of information so I know where to look for these type of oddities. I'd guess it's on the website too, but I saw it in this email: http://groups.google.com/group/puppet-users/msg/a58575de08b7b16d -- 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: extlookup == bad?
On Apr 12, 10:49 am, Patrick kc7...@gmail.com wrote: On Apr 12, 2011, at 8:03 AM, jcbollinger wrote: 1) parameterized classes can be included only once, unlike unparameterized ones. This tends to require modules to have an hierarchical structure, which isn't very suitable in many circumstances. (More on that below.) It does, however, sort of address My understanding is that there's no difference between parameterized classes you can include more than once and defines. If you disagree, please enlighten me. Stand by for enlightenment. You can include unparameterized classes any number of times, and it means the same thing whether you include a class once or a hundred times. This is one of the fundamental characteristics of Puppet classes, and a feature that I personally put to good use. There is no reason in principle why you should not be able to include parameterized classes multiple times as well, provided that the parameters are everywhere the same for a given node. My expectation for such a case would be that the effect is the same as including the class only once, just as for unparameterized classes. Defines are altogether different: they are resource types written in Puppet DSL, much more akin to File or User than to any class. Whereas it must be an error to include a class two or more times with inconsistent parameter sets, multiple instantiations of a define *must* differ, at least in their titles. Whereas multiple inclusions of the same parameterized class (with consistent parameters) should mean the same as a single inclusion of that class, multiple instantiations of a define model separate resources to manage. Defines are nevertheless relevant to the discussion, because they can indeed serve in most of the roles for which parameterized classes are suggested. Since parameterized classes can only be included once anyway, the most significant distinction between a parameterized class and a define is largely mooted in practice. This then begs the question: for what purpose are parameterized classes uniquely useful? I may be missing something, but the only things I come up with are 1) Run stages. You cannot assign individual resources to stages, only classes, and you can only assign classes to stages via the parameter list syntax. That's rather arbitrary, though, and I wonder whether you can get around it by using before = Stage['foo'] on ordinary resources instead of stage = foo on classes. 2) External node classifiers. I think providing for ENCs to set class data is the main reason we now have parameterized classes. There is no particular reason, though, why parameterized classes needed to be provided to give ENCs such a capability. 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: augtool/augeas -- clearly missing something...
On Apr 13, 4:16 am, Adam Heinz a...@metricwise.net wrote: context = /etc/network/interfaces, Shouldn't this be /files/etc/network/interfaces? Thanks! that was the thing I was missing. The iface stuff works fine now but I can't figure out how to add a new auto line set auto[. = 'eth1'] eth1, gives an error on save ? augtool shows auto[1] having multiple values: augtool ls /files/etc/network/interfaces/auto 1 = lo 1 = eth0 so how should I add entries? and by the way http://projects.puppetlabs.com/projects/puppet/wiki/Puppet_Augeas is the best augtool documentation I found -- more in depth than the quick tour on the augtool site. Russell -- 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] Advice for managing package versions with CentOS/yum
Hi all, looking for some general advice for how people are doing
this...
We have some packages that *must* be kept at a particular version
(e.g. httpd, php) because our code and configurations depend on it.
As far as I'm aware, in puppet, the only parameter that can be passed
to a package type describing version information is the ensure
directive, i.e. something like:
package { httpd:
ensure = 2.2.3-43.el5.centos,
}
Which means that we must specify both package version (2.2.3) *and*
RPM release version (43) to be installed. This seems to work fine,
except when CentOS branches to a new release, and suddenly my specific
RPM release is not available in the new yum repo anymore (current
version is now httpd-2.2.3-45.el5.centos).
Anyone have any advice for dealing with this? I'd rather not mirror
the entire CentOS-Base repository locally at version 5.5 just so my
few packages are available...
Thanks!
--
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] dashboard and classes
Can I import all my existing classes/modules into the dashboard, or do I have to create them in the GUI? Thanks, Mohamed. -- 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] noob question - How to manage uid/gid changes outside home directory with puppet?
Hi, This sounds like a once change as you implement puppet, right? I don't imagine you want to run that as part of a manifest. What I would do is get a current list of uid numbers for your users and after running puppet on your hosts for the first time, run a find searching on the uid number and issue an chown as it finds them to the uid number. Be easier and possibly more thorough than doing it in puppet or by searching logs. Cheers, Den On 12/04/2011, at 22:13, scarts stephenandmi...@me.com wrote: If I create a user resource and specify UID and a group resource and specify GID where the user and group may or may not already exist, in the case where the user or group does exist would it be best practice to: 1) Have puppet change the uid/gid values, then post this change, trawl through logs to find old new uid/gid values and manually run find to recursively change files and directories outside the users home directory, or 2) Use some type of exec to trigger on user/group resource refesh only to run the same thing automatically? I'm in two minds, in that the second option means I don't have to do anything manually but I also wouldn't want the exec triggered if I just change something like the user comment for example. If an exec is okay to use in these cases, then how would I get the 'old' uid/gid value into a puppet variable before I make the change, as I would need to know this in order to run the chown/chgrp automatically. Thanks for your time. -- 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] Advice for managing package versions with CentOS/yum
On Tue, Apr 12, 2011 at 7:02 PM, elliott misteresa...@gmail.com wrote:
Hi all, looking for some general advice for how people are doing
this...
We have some packages that *must* be kept at a particular version
(e.g. httpd, php) because our code and configurations depend on it.
As far as I'm aware, in puppet, the only parameter that can be passed
to a package type describing version information is the ensure
directive, i.e. something like:
package { httpd:
ensure = 2.2.3-43.el5.centos,
}
Which means that we must specify both package version (2.2.3) *and*
RPM release version (43) to be installed. This seems to work fine,
except when CentOS branches to a new release, and suddenly my specific
RPM release is not available in the new yum repo anymore (current
version is now httpd-2.2.3-45.el5.centos).
Anyone have any advice for dealing with this? I'd rather not mirror
the entire CentOS-Base repository locally at version 5.5 just so my
few packages are available...
You can specify a package source, that isn't from a repo. IE: You can
specify the RPM package provider, and specify the source for the RPMs in
question from a URL or local file.
See the following for more details:
http://docs.puppetlabs.com/references/latest/type.html#package
-Brian
Thanks!
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
http://aws.amazon.com/solutions/solution-providers/brandorr/
--
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] Templating question
On Tue, Apr 12, 2011 at 02:22:03PM -0700, Brian Gallew wrote: Sadly, my introspection-fu seems to be lacking and I'm unable to figure it out. Any help? Not easily. The only way I was able to find mention of it at all was with the horrible voodoo of a template of: %= require 'pp' ; pp @__scope__ % And even then, there's no safe, sane or simple way of getting it out. You're best off just having two different templates I'm afraid and less magic. -- Ben Hughes || http://www.puppetlabs.com/ -- 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: run stages in puppet 2.6
On Tue, Apr 12, 2011 at 06:57:42PM -0400, Tim Dunphy wrote:
Here's what I've come up with so far:
stage {
repo: before = Stage[main]
}
Have you tried using the other syntax:
stage{ [repo]: }
Stage[repo] - Stage[main]
in site.pp?
--
Ben Hughes || http://www.puppetlabs.com/
--
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] Templating question
On Tue, Apr 12, 2011 at 6:39 PM, Ben Hughes b...@puppetlabs.com wrote: Sadly, my introspection-fu seems to be lacking and I'm unable to figure it out. Any help? Not easily. The only way I was able to find mention of it at all was with the horrible voodoo of a template of: %= require 'pp' ; pp @__scope__ % And even then, there's no safe, sane or simple way of getting it out. You're best off just having two different templates I'm afraid and less magic. I ended up doing something even uglier (and probably stupider). I created two sub-classes of jumpstart: jumpstart::mirrorroot and jumpstart::zfsroot, and each one just sets a variable ($target) and the uses the template. It's incredibly stupid, but it works. -- 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] Templating question
On Tue, Apr 12, 2011 at 07:20:24PM -0700, Brian Gallew wrote: I ended up doing something even uglier (and probably stupider). I created two sub-classes of jumpstart: jumpstart::mirrorroot and jumpstart::zfsroot, and each one just sets a variable ($target) and the uses the template. It's incredibly stupid, but it works. That is neater than trying to pick your way through the objects. Really. -- Ben Hughes || http://www.puppetlabs.com/ -- 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] augtool/augeas -- clearly missing something...
On 13/04/2011, at 4:16 AM, Adam Heinz wrote: context = /etc/network/interfaces, Shouldn't this be /files/etc/network/interfaces? indeed! now I get: err: /Stage[main]//Node[mon225044.insec.auckland.ac.nz]/Augeas[network_interface]/returns: change from need_to_run to 0 failed: Save failed with return code false so it is now trying to do something. I just have to figure out what! :) It had to be something simple. THanks, Russell -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] How to use Puppet to ensure the Sun JDK is installed on CentOS-5.5
Hi there,
I am new to Puppet and am writing my first module to manage our
cluster. So far, it worked out reasonably well. I can add yum
repositories and install packages with Puppet automatically.
However, one package requires the use of Sun JDK, not the openjdk
coming with CentOS.
The only way to do this is to download the jdk-6u24-linux-x64-rpm.bin
file and run it.
I figure I might be able to use something like
package {jdk:
source=/mnt/share/jdk-6u24-linux-x64-rpm.bin,
ensure = installed;
}
I guess I could put the file under the shared NFS /mnt/share. But
there is no way I can tell puppet to simply run the source as an
executable. All the PROVIDER options are for a particular format, such
as RPM or DEB. I guess I could run the file once on one machine, and
it will extract the rpms. I could then just use the rpms, but that is
less than ideal.
Also, if I don't want to pre-mount the NFS share, is there any way to
scp the file from the master node? Do I then have to set up ssh
without password for the root?
Thank you very much.
Shi
--
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] connecting dashboard to facts/inventory service.....
I'm having all sorts of trouble getting our new puppet-dashboard install to connect/get the facts/inventory from the puppet master. These are separate boxes, and I'm getting (testing): root@puppetdash puppet-dashboard]# curl -k -H Accept: yaml https://puppet:8140/production/facts/hero0304.rc.fas.harvard.edu Forbidden request: puppetdash.rc.fas.harvard.edu(10.242.67.211) access to /facts/hero0304.rc.fas.harvard.edu [find] at line 93 And in the WebUI node view: Could not retrieve facts from inventory service: Input/output error puppet-dashboard is v1.1.0 and the clients/puppetmaster are 2.6.7 auth.conf: path /facts method find allow dashboard,puppetdash.rc.fas.harvard.edu path /inventory method search allow dashboard,puppetdash.rc.fas.harvard.edu (that is, the dashboard application, and the hostname of it, just incase). I've generated signed and retrieved the certs as documented. I've also tried with allow * above, same results. puppet.conf on the puppetmaster has: facts_terminus = yaml and settings.yaml on the dashboard has: enable_inventory_service: true # Hostname of the inventory server. inventory_server: 'puppet' # Port for the inventory server. inventory_port: 8140 reports are working just fine, so I feel like I'm missing something obviousany help would be great! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Puppet client 'certificate verify failed'
Hi,
I've looked in the archives and elsewhere but couldn't find a solution
to the issue I'm having. I'm running puppet with an external CA that I
manage myself (ca=false for puppetmasterd) puppetmasterd is behind
nginx reverse proxy. On the client I'm getting:
root@web01:~# puppet agent --verbose --no-daemonize --onetime
err: Could not retrieve catalog from remote server: SSL_connect
returned=1 errno=0 state=SSLv3 read server certificate B: certificate
verify failed
notice: Using cached catalog
err: Could not retrieve catalog; skipping run
The puppetmaster's fqdn is excel.example.com and the SSL settings on
the master shouldn't really matter since nginx is the SSL endpoint in
this scenario. Could you have a look at the below (also available as
http://pastie.org/1789339) and let me know if my config is sensible or
if you can spot anything incorrect?
Upon puppet agent's invocation, no private keys or CSRs are created
which was my goal yet the verification fails. Below I've shown that
the checksums for the certificates used by both the client and master
are the same. Could you tell me (or point to a relevant explanation)
what is being verified in this process?
*** puppetmaster (excel):
/etc/puppet/puppet.conf:
[main]
ca=false
ssldir=/etc/ssl
cadir=$ssldir
publickeydir=$ssldir/public
privatekeydir=$ssldir/private
certdir=$ssldir/certs
vardir=/var/lib/puppet
localcacert = $certdir/ca-example.pem
[agent]
vardir = /var/lib/puppet
logdir = /var/log/puppet
templatedir = /var/lib/puppet/templates
factpath = $vardir/lib/facter
hostcert = $certdir/$certname.pem
hostprivkey = $privatedir/$certname.pem
hostpubkey = $publickeydir/$certname.pem
[master]
certname = puppet.example.com
servertype = mongrel
Relevant parts of /etc/nginx/sites-enabled/default:
server {
listen 8140;
ssl on;
ssl_verify_client on;
ssl_session_timeout 5m;
ssl_certificate /etc/ssl/certs/puppet.example.com.crt;
ssl_certificate_key /etc/ssl/private/puppet.example.com.pem;
ssl_client_certificate /etc/ssl/certs/ca-example.crt;
#ssl_crl /etc/ssl/crl.pem;
}
SSL certs:
excel:/etc# for i in `find /etc/ssl/ -name '*.pem'`; do md5sum $i; done
295340125c63ae9d64a87efc17135fec /etc/ssl/certs/ca-example.pem
7dbfce2a18002180a89df1853885273c /etc/ssl/certs/puppet.example.com.pem
6e33bd09dde9df47274a2ff1e06c1727 /etc/ssl/certs/web01.example.com.pem
ce15583b70c297f1be3c07b6c2f9828a /etc/ssl/private/ca-example.pem
f724911baa98c21291fe4eba4082266a /etc/ssl/private/puppet.example.com.pem
a38699481a609f32fab4374b5e51f4b0 /etc/ssl/private/web01.example.com.pem
5c269566c26c1f268df08b8162e388aa /etc/ssl/crl.pem
39571a88f872fa33256692f7e97d266f /etc/ssl/public/ca-example.pem
2bf6ed6843c4e523c0e0c6f387fd792b /etc/ssl/public/puppet.example.com.pem
94ab66cac55b88c5e8bf02b8a774187d /etc/ssl/public/web01.example.com.pem
*** puppet client (web01):
/etc/puppet/puppet.conf:
[main]
ca=false
ssldir=/etc/ssl
cadir=$ssldir
publickeydir=$ssldir/public
#privatedir=$ssldir/private
privatekeydir=$ssldir/private
certdir=$ssldir/certs
[agent]
vardir = /var/lib/puppet
logdir = /var/log/puppet
templatedir = /var/lib/puppet/templates
factpath = $vardir/lib/facter
localcacert = $certdir/ca-example.pem
hostprivkey = /etc/ssl/private/web01.example.com.pem
hostpubkey = $publickeydir/$certname.pem
SSL certs:
root@web01:~# for i in `find /etc/ssl -name '*.pem'`; do md5sum $i; done
a38699481a609f32fab4374b5e51f4b0 /etc/ssl/private/web01.example.com.pem
6e33bd09dde9df47274a2ff1e06c1727 /etc/ssl/certs/web01.example.com.pem
295340125c63ae9d64a87efc17135fec /etc/ssl/certs/ca-example.pem
94ab66cac55b88c5e8bf02b8a774187d /etc/ssl/public/web01.example.com.pem
39571a88f872fa33256692f7e97d266f /etc/ssl/public/ca-example.pem
5c269566c26c1f268df08b8162e388aa /etc/ssl/crl.pem
excel:~# date; ssh 172.19.80.212 date
Wed Apr 13 02:36:23 BST 2011
Wed Apr 13 02:36:23 BST 2011
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: How to use Puppet to ensure the Sun JDK is installed on CentOS-5.5
I have the same requirement to install Sun JDK, not openJDK. Below is
the module I am using. I would be grateful for suggestions on how
this install can be done better.
Thank you,
Jon
class java {
package {java-1.6.0-openjdk:
ensure = absent,
}
exec {java_install:
cwd = /opt,
command = /usr/bin/yes | /opt/share/downloads/java/jdk-6u24-
linux-x64.bin,
creates = /opt/jdk1.6.0_24/COPYRIGHT,
require = Package[java-1.6.0-openjdk],
}
file {/usr/bin/java:
ensure = /opt/jdk1.6.0_24/bin/java,
require = Exec[java_install],
}
}
On Apr 12, 3:55 pm, Shi jinzish...@gmail.com wrote:
Hi there,
I am new to Puppet and am writing my first module to manage our
cluster. So far, it worked out reasonably well. I can add yum
repositories and install packages with Puppet automatically.
However, one package requires the use of Sun JDK, not the openjdk
coming with CentOS.
The only way to do this is to download the jdk-6u24-linux-x64-rpm.bin
file and run it.
I figure I might be able to use something like
package {jdk:
source=/mnt/share/jdk-6u24-linux-x64-rpm.bin,
ensure = installed;
}
I guess I could put the file under the shared NFS /mnt/share. But
there is no way I can tell puppet to simply run the source as an
executable. All the PROVIDER options are for a particular format, such
as RPM or DEB. I guess I could run the file once on one machine, and
it will extract the rpms. I could then just use the rpms, but that is
less than ideal.
Also, if I don't want to pre-mount the NFS share, is there any way to
scp the file from the master node? Do I then have to set up ssh
without password for the root?
Thank you very much.
Shi
--
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.
