Chris's Wiki :: blog/sysadmin/AutoinstallsWhyNot Commentshttps://utcc.utoronto.ca/~cks/space/blog/sysadmin/AutoinstallsWhyNot?atomcommentsDWiki2014-01-13T19:27:50ZRecent comments in Chris's Wiki :: blog/sysadmin/AutoinstallsWhyNot.By Bashir on /blog/sysadmin/AutoinstallsWhyNottag:CSpace:blog/sysadmin/AutoinstallsWhyNot:7785a3e4649b1d16cc3d2d60d73e4d374b33e671Bashir<div class="wikitext"><table class="wikitable" border="1" cellpadding="4"><tr><td valign="top">The idea of 'if this machine PXE boots it will get (re)installed' is, for me, a nightmare.</td>
</tr>
</table>
<p>You should check out the Foreman: <a href="http://theforeman.org/">http://theforeman.org/</a></p>
<p>Specifically, the 'Build' feature of Foreman, which should let you very easily see which machines have PXE config enabled and which do not.</p>
<p>It also lets you easily enable PXE if needed via the web interface cmd line/script. </p>
<table class="wikitable" border="1" cellpadding="4"><tr><td valign="top">As far as I can tell, it's still generally a fair amount of work to put together a reliable, fully functional auto-install environment that supports a fairly wide variety of machines and software setups.</td>
</tr>
</table>
<p>Foreman makes this too easy. There are many users deploying large numbers of Linux and Solaris systems using Foreman. I believe there is some Windows support also.</p>
</div>2014-01-13T19:27:50ZBy Ade on /blog/sysadmin/AutoinstallsWhyNottag:CSpace:blog/sysadmin/AutoinstallsWhyNot:93db803f490b63b8732cc0db23a8a5006e504104Adehttp://www.big-bubbles.org.uk/<div class="wikitext"><p>I can't speak to Ubuntu, but I would avoid almost any manual (interactive) RHEL install in favour of some automation. I've even generated a dummy Kickstart in Cobbler then edited it by hand to strip out all the build server dependencies (for a non-connected build), rather than undertake another tedious, arbitrary trip through the Anaconda GUI. The benefits of having a consistent, standardised, recorded install that runs without intervention across everything you manage considerably outweigh the vagaries of manual installs IMHO, even if it costs extra effort, <em>even if that's per server</em>. (I realise YMMV and that's effectively what you're saying here - I'm just suggesting you don't knock it until you've tried it.)</p>
<p>As for unintended reinstalls, we build everything on a separate build VLAN and then move it to its production network. If we really have to avoid network boots, we can generate a custom ISO image in Cobbler instead. (You can also disable PXE boot for any system defined in Cobbler after use, although I agree this is easy to forget.)</p>
</div>2014-01-13T11:06:43ZBy zdw on /blog/sysadmin/AutoinstallsWhyNottag:CSpace:blog/sysadmin/AutoinstallsWhyNot:0e0a3f74684baa10eee6b28691ef16f429ffc905zdwhttp://artisancomputer.com<div class="wikitext"><p>Two ideas:</p>
<p>1. I've heard it recommended that a non-default VLAN be set up for imaging, and that's the only place PXE booting is possible. This seemed like a lot of changes to get to the final goal, so I didn't pursue it.</p>
<p>2. Fancier PXE chained boot loaders like iPXE can be set to have non-imaging defaults.
My normal setup is a 10 second delay at the menu, then attempt to boot of primary hard disk, then if that fails drop into a memory test. </p>
<p>I can intervene in that 10 seconds to start OS installers or diagnostic tools. No more slinging around old, unpatched physical media anymore. </p>
<p>Also, you can script iPXE - I haven't done this, but custom config scripts could be generated/loaded depending on the booted machine's MAC address or other distinguishing features by feeding that information to a script on a http server.</p>
</div>2014-01-12T14:51:55Z