Differences

This shows you the differences between two versions of the page.

--- linux:debian:automatic-installation [2013/06/23 06:15] – [Requirements] add link to apt-mirror stybla
+++ linux:debian:automatic-installation [2013/06/25 05:06] (current) – finish up - foreword, conclusion and some other stuff stybla
@@ Line 1: / Line 1: @@
 ====== Debian - Automatic Installation ======
-<note warning>
+===== Foreword of sorts =====
-**WORK IN PROGRESS**
-  * NOTE to myself - preseed file can be supplied by DHCP
-  * NOTE to myself - preseed generated by CGI script
-</note>
 As a pretty much any mainstream GNU/Linux distribution, even Debian allows you to automate
-system installation. You can either use Preseed or build a custom ramdisk and use debootstrap
+system installation. You can either use Preseed or a custom built ramdisk and use debootstrap
 directly.
-No doubt each approach has its own pros and cons. Personally, I think Preseed is sufficient for
+When I told my friend I'm looking into preseeding Debian he was like: //What's wrong with debootstrap?//
-most cases and basic OS installation is what you (should) want. After OS is sucessfully installed,
+The answer is there is nothing wrong with deboostrap and custom built ramdisk except it's a bit of work.
-Ansible/Chef/Puppet will take over and finish the job. I really seek nothing else from OS
+So why not to use Preseeding if it can do the job?
-installation. Preseed is capable of handling not only partitions, but software RAID and LVM as well.
-You can also run commands and do stuff, although admitingly in limited scope.
-On the other hand, customized ramdisk can provide you with universal solution - one rules them all.
+No doubt each approach has its pros and cons. I'm positive custom build ramdisk and deboostrap
-You can add vendor specific tools, assemble HW RAIDs, debug/fix broken OS, run pre/post install tasks
+will be faster than installer. Also, you can add tools you need, eg. tools for HW RAID, but you
-via your favourite management tool etc. and create one ramdisk for OS install and rescue.
+can do a bit of scripting(and magic) as well, eg. assemble HW RAID prior to installation. Ramdisk can be used for
+rescue and debugging. As a con I see maintenance - you have to create it, script(automate) it and keep it up-to-date.
+Preseeding has pretty much the same capabilities. It allows you to install base Debian which is, in my opinion,
+all you need and fine-tune the rest with Ansible/Chef/Puppet/or-alike after installation; install additional
+packages; support for LVM and Linux SW RAID; run additional commands; what have you. I'd almost forget you
+can use Preseed for installation from USB/DVD/CD as well! And it's all maintained for you.
+Now, here are some cons which, despite solveable, are a bit annoying.
+==== Cons of Debian Preseeding ====
+=== Things don't always work out-of-the-box ===
+For example I didn't have much of success with network console. It just kept segfaulting on me at "random" points.
+You might want to use different kernel, although replacing kernel should be the least warry and quite easy.
+Something can be or get broken or there is going to be some sort of regression.
+=== More than one Preseed configuration might be necessary ===
+This might be due to the differences in hardware configuration. The thing is, you must specify target drive in case
+there is more than one drive present. And I'm sure this isn't uncommon case. However, this can be solved by simple
+CGI/script preseed generator which will return correct Preseed configuration file, eg. based on hostname.
+=== Missing tools ===
+I believe you could easilly add whatever you want and pretty much modify netboot ramdisk in way you like.
+=== MD5 sum of Preseed config must be kept up to date ===
+Yes, this is particularly annoying one. You can solve it in two ways. Don't use MD5 sum, however then you can't be sure
+about integrity of preseed file you've just downloaded. Or just integrate it into your script you have for updating TFTP
+boot configuration. I don't really think this is a hard one to do.
+=== Can't be used for rescue and/or debugging ===
+I'm not entirely sure this is true. I also think with a bit of work and modification it very well could be.
+===== Conclusion of sorts =====
+I find Debian Preseeding to be enough. It does basic Debian installation which is all I need, because after installation
+is finished, I hand it over to Ansible/Chef/Puppet/whatever to fine tune system for specific task. I don't mind the time it takes
+to install Debian via Installer, although I will look into custom built ramdisk sooner or later. More out of
+curiosity rather than actual need, I guess. As I mentioned, not every time things work out-of-the-box. However,
+the same can be said about everything and it's something you have to accept and be aware of - always.
-Now, you might argue every server(hardware configuration) is different and requires specific approach.
-I'd counter-argue it's more about profiling and you end up with only couple profiles. I agree
-stuff like HW RAID assembly and vendor specific tools to do that might be a problem. However, you can
-modify Debian's netboot ramdisk and add these. Preseed allows you to run early command(s). Is it early
-enough to assembly HW RAID? Would installer notice/update its device list? I don't know, I haven't tried.
-I still think rolling with Preseed for basic OS installation is better and easier to maintain way than
-having to maintain your customized ramdisk. Althouhg, once you automate its [ramdisk] creation, then
-it won't matter that much.
 ===== Customized ramdisk and debootstrap =====
@@ Line 43: / Line 71: @@
 a way it boots into shell instead of installer, add stuff you need want, remove stuff you don't need,
 pack it, run with it.
 ===== Preseeding =====
@@ Line 51: / Line 81: @@
   * time
   * patience
 ==== Example of preseed file ====
@@ Line 186: / Line 217: @@
 Turning off Frame Buffer(''fb'') in installer is usefull when eg. ''curses'' is used instead of ''SDL'' to display VGA output.
 However, turning Frame Buffer off means graphics in installer will go wonky from time to time even when running in SDL window.
+==== How to configure network-console, how can it be used? ====
+<code>
+### Network console
+# Use the following settings if you wish to make use of the network-console
+# component for remote installation over SSH. This only makes sense if you
+# intend to perform the remainder of the installation manually.
+d-i anna/choose_modules string network-console
+d-i network-console/authorized_keys_url string http://test-deb-01.vm.zeratul.czf/preseed/authorized_keys
+#d-i network-console/password password r00tme
+#d-i network-console/password-again password r00tme
+</code>
+This happens before APT repository is configured. You're presented with instructions and I believe as long
+as you don't click //Continue// installer will wait indefinitely. Then you can login via SSH as user
+''installer'' and either continue installation(I believe Preseed will be used), you can continue installation
+manually, or switch into shell.
+Note, however, network-console has segfaulted(Wheezy 7.1) on my on several occasions. The first was when
+I attempted to get into shell and second when I've clicked //Continue// in installer and tried to log-in
+via SSH when installation proceeded.
+==== When is ''early_command'' being executed? ====
+Before APT repository is configured.
+==== When is ''late_command'' being executed? ====
+Just before machine is about to be rebooted. However ''/target'' is still mounted.
 ==== When things go wrong - unusual/additional questions asked ====