Re: [Puppet Users] Puppet environment can't be used in extlookup (precedence)
It looks like this problem is related to the use of ENC and to the extremely-annoying-more-than-one-year-old #3910 bug :( I wonder what people are doing as a viable workaround. I know the Nokia guys solved it with a hack detecting the environment discrepancy it in their ENC but I don't know the code. Any nice tips anyone ? On Fri, Apr 22, 2011 at 1:08 PM, Marcello de Sousa wrote: > Tested with 2.6.7-1 > > I'll try to reproduce it with 2.6.6 > > On Fri, Apr 22, 2011 at 12:22 PM, R.I.Pienaar wrote: >> >> >> - Original Message - >>> This is bugging me for a couple of days now as I don't seem to find a >>> reasonable explanation for the different behavior on the 2 puppet >>> variables. Not sure if it's a puppet issue or an extlookup issue (or >>> maybe my own issue). >> >> your example looks fine, and it works for me on 2.6.6, not tried on newer >> >> -- >> 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] Puppet environment can't be used in extlookup (precedence)
Anyone able to explain why "$fqdn" works and "$environment" doesn't in:
$extlookup_precedence=["%{fqdn}","%{environment}","common"]
How to reproduce it:
-
- In "/etc/puppet/manifests/site.pp" :
$extlookup_datadir = "/etc/puppet/manifests/extdata"
$extlookup_precedence=["%{fqdn}","%{environment}","common"]
- In "/etc/puppet/manifests/extdata/common.csv"
extdata1,"CommonData1"
extdata2,"CommonData2"
- In "/etc/puppet/manifests/extdata/production.csv"
extdata1,"ProdEnvData"
- In "/etc/puppet/manifests/extdata/myhostname.domain.local.csv"
extdata2,"HostData"
- In a manifest, test it with:
$extdata1 = extlookup(extdata1)
$extdata2 = extlookup(extdata2)
file{"/tmp/test.txt" :
ensure => file,
content => "FQDN = ${fqdn} , ENV = ${environment}, extdata1 =
${extdata1) , extdata2 = ${extdata2) ",
}
- At the end, test.txt will contain :
FQDN = myhostname.domain.local , ENV = production, extdata1 = CommonData1 ,
extdata2 = HostData
- But I guess the expected result should be:
FQDN = myhostname.domain.local , ENV = production, extdata1 = ProdEnvData,
extdata2 = HostData
What am I missing here ?
Cheers,
Marcello
--
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] ssh_authorized_key fails when home directory doesn't exist
I have the same issue (using Likewise Open) and even remember
discussing this briefly with Jeff (Puppetcamp in Belgium). I still
could not find a perfect solution.
Likewise open takes care of k5login kerberos file when creating the
homedir. If the folder already exists because puppet created it,
LWopen won't do anything and you won't be able to login using SSO.
There could be more reasons to let LWopen create the folder, but this
is one I can remember now...
2 approaches I've seen in the past were :
Option 1- Deploy all public keys to a directory and deploy a script
that runs regularly to place the keys in the home dir .ssh folder when
they are created (works but ugly)
Option 2 - Change the sshd_config file to use a centralized
alternative path for the users' "AuthorizedKeysFile" to
"/etc/ssh/keys/%u" folder. I believe this is the best choice but
unfortunately, when I tested this I discovered that RH/Centos stock
SSHd was not working with this option.YMMV
Cheers,
Marcello
On Fri, Apr 22, 2011 at 1:00 AM, Jeff McCune wrote:
> On Thu, Apr 21, 2011 at 3:41 PM, Corey Osman wrote:
>> Here is my situation:
>>
>> 1. We use Active directory (LDAP) to store all user info which is retrieved
>> from linux
>> 2. A home directory is not created until the first time the user logs into
>> the linux system
>>
>>
>> I am using the ssh_authorized_key type to push out my ssh keys to every
>> system. However, because I haven't logged into every system at least once.
>> Puppet errors out due to a missing home directory when trying to create the
>> authorized_keys file. The simple remedy is to login to the box and have the
>> home directory created (su - username). However, I would like the
>> ssh_authorized_key type to not fail but just give a notice. (home directory
>> does not exist, skipping) therefore the reports don't show errors and give
>> misleading errors in the reports.
>>
>> ssh_authorized_key{ "billys key":
>> ensure => present,
>> key => 'billys sshkey',
>> name => "super duper key",
>> type => ssh-rsa,
>> user =>"billy",
>> onlyif => "test -d /home/${user}"
>> }
>>
>> I am assuming that I can refer to the user with ${user} and that onlyif is a
>> valid parameter.
>>
>> Is this possible?
>
> Wouldn't it be better to make sure the home directory does exist, as
> well as the ~/.ssh directory?
>
> This is often accomplished by creating a defined resource type to
> contain all of the resources you need to manage to give you access to
> the system.
>
> --
> Jeff McCune
> Professional Services, Puppet Labs
> @0xEFF
>
> --
> 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] ssh_authorized_key fails when home directory doesn't exist
Btw, you can probably let puppet manage the .k5login as well... It's
just an extra small hassle.
On Fri, Apr 22, 2011 at 2:10 AM, Marcello de Sousa wrote:
> I have the same issue (using Likewise Open) and even remember
> discussing this briefly with Jeff (Puppetcamp in Belgium). I still
> could not find a perfect solution.
>
> Likewise open takes care of k5login kerberos file when creating the
> homedir. If the folder already exists because puppet created it,
> LWopen won't do anything and you won't be able to login using SSO.
> There could be more reasons to let LWopen create the folder, but this
> is one I can remember now...
>
> 2 approaches I've seen in the past were :
>
> Option 1- Deploy all public keys to a directory and deploy a script
> that runs regularly to place the keys in the home dir .ssh folder when
> they are created (works but ugly)
>
> Option 2 - Change the sshd_config file to use a centralized
> alternative path for the users' "AuthorizedKeysFile" to
> "/etc/ssh/keys/%u" folder. I believe this is the best choice but
> unfortunately, when I tested this I discovered that RH/Centos stock
> SSHd was not working with this option.YMMV
>
> Cheers,
> Marcello
>
> On Fri, Apr 22, 2011 at 1:00 AM, Jeff McCune wrote:
>> On Thu, Apr 21, 2011 at 3:41 PM, Corey Osman wrote:
>>> Here is my situation:
>>>
>>> 1. We use Active directory (LDAP) to store all user info which is retrieved
>>> from linux
>>> 2. A home directory is not created until the first time the user logs into
>>> the linux system
>>>
>>>
>>> I am using the ssh_authorized_key type to push out my ssh keys to every
>>> system. However, because I haven't logged into every system at least once.
>>> Puppet errors out due to a missing home directory when trying to create
>>> the authorized_keys file. The simple remedy is to login to the box and
>>> have the home directory created (su - username). However, I would like
>>> the ssh_authorized_key type to not fail but just give a notice. (home
>>> directory does not exist, skipping) therefore the reports don't show errors
>>> and give misleading errors in the reports.
>>>
>>> ssh_authorized_key{ "billys key":
>>> ensure => present,
>>> key => 'billys sshkey',
>>> name => "super duper key",
>>> type => ssh-rsa,
>>> user =>"billy",
>>> onlyif => "test -d /home/${user}"
>>> }
>>>
>>> I am assuming that I can refer to the user with ${user} and that onlyif is
>>> a valid parameter.
>>>
>>> Is this possible?
>>
>> Wouldn't it be better to make sure the home directory does exist, as
>> well as the ~/.ssh directory?
>>
>> This is often accomplished by creating a defined resource type to
>> contain all of the resources you need to manage to give you access to
>> the system.
>>
>> --
>> Jeff McCune
>> Professional Services, Puppet Labs
>> @0xEFF
>>
>> --
>> 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] Puppet environment can't be used in extlookup (precedence)
This is bugging me for a couple of days now as I don't seem to find a
reasonable explanation for the different behavior on the 2 puppet
variables. Not sure if it's a puppet issue or an extlookup issue (or
maybe my own issue).
Help ? :)
On Wed, Apr 20, 2011 at 12:25 AM, Marcello de Sousa wrote:
> Anyone able to explain why "$fqdn" works and "$environment" doesn't in:
>
> $extlookup_precedence=["%{fqdn}","%{environment}","common"]
>
>
> How to reproduce it:
> -
> - In "/etc/puppet/manifests/site.pp" :
> $extlookup_datadir = "/etc/puppet/manifests/extdata"
> $extlookup_precedence=["%{fqdn}","%{environment}","common"]
>
> - In "/etc/puppet/manifests/extdata/common.csv"
> extdata1,"CommonData1"
> extdata2,"CommonData2"
>
> - In "/etc/puppet/manifests/extdata/production.csv"
> extdata1,"ProdEnvData"
>
> - In "/etc/puppet/manifests/extdata/myhostname.domain.local.csv"
> extdata2,"HostData"
>
> - In a manifest, test it with:
> $extdata1 = extlookup(extdata1)
> $extdata2 = extlookup(extdata2)
> file{"/tmp/test.txt" :
> ensure => file,
> content => "FQDN = ${fqdn} , ENV = ${environment}, extdata1 =
> ${extdata1) , extdata2 = ${extdata2) ",
> }
>
> - At the end, test.txt will contain :
> FQDN = myhostname.domain.local , ENV = production, extdata1 = CommonData1 ,
> extdata2 = HostData
>
> - But I guess the expected result should be:
> FQDN = myhostname.domain.local , ENV = production, extdata1 = ProdEnvData,
> extdata2 = HostData
>
> What am I missing here ?
>
> Cheers,
> Marcello
>
> --
> 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] Puppet environment can't be used in extlookup (precedence)
Tested with 2.6.7-1 I'll try to reproduce it with 2.6.6 On Fri, Apr 22, 2011 at 12:22 PM, R.I.Pienaar wrote: > > > - Original Message - >> This is bugging me for a couple of days now as I don't seem to find a >> reasonable explanation for the different behavior on the 2 puppet >> variables. Not sure if it's a puppet issue or an extlookup issue (or >> maybe my own issue). > > your example looks fine, and it works for me on 2.6.6, not tried on newer > > -- > 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] Cascaded conditionals possible ?
I've been trying to use a resolv_conf recipe to setup the DNS servers based
on $domain and $location (a custom fact).
So I cascade the 2 conditionals, but it's not working. Is it supposed to
work ? Or should I look for an alternative ?
--
resolv_conf { "location_based_resolv":
domainname => "$domain",
searchpath => [$domain],
# Here is the cascaded conditional. If I'm in "domain1" I want to test 3
different locations.
nameservers => $domain ? {
"domain1.local" => $location ? {
"Default-First-Site-Name" => ['10.2.38.10','10.128.38.21'],
"HeadOffice" =>
['10.128.36.20','10.128.36.11'],
default => ['10.128.36.10','10.2.36.21'],
}
"domain2.local" => ['10.128.36.20','10.128.36.10'],
default => ['10.128.36.10','10.2.36.20'],
}
}
--
## If I test only one level it works:
#nameservers => $location ? {
# "Default-First-Site-Name" => ['10.2.38.10','10.128.38.21'],
# "HeadOffice" =>
['10.128.36.20','10.128.36.11'],
# default => ['10.128.36.10','10.2.36.21'],
# }
--
Am I missing something ? Or should I do it differently ?
Cheers,
Marcello
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Cascaded conditionals possible ?
"if/else" alternative would make it too big (and a bit ugly).
Don't you think cascading the conditionals should make sense ? Would be
quite neat solution I think.
"case" could be an option, but also didn't get it to work here. It looks
like case only works outside the puppet "type".
My (ugly) workaround now was to create all the combinations as different
files and use the variables in the filename:
source => "puppet:///myresolv/etc/resolv.conf_${domain}_${location}",
I might just go back to the drawing board and try to use "case" to create
what I believe Christopher means with: "detector based recipe which applied
usable variables/arrays".
Something like:
--
class resolver::resolv_location {
case $domain {
"domain1.local": { $nameserv = ['10.2.38.20','10.2.38.10'] }
default: { $nameserv = ['10.2.38.11','10.128.38.20'] }
}
resolv_conf { "location_based_resolv":
domainname => "$domain",
searchpath => [$domain],
nameservers => $nameserv,
}
}
--
That's what you mean right Christopher ?
Can I cascade "case" ? Can you post an example on how you did it?
Cheers,
Marcello
> -Original Message-
> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of Christopher Johnston
> Sent: dinsdag 16 februari 2010 13:52
> To: puppet-users@googlegroups.com
> Cc: puppet-users@googlegroups.com
> Subject: Re: [Puppet Users] Cascaded conditionals possible ?
>
> I found it easier to create a detector based recipe which applied
> usable variables/arrays then passed them down into a template.
>
> Sent from my iPhone
>
> On Feb 16, 2010, at 7:05 AM, Trevor Vaughan
> wrote:
>
> > I haven't tried it that way, but it would seem that that wouldn't
> > work to me.
> >
> > It does work with nested if/else statements.
> >
> > Trevor
> >
> > On Mon, Feb 15, 2010 at 4:12 PM, Marcello de Sousa
> > wrote:
> >> I've been trying to use a resolv_conf recipe to setup the DNS
> >> servers based
> >> on $domain and $location (a custom fact).
> >> So I cascade the 2 conditionals, but it's not working. Is it
> >> supposed to
> >> work ? Or should I look for an alternative ?
> >> --
> >>resolv_conf { "location_based_resolv":
> >>domainname => "$domain",
> >>searchpath => [$domain],
> >> # Here is the cascaded conditional. If I'm in "domain1" I want to
> >> test 3
> >> different locations.
> >>nameservers => $domain ? {
> >> "domain1.local" => $location ? {
> >>"Default-First-Site-Name" =>
> ['10.2.38.10','10.128.38.21
> >> '],
> >>"HeadOffice" =>
> >> ['10.128.36.20','10.128.36.11'],
> >>default =>
> ['10.128.36.10','10.2.36.21
> >> '],
> >> }
> >> "domain2.local" => ['10.128.36.20','10.128.36.10'],
> >> default => ['10.128.36.10','10.2.36.20'],
> >> }
> >>}
> >> --
> >> ## If I test only one level it works:
> >> #nameservers => $location ? {
> >> # "Default-First-Site-Name" =>
> ['10.2.38.10','10.128.38.21
> >> '],
> >> # "HeadOffice" =>
> >> ['10.128.36.20','10.128.36.11'],
> >> # default =>
> ['10.128.36.10','10.2.36.21
> >> '],
> >> # }
> >> --
> >>
> >> Am I missing something ? Or should I do it differently ?
> >>
> >> Cheers,
> >> Marcello
> >>
> >>
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Puppet Users" group.
> >> To post to this group, send email to puppet-us...@googlegroups.com.
> >> To unsubscribe from this group, send email to puppet-
> use
RE: [Puppet Users] vmwaretools
I've recently deployed on (via puppet) the following script to deal automatically with kernel updates: --- #Automatically updates VMWare tools (to be called from /etc/rc.local) if [ ! -e /lib/modules/`uname -r`/.vmware_installed ]; then /usr/bin/vmware-config-tools.pl --default touch /lib/modules/`uname -r`/.vmware_installed if [ "$?" -ne 0 ]; then exit 1 fi echo "*** Rebooting (VMWare tools update)***" reboot fi --- Kind of a calculated risk, but really handy when you patch lots of machines :) Cheers, Marcello > -Original Message- > From: puppet-users@googlegroups.com [mailto:puppet- > us...@googlegroups.com] On Behalf Of Dick Davies > Sent: dinsdag 16 februari 2010 20:28 > To: puppet-users@googlegroups.com > Subject: Re: [Puppet Users] vmwaretools > > On Tue, Feb 16, 2010 at 3:00 PM, Rob McBroom > wrote: > > On Feb 11, 2010, at 7:10 AM, Marc Fournier wrote: > > > >> [²] http://github.com/camptocamp/puppet-openvmtools > > > > Pardon my ignorance, but why run the `install-open-vm-tools.sh` or > `vmware-config-tools.pl` at all? > > > > My manifests for VMWare guests (running RHEL5) just do this: > > > > 1. set up a yumrepo for > http://packages.vmware.com/tools/esx/4.0/rhel5/$architecture/ > > 2. make sure the “vmware-tools” package is installed > > 3. make sure the "vmware-tools” service runs > > > > The only problems I’ve had are that the GPG key for that repo doesn’t > seem to work (last I checked) and it doesn’t support RHEL4. What am I > missing? > > We had issues with certain modules (vmmemctl) not loading until we'd > run vmware-config-tools.pl. Running the service might have helped, but > at the time there were some widespread performance issues on our ESX > hosts and I wanted to be as blameless as possible - so I chickened out > and went for the 'official' RPMs :) > > We install the (official) RPM with Puppet, and do the tools install on > the vmware console when we patch the kernel. I'm not adventurous > enough to have Puppet patch kernels and bounce systems (yet). > > -- > You received this message because you are subscribed to the Google > Groups "Puppet Users" group. > To post to this group, send email to puppet-us...@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-us...@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] Cascaded conditionals possible ?
Yes, that was the problem. The nested conditional works!
Thanks Alan.
> -Original Message-
> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of Alan Barrett
> Sent: dinsdag 16 februari 2010 16:06
> To: puppet-users@googlegroups.com
> Subject: Re: [Puppet Users] Cascaded conditionals possible ?
>
> On Mon, 15 Feb 2010, Marcello de Sousa wrote:
> > I've been trying to use a resolv_conf recipe to setup the DNS servers
> based
> > on $domain and $location (a custom fact).
> > So I cascade the 2 conditionals, but it's not working. Is it supposed
> to
> > work ? Or should I look for an alternative ?
>
> Nested selectors are supposed to work. I think you have some missing
> commas:
>
> > resolv_conf { "location_based_resolv":
> > domainname => "$domain",
> > searchpath => [$domain],
> > # Here is the cascaded conditional. If I'm in "domain1" I want to
> test 3
> > # different locations.
> > nameservers => $domain ? {
> >"domain1.local" => $location ? {
> > "Default-First-Site-Name" =>
> ['10.2.38.10','10.128.38.21'],
> > "HeadOffice" =>
> > ['10.128.36.20','10.128.36.11'],
> > default =>
> ['10.128.36.10','10.2.36.21'],
> > }
>
> Missing comma here -^
>
> >"domain2.local" => ['10.128.36.20','10.128.36.10'],
> >default => ['10.128.36.10','10.2.36.20'],
> > }
>
> I'd put a comma here --^
> but it's not essential, because this is the last attribute
> in the resource.
>
> > }
>
> --apb (Alan Barrett)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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] ssh::auth server dependency on ~/.ssh and a scoping question
I also manage users using AD (and likewise-open deployed with puppet), and
I've had a similar issue.
I couldn't find an elegant way to deploy ssh public keys "only if" the home
dir exists.
I do NOT want the user homedir to be created by puppet! (It must be created
by likewise-open if the user logs in.)
I also don't want errors to occur if the user folder doesn't exist. So I
need a "conditional" like:
"IF homedir exists => deploy .ssh/authorized_keys , else do nothing"
As far as I know this is not possible with puppet.
Still didn't spend a lot of time on it but for now, the only (ugly)
alternative I could find was the suggestion to download all the available
public keys to a temp folder to every puppet client (via "file" type), and
then via "exec" run a script that scans the existing home folders and copy
the corresponding authorized_keys to the .ssh/ folder.
Better ideas anyone ?
Gr,
Marcello
> -Original Message-
> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of Michael Gliwinski
> Sent: donderdag 25 februari 2010 10:54
> To: puppet-users@googlegroups.com
> Cc: Andrew Schulman
> Subject: Re: [Puppet Users] ssh::auth server dependency on ~/.ssh and a
> scoping question
>
> On Wednesday 24 Feb 2010 18:12:18 Andrew Schulman wrote:
> > > Hi Andrew,
> > >
> > > Just noticed that ssh::auth::server doesn't require the resource
> for
> > > ~/.ssh directory. Considering the documentation says it does (in
> > > Examples -> 1. With account management at the bottom mentions that
> > > 'require => [User[$title], File["$home/.ssh"]]' is implicitly
> included in
> > > both client and server), I thought I'll report it.
> > >
> > > This works fine for ssh::auth::server because it uses a file
> resource for
> > > the ~/.ssh/$filename file, so ~/.ssh is autorequired by puppet (if
> > > defined).
> >
> > OK, thanks for pointing this out. Looking back at it now, I think I
> was
> > probably counting on ssh_authorized_key requiring File[$home/.ssh].
> But
> > that doesn't seem to be explicit anywhere, so I'll add it in
> explicitly for
> > the next point release. And the user too, while I'm at it.
>
> Actually, the user dependency is already there. But now that you
> mention it,
> do you think it would be OK to make it optional, e.g. as in `if
> defined(User[foo]) { ... }`? I actually had to disable it as I don't
> manage
> users in puppet (I use nss_ldap and users are in AD).
>
> I realize this can lead to failures when user's home directory doesn't
> exist,
> but it's not critical, i.e. the key will simply be installed when the
> directory is created (in case of nss_ldap that is after the first time
> a user
> logged on). I haven't found a better way to deal with that yet, if you
> have
> better ideas, please share :)
>
> > > Also, while I'm at it, I wanted to ask a question related to
> scoping.
> > > Don't know if it's another difference between puppet 0.24.8 and
> 0.25.x,
> > > can't find any docs mentioning that. Anyway the problem manifests
> itself
> > > in that simple manifest:
> > >
> > >
> > > import "auth.pp"
> > >
> > > include ssh::auth
> > >
> > > Ssh::Auth::Key { length => 4096 }
> > >
> > > ssh::auth::key { 'foo': }
> > >
> > > include ssh::auth::keymaster
> > > file { '/home/foo/.ssh': ensure => directory, mode => 700, owner =>
> > > 'foo', group => 'puppet' }
> > > ssh::auth::client { 'foo': group => 'foo' }
> > >
> > >
> > > this is a simplified manifest which I ran with standalone puppet
> and it
> > > produces the following error:
> > >
> > > Only subclasses can override parameters at /root/puppet-
> > > tests/sshauth/auth.pp:113 on node ...
> > >
> > > The problem here is the "group => 'foo'" param passed to
> > > ssh::auth::client. It doesn't really matter which parameter it is
> though
> > > as the issue seems to be that the ssh::auth::client (or
> > > ssh::auth::server) define cannot override properties of a resource
> > > declared in ssh::auth::key define.
> > >
> > > I searched a bit for something on defines overriding parameters of
> > > resources and found a thread here on puppet-users [1] which implies
> this
> > > isn't possible.
> > >
> > > Does that work in 0.25.x ?
> >
> > I'll have to spend a little time looking into this. The whole
> purpose of
> > the way I set up the defines and virtual resources was to be able to
> > override parameters. The last time I tried it, it worked. I guess
> it's a
> > conflict with the file resource in your manifest? I'll see what I
> can
> > figure out and get back to you.
>
> AFAICS, ssh::auth doesn't declare the '${home}/.ssh' directory and it
> is the
> only file resource in the manifest above.
>
> Don't know, to be honest scoping and related issues in Puppet DSL have
> always
> confused the heck out of me ;)
>
> >
> > Andrew.
> >
>
> Thanks Andrew, let me know if I can help.
>
>
> --
> Michael Gliwinski
> Henderson Group Information Services
> 9-11 Hightown Avenue, Ne
RE: [Puppet Users] ssh::auth server dependency on ~/.ssh and a scoping question
Hi Andrew,
> > "IF homedir exists => deploy .ssh/authorized_keys , else do nothing"
> > As far as I know this is not possible with puppet.
>
> Marcello, I want to understand your use case. AD and LDAP seem to be
> fairly common in Puppet installations, and I'd like for ssh::auth to
> work well with them. But I'm not that familiar with them.
>
> Are you saying that once a user is authorized for a host (or the whole
> domain), the user exists on that host, but his/her home directory
> doesn't, until they first log in?
The user doesn't exactly "exist" on that host. The user and his group
membership are 'visible' (via AD/ldap) and he might be authorized to login
to that host. His homedir doesn't exist initially indeed.
> When the user logs in, is his/her home directory automounted from a
network share?
No, although this might be possible.
But this is not default and is not what I want now.
> In that case, the place to deploy the ssh keys would be in the
> user's home directory on the file server. Or, is the home directory
> created locally on the host the first time the user logs in?
Exactly.
> It would seem to me that once a user is authorized for a host, you'd
> want to create his/her ~/.ssh/authorized_keys right away, so they can log
in
> by ssh.
> If you can explain the sequence of how users get created and
> authorized and when their home directories get created, it would help
> me to address the need.
>
> Andrew.
Let me try to explain that:
Based on a AD group membership I allow the users to login or not. If you
don't configure that parameter on lwopen(Likewise-open) client ("require
membership of") all domain users are allowed to login.
Next to that Likewise-open uses a hash of your ActiveDirectory-UID/GID to
generate your unix UID/GID.
Once you login to the machine for the first time lwopen will create your
homedir with the proper rights (proper hashed UID/GID and optionally
domainname). For example and "ls -ln" would show some info like:
drwxr-xr-x 953680985 953680385 /home/mydomain/myusername
Next to that lwopen would create a .k5login on that directory to allow
single sign on via Kerberos. That's one more reason I need lwopen doing that
and not puppet.
My whole lwopen configuration is deployed via puppet. On the machines that I
login, after my homedir is properly created, I would like to be able to
deploy my .ssh/authorized_keys as an alternative to Kerberos SSO. Btw,
that's because Kerberos SSO has some issues, but that's off-topic. :)
So what I need looks simple but surprisingly difficult to achieve:
> > "IF homedir exists => deploy .ssh/authorized_keys , else do nothing"
Is this enough info about the use case ? Ideas anyone ?
Gr,
Marcello
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] ssh::auth server dependency on ~/.ssh and a scoping question
Patrick,
If you do that you would put all the public keys together, wouldn't you ?
That means users would be able to login as any other user. That is of course
not what you want.
We need to deploy a single specific public key per user.
Gr,
Marcello
> -Original Message-
> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of Patrick
> Sent: donderdag 25 februari 2010 19:47
> To: puppet-users@googlegroups.com
> Subject: Re: [Puppet Users] ssh::auth server dependency on ~/.ssh and a
> scoping question
>
> What about deploying the keys to /etc/skel? Would that be enough for
> what you want?
>
>
> On Feb 25, 2010, at 8:47 AM, Marcello de Sousa wrote:
>
> > Hi Andrew,
> >
> >>> "IF homedir exists => deploy .ssh/authorized_keys , else do
> nothing"
> >>> As far as I know this is not possible with puppet.
> >>
> >> Marcello, I want to understand your use case. AD and LDAP seem to
> be
> >> fairly common in Puppet installations, and I'd like for ssh::auth to
> >> work well with them. But I'm not that familiar with them.
> >>
> >> Are you saying that once a user is authorized for a host (or the
> whole
> >> domain), the user exists on that host, but his/her home directory
> >> doesn't, until they first log in?
> >
> > The user doesn't exactly "exist" on that host. The user and his group
> > membership are 'visible' (via AD/ldap) and he might be authorized to
> login
> > to that host. His homedir doesn't exist initially indeed.
> >
> >> When the user logs in, is his/her home directory automounted from a
> > network share?
> >
> > No, although this might be possible.
> > But this is not default and is not what I want now.
> >
> >> In that case, the place to deploy the ssh keys would be in the
> >> user's home directory on the file server. Or, is the home directory
> >> created locally on the host the first time the user logs in?
> >
> > Exactly.
> >
> >> It would seem to me that once a user is authorized for a host, you'd
> >> want to create his/her ~/.ssh/authorized_keys right away, so they
> can log
> > in
> >> by ssh.
> >> If you can explain the sequence of how users get created and
> >> authorized and when their home directories get created, it would
> help
> >> me to address the need.
> >>
> >> Andrew.
> >
> > Let me try to explain that:
> > Based on a AD group membership I allow the users to login or not. If
> you
> > don't configure that parameter on lwopen(Likewise-open) client
> ("require
> > membership of") all domain users are allowed to login.
> >
> > Next to that Likewise-open uses a hash of your ActiveDirectory-
> UID/GID to
> > generate your unix UID/GID.
> > Once you login to the machine for the first time lwopen will create
> your
> > homedir with the proper rights (proper hashed UID/GID and optionally
> > domainname). For example and "ls -ln" would show some info like:
> >
> > drwxr-xr-x 953680985 953680385 /home/mydomain/myusername
> >
> > Next to that lwopen would create a .k5login on that directory to
> allow
> > single sign on via Kerberos. That's one more reason I need lwopen
> doing that
> > and not puppet.
> >
> > My whole lwopen configuration is deployed via puppet. On the machines
> that I
> > login, after my homedir is properly created, I would like to be able
> to
> > deploy my .ssh/authorized_keys as an alternative to Kerberos SSO.
> Btw,
> > that's because Kerberos SSO has some issues, but that's off-topic. :)
> >
> > So what I need looks simple but surprisingly difficult to achieve:
> >>> "IF homedir exists => deploy .ssh/authorized_keys , else do
> nothing"
> >
> > Is this enough info about the use case ? Ideas anyone ?
> >
> > Gr,
> > Marcello
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> > To post to this group, send email to puppet-us...@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-us...@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-us...@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] ssh::auth server dependency on ~/.ssh and a scoping question
Dant,
The ssh_config trick could be indeed the key for a workaround:
AuthorizedKeysFile/etc/ssh/authorized_keys/%u
But I've tested it with a Centos 5 machine and it didn't work. I suspect the
problem is the expansion of %u to the username (our usernames have the
"mydomain\myuser" format). I wonder how I can debug that and see what's
trying to find as user name.
I've tried the following names without success:
/etc/ssh/authorized_keys/myuser
/etc/ssh/authorized_keys/mydomain\myuser
/etc/ssh/authorized_keys/MYDOMAIN\myuser
I'm still curious though if someone has a 'native' puppet workaround for
this 'conditional' situation, just in case this doesn't work on a specific
OS/ssh version or we face a similar problem in the future.
I also wonder if there's a way to use a user list instead of one hardcoded
class per user.
Thanks a lot for the tip!
Cheers,
Marcello
> -Original Message-
> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of dan trainor
> Sent: donderdag 25 februari 2010 23:16
> To: puppet-users@googlegroups.com
> Subject: Re: [Puppet Users] ssh::auth server dependency on ~/.ssh and a
> scoping question
>
> On Thu, Feb 25, 2010 at 12:52 PM, Patrick wrote:
>
>
>
> On Feb 25, 2010, at 11:23 AM, Marcello de Sousa wrote:
>
> > Patrick,
> >
> > If you do that you would put all the public keys together,
> wouldn't you ?
> > That means users would be able to login as any other user. That
> is of course
> > not what you want.
> >
> > We need to deploy a single specific public key per user.
> >
> > Gr,
> > Marcello
>
>
> I guess I misunderstood your question. I thought you had a
> really strange setup where you were doing just that.
>
>
>
>
> Hi, Guys -
>
> I've been following this thread for a bit here, and I was faced with a
> similar problem. Since we only have a small admin team for some 400+
> machines, this worked out well for us. However, your mileage certainly
> will vary. This is assuming that you're already pulling auth
> information from LDAP, as well.
>
> What I've done is, maintained /etc/ssh/sshd_config with a few choice
> options, namely the AuthorizedKeyFile directive. Here's an excerpt
> from sshd_config, which is a template in my puppet config - you'll see
> why, down at the bottom:
>
>
> Port 22
> ...
> PermitRootLogin without-password (or no, depending on the machine)
> ...
> RSAAuthentication yes
> PubkeyAuthentication yes
> AuthorizedKeysFile/etc/ssh/authorized_keys/%u
> PermitEmptyPasswords no
> PasswordAuthentication no
> ChallengeResponseAuthentication no
> GSSAPIAuthentication yes
> GSSAPICleanupCredentials yes
> UsePAM yes
> ...
> DenyGroupsall
> AllowGroups Domain?Admins wheel <% if environment == 'dev' %>
> Domain?Users <% end %>
> ClientAliveInterval300
>
>
>
> I then have a manifest like this:
>
> class sshd::config {
>
> File {
> require=> Class["sshd::install"],
> notify=> Class["sshd::service"]
> }
>
> file { "/etc/ssh/sshd_config":
> owner=> "root",
> group=> "root",
> mode=> 440,
> #source=> "puppet:///sshd/sshd_config",
> content=> template('sshd/sshd_config')
> }
>
> file { "/etc/ssh/authorized_keys":
> ensure => directory,
> owner => root,
> group => root,
> mode=> 0755,
> require=> Class["ldap"]
> }
>
> }
>
> Further, I maintain that /etc/ssh/authorized_keys/dtrainor file (my
> key) with a class similar to this:
>
> class sshd::users::dtrainor {
>
> include sshd
>
> file { "/etc/ssh/authorized_keys/dtrainor":
> owner=> 2690, // pulled from LDAP
> group=> root,
> mode=> 0600,
> source=> "puppet:///sshd/authorized_keys/dtrainor",
> require=> Class["sshd::config"]
> }
>
> }
>
>
> Now, I'm no programmer, and I'm certainly not a Puppet expert. But
> I've gotten around the chicken-and-the-egg problem by just being able
> to apply sshd::users::dtrainor to a node that this
RE: [Puppet Users] ssh::auth server dependency on ~/.ssh and a scoping question
I can't have errors.
Reporting is part of our procedure and it gets quite messy if you have
errors that should be neglected.
Gr,
Marcello
> -Original Message-
> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of Michael Gliwinski
> Sent: vrijdag 26 februari 2010 11:32
> To: puppet-users@googlegroups.com
> Cc: Alan Barrett
> Subject: Re: [Puppet Users] ssh::auth server dependency on ~/.ssh and a
> scoping question
>
> On Friday 26 Feb 2010 09:37:28 Alan Barrett wrote:
> > On Thu, 25 Feb 2010, Marcello de Sousa wrote:
> > > "IF homedir exists => deploy .ssh/authorized_keys , else do
> nothing"
> >
> > If you don't mind errors when you attempt to apply the manifest and
> the
> > homedir does not exist, then you could make the authorized_keys file
> > depend on something that fails if the homedir does not exist.
> >
> > Here's an untested example:
> >
> > # If the directory exists, then the "unless" clause in the exec
> > # is satisfied, so the "command" does not run; but the overall
> > # exec resource behaves as if it was successful, and anything
> that
> > # requires this exec is happy.
> > #
> > # If the directory does not exist, then the "unless" fails, so
> the
> > # "command" runs; but the command is "/bin/false", so the command
> > # reports a failure, the overall exec resource fails, and
> anything
> > # that requires this exec will have a failed dependency and will
> > # therefore not be evaluated.
> > #
> > exec { "fail if $homedir does not exist":
> > command => "/bin/false",
> > unless => "/usr/bin/test -d $homedir",
> > }
> >
> > file { "$homedir/.ssh/authorized_keys":
> > source => "puppet:///wherever",
> > require => Exec["fail if $homedir does not exist"],
> > }
> >
> > --apb (Alan Barrett)
> >
>
> That's what I'm doing now. Generally it is sufficient to declare a
> file resource
> for ${home}/.ssh and depend on it. It will fail if ${home} doesn't
> exist.
>
> Still, it would be nice to have something better, or at least be able
> to tell
> puppet to ignore errors from this resource/scope.
>
> --
> Michael Gliwinski
> Henderson Group Information Services
> 9-11 Hightown Avenue, Newtownabby, BT36 4RT
> Phone: 028 9034 3319
>
> ***
> ***
> The information in this email is confidential and may be legally
> privileged. It is intended solely for the addressee and access to the
> email by anyone else is unauthorised.
> If you are not the intended recipient, any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance on
> it, is prohibited and may be unlawful.
> When addressed to our clients, any opinions or advice contained in this
> e-mail are subject to the terms and conditions expressed in the
> governing client engagement leter or contract.
> If you have received this email in error please notify
> supp...@henderson-group.com
>
> John Henderson (Holdings) Ltd
> Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern
> Ireland, BT36 4RT.
> Registered in Northern Ireland
> Registration Number NI010588
> Vat No.: 814 6399 12
> ***
> **
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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] Foreman environments vs. Puppet Environments
Does anybody know or have a Howto on how to use "Foreman environments" and their relationship and interaction with "puppet environments" ? If they are not related, is there a way to assign a machine to a "puppet environment" via Foreman's interface ? Cheers, Marcello -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Foreman environments vs. Puppet Environments
Hi Ohad, On your forum I've posted a bit more extensive question (http://theforeman.org/boards/2/topics/show/119) just in case this is a bit offtopic here. I'm already using Foreman for a while with external node mode. But I've configured now puppet with environments like this: == (...) [development] modulepath = /etc/puppet/development/modules:/etc/puppet/modules [testing] modulepath = /etc/puppet/testing/modules:/etc/puppet/modules == But I don't see these environments showing up on the Foreman interface. I've also tried to create an environment inside foreman and assign it to a host, but I don't see it having any effect on the class assignment. In other words, foreman's environments are not working here and not relating to puppet's, and I can't find documentation about it in foreman's wiki or anywhere. It might be worth mentioning that I'm not using foreman to deploy new machines yet. I'm managing existing machines and now they are all assigned to "production", and I would like now to assign some of them to "development" and "testing" to be able to develop and deploy new modules/classes to them without affecting production. Pls Help ? :) Thanks! Cheers, Marcello > -Original Message- > From: puppet-users@googlegroups.com [mailto:puppet- > us...@googlegroups.com] On Behalf Of Ohad Levy > Sent: vrijdag 26 februari 2010 18:55 > To: puppet-users@googlegroups.com > Subject: Re: [Puppet Users] Foreman environments vs. Puppet > Environments > > Foreman can manage puppet environment assignments to hosts if you use > external nodes mode > (http://theforeman.org/wiki/foreman/External_Nodes). > > Foreman can scan your existing modules assigning the right classes to > the relevant environments. > > there is another environment settings in foreman (e.g. if you start the > server in the command line) - this is rails environment and is not > related to puppet at all. > > hope this helps, > Ohad > > > On Fri, Feb 26, 2010 at 6:56 PM, Marcello de Sousa > wrote: > > > Does anybody know or have a Howto on how to use "Foreman > environments" and > their relationship and interaction with "puppet environments" ? > > If they are not related, is there a way to assign a machine to a > "puppet > environment" via Foreman's interface ? > > Cheers, > Marcello > > -- > You received this message because you are subscribed to the > Google Groups "Puppet Users" group. > To post to this group, send email to puppet- > us...@googlegroups.com. > To unsubscribe from this group, send email to puppet- > users+unsubscr...@googlegroups.com <mailto:puppet- > users%2bunsubscr...@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-us...@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-us...@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.
