Chris's Wiki :: blog/sysadmin/OSInstallersEasyChanges Commentshttps://utcc.utoronto.ca/~cks/space/blog/sysadmin/OSInstallersEasyChanges?atomcommentsDWiki2015-10-15T15:36:23ZRecent comments in Chris's Wiki :: blog/sysadmin/OSInstallersEasyChanges.By James on /blog/sysadmin/OSInstallersEasyChangestag:CSpace:blog/sysadmin/OSInstallersEasyChanges:3e0dad4d36a85c7db85fd7164fa3626aa0a6d5bcJames<div class="wikitext"><p>Preseed files are fairly easy to add to CDs: <a href="http://d-i.alioth.debian.org/manual/en.i386/apbs02.html">http://d-i.alioth.debian.org/manual/en.i386/apbs02.html</a> </p>
<p>I won't say that further modifications are easy, but they're certainly documented <a href="https://wiki.debian.org/DebianInstaller/Modify/CD">https://wiki.debian.org/DebianInstaller/Modify/CD</a></p>
</div>2015-10-15T15:36:23ZBy zdw on /blog/sysadmin/OSInstallersEasyChangestag:CSpace:blog/sysadmin/OSInstallersEasyChanges:06d9d05b9118dc616399f849b53999a60b1c4c35zdwhttp://artisancomputer.com<div class="wikitext"><p>This comes back to the packaging problem - the packaging systems used by nearly every OS really make it hard to make distributable changes to a system without a lot of trouble. The tools to create, modify, and diff packages need to get as good as the ones we have for code in a modern DVCS's, but that work isn't being done. </p>
<p>I'd also love to see a packages broke down into the various parts (binaries, config files, documentation) that can be replaced independently. For example, if you wanted to install the vendor's binaries for say Apache, but supply a custom config file, you'd do it by making your own config package, but you could still get security patches to the binaries from the upstream vendor.</p>
<p>As other's say, automation exists when doing PXE installations, but these require more ongoing work, and frequently a PXE or install file caching server running the OS that's being installed in order to install current OS's, which is a challenge in heterogeneous environments. Also, they fall down in ways - Debian's disk partitioning automation is nigh inscrutable, for example.</p>
</div>2015-10-14T17:47:57ZBy Chris Siebenmann on /blog/sysadmin/OSInstallersEasyChangestag:CSpace:blog/sysadmin/OSInstallersEasyChanges:b1d7218656ad8161ab79f2cb7045052f4b087197Chris Siebenmann<div class="wikitext"><p>I've never used Jumpstart so I can't comment specifically, but I have
the impression it's designed to be an automated install system. We
specifically don't want automated installs; we really do want to be
asked a few crucial questions during the install (and to have to approve
a few crucial choices, like system disks and the specific NICs used).</p>
<p>Also, yes, we really do want to use install CDs (although I'm happy to
virtualize them through a IP KVM or the like). We're not fans of DHCP/PXE
install booting for various reasons.</p>
</div>2015-10-14T16:41:39ZBy Tilman Baumann on /blog/sysadmin/OSInstallersEasyChangestag:CSpace:blog/sysadmin/OSInstallersEasyChanges:a89ea68c5cc38111d7985d8b48a478abc5bf3bc6Tilman Baumann<div class="wikitext"><p>I'm surprised by the way you phrase the problem.</p>
<p>I suppose you know that you don't actually need to rebuild the installer image to either use Red Hats kickstart or Debians preseed? (No unified installer yet I'm afraid)
Unless you really want to install from CD which these days seems arcane.</p>
<p>Just point the installer to the right file via DHCP/PXE parameter.
I mean, you want hands off installation anyway, right? So just set the DHCP options and reboot.
(A process which can be automated with tools like cobbler/spacewalk/sattelite)</p>
<p>It's not a brilliant solution. But some kind of magic is always required. (And because pressed is not exactly awesome)</p>
</div>2015-10-14T14:56:33ZBy liam at unc edu on /blog/sysadmin/OSInstallersEasyChangestag:CSpace:blog/sysadmin/OSInstallersEasyChanges:bbfe553b64fe94164e0f7893043283b1743f2f14liam at unc edu<div class="wikitext"><p>So more like the old Solaris 10 Jumpstart experience?</p>
</div>2015-10-14T13:42:47Z