Network installation of workstations based on Debian GNU / Linux
Hello.
Automatic deployment of the workplace - the task, one can say, is typical. Surely many people decided it - starting from the network infrastructure andinstructions from 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 and other external hard drives, which for some reason I personally have the habit of regularly getting lost in the cracks of a working mess, do not read or be cleaned to write some incredibly necessary garbage.
')
If for you this state of affairs seems close and familiar - welcome under cat.
For the network installation to work, you first need a configured DHCP and TFTP server. Unfortunately, I cannot now remember 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.
For the dhcp server, you must specify the interface to use in / etc / default / isc-dhcp-server and set the settings for your network in /etc/dhcp/dhcpd.conf. For the 192.168.121.0/24 network and the eth0 interface, it looks like this:
It goes without saying that you may have other parameters and settings. The only line we are interested in here is the penultimate one, where the name of the file that will be transmitted via tftpd over the network for initial loading of the created system is indicated.
I left tftpd on the 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.
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 search of a bootable flash drive / compact, but not really, so go to the next part of our automation - creating a so-called “answer file” for all questions of the installer.
The response file can be embedded in the initrd, can be placed on external media, or 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 reassemble the initrd), or 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, you need to add the auto and url parameters to the last line (which starts with append). As a result, the file will be about the following
If desired, you can also change the timeout 0 in the configuration of the menu to timeout 5, for example, and save yourself the trouble of pressing “Enter” before starting the installation. Personally, I returned the “eternal” timeout after a neighbor, who was upset with feelings, ran to me, who sent a reboot to restart the car and went out to smoke, and when he returned, he saw the newly installed Debian instead of the favorite “sevens”. My exhortations that the newly installed system, too, of the seventh version did not comfort him :(
Of course, on the appropriate host, you need a web server with a pxeinstall directory, which is still useful to us. Here I didn’t think of anything - apache was already standing for internal needs. If you do not have a web server yet, the command
should solve this problem. So go to writing answers.
The official sample file can be found here . You can also get a ready-made response file for your system by running the command
And with the help
You will supplement this file with all the answers that you gave when installing additional software.
True, I somewhere met the statement that the file obtained in this way can work incorrectly and, as a result, the recommendation to correct the original file to fit my needs, using my.preseed.cfg only as a hint.
In general, the study and editing of this file is not a problem - everything is well commented; the necessary values ​​of the necessary parameters can be found in the file that generated debconf. And yet there are several nuances that I would like to dwell upon.
There are two ways to carry out a breakdown of disks at this stage - select the preset automatic splitting option, or set the size of the partitions manually. Three pre-installed options - all files on one partition; a separate partition under / home and a separate partition under / home, / tmp, / usr and / var. Specified in the answer file line
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, which traditionally allocates a separate section for service needs, so
In short, what is what.
boot-root is some kind of a witch, without which the whole 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 size of the section, the priority for the section calculation algorithm, and the maximum size of the section. The size is indicated in megabytes, while at the breakdown it will be trimmed according to the size of the cylinder. In addition to integer values, you can also use a percentage of the size of RAM. Variants of the type “2000 + 50%” are also allowed, that is 2000MB + half RAM. Priority is a conditional "mid-ceiling" number. The lower it is, the smaller the size of the partition will be closer to the minimum value. It is recommended that one of the sections indicate the maximum size of a larger one, but not more than 1,000,000,000 so as not to run into overflow: on i386 integer arithmetic is limited to 31 bits. The remaining value is, of course, the file system type.
The $ primary {} and $ bootable {} specifiers indicate respectively that the partition being created will be primary and / or bootable. method {format} must be specified if the partition will be formatted. In addition to “format”, “swap” values ​​for the swap partition and “keep” to keep the partition intact can also be used. If method {format} is specified, you must also additionally set another format {} specifier. The following use_filesystem {} and filesystem {ext4} specifiers determine in which file system the partition will be formatted. The last specifier used - mountpoint - defines the mount point of the partition being created. It is crowned with a good dot symbol, which separates the descriptions of sections from each other.
All these parameters should be specified in one line, which makes editing or searching for an error a rather fun exercise, so we traditionally use beksleshy to make our markup more or less friendly.
A more detailed description of the disk layout process, including lvm, raid and other joys, can be found here and here .
Despite the fact that using the answer file, you can fully automate the process of installing the system, yet there remain tasks that it does not solve. This is a variety of configs edits, and a standard set of documents / settings that the user should have at hand, and of course theseals corporate logo on the desktop. To solve this problem, I use the ability to execute any command after installing the system, but with the / target still mounted:
Ie, just download 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 along with all the necessary settings is rolled out to the user.
If desired, in the preceed.cfg you can generally put only the base system, and do everything else from this script. The advantage of this approach is that you have a separate ready-made script that installs and configures the workstation on any working debian, and not only in the installer environment. Or maybe he already has it and it would be nice to use it instead of looking for the necessary keys in preseed.cfg. In this case, the postinstall only downloads a full-fledged script, an example of which we have just reviewed, and which will start after a reboot already in the installed system.
For us personally, another reason for just such a two-step approach was the very slow execution of the script in the installer environment. For example, installing packages of about 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 a reboot, works in a matter of minutes and will be very happy if someone from experienced habrazhiteley tells you where the dog rummaged.
The last line with the forced installation of the bootloader appeared here after the installer stubbornly refused to install grub on some branded computer with windows7 preinstalled.
Needless to say, in this case, in our firstboot script, you need to remember to delete yourself after completing the work:
The above method for deploying workstations allows you to keep everything in one place as regards OS installation - scripts, configs, additional files - which simplifies backup and allows you not to search for a USB flash drive with the correct version of the system image. Well, this method is flexible enough to simply and quickly change the installation script.
We are happy to review your comments and answer the questions that appear.
Automatic deployment of the workplace - the task, one can say, is typical. Surely many people decided it - starting from the network infrastructure and
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 and other external hard drives, which for some reason I personally have the habit of regularly getting lost in the cracks of a working mess, do not read or be cleaned to write some incredibly necessary garbage.
')
If for you this state of affairs seems close and familiar - welcome under cat.
Wednesday deployment
For the network installation to work, you first need a configured DHCP and TFTP server. Unfortunately, I cannot now remember 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 the dhcp server, you must specify the interface to use in / etc / default / isc-dhcp-server and set the settings for your network in /etc/dhcp/dhcpd.conf. For the 192.168.121.0/24 network and the eth0 interface, it looks 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 parameters and settings. The only line we are interested in here is the penultimate one, where the name of the file that will be transmitted via tftpd over the network for initial loading of the created system is indicated.
I left tftpd on the 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 search of a bootable flash drive / compact, but not really, so go to the next part of our automation - creating a so-called “answer file” for all questions of the installer.
Answers and questions
The response file can be embedded in the initrd, can be placed on external media, or 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 reassemble the initrd), or 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, you need to add the auto and url parameters to the last line (which starts with append). As a result, the file will be about 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 the timeout 0 in the configuration of the menu to timeout 5, for example, and save yourself the trouble of pressing “Enter” before starting the installation. Personally, I returned the “eternal” timeout after a neighbor, who was upset with feelings, ran to me, who sent a reboot to restart the car and went out to smoke, and when he returned, he saw the newly installed Debian instead of the favorite “sevens”. My exhortations that the newly installed system, too, of the seventh version did not comfort him :(
Of course, on the appropriate host, you need a web server with a pxeinstall directory, which is still useful to us. Here I didn’t think of anything - apache was already standing for internal needs. If you do not have a web server yet, the command
aptitude install apache2 && mkdir /var/www/pxeinstall should solve this problem. So go to writing answers.
The official sample file can be found here . You can also get a ready-made response file for your system by running the command
debconf-get-selections --installer > my.preseed.cfg And with the help
debconf-get-selections >> my.preseed.cfg You will supplement this file with all the answers that you gave when installing additional software.
True, I somewhere met the statement that the file obtained in this way can work incorrectly and, as a result, the recommendation to correct the original file to fit my needs, using my.preseed.cfg only as a hint.
In general, the study and editing of this file is not a problem - everything is well commented; the necessary values ​​of the necessary parameters can be found in the file that generated debconf. And yet there are several nuances that I would like to dwell upon.
Disk partitioning
There are two ways to carry out a breakdown of disks at this stage - select the preset automatic splitting option, or set the size of the partitions manually. Three pre-installed options - all files on one partition; a separate partition under / home and a separate partition under / home, / tmp, / usr and / var. Specified in the answer file line
di 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, which traditionally allocates a separate section for service needs, so
di 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 a witch, without which the whole 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 size of the section, the priority for the section calculation algorithm, and the maximum size of the section. The size is indicated in megabytes, while at the breakdown it will be trimmed according to the size of the cylinder. In addition to integer values, you can also use a percentage of the size of RAM. Variants of the type “2000 + 50%” are also allowed, that is 2000MB + half RAM. Priority is a conditional "mid-ceiling" number. The lower it is, the smaller the size of the partition will be closer to the minimum value. It is recommended that one of the sections indicate the maximum size of a larger one, but not more than 1,000,000,000 so as not to run into overflow: on i386 integer arithmetic is limited to 31 bits. The remaining value is, of course, the file system type.
The $ primary {} and $ bootable {} specifiers indicate respectively that the partition being created will be primary and / or bootable. method {format} must be specified if the partition will be formatted. In addition to “format”, “swap” values ​​for the swap partition and “keep” to keep the partition intact can also be used. If method {format} is specified, you must also additionally set another format {} specifier. The following use_filesystem {} and filesystem {ext4} specifiers determine in which file system the partition will be formatted. The last specifier used - mountpoint - defines the mount point of the partition being created. It is crowned with a good dot symbol, which separates the descriptions of sections from each other.
All these parameters should be specified in one line, which makes editing or searching for an error a rather fun exercise, so we traditionally use beksleshy to make our markup more or less friendly.
A more detailed description of the disk layout process, including lvm, raid and other joys, can be found here and here .
Expanding opportunities
Despite the fact that using the answer file, you can fully automate the process of installing the system, yet there remain tasks that it does not solve. This is a variety of configs edits, and a standard set of documents / settings that the user should have at hand, and of course the
di 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" Ie, just download 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 along with all the necessary settings is rolled out to the user.
#!/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 the preceed.cfg you can generally put only the base system, and do everything else from this script. The advantage of this approach is that you have a separate ready-made script that installs and configures the workstation on any working debian, and not only in the installer environment. Or maybe he already has it and it would be nice to use it instead of looking for the necessary keys in preseed.cfg. In this case, the postinstall only downloads a full-fledged script, an example of which we have just reviewed, and which will start after a reboot already in the installed system.
For us personally, another reason for just such a two-step approach was the very slow execution of the script in the installer environment. For example, installing packages of about 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 a reboot, works in a matter of minutes and will be very happy if someone from experienced habrazhiteley tells you where the dog rummaged.
The last line with the forced installation of the bootloader appeared here after the installer stubbornly refused to install grub on some branded computer with windows7 preinstalled.
#!/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 <<EOF ### BEGIN INIT INFO # Provides: firstboot # Required-Start: $networking # Required-Stop: $networking # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: A script that runs once # Description: A script that runs once ### END INIT INFO cd /root /usr/bin/nohup sh -x /root/firstboot & EOF chmod +x /etc/init.d/firstboot update-rc.d firstboot defaults 99 grub-install --recheck --no-floppy /dev/sda Needless to say, in this case, in our firstboot script, you need to remember to delete yourself after completing the work:
update-rc.d firstboot remove Conclusion
The above method for deploying workstations allows you to keep everything in one place as regards OS installation - scripts, configs, additional files - which simplifies backup and allows you not to search for a USB flash drive with the correct version of the system image. Well, this method is flexible enough to simply and quickly change the installation script.
We are happy to review your comments and answer the questions that appear.
Source: https://habr.com/ru/post/231967/
All Articles