Re: [Puppet Users] puppetlabs-ntp template discussion
On 13 July 2013 15:00, Ashley Penney apen...@gmail.com wrote: On Sat, Jul 13, 2013 at 7:15 AM, Erik Dalén erik.gustav.da...@gmail.comwrote: I've been missing a way to set which server(s) should be preferred. We generally include all our NTP servers in the config but prefer the one that is in the same site as the node in question. So for a machine in site1 it would look like: server ntp.site1.example.com prefer server ntp.site2.example.com server ntp.site3.example.com I'll take a look at this but I have a sneaky suspicion if you just pass in servers = [ 'ntp.site1.example.com prefer', 'ntp.site2.example.com' ] it should magically do the right thing. On monday I'll find that out and make it do the right thing if not. I guess what you're saying is it's a pain to modify the list per site? In that case we can always add a prefer = 'blah' and have that append to the site you pick if that works. I think what I'm saying is here is tell me the API you'd like most for that and we'll do it. :) I think an extra parameter like $preferred_servers accepting an array of servers would be a nice API for this. It can default to an empty array. -- Erik Dalén -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
On 2013-07-10 19:57, Ashley Penney wrote: Hi guys, As I mentioned in a previous email I've refactored ntp and released a 1.0.0 release candidate. There's one outstanding flaw remaining that's bothering me and I wanted to solicit opinions on the list. We currently maintain a template per distribution that is close to the stock distribution provided ntp configuration. This leads to massive sprawl and means adding a distribution means yet another template. Would users of the ntp module mind if we unified this all into a single template? Obviously we'd have to pick one as the best base template and move over to using it and deal with the fact that your ntp configuration would significantly change. Only a few days ago I would have objected vehemently against such a change. I came to realize that in the puppet vision, distribution specific differences matter less and less. In a way any set of puppet modules becomes its own distribution, its configuration specified by class inclusion and resource usage. Accepting that, the question of differences to the distribution provided conffile ceases to be of relevance. The important questions become - as demonstrated in another part of this thread - questions of operation and best practices. Some of those - like how to react on is_virtual - can perhaps be answered with defaults, others like the cron-vs-daemon debate have underlying tradeoffs which have to be documented and made configurable. This is where the puppet module can excel, as it can wildly reconfigure the system in reaction to a top-level decision. The question arises what can be done to upstream such policies. I would expect[1] package maintainers to have a high interest in flexibly providing the experience for their users. In Debian - where I have the most experience - the reality is that maintainers do not have wide latitude in reconfiguring systems, since the expectation is - rightly - that user's changes are preserved and packages should not try to configure each other. Judging from the things I've seen in RedHat-land, RPMs have even less structure and authority. The alternative seems to be to both throw away much that is provided by distributions to achieve a least common denominator and (re-)implement much that is required for features. Following this line of thought, I soon come to see the parallels to the development of ruby, where a complete set of alternative implementations of basic tools has happened. rbenv/rvm/bundler/gem/rpmforge/passenger/unicorn re-implement the whole stack from container[chroot|lxc]/package manager[dpkg|rpm]/web application host[apache] again, only a few layers[1] further up. Looking at the work on Fedora's Software Collections, we've already come full circle once: e.g. The Foreman deploys a complete ruby stack via yum to /opt on EL6 (and co.), including a custom set of puppet modules, called the foreman-installer. On the other hand, projects like icinga don't even manage (or care) to provide current binary releases. I'm wondering how that will play out in the next few years. [1]http://geek-and-poke.com/geekandpoke/2013/7/13/foodprints Obviously we'd still be using your custom servers in the template so that bit wouldn't change. We could expand the restrict option to let you pass in more customized options here. What else would people like to be able to tune, change, tinker, trigger, whack, or modify in terms of parameters? If you have a really complex ntp setup then I want to hear from you! The more complex and awkward the better so that we can be sure our module meets your needs. While a common set of top-level options is nice for things like servers or runmode, the quirky configurations might be easier solved by just passing in a replacement template. It might be interesting though, to support some kind of (semi-)automatic keying to support encrypted/signed communications, something that is conspicuously absent from all default configs I know. Regards, David -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
I've been missing a way to set which server(s) should be preferred. We generally include all our NTP servers in the config but prefer the one that is in the same site as the node in question. So for a machine in site1 it would look like: server ntp.site1.example.com prefer server ntp.site2.example.com server ntp.site3.example.com On 10 July 2013 19:57, Ashley Penney ashley.pen...@puppetlabs.com wrote: Hi guys, As I mentioned in a previous email I've refactored ntp and released a 1.0.0 release candidate. There's one outstanding flaw remaining that's bothering me and I wanted to solicit opinions on the list. We currently maintain a template per distribution that is close to the stock distribution provided ntp configuration. This leads to massive sprawl and means adding a distribution means yet another template. Would users of the ntp module mind if we unified this all into a single template? Obviously we'd have to pick one as the best base template and move over to using it and deal with the fact that your ntp configuration would significantly change. Obviously we'd still be using your custom servers in the template so that bit wouldn't change. We could expand the restrict option to let you pass in more customized options here. What else would people like to be able to tune, change, tinker, trigger, whack, or modify in terms of parameters? If you have a really complex ntp setup then I want to hear from you! The more complex and awkward the better so that we can be sure our module meets your needs. If you've ever refused to use the ntp module as it lacks something you need, now is the time to shout out! Thanks, -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- Erik Dalén -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
On Sat, Jul 13, 2013 at 7:15 AM, Erik Dalén erik.gustav.da...@gmail.comwrote: I've been missing a way to set which server(s) should be preferred. We generally include all our NTP servers in the config but prefer the one that is in the same site as the node in question. So for a machine in site1 it would look like: server ntp.site1.example.com prefer server ntp.site2.example.com server ntp.site3.example.com I'll take a look at this but I have a sneaky suspicion if you just pass in servers = [ 'ntp.site1.example.com prefer', 'ntp.site2.example.com' ] it should magically do the right thing. On monday I'll find that out and make it do the right thing if not. I guess what you're saying is it's a pain to modify the list per site? In that case we can always add a prefer = 'blah' and have that append to the site you pick if that works. I think what I'm saying is here is tell me the API you'd like most for that and we'll do it. :) Thanks, -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
On 10 July 2013 23:33, Jason Slagle raist...@tacorp.net wrote: If you use hiera and puppet 3, specifying servers is as easy as putting ntp::servers in hiera. Jason I have been reading through the module but not tested it, how does this work then I dont see any call to Hiera? -- Ritchie --Time flies like an arrow; fruit flies like a banana. -- On 07/10/2013 04:52 PM, Dan White wrote: OK. Here are some wish-list items: Using ntp by cron rather than as a daemon An easy way to specify your own, internal time servers without tearing up the class. In the Red Hat template (since that's what I work on) : There is no resource to ensure the driftfile exists or has the proper permissions on it or on its directory. And a comment: Is all the commentary necessary in the template ? As I get time, I will be happy to make some contributions to the module on my first two points -- I can do Red Had / CentOS / Fedora, but someone else will need to assist on the other distros. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) --**--** *From: *Ashley Penney ashley.pen...@puppetlabs.com *To: *puppet-users@googlegroups.com *Sent: *Wednesday, July 10, 2013 1:57:32 PM *Subject: *[Puppet Users] puppetlabs-ntp template discussion If you've ever refused to use the ntp module as it lacks something you need, now is the time to shout out! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@**googlegroups.compuppet-users%2bunsubscr...@googlegroups.com . To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/**group/puppet-usershttp://groups.google.com/group/puppet-users . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@**googlegroups.compuppet-users%2bunsubscr...@googlegroups.com . To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/**group/puppet-usershttp://groups.google.com/group/puppet-users . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
On Thursday, July 11, 2013 9:16:55 AM UTC-7, RichT wrote: On 10 July 2013 23:33, Jason Slagle rais...@tacorp.net javascript:wrote: If you use hiera and puppet 3, specifying servers is as easy as putting ntp::servers in hiera. Jason I have been reading through the module but not tested it, how does this work then I dont see any call to Hiera? Puppet 3 introduced databindings. All class params will do a behind the scenes hiera() call. For more info: https://ask.puppetlabs.com/question/117/how-can-i-use-data-bindings-in-puppet-3/ http://docs.puppetlabs.com/puppet/3/reference/whats_new.html#automatic-data-bindings-for-class-parameters -- Ritchie --Time flies like an arrow; fruit flies like a banana. -- On 07/10/2013 04:52 PM, Dan White wrote: OK. Here are some wish-list items: Using ntp by cron rather than as a daemon An easy way to specify your own, internal time servers without tearing up the class. In the Red Hat template (since that's what I work on) : There is no resource to ensure the driftfile exists or has the proper permissions on it or on its directory. And a comment: Is all the commentary necessary in the template ? As I get time, I will be happy to make some contributions to the module on my first two points -- I can do Red Had / CentOS / Fedora, but someone else will need to assist on the other distros. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) --**--** *From: *Ashley Penney ashley...@puppetlabs.com javascript: *To: *puppet...@googlegroups.com javascript: *Sent: *Wednesday, July 10, 2013 1:57:32 PM *Subject: *[Puppet Users] puppetlabs-ntp template discussion If you've ever refused to use the ntp module as it lacks something you need, now is the time to shout out! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@**googlegroups.com javascript:. To post to this group, send email to puppet...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/**group/puppet-usershttp://groups.google.com/group/puppet-users . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@**googlegroups.com javascript:. To post to this group, send email to puppet...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/**group/puppet-usershttp://groups.google.com/group/puppet-users . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
http://www.nsa.gov/ia/_files/os/redhat/NSA_RHEL_5_GUIDE_v4.2.pdf In general, they recommend running a daemon only when absolutely necessary. Thanks for the reference! The security risk of ntpd listening by default is a good reason for wanting to run it out of cron. In general, that's considered bad practice, and unnecessary because of ntpd's maturity. A few years ago we were bitten by NTP running out of cron on RedHat Enterprise Linux 6.0 systems because of the tickless kernel.” That might be from folks using ntpdate from cron instead of ntpd -q No, I think there's more to it. In my specific case we experienced problems with large time differences across machines between the cronjobs, but our cronjob didn't run as frequently as every fifteen minutes. Anyways, thanks again for explaining the use case for running ntpd out of cron. I now agree that adding such an option to puppetlabs-ntp template is a good idea. :) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
Excellent. I will see what I can do to contribute a run-it-by-cron option to the module, since I already do that. As far as the large time differences, there are multiple references out there to a line at the top of ntp.conf as follows: tinker panic 0 This tells the system to accept any offset that is handed to it. Oddly, there is no mention of it in the Red Hat man pages for ntp, but I found it on the ntp maintainer's site: http://doc.ntp.org/4.2.0/miscopt.html (under tinker) panic panic The argument is the panic threshold, normally 1000 s. If set to zero, the panic sanity check is disabled and a clock offset of any value will be accepted. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) - Original Message - From: Kent R. Spillner kspill...@acm.org To: puppet-users@googlegroups.com Sent: Thursday, July 11, 2013 1:01:30 PM Subject: Re: [Puppet Users] puppetlabs-ntp template discussion http://www.nsa.gov/ia/_files/os/redhat/NSA_RHEL_5_GUIDE_v4.2.pdf In general, they recommend running a daemon only when absolutely necessary. Thanks for the reference! The security risk of ntpd listening by default is a good reason for wanting to run it out of cron. In general, that's considered bad practice, and unnecessary because of ntpd's maturity. A few years ago we were bitten by NTP running out of cron on RedHat Enterprise Linux 6.0 systems because of the tickless kernel.” That might be from folks using ntpdate from cron instead of ntpd -q No, I think there's more to it. In my specific case we experienced problems with large time differences across machines between the cronjobs, but our cronjob didn't run as frequently as every fifteen minutes. Anyways, thanks again for explaining the use case for running ntpd out of cron. I now agree that adding such an option to puppetlabs-ntp template is a good idea. :) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
On 11 July 2013 20:28, Dan White y...@comcast.net wrote: Excellent. I will see what I can do to contribute a run-it-by-cron option to the module, since I already do that. As far as the large time differences, there are multiple references out there to a line at the top of ntp.conf as follows: tinker panic 0 That line's actually *required* on VM guests (see http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1006427 - search for 'NTP Recommendations' ). The templates could use updating to guard it with '% if @panic == false || @is_virtual == true -%' instead of just the single @panic check that they currently have . Or does it perhaps need to be a little more complex so that a warning can be spat out if the conflicting options of @panic == true and @is_virtual == true are set for a particular guest? Regards, Matt. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
On Thu, Jul 11, 2013 at 3:49 PM, Matthew Burgess matthew.2.burg...@gmail.com wrote: On 11 July 2013 20:28, Dan White y...@comcast.net wrote: Excellent. I will see what I can do to contribute a run-it-by-cron option to the module, since I already do that. As far as the large time differences, there are multiple references out there to a line at the top of ntp.conf as follows: tinker panic 0 That line's actually *required* on VM guests (see http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1006427 - search for 'NTP Recommendations' ). The templates could use updating to guard it with '% if @panic == false || @is_virtual == true -%' instead of just the single @panic check that they currently have . Or does it perhaps need to be a little more complex so that a warning can be spat out if the conflicting options of @panic == true and @is_virtual == true are set for a particular guest? In the new code we set panic based on $is_virtual by default, so it sets panic to false for virtual and true for physical. That way we get the right behavior out of the box and physical people can override it too. I figured that was preferable to having more logic in the templates. I suppose it depends on if there is the potential of a use case where people on virtual machines are simply not allowed to tolerate large skews either, I'd hate to railroad them by forcing the issue. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
As far as the large time differences, there are multiple references out there to a line at the top of ntp.conf as follows: tinker panic 0 This tells the system to accept any offset that is handed to it. By large time differences I meant between different servers on the network. We ran ntpd out of cron every couple of hours without problem on RedHat Enterprise Linux 5 for a few years. When we upgraded to RHEL 6 we noticed the clocks on different machines could differ by several seconds between ntpd runs, wreaking havoc on our log analysis tools. Perhaps if we increased the frequency of the cronjobs to every 15 minutes as suggested by NASA it wouldn't be so bad, but we decided to run ntpd continuously on every machine. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
On 11 July 2013 20:59, Ashley Penney ashley.pen...@puppetlabs.com wrote: In the new code we set panic based on $is_virtual by default, so it sets panic to false for virtual and true for physical. Indeed you do; I guess next time I take part in a discussion I should look at *all* the code involved, and not just skim over stuff :-) That way we get the right behavior out of the box and physical people can override it too. I figured that was preferable to having more logic in the templates. Yep; plus the template wouldn't be able to generate a warning that a user-defined option is going to be overridden, if that's the behaviour you decide to implement. I suppose it depends on if there is the potential of a use case where people on virtual machines are simply not allowed to tolerate large skews either, I'd hate to railroad them by forcing the issue. The only case I've come across where large steps are not tolerated/permitted is in an Oracle RAC setup. There, the '-x' option to ntpd is required, and that forces it to always skew rather than step. Assuming it's configured as per Oracle's and VMWare's recommendations, if a VM-based RAC node is suspended then resumed some time later, it'll have a large time difference to its clock source. Given 'tinker panic 0', ntpd will still be running, but given '-x' it will only slowly adjust the clock forward. At this point, RAC will evict the node due to the time difference, causing the server to reboot. On reboot, 'ntpdate' or 'ntpd -q' will be run to set the clock to the correct time, and everything's back to how it was before the VM was resumed. Why did I mention all that? Well, in my opinion, that's about as harsh a way to fix a large time difference as there is, and having ntpd panic or not wouldn't have changed anything at all (RAC would still have rebooted the box upon detection of the time diff). Given all that, *I* can't think of a scenario where you'd want ntpd to panic. I'm always interested to hear other's thoughts/opinions/scenarios though. IMO, the ntp module should issue a notice() if both @panic and @is_virtual are true; it's a bit more polite than just overriding someone's decision, but might help them realise they're probably not doing the right thing. Regards, Matt. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] puppetlabs-ntp template discussion
Hi guys, As I mentioned in a previous email I've refactored ntp and released a 1.0.0 release candidate. There's one outstanding flaw remaining that's bothering me and I wanted to solicit opinions on the list. We currently maintain a template per distribution that is close to the stock distribution provided ntp configuration. This leads to massive sprawl and means adding a distribution means yet another template. Would users of the ntp module mind if we unified this all into a single template? Obviously we'd have to pick one as the best base template and move over to using it and deal with the fact that your ntp configuration would significantly change. Obviously we'd still be using your custom servers in the template so that bit wouldn't change. We could expand the restrict option to let you pass in more customized options here. What else would people like to be able to tune, change, tinker, trigger, whack, or modify in terms of parameters? If you have a really complex ntp setup then I want to hear from you! The more complex and awkward the better so that we can be sure our module meets your needs. If you've ever refused to use the ntp module as it lacks something you need, now is the time to shout out! Thanks, -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
OK. Here are some wish-list items: Using ntp by cron rather than as a daemon An easy way to specify your own, internal time servers without tearing up the class. In the Red Hat template (since that's what I work on) : There is no resource to ensure the driftfile exists or has the proper permissions on it or on its directory. And a comment: Is all the commentary necessary in the template ? As I get time, I will be happy to make some contributions to the module on my first two points -- I can do Red Had / CentOS / Fedora, but someone else will need to assist on the other distros. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) - Original Message - From: Ashley Penney ashley.pen...@puppetlabs.com To: puppet-users@googlegroups.com Sent: Wednesday, July 10, 2013 1:57:32 PM Subject: [Puppet Users] puppetlabs-ntp template discussion If you've ever refused to use the ntp module as it lacks something you need, now is the time to shout out! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
What's the use case for running NTP from cron? In general, that's considered bad practice, and unnecessary because of ntpd's maturity. A few years ago we were bitten by NTP running out of cron on RedHat Enterprise Linux 6.0 systems because of the tickless kernel. On Jul 10, 2013, at 15:52, Dan White y...@comcast.net wrote: OK. Here are some wish-list items: Using ntp by cron rather than as a daemon An easy way to specify your own, internal time servers without tearing up the class. In the Red Hat template (since that's what I work on) : There is no resource to ensure the driftfile exists or has the proper permissions on it or on its directory. And a comment: Is all the commentary necessary in the template ? As I get time, I will be happy to make some contributions to the module on my first two points -- I can do Red Had / CentOS / Fedora, but someone else will need to assist on the other distros. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) From: Ashley Penney ashley.pen...@puppetlabs.com To: puppet-users@googlegroups.com Sent: Wednesday, July 10, 2013 1:57:32 PM Subject: [Puppet Users] puppetlabs-ntp template discussion If you've ever refused to use the ntp module as it lacks something you need, now is the time to shout out! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
On 10 July 2013 18:57, Ashley Penney ashley.pen...@puppetlabs.com wrote: Hi guys, As I mentioned in a previous email I've refactored ntp and released a 1.0.0 release candidate. There's one outstanding flaw remaining that's bothering me and I wanted to solicit opinions on the list. We currently maintain a template per distribution that is close to the stock distribution provided ntp configuration. This leads to massive sprawl and means adding a distribution means yet another template. I can see your point of view regarding sprawl/extending to additional distributions. However, see below. Would users of the ntp module mind if we unified this all into a single template? Obviously we'd have to pick one as the best base template and move over to using it and deal with the fact that your ntp configuration would significantly change. As a sysadmin, that significant change is more important. I like to keep services configured as the distribution does so out of the box, unless there's a specific reason not to. As such, I'd like the diffs between the RPM-provided config file and the puppet-provided template to be as small as possible so that when an agent picks the change up, it's obvious what/why the change has been made. Additionally, this helps when an RPM upgrade occurs and a .rpmsave file is generated; diffing a close-to-stock config file again will be much easier to audit for potential changes to pick up. With all that said, if the consensus is to provide a single template, it's easily overridable using the config_template parameter, so I can just drop the stock RHEL-provided file in there myself. Regards, Matt. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
If you use hiera and puppet 3, specifying servers is as easy as putting ntp::servers in hiera. Jason On 07/10/2013 04:52 PM, Dan White wrote: OK. Here are some wish-list items: Using ntp by cron rather than as a daemon An easy way to specify your own, internal time servers without tearing up the class. In the Red Hat template (since that's what I work on) : There is no resource to ensure the driftfile exists or has the proper permissions on it or on its directory. And a comment: Is all the commentary necessary in the template ? As I get time, I will be happy to make some contributions to the module on my first two points -- I can do Red Had / CentOS / Fedora, but someone else will need to assist on the other distros. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) *From: *Ashley Penney ashley.pen...@puppetlabs.com *To: *puppet-users@googlegroups.com *Sent: *Wednesday, July 10, 2013 1:57:32 PM *Subject: *[Puppet Users] puppetlabs-ntp template discussion If you've ever refused to use the ntp module as it lacks something you need, now is the time to shout out! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
On 07/10/2013 06:33 PM, Jason Slagle wrote: If you use hiera and puppet 3, specifying servers is as easy as putting ntp::servers in hiera. Bah! And the reply to gets me again - this was a quick note just to him - hence no trimming and the top post. Sorry about that. Jason -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppetlabs-ntp template discussion
On Jul 10, 2013, at 5:28 PM, Kent R. Spillner wrote: What's the use case for running NTP from cron? http://www.nsa.gov/ia/_files/os/redhat/NSA_RHEL_5_GUIDE_v4.2.pdf In general, they recommend running a daemon only when absolutely necessary. The ntp daemon is only necessary for a time-server, not the client. 3.10.2.1.2 Run ntpd using Cron Create a le /etc/cron.d/ntpd containing the following crontab: 15 * * * * root /usr/sbin/ntpd -q -u ntp:ntp The -q option instructs ntpd to exit just after setting the clock, and the -u option instructs it to run as the specied user. Note: When setting the clock for the rst time, execute the above command with the -g option, as ntpd will refuse to set the clock if it is signicantly different from the source. This crontab will execute ntpd to synchronize the time to the NTP server at 15 minutes past every hour. (It is possible to choose a dierent minute, or to vary the minute between machines in order to avoid heavy trac to the NTP server.) Hourly synchronization should be suciently frequent that clock drift will not be noticeable. http://people.redhat.com/sgrubb/files/hardening-rhel5.pdf http://doc.ntp.org/4.1.0/ntpd.htm Operating mode, which describes the use of “ntpd -q” instead of ntpdate In general, that's considered bad practice, and unnecessary because of ntpd's maturity. A few years ago we were bitten by NTP running out of cron on RedHat Enterprise Linux 6.0 systems because of the tickless kernel.” That might be from folks using ntpdate from cron instead of ntpd -q On Jul 10, 2013, at 15:52, Dan White y...@comcast.net wrote: OK. Here are some wish-list items: Using ntp by cron rather than as a daemon An easy way to specify your own, internal time servers without tearing up the class. In the Red Hat template (since that's what I work on) : There is no resource to ensure the driftfile exists or has the proper permissions on it or on its directory. And a comment: Is all the commentary necessary in the template ? As I get time, I will be happy to make some contributions to the module on my first two points -- I can do Red Had / CentOS / Fedora, but someone else will need to assist on the other distros. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) From: Ashley Penney ashley.pen...@puppetlabs.com To: puppet-users@googlegroups.com Sent: Wednesday, July 10, 2013 1:57:32 PM Subject: [Puppet Users] puppetlabs-ntp template discussion If you've ever refused to use the ntp module as it lacks something you need, now is the time to shout out! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
