Hi all,
I have an NFS server on our network sharing out package files for
Puppet to install to all and sundry. The clients access said NFS
server via an automounter configuration (I don''t want the packages
share mounted all the time, only when installing packages) As a
result, installation of packages depends on autofs... So I have the
following:
service { "autofs": ensure => running", subscribe =>
File["/etc/
auto_master"] }
package { "SUNWfoo":
# Yes, I''m using /net - its evil, I know...
source => "/net/$installsvr/export/pkgs/$kernelrelease/$hardwareisa/
SUNWfoo.pkg",
require => Service["autofs"]
}
I''m serving it out this way for a number of reasons, including slow
Puppet fileserving for large files, inability to specify response
files with http package streams on Solaris'' package management system
- and so on...
The problem I have is that if the autofs service is restarted right
before a package is installed (which typically happens when I do a
jumpstart as I put in a new /etc/auto_master) then the service is
still restarting whilst the subsequent resources are being configured.
So the package installs fail because they can''t see the files.
5 seconds later the automounter comes online and the files are
available...
Basically the problem here is that the command used to restart the
service doesn''t wait for the service to actually restart - it just
triggers the SMF services to restart it. I can''t see any options in
svcadm to restart and wait for it to be online again - which is a
little annoying. And I think Puppet makes the assumption that because
it told the service to restart that it has actually done that...
If I take the requirement for autofs out from the packages - nothing
installs as it tries to install packages too early and the system
isn''t configured enough to retrieve them...
Has anyone else seen this condition happen? If so, what did you do to
work around (or preferably fix) the problem?
thanks,
Greg
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
Matthew Hyclak
2009-Jul-24 12:03 UTC
[Puppet Users] Re: Solaris SMF services and their dependencies...
On Thu, Jul 23, 2009 at 11:33 PM, Greg<greg.boug@gmail.com> wrote:> > Hi all, > > I have an NFS server on our network sharing out package files for > Puppet to install to all and sundry. The clients access said NFS > server via an automounter configuration (I don''t want the packages > share mounted all the time, only when installing packages) As a > result, installation of packages depends on autofs... So I have the > following: > > service { "autofs": ensure => running", subscribe => File["/etc/ > auto_master"] } > > package { "SUNWfoo": > # Yes, I''m using /net - its evil, I know... > source => "/net/$installsvr/export/pkgs/$kernelrelease/$hardwareisa/ > SUNWfoo.pkg", > require => Service["autofs"] > } > > I''m serving it out this way for a number of reasons, including slow > Puppet fileserving for large files, inability to specify response > files with http package streams on Solaris'' package management system > - and so on... > > The problem I have is that if the autofs service is restarted right > before a package is installed (which typically happens when I do a > jumpstart as I put in a new /etc/auto_master) then the service is > still restarting whilst the subsequent resources are being configured. > So the package installs fail because they can''t see the files. > > 5 seconds later the automounter comes online and the files are > available... > > Basically the problem here is that the command used to restart the > service doesn''t wait for the service to actually restart - it just > triggers the SMF services to restart it. I can''t see any options in > svcadm to restart and wait for it to be online again - which is a > little annoying. And I think Puppet makes the assumption that because > it told the service to restart that it has actually done that... > > If I take the requirement for autofs out from the packages - nothing > installs as it tries to install packages too early and the system > isn''t configured enough to retrieve them... > > Has anyone else seen this condition happen? If so, what did you do to > work around (or preferably fix) the problem? >You can specify the restart command for a service, so I would just use your own for autofs that includes a "&& sleep 5" after the regular restart command. Matt --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Greg
2009-Aug-10 05:44 UTC
[Puppet Users] Re: Solaris SMF services and their dependencies...
Matt, That worked fine - thanks for that... (Finally managed to actually test it this morning...) So long as it always takes less than 5 seconds to restart, this looks like it will work nicely... thanks, Greg On Jul 24, 10:03 pm, Matthew Hyclak <hyc...@gmail.com> wrote:> On Thu, Jul 23, 2009 at 11:33 PM, Greg<greg.b...@gmail.com> wrote: > > > Hi all, > > > I have an NFS server on our network sharing out package files for > > Puppet to install to all and sundry. The clients access said NFS > > server via an automounter configuration (I don''t want the packages > > share mounted all the time, only when installing packages) As a > > result, installation of packages depends on autofs... So I have the > > following: > > > service { "autofs": ensure => running", subscribe => File["/etc/ > > auto_master"] } > > > package { "SUNWfoo": > > # Yes, I''m using /net - its evil, I know... > > source => "/net/$installsvr/export/pkgs/$kernelrelease/$hardwareisa/ > > SUNWfoo.pkg", > > require => Service["autofs"] > > } > > > I''m serving it out this way for a number of reasons, including slow > > Puppet fileserving for large files, inability to specify response > > files with http package streams onSolaris'' package management system > > - and so on... > > > The problem I have is that if the autofs service is restarted right > > before a package is installed (which typically happens when I do a > > jumpstart as I put in a new /etc/auto_master) then the service is > > still restarting whilst the subsequent resources are being configured. > > So the package installs fail because they can''t see the files. > > > 5 seconds later the automounter comes online and the files are > > available... > > > Basically the problem here is that the command used to restart the > > service doesn''t wait for the service to actually restart - it just > > triggers the SMF services to restart it. I can''t see any options in > > svcadm to restart and wait for it to be online again - which is a > > little annoying. And I think Puppet makes the assumption that because > > it told the service to restart that it has actually done that... > > > If I take the requirement for autofs out from the packages - nothing > > installs as it tries to install packages too early and the system > > isn''t configured enough to retrieve them... > > > Has anyone else seen this condition happen? If so, what did you do to > > work around (or preferably fix) the problem? > > You can specify the restart command for a service, so I would just use > your own for autofs that includes a "&& sleep 5" after the regular > restart command. > > Matt--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---