2009/3/4 Luke Kanies
>
>
> What do others think? Should it be acceptable to privately contact
> members of our community, encouraging them to leave?
>
I'm quite comfortable with people talking about other products/approaches on
the list. Even if that seems to be their only contribution to the g
I've used it somewhat and it's great when it works, painful when it
doesn't (re: PAIN), but it's sort of beastly for only 50 boxes IMO.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post t
>From my fairly limited experience there is some functionality in Satellite
servers that takes it beyond local repositories in that you can group hosts
into channels (dev, test, prod etc) and apply changes specific to the
channel
>From the satellite server you can also fire back commands to a host
PeterBurkholder writes:
> FWIW, we'll be looking about 50 systems that need to be
> managed, and we may not have to pay for server itself ($13.5K) just
> for the system subscriptions ($200 each).
Note that the Satellite server code has been open sourced so I'm not
sure why they still charge so
Marti Martinez wrote:
> I have a bizarre problem with yum; I can add packages without incident
> with the following syntax:
>
> package { "mod_perl": ensure => present, }
> package { "mod_ssl": ensure => present, }
> package { "perl-DBD-MySQL": ensure => present, }
>
>
> Works fine, for most
On Fri, Mar 06, 2009 at 04:07:24PM -0800, Pete Emerson wrote:
> I resolved this problem. I discovered that there was a key mismatch. I'm
> loving puppet, but the error messages are completely frustrating.
>
> Pete
If you're finding that frustrating, you should probably submit a bug report to
hav
On Mar 9, 9:17 am, Joe McDonagh wrote:
> Marti Martinez wrote:
> > I have a bizarre problem with yum; I can add packages without incident
> > with the following syntax:
>
> > package { "mod_perl": ensure => present, }
> > package { "mod_ssl": ensure => present, }
> > package { "perl-DBD-MyS
On Sun, Mar 8, 2009 at 11:37 PM, Russ Allbery wrote:
>
> PeterBurkholder writes:
>
>> My boss has RedHat coming in on Tuesday to give a spiel on RHN
>> Satellite. I'm dubious, as it seems mostly like a web UI wrapped around
>> a Yum repository system and a half-baked configuration management
>>
Did a POC of it at my current company. I've also had the RedHat
Enterprise Deployment and Virtualization class.
This product was originally envisioned began development before RedHat
even had an IPO. The reason I mention this is that the mindset around
systems management at that time is what yo
Based on the documentation I had thought that this:
file { "/var/puppet":
ensure => "/var/lib/puppet"
}
should create a symlink /var/puppet which points to the directory
/var/lib/puppet
It doesn't seem to be working :-/
Any ideas?
Thanks!
--
Please remember that an email is ju
That's rather odd. I just tested it with 0.24.7 on my workstation, and
the "ensure => [link target]" syntax works for me. Do you see anything
odd in the logs?
-Josh
On Mar 9, 2009, at 1:10 PM, Steve Wray wrote:
>
> Based on the documentation I had thought that this:
>
> file { "/var/puppe
I always prefer the syntax
file {"/var/puppet":
ensure => symlink,
target => "/var/lib/puppet"
}
as it seems to me to be more accurate in describing what I want it to
do. It should achieve the same thing though.
Steve Wray wrote:
> Based on the documentation I had thought that this:
On 3/9/09, Trevor Hemsley wrote:
>
> I always prefer the syntax
>
> file {"/var/puppet":
> ensure => symlink,
> target => "/var/lib/puppet"
> }
>
++
I find the other syntax to be really confusing as it's quite a
different value type for the ensure parameter compared to all the
other
Thanks for verifying that I have the correct syntax, it pointed to another
error I'd made.
Trevor Hemsley wrote:
> I always prefer the syntax
>
> file {"/var/puppet":
> ensure => symlink,
> target => "/var/lib/puppet"
> }
>
> as it seems to me to be more accurate in describing wh
Hi there,
I'm trying to use a fact to tell whether the machine is virtualised.
I found this and, in testing, its been ok:
http://reductivelabs.com/trac/puppet/wiki/Recipes/VirtualMachine
However, trying to roll this new fact out has been difficult.
1. Debian has got facter looking in /var/pupp
You have to run facter with the "-p" argument if you want to see facts
distributed by Puppet.
-Josh
On Mar 9, 2009, at 1:50 PM, Steve Wray wrote:
>
> Hi there,
>
> I'm trying to use a fact to tell whether the machine is virtualised.
>
> I found this and, in testing, its been ok:
> http://redu
Joshua Anderson wrote:
> You have to run facter with the "-p" argument if you want to see facts
> distributed by Puppet.
facter -p
/usr/bin/facter: invalid option -- p
/usr/lib/ruby/1.8/getoptlong.rb:265:in `set_error': invalid option -- p
(GetoptLong::InvalidOption)
from /usr/lib/rub
Avi Miller wrote:
> Steve Wray wrote:
>> I prefer the second one but cannot fathom why the syntax is wrong.
>
> Inline syntax is a little different:
>
> package { ntp:
>ensure => $lsbdistcodename ? {
> sarge => present,
> default => absent,
>},
> }
>
> Hope that helps,
H
FYI I've butchered this into place now by dropping my custom facts into
/usr/lib/ruby/1.8/facter/
Obviously this isn't ideal but its all I've found that works.
:(
Joshua Anderson wrote:
> You have to run facter with the "-p" argument if you want to see facts
> distributed by Puppet.
>
> -Jos
I think your facter version is rather old. On facter 1.5.4 (and probably
before), as long as I have dmidecode installed, facter presents several
variables that can be used to identify VM's without any coding.
manufacturer => VMware, Inc.
virtual => vmware
manufacturer => Xen
virtual => physical
Trevor Hemsley wrote:
> I think your facter version is rather old. On facter 1.5.4 (and probably
> before), as long as I have dmidecode installed, facter presents several
> variables that can be used to identify VM's without any coding.
yeah I know its kind of old. Eventually when we have converg
I have found something like this works:
package { libc6-xen:
ensure => $lsbdistcodename? {
'sarge' => absent,
default =>
$virtual? {
'xenu' => present,
'xen0' => present,
'openvz' => absent,
'physical' => ab
This wasn't a problem with yum or puppet (at least not directly) but
with an inconsistency in the way that NFS automounts work on Solaris
and Fedora... removing a funky NFS mount point fixed the problem --
anything trying to traverse the mount point (which rpm apparently
does...!?) would segfault.
I want to stop ntpd on all domU and openvz virtual machines while enabling
it on all dom0 and physical machines.
I've been trying to get my head around this and searched through
documentation and examples but cannot find anything like this so far.
If its running Debian Sarge then the init scri
2009/3/9 Steve Wray
>
> I want to stop ntpd on all domU and openvz virtual machines while enabling
> it on all dom0 and physical machines.
>
> I've been trying to get my head around this and searched through
> documentation and examples but cannot find anything like this so far.
>
> If its runnin
RijilV wrote:
>
> 2009/3/9 Steve Wray mailto:steve.w...@cwa.co.nz>>
>
>
> I want to stop ntpd on all domU and openvz virtual machines while
> enabling
> it on all dom0 and physical machines.
>
> I've been trying to get my head around this and searched through
> documentatio
Case statements don't work inside of resource definitions. There are
three ways I can think of do what you're doing:
1. Use multiple inline selectors. (Very long and ugly.)
2. Write four different definitions of the NTP service and wrap them
in a case statement (Not as long, but still ugly.)
Joshua Anderson wrote:
> Case statements don't work inside of resource definitions. There are
> three ways I can think of do what you're doing:
>
> 1. Use multiple inline selectors. (Very long and ugly.)
> 2. Write four different definitions of the NTP service and wrap them
> in a case statem
This is sort of on topic for users, but I'm more than happy to move it
to 'dev' if appropriate.
What I'm trying to do is to create a basic GUI that allows me to detect:
1) What modules are installed on the system
2) What classes are in the modules
3) What defines are in the classes
4) What defaul
Hi,
Thanks to the seven of you who took the time and energy to reply.
It's been very helpful in preparing for the meeting with Red Hat
tomorrow. The key unanswered question was posed by Brett, and I was
of the impression that one could use Puppet for assuring that all
managed packages are the la
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Trevor Vaughan wrote:
> What I'm trying to do is to create a basic GUI that allows me to detect:
>
> 1) What modules are installed on the system
> 2) What classes are in the modules
> 3) What defines are in the classes
> 4) What defaults/requires are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All
Puppet 0.24.8 Release Candidate 1 is now available for testing.
This is mainly a maintenance release for 0.24.7 but contains a small
number of new features including some significant performance
enhancements for large installations and stored co
32 matches
Mail list logo
