Pasar al Servidor Linux (Parte #1) - Preparación del Sistema

Introducción

Existen muchos escenarios donde es posible que tenga que mover los datos y los requisitos operativos de un servidor a otro. Es posible que deba implementar sus soluciones en un nuevo centro de datos, actualizar a una computadora más grande o realizar la transición a un nuevo hardware a un nuevo proveedor de servidor.

Sean cuales sean sus razones, hay muchas consideraciones diferentes que debe hacer al pasar de un sistema a otro. Conseguir configuraciones funcionalmente equivalentes puede ser difícil si no está operando con una solución de administración de configuración como Chef, Puppet o Ansible. No sólo debe transferir datos, sino también configurar sus servicios para que operen de la misma manera en una computadora nueva.

En este tutorial, discutiremos cómo preparar sus sistemas de origen y destino para una migración. Esto incluirá obtener sus dos computadoras para comunicarse con las claves SSH y una investigación sobre qué componentes necesitan ser transferidos. Vamos a trabajar en la migración en el próximo artículo .

Hacer Copias de Seguridad

El primer paso a seguir es crear copias de seguridad nuevas. Sólo porque no debería haber un problema no significa que algo inesperado no va a suceder. No desea quedar en una situación en la que un comando rompe algo en su computaora de producción actual antes de que el reemplazo esté en funcionamiento.

Hay varias maneras diferentes de hacer una copia de seguridad de su servidor. Su selección dependerá de las opciones que tengan sentido para su escenario y de lo que le resulte más cómodo.

Si tiene acceso al hardware físico y un espacio de copia de seguridad (unidad de disco, USB, etc.), puede clonar el disco utilizando cualquiera de las muchas soluciones de copia de seguridad de imágenes disponibles. Un equivalente funcional cuando se trata con un servidor se toma una instantánea o imagen desde la interfaz del panel de control.

Otras opciones a menudo conservarán los datos y tal vez parte de la información sobre sus servicios. Todo depende del mecanismo de respaldo que desee implementar.

Una vez que haya completado las copias de seguridad, estará listo para continuar. Para el resto de esta guía, asumiremos que ha iniciado sesión en ambos sistemas como root.

Recopilar Información sobre el Sistema de Origen

Antes de comenzar la migración, debemos tomar las medidas iniciales para configurar nuestro sistema de destino para que coincida con nuestro sistema de origen.

Queremos igualar tanto como podamos entre el servidor actual y el que planeamos instalar. Si desea que la migración se realice sin problemas, entonces no debería tomar esto como una oportunidad para actualizar a la versión más reciente o probar cosas nuevas. Hacer cambios puede llevar a la inestabilidad ya los problemas en la línea.

La mayoría de la información básica que le ayudará a decidir qué sistema de servidor crear, se puede recuperar con un simple comando uname :

uname -r

3.2.0-24-virtual

Esta es la versión del kernel que nuestro sistema actual está ejecutando. Para que las cosas salgan bien, siempre es una buena idea tratar de igualar eso en el sistema de destino.

uname -m

i686

Esta es la arquitectura del sistema. i686 indica que se trata de un sistema de 32 bits. Si la cadena devuelta era x86_64 , esto significaría que se trata de un sistema de 64 bits.

También debe intentar igualar la distribución y la versión de su servidor de origen. Si no conoce la versión de la distribución que ha instalado en el equipo de origen, puede averiguarlo escribiendo:

cat /etc/issue

Ubuntu 12.04.2 LTS \n \l

Si es posible, debe crear su nuevo servidor con estos mismos parámetros. En este caso, crearíamos un sistema Ubuntu 12.04 de 32 bits. Si es posible, también intentaremos hacer coincidir la versión del kernel con el nuevo sistema.

Configurar el Acceso de Clave SSH entre Servidores de Origen y Destino

Necesitaremos que nuestros servidores puedan comunicarse para que puedan transferir archivos. La forma más fácil de hacerlo es con las teclas SSH. Aquí puede aprender a configurar las claves SSH en un servidor Linux.

Queremos crear una nueva clave en nuestro servidor de destino para que podamos agregarla al archivo authorized_keys nuestro servidor de origen. El nuevo servidor no tendrá una clave extraviada en su archivo authorized_keys cuando la migración esté completa.

En primer lugar, en su servidor de destino, compruebe que su usuario root no tiene una clave SSH (debe iniciar sesión como root) escribiendo:

ls ~/.ssh

authorized_keys

Si ves archivos llamados id_rsa.pub e id_rsa , entonces ya tienes claves y solo necesitarás transferirlos.

Si no ve esos archivos, cree un nuevo par de claves escribiendo:

ssh-keygen -t rsa

Pulse "Enter" en todas las indicaciones para aceptar los valores predeterminados.

Ahora, transfiera la clave al servidor de origen escribiendo:

cat ~/.ssh/id_rsa.pub | ssh other_server_ip "cat >> ~/.ssh/authorized_keys"

Ahora debe ser capaz de SSH libremente a su servidor de origen desde el sistema de destino escribiendo:

ssh other_server_ip 

No se le pedirá una contraseña si ha configurado correctamente.

Crear una Lista de Requisitos

Esta es en realidad la primera parte en la que va a hacer un análisis en profundidad de su sistema y los requisitos.

Durante el transcurso de las operaciones, sus requisitos de software pueden cambiar. A veces los servidores antiguos tienen algunos servicios y software que se necesitaban en un punto, pero han sido reemplazados.

Mientras que los servicios innecesarios deben ser deshabilitados y, si son completamente innecesarios, se necesita descubrir qué servicios se están utilizando en su servidor de origen y, a continuación, decidir si dichos servicios deberían existir en su nuevo servidor.

La forma en que descubre servicios y niveles de ejecución depende en gran medida del tipo de sistema "init" que emplea su servidor. El sistema init es responsable de iniciar y detener los servicios, ya sea a pedido al usuario automáticamente.

Descubriendo Servicios y Niveles de Ejecución en Servidores System V

System V es uno de los sistemas de init más antiguos todavía en uso en muchos servidores de hoy. Ubuntu ha intentado cambiar al sistema de inicialización de Upstart, y en el futuro puede estar pasando a un sistema de inicialización Systemd.

Actualmente, tanto los archivos de init de System V como los nuevos archivos de inicio de Upstart se pueden encontrar en los mismos sistemas, lo que significa que tendrás más lugares para ver. Otros sistemas utilizan el sistema V también. Puede ver si su servidor utiliza System V escribiendo:

which service

/usr/sbin/service

Si el comando devuelve una ruta del sistema, como lo hizo anteriormente, tiene System V en su sistema.

Puede obtener una idea de los servicios que se están ejecutando actualmente escribiendo esto:

service --status-all

 [ ? ]  acpid
 [ ? ]  anacron
 [ + ]  apache2
 [ ? ]  atd
 [ - ]  bootlogd
 [ ? ]  console-setup
 [ ? ]  cron
 [ ? ]  cryptdisks
 . . .

Esto mostrará todos los servicios que el sistema System-V init conoce. El "+" significa que el servicio se inicia, el "-" significa que se detiene, y el "?" Significa que System-V no conoce el estado del servicio.

Si System-V no conoce el estado del servicio, es posible que esté controlado por un sistema init alternativo. En los sistemas Ubuntu, esto suele ser Upstart.

Aparte de averiguar qué servicios se están ejecutando actualmente, otra buena pieza de información que debe tener es en qué nivel de ejecución un servicio está activo. Los niveles de ejecución determinan qué servicios deben estar disponibles cuando el servidor se encuentra en estados diferentes. Es probable que desee igualar la configuración del servidor de origen en el nuevo sistema.

Puede descubrir los niveles de ejecución que cada servicio tiene activo para utilizar una serie de herramientas. Una forma es a través de herramientas como chkconfig o sysv-rc-conf .

En un sistema Ubuntu o Debian, puede instalar y utilizar chkconfig para comprobar los servicios de System V disponibles en diferentes niveles de ejecución. La mayoría de los sistemas basados ​​en RHEL deben tener instalado este software:

apt-get update
apt-get install chkconfig
chkconfig --list

acpid                     0:off  1:off  2:off  3:off  4:off  5:off  6:off
anacron                   0:off  1:off  2:off  3:off  4:off  5:off  6:off
apache2                   0:off  1:off  2:on   3:on   4:on   5:on   6:off
atd                       0:off  1:off  2:off  3:off  4:off  5:off  6:off
bootlogd                  0:off  1:off  2:off  3:off  4:off  5:off  6:off
console-setup             0:off  1:off  2:off  3:off  4:off  5:off  6:off
cron                      0:off  1:off  2:off  3:off  4:off  5:off  6:off
cryptdisks                0:on   1:off  2:off  3:off  4:off  5:off  6:off
cryptdisks-early          0:on   1:off  2:off  3:off  4:off  5:off  6:off
. . .

Otra alternativa es sysv-rc-conf , que se puede instalar y ejecutar de esta manera:

apt-get update
apt-get install sysv-rc-conf
sysv-rc-conf --list

acpid       
anacron     
apache2      0:off  1:off   2:on    3:on    4:on    5:on    6:off
atd         
bootlogd    
console-setu
cron        
cryptdisks   0:on   6:on
cryptdisks-e 0:on   6:on
. . .

Si desea comprobar manualmente un lugar para utilizar una herramienta, puede hacerlo comprobando un número de directorios que toman la forma de /etc/rc*.d/ . El asterisco se reemplazará con el número del nivel de ejecución.

Por ejemplo, para ver qué servicios son activados por System V en el nivel de ejecución 2, puede comprobar los archivos allí:

cd /etc/rc2.d
ls -l

total 4
-rw-r--r-- 1 root root 677 Jul 26  2012 README
lrwxrwxrwx 1 root root  18 Dec 28  2012 S20php5-fpm -> ../init.d/php5-fpm
lrwxrwxrwx 1 root root  15 Apr 26  2012 S50rsync -> ../init.d/rsync
lrwxrwxrwx 1 root root  14 Jun 21  2013 S75sudo -> ../init.d/sudo
lrwxrwxrwx 1 root root  17 Dec 28  2012 S91apache2 -> ../init.d/apache2
. . .

Estos son enlaces a archivos de configuración ubicados en /etc/init.d/ . Cada enlace que comienza con un "S" significa que se utiliza para iniciar un servicio. Los scripts que comienzan con un "K" eliminan los servicios en ese nivel de ejecución.

Descubriendo Servicios y Niveles de Ejecución en Servidores Upstart

Ubuntu y servidores basados ​​en Ubuntu son prácticamente los únicos servidores que implementan el sistema de inicialización de Upstart por defecto. Éstos se utilizan típicamente como el sistema principal del init, con el sistema V que es configurado para los servicios heredados.

Para ver si su servidor tiene un sistema init de Upstart, escriba:

which initctl

/sbin/initctl

Si recibe una ruta al ejecutable como lo hicimos anteriormente, entonces su servidor tiene capacidades Upstart y debe investigar qué servicios son controlados por Upstart.

Puede ver qué servicios son iniciados por Upstart escribiendo:

initctl list

mountall-net stop/waiting
passwd stop/waiting
rc stop/waiting
rsyslog start/running, process 482
tty4 start/running, process 728
udev start/running, process 354
upstart-udev-bridge start/running, process 350
ureadahead-other stop/waiting
. . .

Esto le indicará el estado actual de todos los servicios administrados Upstart. Puede saber qué servicios se están ejecutando actualmente y tal vez ver si hay servicios que proporcionan la misma funcionalidad en la que uno ha asumido el control de un servicio heredado que ya no está en uso.

Una vez más, debe familiarizarse con los servicios que se supone que estarán disponibles en cada nivel de ejecución.

Puede hacerlo con el comando initctl escribiendo:

initctl show-config

mountall-net
  start on net-device-up
passwd
  start on filesystem
rc
  emits deconfiguring-networking
  emits unmounted-remote-filesystems
  start on runlevel [0123456]
  stop on runlevel [!$RUNLEVEL]
rsyslog
  start on filesystem
  stop on runlevel [06]
  . . .

Esto escupe mucha información de configuración para cada servicio. La parte a buscar es la especificación de nivel de ejecución.

Si prefiere recopilar esta información manualmente, puede ver los archivos ubicados en el directorio /etc/init (observe la omisión del ".d" después de "init" aquí).

En su interior, encontrará una serie de archivos de configuración. Dentro de estos archivos, hay especificaciones de nivel de ejecución dadas así:

start on runlevel [2345]
stop on runlevel [!2345]

Debe tener una buena idea de las diferentes maneras de descubrir los servicios Upstart y los niveles de ejecución.

Descubriendo Servicios y Niveles de Ejecución en Servidores Systemd

Un nuevo estilo de init que cada vez es más adoptado por las distribuciones es el sistema init systemd.

Systemd es bastante divergente de los otros tipos de sistemas init, pero es increíblemente. Puede informarse sobre la ejecución de servicios escribiendo:

systemctl list-units -t service

UNIT                                           LOAD   ACTIVE SUB     DESCRIPTION
atd.service                                    loaded active running ATD daemon
avahi-daemon.service                           loaded active running Avahi mDNS/DNS-SD Stack
colord.service                                 loaded active running Manage, Install and Generate Color Profiles
cups.service                                   loaded active running CUPS Printing Service
dbus.service                                   loaded active running D-Bus System Message Bus
dcron.service                                  loaded active running Periodic Command Scheduler
dkms.service                                   loaded active exited  Dynamic Kernel Modules System
. . .

Systemd no reproduce exactamente el concepto de niveles de ejecución de otros sistemas init. En su lugar, implementa el concepto de "objetivos". Mientras que los sistemas con sistemas init tradicionales sólo pueden estar en un nivel de ejecución a la vez, un servidor que utiliza systemd puede alcanzar varios objetivos al mismo tiempo.

Debido a esto, averiguar qué servicios están activos cuando es un poco más difícil.

Puede ver qué destinos están activos escribiendo:

systemctl list-units -t target

UNIT                LOAD   ACTIVE SUB    DESCRIPTION
basic.target        loaded active active Basic System
cryptsetup.target   loaded active active Encrypted Volumes
getty.target        loaded active active Login Prompts
graphical.target    loaded active active Graphical Interface
local-fs-pre.target loaded active active Local File Systems (Pre)
local-fs.target     loaded active active Local File Systems
. . .

Puede listar todos los destinos disponibles escribiendo:

systemctl list-unit-files -t target

UNIT FILE                 STATE   
basic.target              static  
bluetooth.target          static  
cryptsetup.target         static  
ctrl-alt-del.target       disabled
default.target            disabled
emergency.target          static  
final.target              static  
getty.target              static  
graphical.target          disabled
halt.target               disabled
. . .

A partir de aquí, podemos averiguar qué servicios están asociados con cada objetivo. Los destinos pueden tener servicios u otros objetivos como dependencias, por lo que podemos ver qué políticas implementa cada objetivo escribiendo:

systemctl list-dependencies target_name.target

Por ejemplo, puede escribir algo como esto:

systemctl list-dependencies multi-user.target

multi-user.target
├─atd.service
├─avahi-daemon.service
├─cups.path
├─dbus.service
├─dcron.service
├─dkms.service
├─gpm.service
. . .

Esto mostrará el árbol de dependencias de ese destino, proporcionándole una lista de servicios y otros objetivos que se iniciarán cuando se alcance dicho destino.

Doble Comprobación de Servicios a Través de otros Métodos

Aunque la mayoría de los servicios se configuran a través del sistema init, es posible que haya algunas áreas en las que un proceso o servicio se resbale por las grietas y se controle de forma independiente.

Podemos tratar de encontrar estos otros servicios y procesos analizando los efectos secundarios de estos servicios. En la mayoría de los casos, los servicios se comunican entre sí o con entidades externas de alguna manera. Sólo hay un número específico de formas en que los servicios pueden comunicarse y comprobar esas interfaces es una buena manera de detectar otros servicios.

Una herramienta que podemos utilizar para descubrir los puertos de red y los Unix que están siendo utilizados por los procesos para comunicarse es netstat . Podemos emitir un comando como este para obtener una visión general de algunos de nuestros servicios:

netstat -nlp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      762/mysqld      
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      832/apache2     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      918/sshd        
tcp        0      0 127.0.0.1:9000          0.0.0.0:*               LISTEN      799/php-fpm.conf)
tcp6       0      0 :::22                   :::*                    LISTEN      918/sshd        
Active UNIX domain sockets (only servers)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name    Path
unix  2      [ ACC ]     STREAM     LISTENING     1526     1/init              @/com/ubuntu/upstart
unix  2      [ ACC ]     SEQPACKET  LISTENING     1598     354/udevd           /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     6982     480/dbus-daemon     /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     8378     762/mysqld          /var/run/mysqld/mysqld.sock
unix  2      [ ACC ]     STREAM     LISTENING     1987     746/acpid           /var/run/acpid.socket 

