# rm-rf.es | Administración de sistemas

Bitácora personal de un SysAdmin Gnu/Linux, Windows, BSD...

Solaris Zones ERROR: the zonepath must be a ZFS dataset

A la hora de crear una zona en Solaris (Solaris Zones|Solaris Containers), es imprescindible que el zonepath, que es el lugar físico en el que se va a alojar sea un sistema de ficheros zfs independiente, también llamado ZFS dataset. En caso contrario recibiremos este error a la hora de instalarla:

ERROR: No zonepath dataset; the zonepath must be a ZFS dataset.

El error es lo suficientemente descriptivo. A la hora de configurar la zona, establecemos el zonepath del siguiente modo dentro del modo de configuración de la zona:

# zonecfg -z zona01
zonecfg:zona01> set zonepath=/ruta/a/la/zona

El paso previo es entonces crear el dataset correspondiente:

# zfs create /rpool/zones
# zfs create /rpool/zones/zona01

Una vez realizado, podemos establecer como zonepath “/rpool/zones/zona01″, verificar la configuración con “verify”, hacer el “commit” e instalar la zona:

# zoneadm -z zona01 install

Netapp Snapmirror entre dos cabinas

NetAppHacía ya un tiempo que no hacia entradas sobre Netapp, así que vamos a retomar un poco el tema con la utilidad Snapmirror, que permite replicar volumenes/qtrees entre filers. Snapmirror va a trabajar de forma sincrona (snapmirror_sync) y replicando los datos contra el volumen de respaldo a la vez que se escriben en el volumen original o por contra especificando una periodicidad concreta al más puro estilo cron. Los datos antes de ser escritos en disco se guardan en NVRAM con el fin de asegurar su consistencia.

Lo primero de todo, lógicamente es disponer la licencia de snapmirror en ambas cabinas, en este caso vamos a trabajar sobre netapp01 (192.168.1.100) y netapp02 (192.168.1.129). Activamos la licencia y posteriormente snapmirror:

Activación de Snapmirror

Para realizar en los dos filer:

NetApp01> license add XXXXXX
A snapmirror site license has been installed.
snapmirror enabled.
NetApp01> Sat Dec  3 20:02:32 GMT [rc:notice]: snapmirror licensed

NetApp01> license add XXXXXX
A snapmirror_sync site license has been installed.
Sync SnapMirror enabled.

NetApp01> options snapmirror.enable on
NetApp01> options snapmirror.log.enable on

Conectividad entre filers

Lo primero que debemos hacer es revisar la conectividad entre ambas cabinas:

NetApp01> ping 192.168.1.129
192.168.1.129 is alive

NetApp02> ping 192.168.1.100
192.168.1.100 is alive

Configuramos el filer origen permitiendo que el filer destino pueda acceder a él, para ello hay que añadir el hostname/ip del filer destino en el fichero /etc/snapmirror.allow. Antes de nada verificad si existe y tiene contenido para preservarlo, ya que con wrfile eliminamos lo que hubiera anteriormente:

NetApp01> rdfile /etc/snapmirror.allow
/etc/snapmirror.allow: No such file or directory

NetApp01> rdfile /etc/snapmirror.allow
/etc/snapmirror.allow: No such file or directory
NetApp01> wrfile /etc/snapmirror.allow
192.168.1.129
NetApp02
CTRL + C
read: error reading standard input: Interrupted system call
NetApp01> rdfile /etc/snapmirror.allow
192.168.1.129

Creación de volúmenes a replicar

Vamos a crear el volumen de datos en el filer origen:

NetApp01> vol create vol_backup aggr_test 200M
Creation of volume 'vol_backup' with size 200m on containing aggregate
'aggr_test' has completed.

Snapmirror

Una vez creado el volumen en el filer origen, ya podemos crear la configuración de Snapmirror en el destino. Algunas consideraciones son que para hacer Snapmirror el volumen destino tiene que estar en modo restricted. De este modo únicamente permitimos ciertas operaciones en el volumen, como snapmirror o tareas de mantenimiento, pero nunca el acceso a los datos:

