> > > I'm unclear from that on whether you made a typo with "Cobble server" or > you're planning to keep it for some services. I'm going to assume a typo > based on the questions below about per-DC provisioning - do correct me and > clarify otherwise :) > > For Foreman provisioning, you can achieve a completely segregated > provisioning network - the Foreman Proxy can relay templates. So long as > the proxy (which you'd have for TFTP/DHCP management anyway) has a route to > Foreman, it can retrieve rendered templates on behalf of the installing > host. See https://theforeman.org/manuals/1.12/index.html#4.3.12Templates > for more. > > No, we'd be replacing the Cobbler server with a Foreman one entirely, I was just reiterating that the only things that the installing hosts have access to IS the 'Cobbler|Foreman' server, and in general, all we provide as a service is HTTP/TFTP/DHCP to those installing hosts. The 'Cobbler|Foreman' host would definitely have access to the Foreman server, which sounds like it would work.
> - We only use DHCP for the provisioning process. Everything else has >> static IPs. I assume that's ok, as long as we let Foreman control the DHCP >> server on the prov vlan >> > > Yes, that's fine. The default templates (for Kickstart anyway) come with > static configuration snippets, and there's an IP allocation mode for the > Subnet in the UI. Set that to static, and the templates should render > correctly. For other OSs (you mentioned Windows? :p) then you may want to > see how we're detected the IPAM mode and re-use it in templates of your own. > Yeah, Windows was.. interesting. Basically, we iPXE, chainload into a custom iPXE script, into a wimboot of a custom WinPE image, that figures out the Cobbler server IP, downloads some scripts from it and runs them, which then boots us into Windows, where we then download a Chef cookbook and configure the host appropriately. I'm not super happy with it, as it takes too many reboots ( and rebooting Dell R820's is a 5 minute process.. ), so total provision time ends up at 30 min or so. > That said, you'll want to think about scale, no doubt, with the number of > systems you mentioned in the OP. It's quite possible to scale out the > various parts of Foreman itself (in addition to the obvious scaling of the > proxies) in different ways, so that's something we can go into if you need > more info. > > So I'm not sure we'd actually use too much of Foreman's lifecycle management, as we have other tools for that. One of the main reasons we're investigating it ( besides Cobbler's lack of development lately ) is because the team in control of our yum repos is looking at deploying Katello, which means we'd have Foreman anyways, so why not consolidate if we can get it to work. I did checkout the Salt plugin and it looks like it manages what we were doing, although in a little bit of a intrusive way compared to our solution ( we just send an even through the salt-minion on the Cobbler host and the master takes care of everything else.. nothing installed on the master to get it working ) Thanks for bearing with me Greg - sounds like I've got enough where we could at least go to a POC stage on it. -- sh -- You received this message because you are subscribed to the Google Groups "Foreman users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/foreman-users. For more options, visit https://groups.google.com/d/optout.