Los números de puerto en la primera sección están asociados con los programas en la extrema derecha. Del mismo modo, la parte inferior se centra en los Unix que están siendo utilizados por los programas.

Si ve los servicios aquí de los que no tiene información a través del sistema init, tendrá que averiguar por qué es y qué tipo de información necesitará reunir sobre ese servicio.

Puede obtener información similar sobre los puertos que los servicios están haciendo disponibles mediante el comando lsof :

lsof -nPi

COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
mysqld    762    mysql   10u  IPv4   8377      0t0  TCP 127.0.0.1:3306 (LISTEN)
php5-fpm  799     root    6u  IPv4   8195      0t0  TCP 127.0.0.1:9000 (LISTEN)
php5-fpm  800 www-data    0u  IPv4   8195      0t0  TCP 127.0.0.1:9000 (LISTEN)
php5-fpm  801 www-data    0u  IPv4   8195      0t0  TCP 127.0.0.1:9000 (LISTEN)
php5-fpm  802 www-data    0u  IPv4   8195      0t0  TCP 127.0.0.1:9000 (LISTEN)
php5-fpm  803 www-data    0u  IPv4   8195      0t0  TCP 127.0.0.1:9000 (LISTEN)
apache2   832     root    3u  IPv4   8210      0t0  TCP *:80 (LISTEN)
sshd      918     root    3r  IPv4   7738      0t0  TCP *:22 (LISTEN)
. . .

