On Dec 13, 6:02 am, Geoff <geoffnew...@gmail.com> wrote: > On Dec 3, 11:41 am, Geoff <geoffnew...@gmail.com> wrote: > > Anyone had any experience getting puppet to update multiple OS's on a > > single server?
Like Daniel said, I think the resounding silence that greeted your initial query should be interpreted as a group "No." > > For example, for a set of blades Network booting from a primary > > server, the OS for each blade would be stored on the primary server. > > For example: > > /pxe/host1/<normal OS directory structure> > > /pxe/host2/<normal OS directory structure> > > ..... > > /pxe/hostn/<normal OS directory structure> > > > Can puppet be run in a mode that would take into account relative > > directories. i.e. instead of being / (root) based, it would be /pxe/ > > hostn/ based? > > I've tried the chroot approach previously (about 2 years ago) but had > > a nightmare with Ruby libraries. If each /pxe/hostn/ contains a full OS image including Puppet, Facter, and all their dependencies, then you should be able chroot to them and launch puppet[d] within. (Actually, there are a few other details you might need to provide, such as certain working device nodes in /dev and proc mounted inside, but these are general chroot issues.) You could probably use environments or custom facts to associate the desired configuration with each image, despite all the requests coming from the same physical client. If you do this, you will likely find that 1) Some things Puppet can do are inappropriate for your desired usage model. For example, 1a) You can ensure that services are enabled, but not that they are running 1b) You can configure mount points definitions, but you should not ensure them mounted (because they would be mounted on the image, if at all) 2) Some things simply won't work, or won't work correctly. Especially, unless you hack up Facter something fierce, some facts presented to the Puppetmaster will reflect the system running Facter/ Puppet rather than the systems on which you intend to load the images. 3) Some things are heavier-weight than you are looking for. For example, if you plan to install software within chroot via Puppet, then in addition to Puppet and all its dependencies, you will also need in each image a copy of the relevant package manager and its local database. Overall, it sounds like a clever idea on the surface, but the details are likely to kill you. John -- 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.
