New user trying to get a port to compile: I tried searching but all I
get are links to the FreeBSD port of puppet. Easier to find a needle
in a haystack.
A class has:
exec { "port-sudo":
cwd => "/usr/ports/security/sudo",
environment => "BATCH=yes",
command => ''/bin/sh -c "/usr/bin/make
install"'',
path => ["/bin/, /usr/bin/, /usr/local/bin/, /sbin/, /
usr/sbin/, /usr/local/sbin/"],
returns => "1",
}
With the command being "make install" I got:
Exec[port-sudo]/returns) change from notrun to 1 failed: make: not
found
So I added the full path (with and without right angle brackets),
which I don''t think I should need since the path is defined. With
full path I get:
Exec[port-sudo]/returns) change from notrun to 0 failed: /bin/sh -c "/
usr/bin/make install" returned 1 instead of one of [0]
So I added the ''returns => "1" '' part. Now I
get:
Exec[port-sudo]/returns) executed successfully
But no port installed. What am I doing wrong? Any tips on
troubleshooting? Already running puppetmaster with "-d -v --
logdest=" and only seeing what I''m posting above.
And does anyone have any FreeBSD-centric pages on puppet? The one on
puppetlabs.com is useful but quite short.
--
Darek
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On 04/16/2011 12:26 AM, fafaforza wrote:> New user trying to get a port to compile: I tried searching but all I > get are links to the FreeBSD port of puppet. Easier to find a needle > in a haystack. > > A class has: > > exec { "port-sudo": > cwd => "/usr/ports/security/sudo", > environment => "BATCH=yes", > command => ''/bin/sh -c "/usr/bin/make install"'', > path => ["/bin/, /usr/bin/, /usr/local/bin/, /sbin/, / > usr/sbin/, /usr/local/sbin/"], > returns => "1", > } > > With the command being "make install" I got: > > Exec[port-sudo]/returns) change from notrun to 1 failed: make: not > found > > So I added the full path (with and without right angle brackets), > which I don''t think I should need since the path is defined. With > full path I get: > > Exec[port-sudo]/returns) change from notrun to 0 failed: /bin/sh -c "/ > usr/bin/make install" returned 1 instead of one of [0] > > So I added the ''returns => "1" '' part. Now I get:Hi, accepting failure is probably not going to be helpful. Your path syntax looks funny:> path => ["/bin/, /usr/bin/, /usr/local/bin/, /sbin/, / > usr/sbin/, /usr/local/sbin/"],You can do either this: path => [ "/bin", "/usr/bin" ], or this (which I prefer): path => "/bin:/usr/bin", The mixture you''re using is probably what''s causing your trouble. HTH, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Apr 18, 8:55 am, Felix Frank <felix.fr...@alumni.tu-berlin.de> wrote:> Your path syntax looks funny:Yeah, I wasn''t sure whether Puppet did anything with it as a comma separated variable (not an array). Set it to the normal Unix colon separated string and seems to have worked. This is the current resource: 84: exec { "port-sudo": 85: cwd => "/usr/ports/security/sudo", 86: environment => "BATCH=yes", 87: command => "make install", 88: path => "/bin/:/usr/bin/:/usr/local/ bin/:/sbin/:/usr/sbin/:/usr/local/sbin/", 89: require => File[''options-sudo''] 90: } It results in this on the client side: /Stage[main]/Kerberosauth::Freebsd/Exec[port-sudo]/returns) change from notrun to 0 failed: make install returned 1 instead of one of [0] at /usr/local/etc/puppet/manifests/kerberosauth.pp:90 Just above that resource, I set up /var/db/ports/sudo/options to set the port options, and with BATCH=yes, it shouldn''t be opening the interactive dialogue: file { ''options-sudo'': name => "/var/db/ports/sudo/options", source => "puppet://puppet.server.com/kerberosauth/ options.sudo", require => File[''options-sudo-dir''] } client# cat /var/db/ports/sudo/options WITH_LDAP=yes WITH_INSULTS=no WITH_DISABLE_ROOT_SUDO=no WITH_DISABLE_AUTH=no WITH_NOARGS_SHELL=no BATCH=yes I''d imagine make would produce some error message. Any way to catch it? Or is only the exit status recorded? -- Darek -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 04/18/2011 05:23 PM, fafaforza wrote:> > > On Apr 18, 8:55 am, Felix Frank <felix.fr...@alumni.tu-berlin.de> > wrote: > >> Your path syntax looks funny: > > Yeah, I wasn''t sure whether Puppet did anything with it as a comma > separated variable (not an array). Set it to the normal Unix colon > separated string and seems to have worked. > > This is the current resource: > > 84: exec { "port-sudo": > 85: cwd => "/usr/ports/security/sudo", > 86: environment => "BATCH=yes", > 87: command => "make install", > 88: path => "/bin/:/usr/bin/:/usr/local/ > bin/:/sbin/:/usr/sbin/:/usr/local/sbin/", > 89: require => File[''options-sudo''] > 90: } > > It results in this on the client side: > > /Stage[main]/Kerberosauth::Freebsd/Exec[port-sudo]/returns) change > from notrun to 0 failed: make install returned 1 instead of one of [0] > at /usr/local/etc/puppet/manifests/kerberosauth.pp:90 > > Just above that resource, I set up /var/db/ports/sudo/options to set > the port options, and with BATCH=yes, it shouldn''t be opening the > interactive dialogue: > > file { ''options-sudo'': > name => "/var/db/ports/sudo/options", > source => "puppet://puppet.server.com/kerberosauth/ > options.sudo", > require => File[''options-sudo-dir''] > } > > client# cat /var/db/ports/sudo/options > WITH_LDAP=yes > WITH_INSULTS=no > WITH_DISABLE_ROOT_SUDO=no > WITH_DISABLE_AUTH=no > WITH_NOARGS_SHELL=no > BATCH=yes > > I''d imagine make would produce some error message. Any way to catch > it? Or is only the exit status recorded?Yes, you definitely want to set "log_output => ''on_failure''" (I think it was) in your exec resource. Regards, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Apr 18, 11:29 am, Felix Frank <felix.fr...@alumni.tu-berlin.de> wrote:> Yes, you definitely want to set "log_output => ''on_failure''" (I think it > was) in your exec resource. > > Regards, > FelixThanks again. it''s right in the documentation :P I should pay better attention! And surprisingly openldap client installed as a dependancy as well. I guess the BATCH env var carried to the other build But I can''t imagine installing something like gd from ports with puppet. So many deps, and you''d have test the whole compile process first, have an options file for each one, and audit it all when any of the ports changes. Managing ports/packages on FreeBSD with puppet sure ain''t fun :P -- Darek -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
One last somewhat unrelated question, but one that might help someone
with a similar setup:
How do I ensure that nss_ldap is installed only after ''sudo'',
as
otherwise, installing nss_ldap from ports would trigger the openldap
and sudo packages, which I don''t want.
"require => Package[''port-sudo'']"
wouldn''t work, and I don''t see an
''onlyif'' or similar parameter under "package"
==========================class kerberosauth {
include "kerberosauth::$operatingsystem"
}
class kerberosauth::common {
...
$nss_ldap = "nss_ldap"
package { $nss_ldap:
ensure => installed
}
...
}
class kerberosauth::freebsd inherits kerberosauth::common {
exec { "port-sudo":
cwd => "/usr/ports/security/sudo",
environment => "BATCH=yes",
command => "make install",
path => "/bin/:/usr/bin/:/usr/local/bin/:/
sbin/:/usr/sbin/:/usr/local/sbin/",
logoutput => ''on_failure'',
require => File[''options-sudo'']
}
}
================
--
Darek
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
One last somewhat unrelated question, but one that might help someone
with a similar setup:
How do I ensure that nss_ldap is installed only after ''sudo'',
as
otherwise, installing nss_ldap from ports would trigger the openldap
and sudo packages, which I don''t want.
"require => Package[''port-sudo'']"
wouldn''t work, and I don''t see an
''onlyif'' or similar parameter under "package"
==========================class kerberosauth {
include "kerberosauth::$operatingsystem"
}
class kerberosauth::common {
...
$nss_ldap = "nss_ldap"
package { $nss_ldap:
ensure => installed
}
...
}
class kerberosauth::freebsd inherits kerberosauth::common {
exec { "port-sudo":
cwd => "/usr/ports/security/sudo",
environment => "BATCH=yes",
command => "make install",
path => "/bin/:/usr/bin/:/usr/local/bin/:/
sbin/:/usr/sbin/:/usr/local/sbin/",
logoutput => ''on_failure'',
require => File[''options-sudo'']
}
}
================
--
Darek
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
One last somewhat unrelated question, but one that might help someone
with a similar setup:
How do I ensure that nss_ldap is installed only after ''sudo'',
as
otherwise, installing nss_ldap from ports would trigger the openldap
and sudo packages, which I don''t want.
"require => Package[''port-sudo'']"
wouldn''t work, and I don''t see an
''onlyif'' or similar parameter under "package"
==========================class kerberosauth {
include "kerberosauth::$operatingsystem"
}
class kerberosauth::common {
...
$nss_ldap = "nss_ldap"
package { $nss_ldap:
ensure => installed
}
...
}
class kerberosauth::freebsd inherits kerberosauth::common {
exec { "port-sudo":
cwd => "/usr/ports/security/sudo",
environment => "BATCH=yes",
command => "make install",
path => "/bin/:/usr/bin/:/usr/local/bin/:/
sbin/:/usr/sbin/:/usr/local/sbin/",
logoutput => ''on_failure'',
require => File[''options-sudo'']
}
}
================
--
Darek
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
One last somewhat unrelated question, but one that might help someone
with a similar setup:
How do I ensure that nss_ldap is installed only after ''sudo'',
as
otherwise, installing nss_ldap from ports would trigger the openldap
and sudo packages, which I don''t want.
"require => Package[''port-sudo'']"
wouldn''t work, and I don''t see an
''onlyif'' or similar parameter under "package"
==========================class kerberosauth {
include "kerberosauth::$operatingsystem"
}
class kerberosauth::common {
...
$nss_ldap = "nss_ldap"
package { $nss_ldap:
ensure => installed
}
...
}
class kerberosauth::freebsd inherits kerberosauth::common {
exec { "port-sudo":
cwd => "/usr/ports/security/sudo",
environment => "BATCH=yes",
command => "make install",
path => "/bin/:/usr/bin/:/usr/local/bin/:/
sbin/:/usr/sbin/:/usr/local/sbin/",
logoutput => ''on_failure'',
require => File[''options-sudo'']
}
}
==========================
--
Darek
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On 04/19/2011 11:52 PM, fafaforza wrote:> One last somewhat unrelated question, but one that might help someone > with a similar setup: > > How do I ensure that nss_ldap is installed only after ''sudo'', as > otherwise, installing nss_ldap from ports would trigger the openldap > and sudo packages, which I don''t want. > > "require => Package[''port-sudo'']" wouldn''t work, and I don''t see an > ''onlyif'' or similar parameter under "package"Yes it does. What semantics are you gunning for? "Only install X on boxes where Y is getting installed" is a tough call. You could use custom facts to find out about your Y. Otherwise, the require is a nice choice, because your catalog should fail where Y is not in the catalog. HTH, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Apr 20, 3:11 am, Felix Frank <felix.fr...@alumni.tu-berlin.de> wrote:> > "require => Package[''port-sudo'']" wouldn''t work, and I don''t see an > > ''onlyif'' or similar parameter under "package" > > Yes it does. > > What semantics are you gunning for? "Only install X on boxes where Y is > getting installed" is a tough call. > You could use custom facts to find out about your Y. > Otherwise, the require is a nice choice, because your catalog should > fail where Y is not in the catalog.I''ll give require a try. I wasn''t sure whether Package[] referenced a definition within the class (which wouldn''t work for me since I used exec), or whether it queried the system''s packaging system to check whether it was installed. Also, sorry for the multiple posts. Google kept throwing an error, and I retried posting a few time before seeing that some of them went through. -- Darek -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Fri, Apr 15, 2011 at 3:26 PM, fafaforza <fafaforza@gmail.com> wrote:> New user trying to get a port to compile: I tried searching but all I > get are links to the FreeBSD port of puppet. Easier to find a needle > in a haystack. > > A class has: > > exec { "port-sudo": > cwd => "/usr/ports/security/sudo", > environment => "BATCH=yes", > command => ''/bin/sh -c "/usr/bin/make install"'', > path => ["/bin/, /usr/bin/, /usr/local/bin/, /sbin/, / > usr/sbin/, /usr/local/sbin/"], > returns => "1", > }Shouldn''t you be using the ports package provider instead? package { "sudo": provider => ports, ensure => installed, } I haven''t touched Puppet on FreeBSD personally, it may auto-detect the provider automatically for you correctly. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> What semantics are you gunning for? "Only install X on boxes where Y is >> getting installed" is a tough call. >> You could use custom facts to find out about your Y. >> Otherwise, the require is a nice choice, because your catalog should >> fail where Y is not in the catalog. > > I''ll give require a try. I wasn''t sure whether Package[] referenced a > definition within the class (which wouldn''t work for me since I used > exec), or whether it queried the system''s packaging system to check > whether it was installed.No, it does indeed only consider what you''re managing with puppet. You don''t manage a package - puppet doesn''t know about it. If you want one resource to work only when a certain exec is also present in the node''s catalog, you need to require the Exec[] of course, not some Package[] that doesn''t exist as far as puppet is concerned. But do heed Nigel''s comment about the ports provider! If that solves your problem, the above may not even matter to you after all. Cheers, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 04/20/2011 02:45 PM, Nigel Kersten wrote:> On Fri, Apr 15, 2011 at 3:26 PM, fafaforza <fafaforza@gmail.com> wrote: >> New user trying to get a port to compile: I tried searching but all I >> get are links to the FreeBSD port of puppet. Easier to find a needle >> in a haystack. >> >> A class has: >> >> exec { "port-sudo": >> cwd => "/usr/ports/security/sudo", >> environment => "BATCH=yes", >> command => ''/bin/sh -c "/usr/bin/make install"'', >> path => ["/bin/, /usr/bin/, /usr/local/bin/, /sbin/, / >> usr/sbin/, /usr/local/sbin/"], >> returns => "1", >> } > > Shouldn''t you be using the ports package provider instead? > > package { "sudo": > provider => ports, > ensure => installed, > } > > I haven''t touched Puppet on FreeBSD personally, it may auto-detect the > provider automatically for you correctly. >The ports provider doesn''t work due to bugs in portupgrade when run without a controlling tty. I opened a problem report about this sometime ago and recommended removing the provider entirely. The port (sysutils/puppet) already patches the providers to demote the ports provider in favor of the package provider. There''s also an optional (but enabled by default) patch to use an alternate package provider that uses the port origin as the package name as well as utilizing the INDEX for name resolution. http://github.com/xraj/puppet/commits/freebsd%2Fpackage -- Russell A Jackson <raj@csub.edu> Network Analyst California State University, Bakersfield -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Apr 21, 2011 at 11:03 AM, Russell Jackson <raj@csub.edu> wrote:> The ports provider doesn''t work due to bugs in portupgrade when run > without a controlling tty. I opened a problem report about this sometime > ago and recommended removing the provider entirely.I''ll chase this up now Russell.> The port (sysutils/puppet) already patches the providers to demote the > ports provider in favor of the package provider. There''s also an > optional (but enabled by default) patch to use an alternate package > provider that uses the port origin as the package name as well as > utilizing the INDEX for name resolution. > > http://github.com/xraj/puppet/commits/freebsd%2FpackageWhich package provider is preferred over the ports provider Russell? Have those patches been sent to the dev-list for merging into upstream ? -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 04/21/2011 11:05 AM, Nigel Kersten wrote:> On Thu, Apr 21, 2011 at 11:03 AM, Russell Jackson <raj@csub.edu> wrote: > >> The ports provider doesn''t work due to bugs in portupgrade when run >> without a controlling tty. I opened a problem report about this sometime >> ago and recommended removing the provider entirely. > > I''ll chase this up now Russell. > >> The port (sysutils/puppet) already patches the providers to demote the >> ports provider in favor of the package provider. There''s also an >> optional (but enabled by default) patch to use an alternate package >> provider that uses the port origin as the package name as well as >> utilizing the INDEX for name resolution. >> >> http://github.com/xraj/puppet/commits/freebsd%2Fpackage > > Which package provider is preferred over the ports provider Russell?package/freebsd.rb> > Have those patches been sent to the dev-list for merging into upstream ?An older incarnation was, but died and never went anywhere. On the other hand, I haven''t been very good about pushing for it either. There are also a few competing provider rewrites. I thought I''d let the community decide which one was best, but that doesn''t appear to be happening either. -- Russell A Jackson <raj@csub.edu> Network Analyst California State University, Bakersfield -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.