Creamos el volumen:

NetApp02> vol create vol_mirror aggr0 200M
Creation of volume 'vol_mirror' with size 200m on containing aggregate
'aggr0' has completed.

Lo restringimos para poder hacer la transferencia inicial:

NetApp02> vol restrict vol_mirror
Volume 'vol_mirror' is now restricted.

Ejecutamos la transferencia inicial de datos:

NetApp02> snapmirror initialize -S 192.168.1.100:vol_backup NetApp02:vol_mirror
Transfer started.
Monitor progress with 'snapmirror status' or the snapmirror log.

Podemos ver el estado mediante snapmirror status o a través del log específico (en caso de haber sido activado como mencionaba antes):

NetApp02> snapmirror status
Snapmirror is on.
Source                    Destination           State          Lag        Status
192.168.1.100:vol_backup  NetApp02:vol_mirror   Snapmirrored   00:00:15   Idle

Configurar periodicidad de sincronización

Una vez realizada la copia inicial, podemos programar las copias incrementales cada X tiempo o que se realicen de forma síncrona. En estas copias únicamente se transferirán los bloques que hayan sido modificados desde la última realizada. Estas configuraciones se especifican en el fichero de configuración /etc/snapmirror.conf con esta estructura:

filer_origen:volumen_origen filer_destino:volumen_destino – opciones min hora dia_mes dia_sem

Para configurar que la copia sea síncrona y que los datos se mantengan actualizados al mismo tiempo en ambos volúmenes únicamente hay que añadir la palabra sync (recordad revisar antes el contenido del fichero):

NetApp02> wrfile /etc/snapmirror.conf
192.168.1.100:vol_backup NetApp02:vol_mirror - sync
CTRL+C

Nota: para la replicación síncrona el volumen tiene que tener un tamaño mínimo, sino recibiréis este error:

Sun Dec 4 08:38:00 GMT [snapmirror.src.sync.FvolSyncTooSmall:error]: The flexible volume Synchronous SnapMirror source vol_backup is 200 MB, which is smaller than the minimum supported size of 10240 MB.

Y si lo que queremos es que la sincronización se realice periódicamente en lugar de a tiempo real usamos el estilo cron que veíamos en la estructura. Vamos a configurarlo todos los días a las 23:00:

NetApp02> wrfile /etc/snapmirror.conf
192.168.1.100:vol_backup NetApp02:vol_mirror - 00 23 * *
CTRL+C

Es recomendable cuando hacemos la configuración de snapmirror y las primeras sincronizaciones tener las consolas de ambas cabinas abiertas para revisar todos los errores que puedan ir apareciendo en una y otra.

Si necesitaramos forzar manualmente la sincronización podemos hacerlo con el comando snapmirror update, con la misma sintaxis que utilizamos con la sincronización inicial:

NetApp02> snapmirror update -S 192.168.1.100:vol_backup NetApp02:vol_mirror
Transfer started.
Monitor progress with 'snapmirror status' or the snapmirror log.

Podéis revisar otros comandos como snapmirror abort para cancelar la sincronización, snapmirror break, snapmirror resync, etc.

¿Por qué ‘dig +trace’ resuelve y ‘dig’ a secas no?

Analizando un problema de resolución DNS esta tarde he detectado algo que me ha parecido curioso. El dominio en cuestión no resolvía utilizando un determinado servidor DNS. Voy a enseñaros el ejemplo con un servidor DNS ficticio “10.0.0.115″ y un nombre de dominio “test.com”:

$ dig @10.0.0.115 test.com

; <<>> DiG 9.7.3 <<>> @10.0.0.115 test.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57041
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

 ;; QUESTION SECTION:
 ;test.com.            IN    A

 ;; Query time: 214 msec
 ;; SERVER: 10.0.0.115#53(10.0.0.115)
 ;; WHEN: Wed Nov 30 18:00:33 2011
 ;; MSG SIZE  rcvd: 32

