15%

Ahorra 15%<\/span> en todos los servicios de hosting

Pon a prueba tus habilidades y obtén Descuento<\/span> en cualquier plan de hosting

Usa el código:

Skills
Comenzar
23.10.2024

Cómo Asignar un Nombre de Host Estático a una Máquina Linux

Un hostname estático es una etiqueta legible por humanos configurada de forma permanente, asignada a un sistema Linux que persiste entre reinicios y no es sobreescrita por servicios de red como DHCP. A diferencia de un hostname transitorio — que puede ser establecido dinámicamente por el daemon de red y restablecido en el siguiente arranque — un hostname estático se almacena en disco y permanece como referencia autoritativa independientemente de cómo la máquina obtenga su dirección IP.

Esta distinción es enormemente importante en entornos de producción. Cuando ejecutas un VPS o un servidor dedicado, un hostname estable es el ancla para las entradas de SSH known-hosts, los Subject Alternative Names de certificados TLS, los identificadores de syslog, las etiquetas de destino de Prometheus y los nombres de principal de Kerberos. Un hostname que cambia silenciosamente tras una renovación DHCP puede romper todos estos elementos simultáneamente.

¿Qué es exactamente un hostname de Linux?

Linux rastrea tres clases distintas de hostname, cada una con un propósito diferente:

Tipo de hostnameUbicación de almacenamientoAlcanceSobrevive al reinicio
Estático/etc/hostnameIdentidad persistente del sistema
TransitorioSolo en tiempo de ejecución del kernelTemporal, establecido por NTP/DHCPNo
Descriptivo/etc/machine-infoNombre de visualización UTF-8 (se permiten espacios)

El hostname estático es el que configuras intencionalmente. El hostname transitorio es el que el kernel está usando actualmente — normalmente idéntico al estático a menos que un servidor DHCP o systemd-timesyncd lo haya sobreescrito. El hostname descriptivo es puramente cosmético (p. ej., "Alex's Web Server") y nunca se usa en DNS ni en SSH.

Los hostnames estáticos válidos siguen las reglas de RFC 1123: solo letras minúsculas, dígitos y guiones; sin guiones bajos; sin guiones al inicio o al final; máximo 63 caracteres por etiqueta; máximo 253 caracteres en total para un nombre de dominio completamente calificado (FQDN).

Verificar el hostname actual

Antes de realizar cualquier cambio, audita el estado actual de los tres tipos de hostname:

hostnamectl

Ejemplo de salida en un sistema basado en systemd:

 Static hostname: old-server-name
 Pretty hostname: Old Server Name
Transient hostname: dhcp-assigned-name
       Icon name: computer-server
         Chassis: server
      Machine ID: a1b2c3d4e5f6...
         Boot ID: 9f8e7d6c5b4a...
Operating System: Ubuntu 22.04.3 LTS
          Kernel: Linux 5.15.0-91-generic
    Architecture: x86-64

Si el hostname transitorio difiere del hostname estático, tu cliente DHCP está sobreescribiendo el valor estático — un problema que se aborda en la sección de persistencia a continuación.

Para sistemas sin hostnamectl, usa:

hostname
cat /etc/hostname
uname -n

Método 1: Usar hostnamectl (distribuciones basadas en systemd)

Este método se aplica a Ubuntu 16.04+, Debian 8+, CentOS 7+, RHEL 7+, Fedora 15+, AlmaLinux, Rocky Linux y cualquier distribución que ejecute systemd como PID 1.

Paso 1: Establecer el hostname estático

sudo hostnamectl set-hostname new-static-hostname

hostnamectl escribe el valor en /etc/hostname, llama a la syscall sethostname(2) para actualizar el kernel en ejecución de inmediato y notifica a systemd-hostnamed — todo de forma atómica. No se requiere reinicio.

Para establecer los tres tipos de hostname simultáneamente:

sudo hostnamectl set-hostname "new-static-hostname" --static
sudo hostnamectl set-hostname "New Static Hostname" --pretty
sudo hostnamectl set-hostname "new-static-hostname" --transient

Paso 2: Verificar el cambio

hostnamectl

Confirma que el campo Static hostname muestra tu nuevo valor. Verifica también que el kernel lo haya recogido:

hostname

Paso 3: Actualizar /etc/hosts

hostnamectl no actualiza /etc/hosts automáticamente. No actualizar este archivo hace que sudo emita la advertencia unable to resolve host, rompe las aplicaciones que llaman a gethostbyname() sobre el hostname local y puede causar que los servicios basados en Java (Elasticsearch, Kafka) fallen al iniciarse.

sudo nano /etc/hosts

El archivo debe contener como mínimo:

127.0.0.1   localhost
127.0.1.1   new-static-hostname.yourdomain.com  new-static-hostname

La segunda línea usa 127.0.1.1 (no 127.0.0.1) para el hostname propio de la máquina en sistemas de la familia Debian. En sistemas de la familia RHEL, usa la dirección IP primaria real en su lugar:

192.168.1.50  new-static-hostname.yourdomain.com  new-static-hostname

Si estás administrando un VPS con cPanel, la herramienta de cambio de hostname de cPanel gestiona /etc/hosts automáticamente, pero aun así deberías verificar el resultado manualmente.

Método 2: Editar manualmente /etc/hostname (distribuciones sin systemd)

Este método se aplica a versiones antiguas de Debian/Ubuntu que usan SysVinit o Upstart, Alpine Linux, Gentoo con OpenRC, Void Linux y sistemas embebidos.

Paso 1: Editar /etc/hostname

sudo nano /etc/hostname

El archivo debe contener exactamente una línea — el hostname corto sin espacios en blanco al final ni salto de línea más allá del terminador de línea estándar:

new-static-hostname

Paso 2: Actualizar /etc/hosts

sudo nano /etc/hosts

Aplica el mismo mapeo descrito en el Método 1.

Paso 3: Aplicar el cambio sin reiniciar

Notifica al kernel en ejecución del nuevo hostname de inmediato:

sudo hostname new-static-hostname

En sistemas con systemd-hostnamed disponible incluso sin adopción completa de systemd:

sudo systemctl restart systemd-hostnamed

En sistemas SysVinit puros, el comando hostname anterior es suficiente. El cambio surte efecto para todos los nuevos procesos; los shells existentes seguirán mostrando el prompt antiguo hasta que abras una nueva sesión de terminal o ejecutes:

exec bash

Método 3: Anulación mediante cloud-init (crítico para instancias VPS en la nube)

Este es el escenario que más frecuentemente se pasa por alto. En plataformas en la nube — incluida la mayoría de los proveedores de VPS — cloud-init se ejecuta en cada arranque y restablece el hostname a lo que devuelva la API de metadatos de la instancia. Tu cambio en /etc/hostname será sobreescrito silenciosamente en el próximo reinicio.

Para que un hostname estático sobreviva a cloud-init, edita /etc/cloud/cloud.cfg:

sudo nano /etc/cloud/cloud.cfg

Busca o añade la siguiente directiva:

preserve_hostname: true

Alternativamente, crea un archivo de anulación drop-in para evitar modificar la configuración gestionada por el paquete:

sudo mkdir -p /etc/cloud/cloud.cfg.d/
sudo tee /etc/cloud/cloud.cfg.d/99_hostname.cfg > /dev/null <<EOF
preserve_hostname: true
EOF

Tras este cambio, cloud-init ya no modificará el hostname en los arranques posteriores.

Evitar que DHCP sobreescriba el hostname estático

Incluso sin cloud-init, un cliente DHCP puede sobreescribir el hostname transitorio. La solución depende de qué cliente DHCP use tu distribución.

Para dhclient (Debian/Ubuntu heredado)

Edita /etc/dhcp/dhclient.conf:

sudo nano /etc/dhcp/dhclient.conf

Añade o modifica:

send host-name "new-static-hostname";
supersede host-name "new-static-hostname";

La directiva supersede garantiza que el cliente ignore cualquier hostname ofrecido por el servidor DHCP.

Para systemd-networkd con systemd-resolved

