Network Debian GNU / Linux Workstation Installation

    Hello.

    Automatic deployment of the workplace is a typical task, one might say. Surely a lot of people solved it - starting from the network infrastructure and the instructions of the authorities of personal preferences; using ready-made solutions, or creating your own.

    In this article, I would like to share with the community my way of building an automated network installation system for workstations running under Debian GNU / Linux. No flash drives, disks, or other external hard drives, which for some reason personally I personally have the habit of regularly getting lost in the ruins of a working mess, not reading or being cleaned up to record some incredibly necessary garbage.

    If for you this state of affairs seems close and familiar - welcome under cat.

    Environment deployment


    For the network installation to work, you first need configured DHCP and TFTP servers. Unfortunately, I can’t remember now what I was guided by when choosing them, since the first successful experiments were made a year and a half ago, or even earlier. At that time, isc-dhcp-server and tftpd-hpa were chosen as dhcp and tftp servers, respectively.

     aptitude install isc-dhcp-server tftpd-hpa
    

    For a dhcp server, you need to specify the interface used in / etc / default / isc-dhcp-server and write the appropriate settings for your network in /etc/dhcp/dhcpd.conf. For the network 192.168.121.0/24 and the eth0 interface, it looks something like this:

     sed -i 's/INTERFACES=""/INTERFACES="eth0"/g' /etc/default/isc-dhcp-server
     sed -i 's/#authoritative;/authoritative;/g' /etc/dhcp/dhcpd.conf
     echo -e ' 
     subnet 192.168.121.0 netmask 255.255.255.0 {
      range 192.168.121.128 192.168.121.200;
      option domain-name-servers 192.168.121.1;
      option routers 192.168.121.1;
      filename "pxelinux.0";
     }' >> /etc/dhcp/dhcpd.conf
    

    It goes without saying that you may have other options and settings. The only line that interests us here is the penultimate one, where the name of the file that will be transmitted using tftpd over the network for the initial loading of the created system is indicated.

    I left tftpd on default settings; changed only the TFTP_DIRECTORY parameter in the / etc / default / tftpd-hpa file, which is not necessary in principle. Next, download the image for the Debian network installation to this directory and unpack it

    wget http://ftp.debian.org/debian/dists/wheezy/main/installer-i386/current/images/netboot/netboot.tar.gz
    tar -xzvf netboot.tar.gz
    rm netboot.tar.gz
    

    At this stage, we can already install the system over the network (yes, that's how simple it is), but so far only in manual mode. That, although it saves time and nerves in the search for a bootable flash drive / compact, but not really, so we move on to the next part of our automation - creating the so-called “answer file” for all installer questions.

    Answers and questions


    The answer file can be embedded in initrd, it can be placed on an external medium, or it can be placed on a web server, which will be available during the installation process. The last option turned out to be the most convenient for me both for making changes (no need to rebuild initrd), and directly in the process of work (no need to look for a flash drive with answers). I want to note that although I have this whole thing spinning on one computer, this is completely optional.

    In order for the installer to “find out” where to look for answers to all his questions, in the $ TFTP_DIRECTORY / debian-installer / i386 / boot-screens / txt.cfg file, add the auto and url parameters to the last line (which starts with append). As a result, the file will have something like the following

    default install
    label install
            menu label ^Install
            menu default
            kernel debian-installer/i386/linux
            append vga=788 initrd=debian-installer/i386/initrd.gz -- quiet auto=true url=http://192.168.121.1/pxeinstall/preseed.cfg
    

    If desired, you can also change timeout 0 to timeout 5 in the menu configuration, for example, and save yourself the trouble of pressing Enter before starting the installation. Personally, I returned the “eternal” timeout after my neighbor, who was upset and ran up to me, sent a crashed car to restart and went out for a smoke, and when he returned, I saw a freshly installed Debian instead of my favorite “seven”. My admonitions that the freshly installed system of the seventh version were not comforted either :(

    Of course, on the appropriate host we need a web server with the pxeinstall directory, which we still need. Here I didn’t think of anything - apache was already for internal needs. you don’t have a web server yet, command

     aptitude install apache2  && mkdir /var/www/pxeinstall 
    

    should solve this problem. So let's move on to writing the answers.

    The official sample file can be viewed here . You can also get a ready-made answer file for your system by running the command

     debconf-get-selections --installer > my.preseed.cfg
    

    And with

     debconf-get-selections >> my.preseed.cfg
    

    You will supplement this file also with all the answers that you gave when installing additional software.

    True, I somewhere met the statement that the file thus obtained may not work correctly and, as a result, the recommendation to correct the original file to your needs, using my.preseed.cfg only as a hint.

    In general, studying and editing this file is not a problem - everything is well commented; the necessary values ​​of the necessary parameters can be found in the file generated by debconf. And yet there are a few nuances that I would like to dwell on in more detail.

    Disk layout

    There are two ways to partition the disks at this stage - choose a predefined automatic partitioning option, or set the size of the partitions manually. There are three predefined options - all files on one partition; a separate section under / home and separate sections under / home, / tmp, / usr and / var. Indicated in the answer file as a line

     d-i partman-auto/choose_recipe select atomic
    

    Instead of atomic, you can use home and multi, respectively.

    As an experiment, and for many typical breakdown options, this is quite enough, but we use markup, in which a separate section for service needs is traditionally allocated, so

     d-i partman-auto/expert_recipe string                        \
          boot-root ::                                            \
                  30000 5000 40000 ext4                           \
                          $primary{ } $bootable{ }                \
                          method{ format } format{ }              \
                          use_filesystem{ } filesystem{ ext4 }    \
                          mountpoint{ / }                         \
                  .                                               \
                  20000 3000 40000 ext3                           \
                          method{ format } format{ }              \
                          use_filesystem{ } filesystem{ ext3 }    \
                          mountpoint{ /srv }                      \
                  .                                               \
                  10000 2000 10000000 ext4                        \
                          method{ format } format{ }              \
                          use_filesystem{ } filesystem{ ext4 }    \
                          mountpoint{ /home }                     \
                  .                                               \
                  50% 6000 200% linux-swap                        \
                          method{ swap } format{ }                \
                  .
    

    In short, what is what.

    boot-root is some kind of witchcraft, without which all this canoe refuses to work :) After it there are parameters for each of the created partitions. In the first line, three digits respectively indicate the minimum partition size, priority for the partition calculation algorithm, and the maximum partition size. The size is indicated in megabytes, and when broken, it will be truncated according to the size of the cylinder. In addition to integer values, you can also use percentages of the size of RAM. Variants of the type "2000 + 50%" are also allowed, that is 2000MB + half the RAM. Priority is a conditional “mid-ceiling” number. The lower it is, the final section size will be closer to the minimum value. It is recommended that one of the sections indicate the maximum size larger, but not more than 1,000,000,000 so as not to run into an overflow: on i386, integer arithmetic is limited to 31 bits. The remaining value is, of course, the type of file system.

    The $ primary {} and $ bootable {} qualifiers indicate respectively that the partition being created will be primary and / or bootable. method {format} must be specified if the section will be formatted. In addition to format, swap values ​​for the swap partition and keep can also be used to keep the partition intact. If method {format} is specified, you must also specify one more format {} qualifier. The following use_filesystem {} and filesystem {ext4} qualifiers determine which file system the partition will be formatted into. The last qualifier used, mountpoint, defines the mount point for the partition to be created. The “dot” symbol crowns this goodness, which separates the description of the sections from each other.

    All these parameters should be indicated on one line, which makes editing or searching for errors a rather fun task, so we traditionally use backslashes to give our markup a more or less maintainable look.

    A more detailed description of the disk layout process, including lvm, raid and other joys, can be seen here and here .

    Expanding opportunities

    Despite the fact that with the help of the answer file you can fully automate the system installation process, there still remain tasks that it does not solve. These are various edits of configs, and a standard set of documents / settings that a user should have at hand, and of course the seals are the corporate logo on the desktop. To solve this problem, I use the ability to execute any command after installing the system, but with / target still mounted:

     d-i preseed/late_command string \
      chroot /target sh -c "/usr/bin/wget -O /tmp/postinstall http://192.168.121.1/pxeinstall/postinstall && /bin/sh -x /tmp/postinstall"
    

    That is, we just pump out the prepared script and run it.

    There is nothing particularly outstanding in the postinstall file - repositories with additional software are connected, the same software is installed. Then the configuration files are corrected and the reference home directory is rolled out to the user along with all the necessary settings.

    #!/bin/bash
    deployserver=192.168.121.1
    deployconfig=/pxeinstall/configs
    #
    # Installing additional software
    #
    wget $deployserver$deployconfig/apt_sources.list -O /etc/apt/sources.list
    export DEBIAN_FRONTEND=noninteractive
    aptitude update
    #Installing unzip with full cyryllic support
    apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 4EEBB18420019065
    aptitude -y install unzip p7zip-full
    #opera has own repo
    wget -O - http://deb.opera.com/archive.key | apt-key add -
    aptitude update
    aptitude -y install opera
    #For skype we do the following
    aptitude install libasound2-plugins
    wget -O skype-install.deb http://www.skype.com/go/getskype-linux-deb
    dpkg -i skype-install.deb
    # wvdial cofig for intertelecom. Just in case.
    wget $deployserver$deployconfig/wvdial.conf -O /etc/wvdial.conf
    #Set adequate editor by default
    update-alternatives --set editor /usr/bin/vim.basic
    #
    #  User profile
    #
    username=`cat /etc/passwd | grep 1000 | awk 'BEGIN { FS = ":" } ; { print $1 }'`
    cd /home/$username
    wget $deployserver$deployconfig/home.tar.gz
    # This archive is made by commands 
    # cd home && tar -czvf ../home.tar.gz .
    # to include also hidden (config) files 
    tar -xzvf home.tar.gz
    chown -R $username /home/$username
    rm home.tar.gz
    #
    # Additional system configs
    #
    wget $deployserver$deployconfig/10-service.rules -O /etc/udev/rules.d/10-service.rules
    wget $deployserver$deployconfig/service-blacklist.conf -O /etc/modprobe.d/service-blacklist.conf
    sed -i 's/#AutoLoginEnable=true/AutoLoginEnable=true/g' /etc/kde4/kdm/kdmrc
    sed -i 's/#AutoLoginAgain=true/AutoLoginAgain=true/g' /etc/kde4/kdm/kdmrc
    sed -i 's/#AutoLoginUser=fred/AutoLoginUser='$username'/g' /etc/kde4/kdm/kdmrc
    sed -i 's/"syntax on/syntax on/g' /etc/vim/vimrc
    exit 0
    


    If desired, in preceed.cfg you can generally set only the base system, and do the rest with this script. The advantage of this approach is that you will have a separate ready-made script that installs and configures the workplace on any working debian, and not just in the installer environment. Or maybe it already exists and it would be nice to use it instead of looking for the necessary keys in preseed.cfg. In this case, postinstall only downloads a full-fledged script, an example of which we just examined, and which will start after a reboot already in the installed system.

    For us personally, another reason for this particular two-step approach was the very slow execution of the script in the installer environment. For example, installing packages of approximately 600 MB from the repository on the local network plus unpacking the archive of the home directory takes more than a day. I could not find the reason for such a slow execution of the script, which on the same machine after the reboot works out in a matter of minutes and I will be very glad if someone from the experienced hawkers tells me where the dog rummaged here.
    The last line with the forced installation of the bootloader appeared here after the installer stubbornly did not want to install grub on some branded computer with preinstalled windows7.

    #!/bin/sh
    # Get firstboot script
    /usr/bin/wget -O /root/firstboot http://192.168.121.1/pxeinstall/firstboot
    chmod +x /root/firstboot
    # create a service that will run our firstboot script
    cat > /etc/init.d/firstboot <


    Само собой разумеется, в таком случае в нашем скрипте firstboot надо не забыть удалить себя после завершения работы:
    update-rc.d firstboot remove
    

    Заключение


    Вышеописанный метод разворачивания рабочих мест позволяет держать в одном месте все, что касается установки ОС — скрипты, конфиги, дополнительные файлы — что упрощает бекап и позволяет не искать флешку с правильной версией образа системы. Ну и этот метод достаточно гибок для того, чтобы просто и быстро изменить сценарий установки.

    С радостью рассмотрю ваши замечания и отвечу на появившиеся вопросы.

    Also popular now: