[2024-feb-29] Sad news: Eric Layton aka Nocturnal Slacker aka vtel57 passed away on Feb 26th, shortly after hospitalization. He was one of our Wiki's most prominent admins. He will be missed.

Welcome to the Slackware Documentation Project

¡Esta es una revisión vieja del documento!


En proceso de traducción. Victor

Instale Slackware en un servidor de BareMetal Dedibox de online.net

Este tutorial explica cómo instalar y arrancar Slackware Linux en online.net Dedibox BareMetal Server Start Family. Se centra en los servidores a los que no tiene acceso físico y aquellos que no admiten la exposición remota del hardware (es decir, no hay KVM sobre IP). La configuración de este tipo de servidores es posible a través de Web interface. Afortunadamente o no, esta interfaz no admite de forma nativa la instalación de Slackware. No te preocupes, nos las arreglaremos sin embargo.

Aunque las primeras partes del tutorial son específicas del servidor Dedibox, el resto es más genérico. Esto significa que la información proporcionada aquí se aplica por igual a otras ofertas de alojamiento, que solo deben proporcionar un sistema operativo de rescate similar (más información sobre el sistema operativo de rescate más abajo). Por el contrario, las primeras partes se aplican bien a las distribuciones de Linux que no sean Slackware. Si necesita un control detallado sobre el proceso de instalación en el servidor Dedibox, está en un buen lugar.

1. Dedibox rescue OS

El sistema operativo de rescate es un sistema operativo en el que puede iniciar su servidor utilizando la interfaz web. Este sistema operativo le permite realizar tareas de mantenimiento, si su sistema operativo principal no se inicia o si necesita acceder al servidor, mientras pasa por alto su sistema operativo principal. Hay varias versiones del sistema operativo de rescate para elegir; estaremos usando uno basado en Linux.

Puede (y debe) conectarse al sistema operativo de rescate a través de SSH. Una de las características del sistema operativo de rescate es que es volátil, lo que significa que los cambios realizados en él se pierden después del reinicio. Pero lo que es más importante, las claves de host SSH se regeneran cada vez que se inicia el sistema operativo de rescate, lo que hace que la huella dactilar de la clave del host SSH también se modifique, cada vez que reinicie. Esto hace que la verificación de la autenticidad del servidor sea un poco incómoda.

Una de las formas de verificar la autenticidad del host es abrir el ticket de soporte técnico de online.net, solicitando que se le proporcione la huella digital clave del host del sistema de rescate. Y debido a que la huella digital cambia con cada reinicio, no es deseable reiniciar la máquina durante la instalación de Slackware. No es un gran drama, es posible instalar con éxito y luego arrancar Slackware en todo su esplendor con solo un reinicio al final del viaje. También puede conectarse sin asegurarse de la autenticidad del host, tener un juego e incluso una instalación de prueba. Una vez que esté familiarizado con el entorno, puede reiniciar nuevamente en el sistema operativo de rescate, solicitar asistencia técnica para la huella digital, limpiar el disco duro y realizar la instalación y configuración final. Solo ten en cuenta que sin verificar la autenticidad del host, eres susceptible a los ataques MITM. Aunque el sistema de archivos de rescate es volátil y puede limpiar el contenido del disco para asegurarse de que esté limpio y seguro, aún así, el propio hardware podría ser el objetivo del ataque. Y hoy en día, el hardware en realidad está ejecutando software (firmware) más a menudo.

Afortunadamente, existe un método alternativo que no implica el compromiso del soporte técnico. Puede leer los detalles completos en LinuxQuestions.org: Verificación de la autenticidad del host (SSH) después de iniciar sesión, por encima del terminal en serie seguro y accesible. En el tutorial en sí, solo me centraré en cómo hacer las cosas.

2. Consola serial

La interfaz web proporciona una opción de consola serie, que le permite interactuar con el hardware del servidor. Es de uso limitado con el sistema operativo de rescate (es decir, no es posible iniciar sesión), pero se puede utilizar completamente con el sistema operativo principal. Si se configura correctamente, le permitirá ver el proceso de arranque del sistema operativo principal y también tener un inicio de sesión de terminal, en caso de que la conexión SSH no esté disponible por cualquier motivo. (Pero no esperes nada lujoso, es solo una consola serie después de todo).

Resulta que, en realidad, es posible iniciar sesión en el sistema operativo de rescate utilizando la consola serie. Al menos funciona cuando se selecciona Ubuntu 16.04 amd64 como sistema operativo de rescate. Desafortunadamente, este tutorial fue escrito con el supuesto de que no era posible (¡lo que en realidad fue el caso!). Por esa razón, algunos pasos son más complejos de lo que serían si la consola en serie estuviera disponible desde el principio. Esto se aplica especialmente al paso de verificación de autenticidad SSH del servidor. Desafortunadamente, no actualizaré el tutorial para dar cabida a este descubrimiento.

3. Hacer que el sistema operativo de rescate esté disponible

Si acaba de comprar un servidor nuevo, debe venir sin un sistema operativo preinstalado. Desafortunadamente, significa también que el sistema operativo de rescate no está disponible todavía.

Para habilitar el sistema operativo de rescate: mediante la interfaz web, vaya a la página de administración de su servidor: ServerServer list(server name) Manage. Si la única opción que ve es [INSTALL] , entonces el sistema operativo de rescate no está disponible y primero debe instalar uno de los sistemas operativos ofrecidos. (Nota de Purist: elija sabiamente el sistema operativo, ya que el ícono asociado con este sistema operativo representará su sistema Slackware a partir de entonces). Una vez que se complete la instalación del sistema operativo, se le presentarán más opciones: [REBOOT] , [RESCUE] , [SERIAL_CONSOLE] y [INSTALL] . Estás listo para irte ahora. Simplemente no arranques el sistema operativo de rescate todavía.

4. Preparando el acceso del sistema operativo de rescate a través de SSH

Tenga cuidado de no sobrescribir las claves SSH de su estación de trabajo en ~/.ssh

Ahora estamos a punto de crear dos pares de claves SSH. Se usará un par para iniciar sesión en el sistema operativo de rescate y el otro (solo parte de la clave pública) para la autenticación del sistema operativo de rescate. Escriba lo siguiente en su estación de trabajo:

$ mkdir dedibox_rescue_os_keys
$ cd dedibox_rescue_os_keys
$ ssh-keygen -t rsa -f login_key -N ''
$ ssh-keygen -t rsa -f auth_key -N ''

Mediante la interfaz web, vaya a la página de administración de claves SSH: inicie sesión como (username) SSH keys y agregue auth_key.pub y login_key.pub public llaves. Tenga en cuenta que después de la adición exitosa, la página no se actualiza automáticamente y para ver las claves, debe hacer clic en el enlace SSH keys en el lado izquierdo.

Cargar las claves a través de la interfaz web tiene el efecto de ponerlas a disposición del sistema operativo de rescate. Cuando se inicia el sistema operativo de rescate, las claves simplemente se agregan al archivo ~/.ssh/authorized_keys para el usuario en particular.

Estas claves pueden eliminarse de manera segura de la interfaz web una vez que haya terminado con la instalación de Slackware.

5. Arrancar y conectarse al sistema operativo de rescate

Usando la interfaz web, vaya a la página de administración de su servidor: ServerServer list(server name) Manage. Habilite la consola serie haciendo clic en el botón [SERIAL_CONSOLE] y siga la guía. La consola se abrirá en una nueva pestaña del navegador. Tenga en cuenta que la conexión de la consola tiene un tiempo de caducidad, por lo que no se quedará allí para siempre. Además, no aparecen muchos mensajes relacionados con el arranque del sistema operativo de rescate, pero sigue siendo mejor que nada. El OS Rescue tarda un tiempo en iniciarse y poder verlo puede permitirle calmarse un poco (solo tenga en cuenta que hay un tiempo entre el momento en que los mensajes dejan de aparecer y el momento en que realmente puede conectarse a través de SSH). La razón por la que necesita iniciar [SERIAL_CONSOLE] antes de [RESCUE] es que el botón [SERIAL_CONSOLE] desaparece una vez que inicie el sistema operativo de rescate.

Aún es posible acceder a la consola serie, incluso si el botón [SERIAL_CONSOLE] no está visible. Solo tiene que ir a https://console.online.net/en/server/state/XXXXX/bmc address, reemplazando XXXXX parte con el número real de su servidor.

Ahora vuelva a la página de administración del servidor y haga clic en “[RESCUE]'”. Cuando se le solicite la selección del sistema operativo, seleccione [Ubuntu_16.04_amd64] y luego haga clic en [CLICK_HERE_TO_LAUNCH_THE_RESCUE_SYSTEM] . Después de un tiempo, se le presentarán los detalles necesarios para conectarse al sistema operativo de rescate a través de SSH. También puede cambiar a la ventana de salida [SERIAL_CONSOLE] para monitorear lo que está sucediendo.

Una vez que el sistema operativo de rescate esté completamente iniciado, conéctese desde su estación de trabajo:

$ ssh username@x.y.z.w -i ./login_key

Cuando se le pregunte Are you sure you want to continue connecting (yes/no)?, responda que sí.

Podría ser una buena idea agregar temporalmente la huella dactilar del host del SSH de rescate al archivo / /.ssh/known_hosts en su estación de trabajo. Esto le permitirá volver a iniciar sesión (por ejemplo, en el caso de una conexión rota) en el sistema operativo de rescate sin la necesidad de repetir el procedimiento de autenticación que se describe a continuación. Solo recuerde eliminar la huella digital una vez que haya terminado o si el procedimiento de autenticación descrito a continuación falla.

Una vez que haya iniciado sesión, para autenticar el sistema operativo de rescate, en el lado del servidor escriba lo siguiente:

$ cat ~/.ssh/authorized_keys

y luego compare las claves públicas impresas en el terminal con las claves públicas auth_key.pub y login_key.pub que generó anteriormente. Si las dos claves entre el servidor y la estación de trabajo coinciden, está seguro de ir. (Una vez más, si desea comprender los detalles, consulte el LinuxQuestions.org mencionado anteriormente thread).

Ahora, en el lado del servidor, le sugiero que primero inicie el programa screen y luego inicie sesión como root (la contraseña se encuentra en la página de detalles de la conexión del sistema operativo de rescate):

$ screen
$ sudo su -

(Siendo paranoico, cambio las contraseñas de usuario y root proporcionadas poronline.net).

No entraré en detalles del programa screen , pero la razón por la que queremos usarlo es su capacidad para mantener abierto el terminal remoto, incluso si la conexión SSH (o más bien la red) se interrumpe o si cierra accidentalmente la Ventana. Normalmente, tal evento rompería el proceso de instalación. Si eso le sucede a usted, y utiliza screen , puede recuperar el terminal remoto (¡con todos los comandos iniciados aún en ejecución!), Simplemente conectándose a través de SSH y luego volviendo a conectar el llamado screen sesión:

$ screen -r
$ # Sometimes, detaching the session first is needed:
$ screen -rd SESSION_PID

Todo lo anterior significa también que no puede detener la ejecución remota de comandos simplemente cerrando la ventana del terminal local; screen sesión se mantendrá en el extremo remoto hasta que la cierre explícitamente. Por cierto, también puede usar esta funcionalidad para reducir el tráfico de red durante la fase de instalación, es decir, una vez que los paquetes se empezaron a instalar y no necesitan atención, puede desconectarse de la sesión y volver a adjuntarla un tiempo más tarde para verificar el estado. Utiliza la combinación de teclado Ctrl+A D para separar de screen sesión. Verifique en Internet cómo usar el programa screen (la página de manual es en realidad enormemente larga).

6. Configuración del entorno del instalador de Slackware (chroot)

La principal motivación detrás de este HOWTO es el hecho de que online.net no proporciona un método directo de instalación de Slackware en sus servidores Dedibox. Y eso es genial! El punto es, si tal método existiera, sería algo desconocido para un usuario de Slackware: un instalador basado en GUI / Web. Mientras que ser colocado en el shell del instalador de Slackware le permite instalar y configurar el sistema de la manera que desee (TM). Todas las opciones avanzadas están disponibles sin mucha molestia. Y vamos a usarlos todos. : - ^

El procedimiento detallado a continuación es conocido y común. Vamos a chroot a desempacar Slackware initrdimage y ejecutamos setup desde allí.
Nuestro Slackware chroot se quedará sin el sistema operativo de rescate de Ubuntu, que se está quedando sin sistema de archivos basado en RAM. El tamaño del sistema de archivos RAM es de ~ 8.0 GiB (que depende de la cantidad total de RAM del sistema). Sugerencia: 8.0 GiB es más que suficiente para mantener el árbol completo de paquetes de Slackware, si es necesario (es decir, si desea descargar los paquetes antes de ejecutar setup ).

Ahora, vamos a configurar el instalador de Slackwarechroot:

$ mkdir -p ~/slackware-chroot
$ cd ~/slackware-chroot
$ wget https://slackware.osuosl.org/slackware64-14.2/isolinux/initrd.img
$ gunzip -cd initrd.img | cpio -dvim
$ mount --bind /proc proc
$ mount --bind /sys sys
$ mount --bind /dev dev
$ mount --bind /dev/pts dev/pts
$ mount --bind /run run
$ touch etc/resolv.conf
$ mount --bind /etc/resolv.conf etc/resolv.conf

And run the chroot:

$ chroot ~/slackware-chroot /bin/bash --login
$ cd
El montaje de /etc/resolv.conf proporciona DNS a chroot.

Una vez que haya chrooted, es posible que desee jugar con la variable de entorno TERM , que influirá en la forma en que se muestran dialogs. De forma predeterminada, TERM = linux y no funciona bien si usa screen o si se conecta desde un emulador de terminal que se ejecuta bajo X.

Para obtener los mejores resultados con screen, use lo siguiente:

$ export TERM=screen

y si no usa screen , pero se está conectando desde X:

$ export TERM=xterm

Finalmente, para el terminal virtual (VT), deje el valor predeterminado:

$ export TERM=linux

Welcome to the Slackware Linux installation disk!

7. Particionamiento

Ahora puede particionar el disco a su gusto, con dos excepciones. En este tutorial, usaré una partición separada para ser montada en el directorio /boot . Este directorio contendrá los archivos de configuración del kernel, initrd y bootloader. Lo que nos lleva a la segunda excepción: como gestor de arranque, voy a usar syslinux instalado en MBR, lo que significa que el disco tiene que usar el tipo de etiqueta MBR. Si necesitas GPT, estás por tu cuenta. ;-)

El sistema de archivos de la partición / boot debe ser compatible con syslinux . ext4 hará el trabajo bien. Y cuando se trata del tamaño, 128 MiB es suficiente.

Las siguientes instrucciones destruirán los datos en el disco..

Puede usar su herramienta de partición favorita, por ejemplo, fdisk , cfdisk , etc. Voy a utilizar parted . Tenga en cuenta que el disco debe estar en estado “unmanaged”, es decir, los servicios como LVM2 o el software RAID (mdadm) deben estar desactivados. Tuve muchos dolores de cabeza al liberar el disco desde el control de LVM2, cuando estaba jugando con él (pero lo logré ;-)).

Por cierto, el disco ya contendrá la tabla de particiones, que se creó cuando instalamos uno de los sistemas operativos de reserva para habilitar el sistema operativo de rescate. La tabla de particiones se puede limpiar con los siguientes comandos:

$ dd count=1 bs=512 conv=notrunc if=/dev/zero of=/dev/sda
$ partprobe

Los siguientes comandos parted crearán la etiqueta MBR y la partición / boot:

$ parted /dev/sda mklabel msdos
$ # Start at 1 MiB in the hope of a correct alignment:
$ parted -a optimal /dev/sda mkpart primary 1MiB 129MiB
$ # Set bootable flag:
$ parted /dev/sda set 1 boot on

Con la partición / boot [/dev/sda1] en su lugar, puede particionar el espacio restante de la forma que mejor se adapte a sus necesidades. Voy a usar LVM2 para administrar el disco, así que creo una partición grande [/dev/sda2 ] que se pasará a LVM2. El procedimiento de configuración para habilitar LVM2 se describe en Apéndice A. El siguiente comando parted creará la partición requerida:

$ # Passing "-a optimal" automatically aligns at the last sectors of the disk.
$ # The start and end offsets have to be given explicitly:
$ parted -a optimal /dev/sda mkpart primary 129MiB 100%
$ # Set the 'lvm' flag only if you plan to use LVM2 for managing the disk.
$ parted /dev/sda set 2 lvm on

Informe al kernel sobre los cambios de partición:

$ partprobe

Vamos a verificar el resultado:

$ parted /dev/sda print
Model: ATA SAMSUNG MZ7LN256 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  135MB  134MB  primary  ext4         boot
 2      135MB   256GB  256GB  primary               lvm

8. Instalación de Slackware (programa de instalación)

Si prefiere descargar los paquetes requeridos por usted mismo, en lugar de dejar que el programa setup lo haga por usted (en realidad lo prefiero así), ahora es el momento.

Quiero usar rsync para descargar los paquetes de antemano. Como Slackware chroot no proporciona el comando rsync , debemos dejar Slackware chroot por un momento, usar rsync del sistema operativo de rescate de Ubuntu y luego regresar:

$ # Exit from Slackware chroot:
$ exit
$ mkdir -p ~/slackware-chroot/packages
$ cd ~/slackware-chroot/packages
$ # Download only: a, ap, d, l, n packages series (I don't need GUI apps),
$ # pay !attention! to the "." at the end of command line:
$ rsync -vaz rsync://rsync.osuosl.org/slackware/slackware64-14.2/slackware64/{a,ap,d,l,n} .
$ wget https://slackware.osuosl.org/slackware64-14.2/slackware64/CHECKSUMS.md5
$ # Verify the checksums of the downloaded packages:
$ grep -P "\./(a|ap|d|l|n)/" CHECKSUMS.md5 | md5sum -c --quiet
$ mkdir -p ~/slackware-chroot/patches
$ cd ~/slackware-chroot/patches
$ Download patches, pay !attention! to the "." at the end of command line:
$ rsync -vaz rsync://rsync.osuosl.org/slackware/slackware64-14.2/patches/packages .
$ wget https://slackware.osuosl.org/slackware64-14.2/patches/CHECKSUMS.md5
$ # Verify the checksums of the downloaded patches:
$ grep -P "\./packages" CHECKSUMS.md5 | md5sum -c --quiet
$ # Return to Slackware chroot:
$ chroot ~/slackware-chroot /bin/bash --login
$ cd
$ # Remember to update TERM as described earlier:
$ export TERM=screen

Teniendo todas las particiones en su lugar, ahora es el momento de ejecutar el programa setup y realizar la instalación como lo sabe. Solo recuerde formatear y montar la partición / boot cuando se le solicite mediante setup . Cuando se le solicite, omita LILO instalación, ya que vamos a utilizar syslinux en su lugar. Si descargó los paquetes de antemano, dirija configuración al directorio / paquetes premontado. De lo contrario, use setup para descargar los paquetes por usted.

No reinicie la máquina cuando el programa de instalación se ofrezca al final de la instalación.

9. Chroot recién instalado de Slackware

Sí, uno más chroot para tratar. ;-) La configuración del sistema recién instalado se realiza mejor desde el propio sistema. Y vamos a hacer exactamente eso. Cuando el programa setup terminó su trabajo, dejó el sistema de archivos raíz de Slackware (y algunos más) montado en / mnt . Y no hay nada que nos impida desde chrooting a este directorio, lo que significa que realmente podemos “iniciar sesión” en el sistema recién instalado sin reiniciar.

Este sistema es de alguna manera limitado (es decir, no hay servicios en ejecución), pero tiene todas las herramientas necesarias para realizar los pasos de configuración finales antes de reiniciar el servidor.

Para evitar sorpresas desagradables, montamos algunos sistemas de archivos posiblemente necesarios, antes de chrooting :

$ cd /mnt
$ mount --bind /run run
$ mount --bind /dev/pts dev/pts
$ # Only needed if you downloaded the patches and want to apply them:
$ mkdir run/patches
$ mount --bind /patches/packages run/patches
$ # Enter Slackware Chroot (tm):
$ chroot /mnt /bin/bash --login
$ cd
$ # Remember to update TERM as described earlier:
$ export TERM=screen

10. Applying patches

The following set of commands will apply all the available patches and let you know of any .new files to deal with:

$ find /run/patches -name \*.txz -exec upgradepkg {} \;
$ find /etc -name \*.new

11. Bootloader (syslinux)

The following set of commands will install the syslinux bootloader:

$ extlinux --install /boot
$ dd count=1 bs=440 conv=notrunc if=/usr/share/syslinux/mbr.bin of=/dev/sda

Then, create the syslinux config file:

$ cat << EOF > /boot/syslinux.cfg
PROMPT  0
TIMEOUT 0
DEFAULT vmlinuz-generic
SERIAL  1 9600

LABEL vmlinuz-generic
  KERNEL vmlinuz-generic
  APPEND console=ttyS1,9600 printk.time=0 quiet ipv6.disable=1 ro
  INITRD initrd-generic.gz
EOF

This configuration will enable the messages to appear on the serial console. I also specify some kernel parameters (printk.time=0 quiet) to considerably silence its output (error messages would still appear). As I do not want to bother with IPv6, I disable it at kernel level (ipv6.disable=1). As you can see, we will be using the generic kernel with initrd. This is the only way (that is, by means of initrd) the LVM2 can be made functional.

Note that the kernel and initrd paths specified in syslinux.cfg have to be relative to the /boot directory. This is because syslinux is unable to read from LVM2 based root partition, so something like /boot/vmlinuz-generic would not work (/ is on LVM2 partition in my case).

12. Initial RAM disk (initrd)

Create the initrd config file:

$ cat << EOF > /etc/mkinitrd.conf
# mkinitrd.conf
# See "man mkinitrd.conf" for details on the syntax of this file
#
#SOURCE_TREE="/boot/initrd-tree"
#CLEAR_TREE="0"
OUTPUT_IMAGE="/boot/initrd-generic.gz"
KERNEL_VERSION="$( readlink /boot/vmlinuz-generic | rev | cut -f1 -d- | rev )"
#KEYMAP="us"
MODULE_LIST="ext4"
#LUKSDEV="/dev/sda2"
#LUKSKEY="LABEL=TRAVELSTICK:/keys/alienbob.luks"
ROOTDEV="/dev/vg0/rootfs"
ROOTFS="ext4"
#RESUMEDEV="/dev/sda2"
#RAID="0"
LVM="1"
#UDEV="1"
#MODCONF="0"
#MICROCODE_ARCH="/boot/intel-ucode.cpio"
WAIT="0"
EOF

As the comment says, refer to the mkinitrd.conf man page for details. ;-) In particular, make sure your MODULE_LIST, ROOTDEV and ROOTFS are defined correctly. If you don't need LVM2 support, you can set LVM=“0” (or comment it out).

The notable thing is how the KERNEL_VERSION is automatically derived, not for the running kernel, but rather for the installed kernel (which might be newer or older than the running one). /etc/mkinitrd.conf is sourced by the /sbin/mkinitrd script, so it is possible to use shell commands within the config file. On standard Slackware installation, you will find that /boot/vmlinuz-generic is actually a symlink:

$ ls -l /boot/vmlinuz-generic
lrwxrwxrwx 1 root root 22 Dec 13 00:44 /boot/vmlinuz-generic -> vmlinuz-generic-4.4.38

So the following code:

KERNEL_VERSION="$( readlink /boot/vmlinuz-generic | rev | cut -f1 -d- | rev )"

will simply extract the version number from the installed kernel image.

And finally, to create the initrd, run the following command:

$ mkinitrd -c -F

Note that it is not necessary to run any syslinux related commands after creating or updating the initrd image. This is different from LILO, where you have to run lilo command after changing the initrd image.

13. Enabling serial console access

As of now, the serial console configuration in /boot/syslinux.cfg allows for interacting with the bootloader and also to see the kernel messages, but it does not allow for root login over serial port. If you want to enable it, then uncomment the following line in /etc/inittab:

s2:12345:respawn:/sbin/agetty -L ttyS1 9600 vt100

and the following line in /etc/securetty:

ttyS1

You might also want to comment out the follwing lines in /etc/inittab:

#c1:12345:respawn:/sbin/agetty --noclear 38400 tty1 linux
#c2:12345:respawn:/sbin/agetty 38400 tty2 linux
#c3:12345:respawn:/sbin/agetty 38400 tty3 linux
#c4:12345:respawn:/sbin/agetty 38400 tty4 linux
#c5:12345:respawn:/sbin/agetty 38400 tty5 linux
#c6:12345:respawn:/sbin/agetty 38400 tty6 linux

and the following lines in /etc/securetty:

#tty1
#tty2
#tty3
#tty4
#tty5
#tty6

tty[1-6] are for the standard VT login prompts, but since we have no keyboard and no display, we cannot make any use of them.

14. Finalising the installation

We're done with the installation and initial configuration of the Slackware Linux. ;-) You can now prepare the system for reboot and, well, reboot. Before doing that, you might also consider looking at the Appendix B, where I explain how to prepare the SSH stuff, so that after rebooting, you can connect to the server with SSH right away. (Otherwise, you will have to log in over serial console to perform the other configuration tasks).

First, prepare the hard disk to safely survive the reboot phase. Note that, I only (u)mount /mnt/boot and /mnt partitions as these are the only hard disk partitions I have. If you have more mounted disk partitions, you should umount them too:

$ # Exit freshly installed Slackware chroot:
$ exit
$ umount -v /mnt/boot
$ mount -v -o remount,ro /mnt
$ # This never hurts:
$ sync
$ # Only needed if LVM2 is used:
$ vgchange -an --ignorelockingfailure
$ # This never hurts again:
$ sync
$ # Shouldn't be needed, but just in case:
$ sleep 3

Now, go to the server management page and press [BOOT_IN_NORMAL_MODE] button. You can observe the reboot process on the serial console.

A. Setting up LVM2 disk management

The following instructions will destroy the data on the disk.

Before continuing to LVM2 partitioning, if the disk is already under LVM2 control, it has to be first deactivated. I use the following set of commands to do so:

$ lvscan
$ ( cd /dev/mapper && lvchange -an $(pvs --noheadings -o vg_name) )
$ vgscan
$ vgchange -an $(pvs --noheadings -o vg_name)
$ pvscan
$ pvremove -ffy $(pvs --noheadings -o pv_name)
$ partprobe
To find out more about LVM2, go to https://wiki.archlinux.org/index.php/LVM

Remember that the disk has already been partitioned using MBR in the “Partitioning” chapter and /dev/sda2 already exists. The following set of commands will activate LVM2 on /dev/sda2 and create the partitions (the LVM2 partitions are going to sit on top of /dev/sda2 partition):

$ pvcreate /dev/sda2
$ pvdisplay
$ vgcreate vg0 /dev/sda2
$ vgdisplay
$ # Create the partitions (logical volumes):
$ lvcreate -L 12G vg0 -n rootfs
$ lvdisplay
$ vgchange -ay

NOTE:

  • The good thing about LVM2 is that you can easily add more partitions later on.
  • I have chosen partition sizes that suit my current needs, leaving significant free space. LVM2 can easily grow the sizes later on if needed.
  • I haven't created the swap partition. The server has more than enough of RAM. But if needed, it can be easily added later on.

B. SSH server configuration (before rebooting)

You have to be in the chroot of the freshly installed Slackware system to perform the configuration steps detailed below.

If you enabled the sshd service during setup, it'll be automatically started the next time the Slackware system boots. Unfortunately, you won't be able to connect to it for two reasons:

  1. the host keys are not generated yet, so you won't be able to verify host's authenticity and of course you don't want to connect without being able to verify it,
  2. user's public key authentication is not set up and of course you don't want to be logging in using password authentication.

To solve the first issue, we need to manually perform the task that would normally be done by the Slackware init scripts when the system boots for the first time. Generating the host keys basically boils down to the following command:

$ ssh-keygen -A

And then to obtain the host's key fingerprint (I stick to RSA):

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Setting up public key authentication is a bit more cumbersome, but still far from being rocket science. :-^ First, you need to upload your public key from your workstation to the server. Run the following command on the workstation:

$ scp -i ./login_key ~/.ssh/id_rsa.pub user@x.y.z.w:~

NOTE: The above command uploads ~/.ssh/id_rsa.pub public key, but for the transfer authentication, it uses the very same key you uploaded earlier using the Web interface.

Now, back to the server, create the required ~/.ssh directory:

$ mkdir ~/.ssh

I told you to use the screen program at the beginning, right? :-) Now we will make use of it. The public key that you uploaded above has been placed in the user home directory of the Ubuntu rescue OS. We need to rename it to the authorized_keys file in the ~/.ssh directory of the fresh Slackware installation:

$ # Detach from screen session, you'll be dropped to Ubuntu rescue OS:
(keyboard) Ctrl+a d
$ # Login as root:
$ sudo su -
$ mv /home/user/id_rsa.pub /root/slackware-chroot/mnt/root/.ssh/authorized_keys
$ # Exit root login:
$ exit
$ Re-attach to screen session:
$ screen -r

Ensure correct ownership and permissions, otherwise sshd won't let us in:

$ chown root:root ~/.ssh
$ chown root:root ~/.ssh/authorized_keys
$ chmod 0700 ~/.ssh
$ chmod 0600 ~/.ssh/authorized_keys

NOTE:

  1. If you haven't used screen, you would just open second SSH connection to perform the above task. Alternatively, you could exit all the chroots and then run them again, but who would want to do that? ;-)
  2. Remember that the correct server's network configuration has to be in place for you to be able to connect over SSH after reboot.

At this point, all the pieces should be in place and you should be able to successfully login to your fresh Slackware installation after the server is rebooted.

NOTE: I know I allow for root login over SSH. I have to live with that. :-^

Sources

 es:howtos:slackware_admin:install_slackware_on_a_online.net_dedibox_baremetal_server ()