Edita o crea un archivo .network en /etc/systemd/network/:

[DHCP]
SendHostname=yes
UseHostname=no

UseHostname=no evita que el hostname ofrecido por DHCP sobreescriba el estático.

Para NetworkManager (la mayoría de distribuciones de escritorio y servidores modernos)

sudo nmcli con modify "connection-name" ipv4.dhcp-hostname "new-static-hostname"
sudo nmcli con modify "connection-name" ipv4.dhcp-send-hostname yes

Para evitar que NetworkManager acepte un hostname de DHCP por completo, añade a /etc/NetworkManager/NetworkManager.conf:

[main]
hostname-mode=none

Propagación del hostname: qué más necesita saberlo

Establecer el hostname en el sistema operativo es necesario pero no suficiente en un entorno en red. Ten en cuenta estos sistemas dependientes:

  • Registros DNS directos e inversos: Actualiza el registro A y el registro PTR de tu zona DNS. Sin un registro PTR coincidente, muchos servidores de correo rechazarán el correo saliente y algunas herramientas de seguridad marcarán el host como sospechoso.
  • Certificados SSL/TLS: Si tu hostname forma parte del CN o SAN de un certificado, necesitas un nuevo certificado. Los certificados SSL vinculados al hostname antiguo producirán errores de validación.
  • Registro de dominio y propagación DNS: Si el hostname se corresponde con un FQDN público, actualiza el registro DNS en tu registrador de dominios y espera el tiempo de propagación basado en el TTL.
  • Agentes de monitorización: El exportador de nodos de Prometheus, Datadog, Zabbix y agentes similares usan el hostname como etiqueta. Tras un cambio de hostname, las métricas históricas pueden aparecer bajo una identidad de host diferente.
  • /etc/ssh/ssh_known_hosts: Los archivos known-hosts de todo el clúster que hagan referencia al hostname antiguo deben actualizarse.
  • Archivos de configuración de aplicaciones: Cualquier hostname codificado de forma fija en configuraciones de aplicaciones, cadenas de conexión JDBC o listeners anunciados de brokers de mensajes debe actualizarse.

Comparación: métodos de configuración de hostname

MétodoCompatibilidad con distribucionesRequiere reinicioGestiona cloud-initActualización atómica
hostnamectl set-hostnameDistribuciones con systemdNoNo (necesita preserve_hostname)
Editar /etc/hostname manualmenteTodas las distribucionesNo (con el cmd hostname)NoNo
preserve_hostname de cloud-initInstancias en la nubeNoN/A
Configuración del cliente DHCP (supersede)Todas las distribucionesNoNoNo
nmcli de NetworkManagerSistemas gestionados por NMNoNo

Casos límite y problemas comunes en el mundo real

Problema 1: El bucle de advertencia sudo. Si estableces el hostname pero olvidas actualizar /etc/hosts, cada invocación de sudo imprimirá sudo: unable to resolve host new-static-hostname. Esto no es fatal, pero añade latencia a cada comando privilegiado e inunda los registros.

Problema 2: Los servicios Java se niegan a iniciar. InetAddress.getLocalHost() de Java resuelve el hostname mediante gethostbyname(). Si el hostname no está en /etc/hosts ni es resoluble mediante DNS, servicios como Elasticsearch, Kafka y Cassandra lanzan UnknownHostException al iniciarse.

Problema 3: Hostname con guiones bajos. A pesar de su uso informal generalizado, los guiones bajos en los hostnames violan RFC 952 y RFC 1123. Algunos resolvedores DNS, bibliotecas TLS y componentes de Kubernetes los rechazarán o los gestionarán incorrectamente. Usa siempre guiones.

Problema 4: FQDN frente a hostname corto. hostnamectl almacena solo el hostname corto (p. ej., web01). El FQDN (p. ej., web01.example.com) se resuelve combinando el hostname corto con la lista de búsqueda de dominio en /etc/resolv.conf o /etc/systemd/resolved.conf. Establece Domains=example.com en resolved.conf o search example.com en resolv.conf para que hostname --fqdn devuelva el valor correcto.

Problema 5: Aislamiento de contenedores y namespaces. Dentro de un contenedor Docker o un namespace LXC, hostnamectl puede fallar con Failed to connect to bus: No such file or directory porque systemd-hostnamed no está en ejecución. Usa hostname new-name directamente, o establece el hostname en el momento de creación del contenedor mediante docker run --hostname o la clave hostname: en docker-compose.yml.

Lista de verificación práctica

Usa esta lista de verificación antes y después de cada cambio de hostname en un entorno de producción:

  • Confirma que el nuevo hostname cumple con RFC 1123 (minúsculas, solo guiones, máximo 63 caracteres por etiqueta)
  • Ejecuta hostnamectl antes del cambio y guarda la salida para fines de auditoría
  • Establece el hostname estático con hostnamectl set-hostname o editando /etc/hostname
  • Actualiza /etc/hosts con el hostname corto y el FQDN en la misma línea
  • Si el sistema es una instancia en la nube, establece preserve_hostname: true en la configuración de cloud-init
  • Si DHCP está activo, configura el cliente DHCP para ignorar los hostnames ofrecidos por el servidor
  • Actualiza los registros DNS A y PTR
  • Renueva o vuelve a emitir cualquier certificado TLS que haga referencia al hostname antiguo
  • Reinicia los servicios dependientes del hostname (syslog, agentes de monitorización, aplicaciones Java)
  • Abre una nueva sesión de shell y verifica que hostname, hostname --fqdn y hostnamectl devuelvan valores coherentes
  • Comprueba /var/log/syslog o journalctl -b en busca de errores posteriores al cambio que hagan referencia al hostname antiguo

Preguntas frecuentes

¿Requiere hostnamectl set-hostname un reinicio para que surta efecto?

No. hostnamectl llama a la llamada al sistema sethostname(2) de inmediato, actualizando el kernel en ejecución en tiempo real. El cambio también se escribe en /etc/hostname para su persistencia. Los nuevos procesos y las nuevas sesiones de shell verán el hostname actualizado sin ningún reinicio.

¿Por qué mi hostname vuelve al valor anterior tras cada reinicio en un VPS en la nube?

Cloud-init casi con certeza lo está sobreescribiendo. Añade preserve_hostname: true a /etc/cloud/cloud.cfg o crea un archivo drop-in en /etc/cloud/cloud.cfg.d/99_hostname.cfg con la misma directiva. Esta es la causa más común de reversión del hostname en máquinas alojadas en la nube.

¿Cuál es la diferencia entre 127.0.0.1 y 127.0.1.1 en /etc/hosts?

127.0.0.1 es la dirección de loopback estándar mapeada a localhost. Las distribuciones de la familia Debian usan 127.0.1.1 como dirección de loopback secundaria específicamente para el hostname propio de la máquina, evitando conflictos cuando la máquina no tiene IP estática. En sistemas de la familia RHEL y máquinas con IP fija, usa la dirección IP primaria real para el mapeo del hostname.

¿Puedo usar un guion bajo en un hostname de Linux?

Técnicamente el sistema operativo lo aceptará, pero no deberías hacerlo. Los guiones bajos violan RFC 952 y RFC 1123. Causan fallos en la resolución DNS (BIND los rechaza por defecto), la validación de certificados TLS y la nomenclatura de nodos de Kubernetes. Usa exclusivamente guiones.

¿Cómo verifico que el hostname es completamente coherente en todas las capas del sistema?

Ejecuta la siguiente secuencia y confirma que todas las salidas coinciden:

hostname
hostname --fqdn
hostnamectl --static
cat /etc/hostname
systemd-resolve --status | grep "Current hostname"

Si alguno de estos devuelve valores diferentes, una de las capas — cloud-init, el cliente DHCP o NetworkManager — sigue sobreescribiendo la configuración estática.

15%

Ahorra 15%<\/span> en todos los servicios de hosting

Pon a prueba tus habilidades y obtén Descuento<\/span> en cualquier plan de hosting

Usa el código:

Skills
Comenzar