Vemos efectivamente que recibimos un SERVFAIL y no hay respuesta del registro A del dominio. El paso siguiente es hacer debug y sacar la traza con +trace para ver todos los saltos y encontrar donde está el problema:

$ dig +trace  @10.0.0.115 test.com

; <<>> DiG 9.7.3 <<>> +trace @10.0.0.115 test.com
; (1 server found)
;; global options: +cmd
.            72650    IN    NS    e.root-servers.net.
.            72650    IN    NS    f.root-servers.net.
.            72650    IN    NS    g.root-servers.net.
.            72650    IN    NS    h.root-servers.net.
.            72650    IN    NS    i.root-servers.net.
.            72650    IN    NS    j.root-servers.net.
.            72650    IN    NS    k.root-servers.net.
.            72650    IN    NS    l.root-servers.net.
.            72650    IN    NS    m.root-servers.net.
.            72650    IN    NS    a.root-servers.net.
.            72650    IN    NS    b.root-servers.net.
.            72650    IN    NS    c.root-servers.net.
.            72650    IN    NS    d.root-servers.net.
;; Received 364 bytes from 10.0.0.115#53(10.0.0.115) in 213 ms

com.            172800    IN    NS    d.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
com.            172800    IN    NS    b.gtld-servers.net.
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    e.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            172800    IN    NS    a.gtld-servers.net.
;; Received 492 bytes from 192.228.79.201#53(b.root-servers.net) in 223 ms

test.com.        172800    IN    NS    ns1.servidordns.com.
test.com.        172800    IN    NS    ns2.servidordns.com.
;; Received 117 bytes from 192.48.79.30#53(j.gtld-servers.net) in 341 ms

test.com. 14400 IN A 93.93.108.200
test.com.        86400    IN    NS    ns2.servidordns.com.
test.com.        86400    IN    NS    ns1.servidordns.com.
;; Received 101 bytes from 93.93.108.58#53(ns2.servidordns.com) in 212 ms

Curiosamente, al ejecutar el dig +trace sí que ha llegado al servidor DNS autoritativo y recibido respuesta del registro A. ¿Por qué? Esto es debido a que dig +trace no utiliza la caché del servidor DNS que estamos utilizando. En caso de que esta caché sea incorrecta nos encontraríamos con esta situación.

La solución pasa por reiniciar el servidor DNS que tiene la entrada incorrecta o esperar a que expire el TTL y automáticmaente se actualicen los registros de la zona DNS.

Gestión de particiones con parted en Linux

gnu partedHace un tiempo aprendimos a gestionar discos y particiones con fdisk, ahora vamos ver como trabajar con el programa GNU parted, que permite particionar y redimensionar discos, así como crear, redimensionar y copiar sistemas de fichero extX, swap, FAT y FAT32 (luego veremos que es recomendable utilizar las herramientas propias de Linux en lugar que las que ofrece parted en algunos casos).

Vamos a partir de un disco (virtual) sin particionar. Lo primero que vemos al acceder a parted es un error, ya que parted necesita que el disco tenga una etiqueta (LABEL) para poder trabajar con él:

# parted /dev/sdb
GNU Parted 2.1
Usando /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Error: /dev/sdb: unrecognised disk label

Normalmente se utiliza la etiqueta ‘msdos’ ya que Microsoft y OS/2 es la que reconocen, así que la asignamos con el comando mklabel:

(parted) mklabel
¿Nuevo tipo de etiqueta de disco? msdos

En todo momento podéis ver los comandos disponibles escribiendo el signo de interrogación (?)

(parted) ?
  align-check TYPE N                        check partition N for TYPE(min|opt) alignment
  check NUMBER                             do a simple check on the file system
  cp [DESDE-DISPOSITIVO] DE-NUMERO A-NUMERO   copia el sistema de ficheros a otra partición
  help [COMMAND]                           print general help, or help on COMMAND
  mklabel,mktable LABEL-TYPE               create a new disklabel (partition table)
  mkfs NUMBER FS-TYPE                      make a FS-TYPE file system on partition NUMBER
  mkpart TIPO-PART [TIPO-SF] INICIO FIN     crea una partición
  mkpartfs TIPO-PART TIPO-SF INICIO FIN     crear una partición con un sistema de ficheros
...
...
...

print: listar discos duros, particiones y espacio libre

El comando print nos permite por un lado mostrar todos los dispositivos (discos duros) reconocidos por el sistema:

(parted) print devices
/dev/sdb (268MB)
/dev/sda (12,7GB)

También las particiones de cada uno y/o el espacio libre:

(parted) print free
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sdb: 268MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Numero  Inicio  Fin    Tamaño  Typo  Sistema de ficheros  Banderas
        32,3kB  268MB  268MB         Free Space

mkpart: crear una partición sin filesystem

Parted nos da la opción de crear una partición y al mismo tiempo el sistema de ficheros (lo vemos más adelante), pero de momento únicamente vamos a crear una partición estándar sin asignar filesystem. Podemos hacer dos cosas, o seguir el asistente o escribir la línea de comandos completa directamente. Para comenzar lo más sencillo es el asistente:

Partición primaria de 100MB que será usada como filesystem ext4

(parted) mkpart
¿Tipo de partición?  primary/primaria/extended/extendida? primary
¿Tipo de sistema de ficheros?  [ext2]? ext4
¿Inicio? 1
¿Fin? 100

Si ejecutamos un print list veremos la nueva partición lista para ser formateada con mkfs.ext4:

(parted) print
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sdb: 268MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Numero  Inicio  Fin     Tamaño  Typo     Sistema de ficheros  Banderas
 1      1049kB  99,6MB  98,6MB  primary

mkpartfs: crear una partición con filesystem

Como comentaba antes, parted permite dar formato a la partición en el proceso de creación, aunque claramente vemos al ejecutarlo que recomiendan encarecidamente hacer uso de las herramientas adecuadas para ello (mkfs.extX, e2fsprogs). Así que simplemente vamos a ver como hacerlo por curiosidad (además no soporta ni ext3 ni ext4, sólo ext2…):

WARNING: you are attempting to use parted to operate on (mkpartfs) a file system.
parted’s file system manipulation code is not as robust as what you’ll find in
dedicated, file-system-specific packages like e2fsprogs. We recommend
you use parted only to manipulate partition tables, whenever possible.
Support for performing most operations on most types of file systems
will be removed in an upcoming release.

(parted) mkpartfs
WARNING: you are att.....
will be removed in an upcoming release.
¿Tipo de partición?  primary/primaria/extended/extendida? primary
¿Tipo de sistema de ficheros?  [ext2]? ext2
¿Inicio? 100
¿Fin? 200

Y ya tenemos la partición con sistema de ficheros ext2:

(parted) print
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sdb: 268MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Numero  Inicio  Fin     Tamaño  Typo     Sistema de ficheros  Banderas
 1      1049kB  99,6MB  98,6MB  primary
 2      99,6MB  200MB   101MB   primary  ext2
# mount /dev/sdb2 /test
# df -h | grep /test
/dev/sdb2              90M   13K   86M   1% /test
# umount /test

rm: eliminar una partición

Para eliminar una partición con parted es tan simple como ejecutar “rm” seguido del número de la partición:

(parted) print
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sdb: 268MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Numero  Inicio  Fin     Tamaño  Typo     Sistema de ficheros  Banderas
 1      1049kB  99,6MB  98,6MB  primary
 2      99,6MB  200MB   101MB   primary  ext2
(parted) rm 2  /pre>

check: comprobación de un filesystem

Existen otras opciones, como por ejemplo hacer un check al sistema de ficheros, pero igual que con mkpartfs recomiendan utilizar herramientas propias del sistema como fsck. Además, no soportan sistemas de ficheros ext4 o ext3:

(parted) check 1
WARNING: you are attempting to use parted to operate on (check) a file system.
parted's file system manipulation code is not as robust as what you'll find in
dedicated, file-system-specific packages like e2fsprogs.  We recommend
you use parted only to manipulate partition tables, whenever possible.
Support for performing most operations on most types of file systems
will be removed in an upcoming release.
Sin Implementación: El soporte para abrir el sistema de ficheros ext4 aún no está implementado.

Si revisáis la página man o la propia salida de ‘?’ veréis otras opciones, como mkfs para formatear sistemas de ficheros (como comentaba antes, no recomendable) y otras más interesantes como rescue, que permite recuperar una partición perdida indicando su posición de inicio y fin:

(parted) rescue INICIO FIN

Os recomiendo como siempre revisar la página man o la salida de ‘?’ para descubrir todas sus posibilidades, como redimensionar una partición con resize, moverla con move, etc. Eso sí, recordad que es preferible usar los comandos/herramientas propios del sistema para mayor seguridad en estos casos.

Montar un filesystem por UUID o label

disco duroEl beneficio de montar los sistemas de ficheros con su UUID o label en lugar de con el nombre asignado a la partición (/dev/sda1, /dev/hda2…) es que se trata de un identificador único, como su propio nombre indica: Universally Unique Identifier (UUID). Esto evita problemas que se pueden producir cuando añadimos nuevos dispositivos al sistema, movemos particiones, etc ya que el nombre de la partición puede cambiar pero no el UUID o label (etiqueta asignada por nosotros).

¿Cómo averiguamos el UUID de una partición?

Hay varias formas: con el comando blkid, tune2fs… Vamos a localizar el UUID de la partición /dev/sda2:

# tune2fs -l /dev/sda2 | grep UUID
Filesystem UUID:          528c141b-66fd-43d5-808b-4a94a639f323
# blkid /dev/sda2
/dev/sda2: UUID="528c141b-66fd-43d5-808b-4a94a639f323" TYPE="ext4"

Con esta información ya podemos añadir la entrada correspondiente al fichero /etc/fstab. Si antes estaba así:

/dev/sda2     /datos               ext4    defaults        1 1

Ahora quedaría así:

UUID=528c141b-66fd-43d5-808b-4a94a639f323     /datos        ext4    defaults   1 1

¿Y cómo averiguamos o configuramos la etiqueta del filesystem?

Es sencillo, con el comando tune2fs seguido del parámetro -L podemos configurar la etiqueta que queramos:

# tune2fs -L "DATOS" /dev/sda2
tune2fs 1.41.12 (17-May-2010)

Para consultar la etiqueta/label de la partición:

# tune2fs -l /dev/sda2 | grep "Filesystem volume name"
Filesystem volume name:   DATOS

También podemos verla con el comando anterior blkid, ahora que la partición tiene label nos muestra tanto el UUID como la etiqueta:

# blkid /dev/sda2
/dev/sda2: UUID="528c141b-66fd-43d5-808b-4a94a639f323" TYPE="ext4" LABEL="DATOS"

Y para montarla en /etc/fstab tan sencillo como:

LABEL=DATOS     /datos        ext4    defaults   1 1

Configurar una VLAN en Linux con vconfig

La forma más conocida de configurar una VLAN en Linux es la de copiar el fichero de configuración de la interfaz y añadir/cambiar ciertos parámetros, ejemplo en RHEL asumiendo el ID 80 para la VLAN:

# cp -p /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0.80
# vim /etc/sysconfig/network-scripts/ifcfg-eth0.80
    # Añadimos:
    VLAN=yes
    # Cambiamos el dispositivo:
    DEVICE=eth0.80
# /etc/init.d/network restart

El comando vconfig nos simplifica un poco la tarea de gestionar una o varias VLAN. Para el ejemplo anterior, sería tan sencillo como:

# vconfig add eth0 80
Added VLAN with VID == 80 to IF -:eth0:-

Ya tenemos la interfaz creada:

# ifconfig eth0.80
eth0.80   Link encap:Ethernet  HWaddr 08:00:27:E7:48:CC
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Podemos ver información detallada sobre ella en /proc/net/vlan/:

