Installing any clone of Red Hat Enterprise Linux without using a standard installer
Installing a modern Linux system only needs to be done once, for both a single physical server and the deployment of an entire virtual farm. Why not spend a little more time on this and immediately do everything exactly as it should, and not finish what came from the installer along its rails. Moreover, the amount of software that is installed in the “minimal” mode of the standard installer does not correspond to the really minimal one.
Someone manual installation may seem like a waste of time, but every linuxid is obliged to do this at least once in order to better understand how it works. If you are not afraid of the words fdisk, grub and chroot, read on.
Installation of the operating system can be divided into 4 separate stages.
In most modern systems, tasks 1–3 are performed by installers. In semi-automated installers, items 1–3 are in question-answer mode. In the majority of automated ones, it is similar; just there is an opportunity to specify a previously prepared answer file.
Writing an installer is not a trivial task. This was always known to the guys from the Gentoo project, in which he had never been, and in the Arch Linux community, they recently decided to abandon the support of the installer in favor of more pressing tasks. It was understood even by Microsoft - the second stage in Windows Installer, starting with Vista, comes down to rolling an already pre-assembled image. In other matters, we are not talking about windows, this is the topic of another article.
By installing the OS manually, we have complete freedom of action at all stages. This article is naturally not the only correct instruction, it is a script for installing a “spherical server in a vacuum.” Specific objectives and conditions can significantly affect any of the steps. As an example, we will install Oracle Enterprise Linux 6 on a virtual machine running Microsoft Hyper-V . Not the freest combination of course, but that's not the point. By the way, this installation method does not require registration with Oracle. But for purists and adepts of Comrade Stallman, I suggest using KVM and installing CentOS or Scientific , which are almost 1: 1 clones of RHEL, so there is practically no difference in the installation for them. OEL has not many unique nuances. In addition to its kernel-uek, Oracle Linux also offers the kernel of its Django Fett , which has paravirtual firewood for Hyper-V devices and PnP disk forwarding.
')
In principle, any Linux or LiveCD is suitable for installation, rpm and yum are available for many platforms. But since we will have RHEL, it's best to use the fresh LiveCD RHEL-like distra of the same major version. It will be exactly rpm and yum compatible versions, which greatly simplifies the task. I chose the CentOS LiveCD , which can be downloaded from the nearest mirror .
In this example, the system storage will be a 10 Gb virtual disk connected to the VMke. All space, except for a small partition for the bootloader, will be handed over to LVM , which I consider to be the most stable volume management system on the Linux platform.
Boot from our LiveCD and climb into the terminal. If we plan to work with the virtual machine itself, it is convenient to use the graphical mode of loading the LiveCD. There is even Firefox, of course not the freshest.
But if we are already tuned to minimalism, well, or the machine doesn’t have a lot of RAM, we load into text mode, which can be selected in the bootloader. Raise the ssh server to be able to work in the terminal from your machine. For access you will need to change the root password and disable or configure the firewall.
We split our disk with fdisk , (parted, Red Hat Disk utility, hex editor, as you like :) into the necessary partitions. Personally, I like the time-tested fdisk. RHEL is a conservative system, fdisk works by default in the mode of compatibility with DO and Historical heritage, so we run it with special flags.
Create a 500M partition for the bootloader. This is a huge size for the boot partition, but we do not mind.
We expose her “bootable” flag so that the first stage of the loader knows exactly where to boot.
The rest of the space we give the second partition,
which, to simplify the definition of LVM groups at the boot stage, set type 8e (Linux LVM)
Create a file system for / boot. There are many fs from which the standard for the army of RHEL-clones GRUB can load. Even the old woman ext2 is enough, the log on the boot partition is not really needed - writing to it occurs only when installing new kernels and changing the boot loader configuration. I chose ext4 . Additionally, we specify the label for the new fs, which can then be used in mount and fstab .
We are preparing LVM on which our system will live
In the created group, select the root partition in 4G. This is more than enough for a minimal system, we will give 1G for the swap, which together with the new sections will be mounted to the Live system. The rest of the place gives you the freedom to create additional fs for / opt or / var, and you can also leave a reserve, which will allow you to use LVM snapshots
Information about all installed rpm packages is stored in a special database. For both rpm and yum, you can specify an alternative root fs, which allows us to install RHEL in any directory with a minimum number of commands. RPMDB - spine RHEL, create it for the new system.
The sources of the installation packages for yum are package repositories, links to which are located in the /etc/yum.repos.d/ configs. If there is a connection, this can be any public repository accessible via the Internet, your own, mounted from the network storage, or, if you can find installation disk images, you can use them. Like this:
If we want to install CentOS, it suffices to explicitly specify $ releasever in existing .repo files. These variables are taken from the distribution package of the distribution kit, which is not yet in the new system, so you have to take a bit of a sed
I need OEL, so yum will be tuned to Oracle's public repository
You can begin to install the system. Let's start with a completely “rudimentary” set of packages: release package, glibc, bash and their dependencies:
Such a system is ready to run as a chroot from any Linux. But we have other plans, so we put rpm and yum there with all the dependencies:
The remaining packages will be installed in the new system. Copy settings dns, yum repositories. Zabindim virtual fs our Live environment on the same path of the system and enter into it.
The first thing we see is the standard bash invitation. To bring it to normal RHEL, copy the bash settings from / etc / skel.
Put some basic software:
The set of software in the basic RHEL repositories is very limited, but fortunately there is EPEL , which is designed to solve this problem:
Since we use LVM, at any moment of the installation (for example now) we can make a snapshot of our fs - which will be a block replica of the base RHEL, or stage3 according to Gentoo terminology. It can be dumped to another repository. Or create an archive of FS snapshots by mounting it. On the basis of such a snapshot with minimal effort, you can create templates for OpenVZ and similar systems. All this is best done outside of chroot:
Prepare a table of file systems. For the root path, it’s safest to point out as a virtual device LVM, since the potential problems with naming when changing the configuration of the disk system of the machine are solved by “design”.
Configure the network by creating configuration files, as the anaconda installer usually does.
Create a new user with sudo rights and specify a password for it.
Set up a local time zone.
Put the greeting in motd.
Further, in principle, we can already configure the machine for a working task at our discretion, but I prefer to boot from it first:
Mount the boot partition and install the boot loader, its configuration manager, LVM management tools and the kernel
So that grubby could prescribe the kernels in the bootloader config, there is a little work to do. In addition to the symlink to the GRUB config, it needs at least one working entry in the config, which is used as a template. In the system installed in the standard way, the initial template generates anaconda. We should prepare a config manually, having specified just installed kernel and the necessary parameters to it. For example, quiet will remove the excessive verbosity of the kernel, and rhgb will launch the fake progress bar.
Reinstall the kernel to make sure that grubby is working and kernel updates will be added to the config correctly in the future. After that, we can delete the entry with our example from the config:
Install the bootloader on our disk
If for some reason the installation script did not work, grub can be installed on the disk manually.
Reboot into our system and start 4. Adjusting the system for work tasks . Their.
This creates sharpened templates for servers. Both universal, to the mercy of automation systems, and targeted, ready to scan with minimal configuration.
Someone manual installation may seem like a waste of time, but every linuxid is obliged to do this at least once in order to better understand how it works. If you are not afraid of the words fdisk, grub and chroot, read on.
Installation of the operating system can be divided into 4 separate stages.
- Preparing System Storage
- Installing and configuring system components
- Preparing the system for self-loading
- Adjusting the system for work tasks
In most modern systems, tasks 1–3 are performed by installers. In semi-automated installers, items 1–3 are in question-answer mode. In the majority of automated ones, it is similar; just there is an opportunity to specify a previously prepared answer file.
Writing an installer is not a trivial task. This was always known to the guys from the Gentoo project, in which he had never been, and in the Arch Linux community, they recently decided to abandon the support of the installer in favor of more pressing tasks. It was understood even by Microsoft - the second stage in Windows Installer, starting with Vista, comes down to rolling an already pre-assembled image. In other matters, we are not talking about windows, this is the topic of another article.
By installing the OS manually, we have complete freedom of action at all stages. This article is naturally not the only correct instruction, it is a script for installing a “spherical server in a vacuum.” Specific objectives and conditions can significantly affect any of the steps. As an example, we will install Oracle Enterprise Linux 6 on a virtual machine running Microsoft Hyper-V . Not the freest combination of course, but that's not the point. By the way, this installation method does not require registration with Oracle. But for purists and adepts of Comrade Stallman, I suggest using KVM and installing CentOS or Scientific , which are almost 1: 1 clones of RHEL, so there is practically no difference in the installation for them. OEL has not many unique nuances. In addition to its kernel-uek, Oracle Linux also offers the kernel of its Django Fett , which has paravirtual firewood for Hyper-V devices and PnP disk forwarding.
')
In principle, any Linux or LiveCD is suitable for installation, rpm and yum are available for many platforms. But since we will have RHEL, it's best to use the fresh LiveCD RHEL-like distra of the same major version. It will be exactly rpm and yum compatible versions, which greatly simplifies the task. I chose the CentOS LiveCD , which can be downloaded from the nearest mirror .
1. Preparation of system storage
In this example, the system storage will be a 10 Gb virtual disk connected to the VMke. All space, except for a small partition for the bootloader, will be handed over to LVM , which I consider to be the most stable volume management system on the Linux platform.
Boot from our LiveCD and climb into the terminal. If we plan to work with the virtual machine itself, it is convenient to use the graphical mode of loading the LiveCD. There is even Firefox, of course not the freshest.
But if we are already tuned to minimalism, well, or the machine doesn’t have a lot of RAM, we load into text mode, which can be selected in the bootloader. Raise the ssh server to be able to work in the terminal from your machine. For access you will need to change the root password and disable or configure the firewall.
$ sudo su
# service sshd start
# passwd root
# service iptables stop
We split our disk with fdisk , (parted, Red Hat Disk utility, hex editor, as you like :) into the necessary partitions. Personally, I like the time-tested fdisk. RHEL is a conservative system, fdisk works by default in the mode of compatibility with DO and Historical heritage, so we run it with special flags.
# fdisk -cu / dev / sda
Create a 500M partition for the bootloader. This is a huge size for the boot partition, but we do not mind.
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First sector (2048-20971519, default 2048):
Using default value 2048
Last sector, + sectors or + size {K, M, G} (2048-20971519, default 20971519): + 500M
We expose her “bootable” flag so that the first stage of the loader knows exactly where to boot.
Command (m for help): a
Partition number (1-4): 1
The rest of the space we give the second partition,
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First sector (1026048-20971519, default 1026048):
Using default value 1026048
Last sector, + sectors or + size {K, M, G} (1026048-20971519, default 20971519):
Using default value 20971519
which, to simplify the definition of LVM groups at the boot stage, set type 8e (Linux LVM)
Command (m for help): t
Partition number (1-4): 2
Hex code (type L to list): 8e
Create a file system for / boot. There are many fs from which the standard for the army of RHEL-clones GRUB can load. Even the old woman ext2 is enough, the log on the boot partition is not really needed - writing to it occurs only when installing new kernels and changing the boot loader configuration. I chose ext4 . Additionally, we specify the label for the new fs, which can then be used in mount and fstab .
# mkfs.ext4 / dev / sda1
# e2label / dev / sda1 boot
We are preparing LVM on which our system will live
# pvcreate / dev / sda2
# vgcreate system / dev / sda2
In the created group, select the root partition in 4G. This is more than enough for a minimal system, we will give 1G for the swap, which together with the new sections will be mounted to the Live system. The rest of the place gives you the freedom to create additional fs for / opt or / var, and you can also leave a reserve, which will allow you to use LVM snapshots
# lvcreate -n root -L 4G system
# mkfs.ext4 / dev / system / root
# e2label root! $
# lvcreate -n swap –L 1G system
# mkswap -f / dev / system / swap
# swapon! $
# mkdir -p / mnt / system / boot
# mount LABEL = root / mnt / system
# mount LABEL = boot / mnt / system / boot
2. Install and configure system components
Information about all installed rpm packages is stored in a special database. For both rpm and yum, you can specify an alternative root fs, which allows us to install RHEL in any directory with a minimum number of commands. RPMDB - spine RHEL, create it for the new system.
# rpm --root = / mnt / system –initdb
The sources of the installation packages for yum are package repositories, links to which are located in the /etc/yum.repos.d/ configs. If there is a connection, this can be any public repository accessible via the Internet, your own, mounted from the network storage, or, if you can find installation disk images, you can use them. Like this:
# yum install createrepo
# mkdir -p / mnt / iso / {1,2,3}
# mount -o loop /mnt/nas/install/oel-6.4-cd{1,2,3}.iso / mnt / iso / {1,2,3}
# createrepo / mnt / iso
If we want to install CentOS, it suffices to explicitly specify $ releasever in existing .repo files. These variables are taken from the distribution package of the distribution kit, which is not yet in the new system, so you have to take a bit of a sed
# sed -i.orig 's / $ releasever / 6 / g' /etc/yum.repos.d/*.repo
I need OEL, so yum will be tuned to Oracle's public repository
# mv /etc/yum.repos.d{,.orig}
# mkdir /etc/yum.repos.d
# cd! $
# wget public-yum.oracle.com/public-yum-ol6.repo
You can begin to install the system. Let's start with a completely “rudimentary” set of packages: release package, glibc, bash and their dependencies:
# yum --installroot = / mnt / system install oraclelinux-release glibc bash
Such a system is ready to run as a chroot from any Linux. But we have other plans, so we put rpm and yum there with all the dependencies:
# yum --installroot = / mnt / system install rpm yum
The remaining packages will be installed in the new system. Copy settings dns, yum repositories. Zabindim virtual fs our Live environment on the same path of the system and enter into it.
# cd / mnt / system
# cp /etc/resolv.conf ./etc/
# cp /etc/yum.repos.d/*.repo ./etc/yum.repos.d/
# mount -o bind / dev ./dev
# mount -o bind / sys ./sys
# mount -o bind / proc ./proc
# chroot ./
The first thing we see is the standard bash invitation. To bring it to normal RHEL, copy the bash settings from / etc / skel.
bash-4.1 # cp /etc/skel/.bash* / root /
bash-4.1 # source /root/.bashrc
Put some basic software:
- dhclient, among whose dependencies (besides OS logos in OEL :) there is also udev, an initialization system and even a firewall, which will bring our system closer to independence
- the cronie scheduler, which pulls postfix as an MTA and the rsyslog logger
- less, which, passwd, nc, telnet, which, man
- favorite shell, editor, other software at its discretion
The set of software in the basic RHEL repositories is very limited, but fortunately there is EPEL , which is designed to solve this problem:
rpm -i www.mirrorservice.org/sites/dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
yum install passwd dhclient openssh cronie vim-minimal netcat telnet
Since we use LVM, at any moment of the installation (for example now) we can make a snapshot of our fs - which will be a block replica of the base RHEL, or stage3 according to Gentoo terminology. It can be dumped to another repository. Or create an archive of FS snapshots by mounting it. On the basis of such a snapshot with minimal effort, you can create templates for OpenVZ and similar systems. All this is best done outside of chroot:
(livecd) # lvcreate -L1G -s -nstage3 system / root
(livecd) # xz / dev / system / stage3> /mnt/nas/templates/OEL6.4-minimal.bin.xz
(livecd) # mkdir / mnt / stage3
(livecd) # mount / dev / system / stage3! $
(livecd) # cd! $
(livecd) # tar -zvpf /mnt/nas/templates/OEL6.4-minimal.tar.gz ./
Prepare a table of file systems. For the root path, it’s safest to point out as a virtual device LVM, since the potential problems with naming when changing the configuration of the disk system of the machine are solved by “design”.
# vi / etc / fstab
LABEL = boot / boot ext4 noauto 1 1
/ dev / mapper / system-root ext4 defaults 1 2
Configure the network by creating configuration files, as the anaconda installer usually does.
# vi / etc / sysconfig / network
NETWORKING = yes
HOSTNAME = spoon.matrix.local
# vi / etc / sysconfig / network-scripts / ifcfg-eth0
DEVICE = eth0
BOOTPROTO = dhcp
ONBOOT = yes
Create a new user with sudo rights and specify a password for it.
useradd -u1337 -m -s / bin / zsh -G wheel morpheus
# echo "morpheus ALL = (ALL) ALL" >> /etc/sudoers.d/morpheus
# passwd morpheus
Set up a local time zone.
# ln -sf / usr / share / zoneinfo / Europe / Riga / etc / localtime
Put the greeting in motd.
# echo " there is no "> / etc / motd
# figlet -f mini spoon >>! $
Further, in principle, we can already configure the machine for a working task at our discretion, but I prefer to boot from it first:
3. Preparing the system for self-loading
Mount the boot partition and install the boot loader, its configuration manager, LVM management tools and the kernel
# mount / boot
# yum install grub grubby lvm2 kernel
So that grubby could prescribe the kernels in the bootloader config, there is a little work to do. In addition to the symlink to the GRUB config, it needs at least one working entry in the config, which is used as a template. In the system installed in the standard way, the initial template generates anaconda. We should prepare a config manually, having specified just installed kernel and the necessary parameters to it. For example, quiet will remove the excessive verbosity of the kernel, and rhgb will launch the fake progress bar.
# cd / etc
# ln -sf ../boot/grub/grub.conf
# cd / boot
# ln -sf grub.conf menu.lst
# vi grub.conf
timeout = 5
splashimage = (hd0,0) /grub/splash.xpm.gz
hiddenmenu
linux title
root (hd0,0)
kernel /vmlinuz-2.6.32-358.6.2.el6.x86_64 ro lvm root = / dev / mapper / system-root LANG = en_US.UTF-8
initrd /initramfs-2.6.32-358.6.2.el6.x86_64.img
Reinstall the kernel to make sure that grubby is working and kernel updates will be added to the config correctly in the future. After that, we can delete the entry with our example from the config:
# yum reinstall kernel
# vi grub.conf
Install the bootloader on our disk
# grub-install / dev / sda --no-floppy
If for some reason the installation script did not work, grub can be installed on the disk manually.
# grub
grub> root (hd0,0)
grub> setup (hd0)
Reboot into our system and start 4. Adjusting the system for work tasks . Their.
This creates sharpened templates for servers. Both universal, to the mercy of automation systems, and targeted, ready to scan with minimal configuration.
Source: https://habr.com/ru/post/182786/
All Articles