Puede obtener una gran información del comando ss sobre qué procesos utilizan los puertos y los sockets:

ss -nlpaxtudw

Netid  State      Recv-Q Send-Q   Local Address:Port     Peer Address:Port 
u_str  LISTEN     0      0      @/com/ubuntu/upstart 1526                * 0     users:(("init",1,7))
u_str  ESTAB      0      0      @/com/ubuntu/upstart 1589                * 0     users:(("init",1,10))
u_str  ESTAB      0      0                    * 1694                * 0     users:(("dbus-daemon",480,6))
u_str  ESTAB      0      0                    * 1695                * 0     users:(("dbus-daemon",480,7))
u_str  ESTAB      0      0                    * 1803                * 0

Recopilación de Versiones de Paquete

Después de toda esa exploración, debería tener una buena idea sobre qué servicios se están ejecutando en su computadora y que debe implementar en su servidor de destino.

Usted debe tener una lista de servicios que sabe que necesitará implementar. Para que la transición se realice sin problemas, es importante intentar igualar las versiones donde sea posible.

Es obvio que no podrás pasar por todos los paquetes instalados en el sistema fuente e intentar replicarlo en el nuevo sistema, pero deberías comprobar los componentes de software que son importantes para tus necesidades e intentar encontrar el número de versión.

Puede intentar obtener los números de versión del software en sí, a veces pasando los indicadores -v o --version a los comandos, pero normalmente esto es más fácil de llevar a cabo a través del gestor de paquetes. Si está en un sistema basado en Ubuntu / Debian, puede ver qué versión de los paquetes se instalan desde el gestor de paquetes escribiendo:

dpkg -l | grep package_name 

Si en su lugar está en un sistema basado en RHEL, puede utilizar este comando para comprobar la versión instalada en su lugar.

rpm -qa | grep package_name 

Esto le dará una buena idea de la versión del programa que está buscando instalar.

Mantenga una lista de los números de versión de los componentes importantes que desea instalar. Intentaremos adquirirlos en el sistema de destino.

Conclución

Ahora debe tener una buena idea de qué procesos y servicios en su servidor de origen necesitan ser transferidos al nuevo. También debe completar los pasos preliminares para permitir que sus dos instancias de servidor se comuniquen entre sí.

La base para su migración ya está completa. Ahora podraver en el próximo tutorial para que tenga una buena idea de lo que necesita hacer.