# cat /proc/net/vlan/eth0.80
eth0.80  VID: 80	 REORDER_HDR: 1  dev->priv_flags: 1
         total frames received            0
          total bytes received            0
      Broadcast/Multicast Rcvd            0

      total frames transmitted            0
       total bytes transmitted            0
            total headroom inc            0
           total encap on xmit            0
Device: eth0
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings:

Podríamos asignarle la IP con el comando ifconfig:

# ifconfig eth0.80 192.168.1.222 netmask 255.255.255.0

Y si quisiéramos eliminar la interfaz:

# ifconfig eth0.80 down && vconfig rem eth0.80

Recordad que tiene que estar cargado en el kernel el módulo 8021q:

# lsmod | grep 8021q
8021q                  19491  0
garp                    5901  1 8021q

En fin, ¡para gustos los colores!

SELinux ‘semanage: command not found’

semanage (SELinux Policy Management tool) es un comando que permite configurar políticas de SELinux en RHEL, CentOS, etc. Lo más probable es que en un sistema Red Hat 6 instalado por defecto (base) el comando no se encuentre disponible:

# semanage login -l
semanage: command not found

Si visteis el artículo que hice hace un tiempo sobre trucos de yum recordaréis que con “whatprovides” podemos encontrar rápidamente el paquete que contiene un determinado binario/fichero:

# yum whatprovides */semanage
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: sunsite.rediris.es
 * extras: sunsite.rediris.es
 * updates: sunsite.rediris.es
libsemanage-devel-2.0.43-4.el6.i686 : Header files and libraries used to build
                                    : policy manipulation tools
Repo        : base
Matched from:
Filename    : /usr/include/semanage

policycoreutils-python-2.0.83-19.1.el6.i686 : SELinux policy core python
                                            : utilities
Repo        : base
Matched from:
Filename    : /usr/sbin/semanage

policycoreutils-python-2.0.83-19.8.el6_0.i686 : SELinux policy core python
                                              : utilities
Repo        : updates
Matched from:
Filename    : /usr/sbin/semanage

Así que instalamos el paquete (y sus dependencias) y listo:

# yum install policycoreutils-python-2.0.83-19.1.el6.i686
# semanage login -l

Login Name         SELinux User           MLS/MCS Range            

__default__               unconfined_u              s0-s0:c0.c1023
root                      unconfined_u              s0-s0:c0.c1023
system_u                  system_u                  s0-s0:c0.c1023

Enrutar en Linux (route add/del)

Ayer expliqué cómo visualizar las tablas de rutas en Linux, pero no vimos cómo agregar nuevas rutas, modificarlas o borrarlas. Vamos a ver en una entrada rápida unos ejemplos básicos del comando route que nos enseñarán a modificar la tabla de rutas. Partimos de esta base:

$ route -n
Tabla de rutas IP del núcleo
Destino         Pasarela        Genmask         Indic Métric Ref    Uso Interfaz
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

Vamos a añadir una nueva ruta cuyo destino tenga la red 169.255.0.0/16. Todo tráfico contra esa red será redirigido a la interfaz eth0 y usará la puerta de enlace (gateway) 192.168.1.1:

$ sudo route add -net 169.255.0.0/16 gw 192.168.1.1 dev eth0
$ route -n
Tabla de rutas IP del núcleo
Destino         Pasarela        Genmask         Indic Métric Ref    Uso Interfaz
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0
169.255.0.0     192.168.1.1     255.255.0.0     UG    0      0        0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

Para eliminar esta ruta en lugar de route add usamos route del:

$ sudo route del -net 169.255.0.0/16 eth0

También podríamos enrutar tráfico de una LAN sin necesidad de pasar por una gateway:

$ sudo route add -net 169.255.0.0/16 dev eth0

O establecer la gateway (puerta de enlace) por defecto. Será utilizada en caso de no haber otra regla efectiva por delante:

$ sudo route add default gw 192.168.2.1

Como siempre, para más información:

$ man route

Recordad que estos cambios no son persistentes a reinicios, tendréis que añadir los comandos a /etc/rc.local.