Mostrando las entradas con la etiqueta configuración. Mostrar todas las entradas
Mostrando las entradas con la etiqueta configuración. Mostrar todas las entradas

martes, 6 de diciembre de 2011

Cambiar el nombre de un equipo Solaris

Cambiar el nombre a un equipo Solaris en realidad es algo muy sencillo, simplemente se debe modificar el archivo /etc/nodename con el nuevo nombre.

También debemos hacer algunas modificaciones en los archivos de configuración de red para que funcione correctamente, se debe modificar el archivo de la interfaz de red principal /etc/hostname.interfaz y en el caso de usar una IP fija, también se deberá modificar el archivo /etc/hosts

Una vez realizados estos cambios se debe reiniciar el equipo para que utilice la nueva configuración.

También es cierto que este cambio se puede realizar en línea por medio del comando hostname, en cualquier caso, los archivos deben modificarse para que el cambio sea “permanente”. El cambio en línea no es recomendable en servidores en producción debido a que hay aplicaciones que al iniciar indagan el nombre del equipo y lo utilizan durante la “corrida” del programa como parte de su funcionalidad, por lo que siempre se recomienda hacer el cambio con aplicaciones abajo.

lunes, 28 de noviembre de 2011

Configuración avanzada de un servidor DNS BIND

En una entrada anterior vimos cómo configurar a un servidor DNS BIND para contener un dominio, el loopback y una zona con los servidores raíz de Internet.

En esta ocasión veremos cómo activar el rndc y la actualización dinámica (DDNS).

Para esto utilizaré dos equipos Solaris 10, uno contendrá el servidor y otro lo utilizaremos como cliente.

Además del archivo con los servidores raíz (db.cache) y del loopback (db.127.0.0) voy a crear dos archivos más, uno para el dominio y otro para la resolución inversa de mi red local (192.168.100.0/24)

db.unixymas.com.mx

$TTL 3h
; Zona unixymas.com.mx
@       IN SOA draco.unixymas.com.mx. administrator.unixymas.com.mx. (
                01 ; serial
                3h ; refresh
                1h ; retry
                1w ; expire
                1h ) ; negative ttl
@       IN NS draco.unixymas.com.mx.
draco   IN A 192.168.100.10

db.192.168.100

$TTL 3h
; Zona 100.168.192.in-addr.arpa
@       IN SOA draco.unixymas.com.mx. administrator.unixymas.com.mx. (
                01 ; serial
                3h ; refresh
                1h ; retry
                1w ; expire
                1h ) ; negative ttl
@       IN NS draco.unixymas.com.mx.
10      IN PTR draco.unixymas.com.mx.

Observen que en realidad los dos archivos solo contienen los registros SOA y NS, esto es porque los vamos a actualizar en forma dinámica.

Para actualizar en forma dinámica una zona es necesario otorgarle la autoridad a la zona mediante la opción allow-update en el archivo de configuración /etc/named.conf . Se le puede otorgar la autoridad a una IP, a una lista; pero la forma más segura es por medio de una llave. Dicha llave es una cadena cifrada con el algoritmo HMAC-MD5.

Lo primero es crear la llave por medio del comando dnssec-keygen en la forma: dnssec-keygen –a HMAC-MD5 –b 128 –n HOST llave

# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST update-key
Kupdate-key.+157+04139

Con este comando generamos 2 archivos uno con terminación .key y otro con .private . En el caso de este algoritmo en realidad los dos archivos contienen información similar, vamos a revisar el .private

Kupdate-key.+157+04139.private

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: onuHJl6U5lqKEk8/9mbMQw==
Bits: AAA=

La cadena señalada como key es la que vamos a utilizar.

El archivo de configuración queda de la siguiente forma:

options {
        directory "/var/named";
};

zone "." {
        type hint;
        file "db.cache";
};

zone "0.0.127.in.addr.arpa" {
        type master;
        file "db.127.0.0";
};

zone "unixymas.com.mx" {
        type master;
        file "db.unixymas.com.mx";
        allow-update { key "update-key"; };
};

zone "100.168.192.in-addr.arpa" {
        type master;
        file "db.192.168.100";
        allow-update { key "update-key"; };
};

key "update-key" {
        algorithm hmac-md5;
        secret "onuHJl6U5lqKEk8/9mbMQw==";
};

Ahora ya podemos iniciar el BIND, desde otro equipo, en el que ya configuramos al servidor draco.unixymas.com.mx como su servidor de dominio, vamos a agregar un nuevo nombre por medio del comando nsupdate en la formal: nsupdate –k archivo.key ó nsupdate –k archivo.private

Esto nos va a llevar al modo interactivo, desde el cual, podemos agregar o eliminar nombres con los siguientes comandos:

update add nombre ttl tipo dato

update delete nombre

En este ejemplo, vamos a agregar una dirección en el dominio unixymas.com.mx

# nsupdate -k Kupdate-key.+157+04139.private
> update add equuleus.unixymas.com.mx 10800 a 192.168.100.20
>

La línea en blanco al final, le indica que ejecute el cambio.

Para la resolución inversa la actualización es similar:

# nsupdate -k Kupdate-key.+157+04139.private
> update add 20.100.168.192.in-addr.arpa 10800 ptr equuleus.unixymas.com.mx
>

Ahora vamos a ver cómo se activa el rndc, necesitamos como requisito indispensable una llave, puede ser la misma para el DNS dinámico, pero en este ejemplo vamos a crear una nueva:

# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST rndc-key
Krndc-key.+157+11727

Ahora vamos a activarlo en el archivo de configuración con la opción controls, el archivo queda finalmente así:

/etc/named.conf

options {
        directory "/var/named";
};

zone "." {
        type hint;
        file "db.cache";
};

zone "0.0.127.in.addr.arpa" {
        type master;
        file "db.127.0.0";
};

zone "unixymas.com.mx" {
        type master;
        file "db.unixymas.com.mx";
        allow-update { key "update-key"; };
};

zone "100.168.192.in-addr.arpa" {
        type master;
        file "db.192.168.100";
        allow-update { key "update-key"; };
};

key "update-key" {
        algorithm hmac-md5;
        secret "onuHJl6U5lqKEk8/9mbMQw==";
};

controls {
        inet * allow { any; } keys { "rndc-key"; };
};

key "rndc-key" {
        algorithm hmac-md5;
        secret "5V73kf47NK6HjvygCjCJ9w==";
};

En el cliente, es necesario crear el archivo /etc/rndc.conf

/etc/rndc.conf

options {
        default-server 192.168.100.10;
        default-key "rndc-key";
};

key "rndc-key" {
        algorithm hmac-md5;
        secret "5V73kf47NK6HjvygCjCJ9w==";
};

Por último observen que los archivos de zona ya fueron actualizados por el BIND:

db.unixymas.com.mx

$ORIGIN .
$TTL 10800      ; 3 hours
unixymas.com.mx         IN SOA  draco.unixymas.com.mx. administrator.unixymas.com.mx. (
                                2          ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                3600       ; minimum (1 hour)
                                )
                        NS      draco.unixymas.com.mx.
$ORIGIN unixymas.com.mx.
draco                   A       192.168.100.10
equuleus                A       192.168.100.20

db.192.168.100

$ORIGIN .
$TTL 10800      ; 3 hours
100.168.192.in-addr.arpa IN SOA draco.unixymas.com.mx. administrator.unixymas.com.mx. (
                                2          ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                3600       ; minimum (1 hour)
                                )
                        NS      draco.unixymas.com.mx.
$ORIGIN 100.168.192.in-addr.arpa.
10                      PTR     draco.unixymas.com.mx.
20                      PTR     equuleus.unixymas.com.mx.

jueves, 27 de octubre de 2011

Configurar una interfaz de red en Solaris (parte 3)

Continuando con el tema de configurar una interfaz de red, en esta ocasión veremos cómo configurar una IP virtual.

Una IP virtual es aquella que se agrega a una interfaz ya configurada con otra IP llamada real, la razón por la que se le denomina IP virtual es porque es necesario crear una nueva instancia del dispositivo, es decir, creamos un dispositivo virtual con la dirección adicional. Normalmente una IP virtual se encuentra en la misma LAN de la IP real, sin embargo, no es una regla, depende del uso que se le va a dar.

Los usos de una IP virtual pueden ser muy variados: es posible que la aplicación requiera una IP para cada componente; puede ser una aplicación que originalmente corría en otro servidor tuvo que ser "migrada" al actual; también es posible que sea una IP asociada a una máquina virtual (un contenedor), o tal vez, se trate de un esquema de alta disponibilidad en el que la ejecución de la aplicación se puede "pasar" de un servidor a otro con todo y su IP (un cluster activo-pasivo). En cualquier caso, aunque la forma de crear las IP's virtuales puede variar, en esencia, es el mismo principio para todas.

Para mostrar cómo se configura la IP virtual, voy a utilizar un servidor llamado solaris10 con la IP fija 192.168.100.51/255.255.255.0 y vamos a crear la IP virtual 192.168.100.50

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.100.51 netmask ffffff00 broadcast 192.168.100.255
        ether 0:c:29:5b:b3:1d
# netstat -rn
Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              192.168.100.2        UG        1          0
192.168.100.0        192.168.100.51       U         1          3 e1000g0
224.0.0.0            192.168.100.51       U         1          0 e1000g0
127.0.0.1            127.0.0.1            UH        3         68 lo0

Ahora vamos a crear la IP virtual con la instrucción addif del comando ifconfig.

# ifconfig e1000g0 addif 192.168.100.50 netmask + broadcast + up
Created new logical interface e1000g0:1

Con los parámetros netmask + y broadcast + le indico que configure la máscara y el broadcast más convenientes; con up  que deje "encendida" a la interfaz, es decir, que permita el envío y recepción a través de la interfaz. Ahora veamos cómo queda, noten que el dispositivo virtual no posee una MAC, debido a que utiliza la misma que el dispositivo real.

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.100.51 netmask ffffff00 broadcast 192.168.100.255
        ether 0:c:29:5b:b3:1d
e1000g0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.100.50 netmask ffffff00 broadcast 192.168.100.255
# netstat -rn
Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              192.168.100.2        UG        1          0
192.168.100.0        192.168.100.51       U         1          5 e1000g0
192.168.100.0        192.168.100.50       U         1          0 e1000g0:1
224.0.0.0            192.168.100.51       U         1          0 e1000g0
127.0.0.1            127.0.0.1            UH        3         68 lo0

Como les mencione anteriormente, existen varias formas de crear las IP's virtuales, una muy usual es crear el dispositivo virtual con plumb de la forma: ifconfig interfaz:instancia plumb; posteriormente se configura la IP igual que un dispositivo real. Mi recomendación es utilizar addif por dos razones: la primera, ahorran el paso de crear el dispositivo; la segunda, no necesitan llevar la cuenta de qué instancia sigue.

Para dejar esta configuración en forma permanente vamos a modificar al archivo /etc/hostname.interfaz que en este caso se llama /etc/hostname.e1000g0:

# cat /etc/hostname.e1000g0
192.168.100.51 netmask + broadcast + up \
addif 192.168.100.50 netmask + broadcast + up

Como podrán observar son los parámetros del comando ifconfig, la función del backslash (\) es simplemente separar lo que corresponde a la IP real de la virtual.

De esta forma, la IP virtual queda operando y podrá el servidor recibir conexiones tanto por la IP real como la virtual, por lo cual, si la IP virtual va a ser utilizada por alguna aplicación que reciba conexiones desde otro equipo (un servidor web, por ejemplo) no tendrá ningún problema (estas conexiones son las conocidas como conexiones entrantes). Sin embargo, quiero resaltar el hecho de que en el caso de las conexiones salientes, por la forma en la que la tabla de ruteo señala la ruta hacia la red local, utilizará ambas IP's para salir, es decir, en algunas ocasiones se conectará por medio de la 192.168.100.51 y en otras por la 192.168.100.50. Menciono ésto porque en algunos sistemas es relevante desde que IP se inicia la conexión y esto puede ser por razones administrativas, funcionales o de seguridad.

La forma de controlar desde qué IP se va conectar el equipo es "depreciando" la IP con la que no queremos se conecte por medio de la instrucción deprecated del comando ifconfig, de la forma: ifconfig interfaz deprecated. En nuestro ejemplo, vamos depreciar la IP real: ifconfig e1000g0 deprecated

# ifconfig e1000g0 deprecated
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0: flags=1040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4> mtu 1500 index 2
        inet 192.168.100.51 netmask ffffff00 broadcast 192.168.100.255
        ether 0:c:29:5b:b3:1d
e1000g0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.100.50 netmask ffffff00 broadcast 192.168.100.255
# netstat -rn
Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              192.168.100.2        UG        1          0
192.168.100.0        192.168.100.50       U         1          2 e1000g0:1
192.168.100.0        192.168.100.50       U         1          0 e1000g0
224.0.0.0            192.168.100.51       U         1          0 e1000g0
127.0.0.1            127.0.0.1            UH        4        147 lo0

Observen el cambio en la tabla de ruteo para la red local, le indica que tanto en la interfaz real como en la virtual utilice la IP 192.168.100.50 (Nota: en el caso del multicast 224.0.0.0 no afecta porque no es a la red local). Para que la configuración quede en forma permanente solo basta agregar la instrucción deprecated en el archivo /etc/hostname.interfaz en la línea que corresponda a la IP a depreciar:

# cat /etc/hostname.e1000g0
192.168.100.51 netmask + broadcast + deprecated up \
addif 192.168.100.50 netmask + broadcast + up

miércoles, 26 de octubre de 2011

Configurar una interfaz de red en Solaris (parte 2)

En la entrada anterior vimos cómo configurar a una interfaz de red con una IP fija, en esta ocasión, veremos como configurarla con una IP dinámica por medio del DHCP.

Pero, ¿qué es el DHCP?

Es un servicio TCP/IP que utiliza el protocolo UDP con el puerto 67 y que, básicamente, consiste en asignarle una IP a quién lo “solicite” de un pool de IP’s que posee para este fin.

Lo más lógico sería suponer que este protocolo debería operar en capa 3 pero no es así, opera en capa 5.

¿Cómo es posible tener una comunicación en ese nivel sin tener una dirección IP?. El cliente DHCP, provisionalmente, asigna la IP 0.0.0.0 a la interfaz y envía una petición a la IP 255.255.255.255, esta IP esta reservada como un broadcast en cualquier red local no importando su direccionamiento. El servidor atiende la petición, asigna una IP y la “ofrece” al cliente; el cliente acepta la IP ofrecida y la solicita; el servidor asocia la IP a la MAC del cliente y envía una respuesta de confirmación junto con otros parámetros tales como: máscara, dirección del broadcast y ruteador. Adicional a esto, el servidor puede enviar otros datos y que, por lo regular, incluyen las direcciones de los servidores DNS, el nombre del dominio, las direcciones de los servidores WINS, etc.

En Solaris el cliente DHCP se llama dhcpagent y es controlado por el comando ifconfig utilizando la instrucción dhcp, de la forma: ifconfig interfaz dhcp start

# ifconfig e1000g0 dhcp start

En esta forma, el agente asignará una IP en forma dinámica para la interfaz, además del broadcast y la máscara. Adicionalmente, dará de alta una ruta en la tabla de ruteo.

Lo normal es que este tipo de configuración se utilice sólo para estaciones de trabajo (más adelante comento la razón) y solamente en la interfaz principal. Generalmente se configura en forma permanente de la siguiente manera:

  • Se crea el archivo /etc/dhcp.interfaz en donde interfaz representa el nombre de la interfaz principal, este archivo normalmente esta vacío y puede contener parámetros específicos (consultar archivo /etc/default/dhcpagent)
  • Crear o modificar el archivo /etc/hostname.interfaz para que contenga la línea: inet hostname, donde hostname es un nombre de host que, por lo regular, es el nombre del servidor.

En este ejemplo, creamos el archivo vacío: /etc/dhcp.e1000g0 y en el archivo hostname.e1000g0 dejamos la línea: inet solaris10 (solaris10 es el nombre del equipo).

Después de esto podemos reiniciar el equipo, sin embargo, antes de eso, les recomiendo editar el archivo /etc/hosts, si existe una línea para el hostname del equipo, borrarla, y en la línea de la dirección 127.0.0.1 localhost adicionarle como un nombre adicional loghost de esta forma:

# cat /etc/hosts
#
# Internet host table
#
::1     localhost
127.0.0.1       localhost       loghost

Reiniciamos y observen cómo configura a la interfaz:

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 2
        inet 192.168.100.101 netmask ffffff00 broadcast 192.168.100.255
        ether 0:c:29:5b:b3:1d
# netstat -rn

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              192.168.100.2        UG        1          0 e1000g0
192.168.100.0        192.168.100.101      U         1         17 e1000g0
224.0.0.0            192.168.100.101      U         1          0 e1000g0
127.0.0.1            127.0.0.1            UH        4        401 lo0
# cat /etc/hosts
#
# Internet host table
#
::1     localhost
127.0.0.1       localhost       loghost
192.168.100.101 solaris10       # Added by DHCP

Adicional a esto, también configura la parte del cliente DNS:

# cat /etc/resolv.conf
domain unixymas.com.mx
nameserver 192.168.100.2

# cat /etc/nsswitch.conf
#
# Copyright 2006 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
# ident "@(#)nsswitch.files     1.14    06/05/03 SMI"

#
# /etc/nsswitch.files:
#
# An example file that could be copied over to /etc/nsswitch.conf; it
# does not use any naming service.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.

passwd:     files
group:      files
#hosts:      files # Commented out by DHCP
hosts: files dns # Added by DHCP
#ipnodes:    files # Commented out by DHCP
ipnodes: files dns # Added by DHCP
networks:   files
protocols:  files
rpc:        files
ethers:     files
netmasks:   files
bootparams: files
publickey:  files
# At present there isn't a 'files' backend for netgroup;  the system will
#   figure it out pretty quickly, and won't use netgroups at all.
netgroup:   files
automount:  files
aliases:    files
services:   files
printers:       user files

auth_attr:  files
prof_attr:  files
project:    files

tnrhtp:     files
tnrhdb:     files

En esta forma nuestro equipo queda configurado con una IP dinámica, lo cual es muy conveniente para una estación de trabajo y no importa si es necesario modificar a la red o si es necesario moverla a otra parte, siempre y cuando, en nuestra red exista un servidor DHCP.

Como les comentaba anteriormente, no es recomendable esta configuración para un servidor, menos si se trata de un servidor en producción ya que la IP puede ser modificada por el servidor DHCP. Aunque se realice la modificación en un servidor DNS con la nueva dirección, lo cierto es que existiría un tiempo de desfasamiento entre la IP anterior y la nueva que, simplemente, se puede resolver evitando esta modificación en forma dinámica (Nota: de hecho, este desfasamiento es la razón por la que en los ambientes de alta disponibilidad los servicios siempre van asociados cada uno a una IP, ya que es más rápido migrar una IP de una interfaz a otra que hacer el cambio en un servidor de dominio). Aunque existe la posibilidad de asignar en forma permanente la IP en el servidor DHCP, la mejor práctica es reservar siempre una parte del segmento de red para su uso con IP’s fijas (e incluso reservar segmentos completos para esto) por lo que en el servidor DHCP se configuran fragmentos de segmentos de red como pool de IP’s.

Y ya que mencionamos ambientes de alta disponibilidad, algo muy básico en éstos es el uso de IP’s virtuales por lo que en la siguiente entrega veremos cómo configurarlas en su forma básica.

jueves, 20 de octubre de 2011

Configurar una interfaz de red en Solaris (parte 1)

Para que nuestro equipo Solaris (estación de trabajo o servidor) se pueda conectar a una red es necesario configurar, al menos, una interfaz de red con una IP estática o dinámica (la diferencia entre una IP estática y dinámica es que la primera debe ser proporcionada en forma manual y la segunda será proporcionada por otro servidor dedicado a esto a través del protocolo DHCP).

Si bien, es cierto, podemos configurar a una interfaz de red desde la instalación de sistema operativo, muchas veces requeriremos de configurar interfaces después de la instalación.

El primer paso es identificar la NIC que debemos activar, aunque es, en apariencia, muy obvio en realidad es sorprendente el número de ocasiones que tendremos que “sufrir” un poco para encontrar el dispositivo que corresponde. Aunque existen otros métodos, creo que el más genérico es por medio del comando prtdiag.

# prtdiag –v | less

Yo en lo personal, prefiero utilizar less en lugar de more debido a que es más fácil navegar a través de la salida del comando prtdiag.

Buscamos la cadena “net” y revisamos el dispositivo, en mi ejemplo, éste fue el dispositivo que encontré:

         name='model' type=string items=1
             value='Ethernet controller'
         name='power-consumption' type=int items=2
             value=00000001.00000001
         name='66mhz-capable' type=boolean
         name='devsel-speed' type=int items=1
             value=00000001
         name='interrupts' type=int items=1
             value=00000001
         name='max-latency' type=int items=1
             value=00000000
         name='min-grant' type=int items=1
             value=000000ff
         name='subsystem-vendor-id' type=int items=1
             value=000015ad
         name='subsystem-id' type=int items=1
             value=00000750
         name='unit-address' type=string items=1
             value='0'
         name='class-code' type=int items=1
             value=00020000
         name='revision-id' type=int items=1
             value=00000001
         name='vendor-id' type=int items=1
             value=00008086
         name='device-id' type=int items=1
             value=0000100f
     Interrupt Specifications:
         Interrupt Priority=0x6 (ipl 6), vector=0xa (10)
     Device Minor Nodes:
         dev=(71,1)
             dev_path=/pci@0,0/pci15ad,790@11/pci15ad,750@0:e1000g0
                 spectype=chr type=minor
                 dev_link=/dev/e1000g0
         dev=(71,1002)
             dev_path=<clone>
             Device Minor Layered Under:
                 mod=udp accesstype=chr
                     dev_path=/pseudo/udp@0
         dev=(71,1003)
             dev_path=<clone>
             Device Minor Layered Under:
                 mod=udp accesstype=chr
                     dev_path=/pseudo/udp@0

Observen que indica que se trata de un dispositivo Ethernet y que la ruta del dispositivo es la que está indicada como dev_link y que corresponde a /dev/e1000g0

En este caso, es la única interfaz que posee el equipo, por lo que este debe ser el dispositivo que busco sin duda alguna, sin embargo, ya es muy común encontrar servidores con más de una interfaz, por lo que debemos constatar que si corresponde a la interfaz con la que debemos trabajar, habrá ocasiones en la que debamos utilizar el método de prueba y error.

Ya seleccionado el dispositivo de la interfaz vamos proceder a activarla con el comando ifconfig.

# ifconfig e1000g0 plumb

Con el primer parámetro le indicamos el dispositivo con el que vamos a trabajar, no es necesario indicar toda la ruta /dev/e1000g0. El siguiente es la instrucción plumb, la cual, activa al dispositivo.

A continuación, procedemos a configurar la interfaz, también con el comando ifconfig.

# ifconfig e1000g0 inet 192.168.188.22 netmask 255.255.255.0 broadcast + up

Los parámetros son:

  • e1000g0: El dispositivo
  • inet 192.168.188.22: La IP fija que vamos a asignarle a la interfaz
  • netmask 255.255.255.0: La máscara de red
  • broadcast +: Que utilice como dirección reservada para el broadcast la última dirección del segmento
  • up: Que deje a la interfaz arriba (es decir, encendida)

Es una buena práctica el indicarle todos estos parámetros ya que de lo contrario corremos el riesgo de que quede mal establecido el segmento de red y el equipo no pueda localizar algunas direcciones (Nota: en la práctica real, observarán que en algunas ocasiones el servidor no puede conectarse con algunas direcciones, pero con otras si, en esos casos lo primero que debemos revisar es si los parámetros de subnet mask y brodcast están bien designados).

Una vez realizado lo anterior, podemos decir que ya tenemos el equipo en red, sin embargo, hasta este punto solo va a ser posible su comunicación con otros equipos de la red local, es necesario configurar un ruteador para que puede comunicarse con equipos remotos.

En este ejemplo, vamos a configurar el ruteador por default utilizando el comando route.

# route add default 192.168.188.2

Los parámetros que utilizamos indican lo siguiente:

  • add: Le indica que vamos a agregar una ruta, la instrucción contraria es delete
  • default: Esta palabra indica que ésta es la ruta por default, en su lugar, puede ser la dirección de una red o la de un host (por ejemplo: host 192.168.190.2 ó net 192.168.190.0)
  • 192.168.188.2: La IP del ruteador, esta IP debe ser local

La forma de revisar la configuración con los comandos ifconfig (para la interfaz) y netstat (para el ruteador) es la siguiente:

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.188.22 netmask ffffff00 broadcast 192.168.188.255
        ether 0:c:29:4b:86:96
# route add default 192.168.188.2
add net default: gateway 192.168.188.2
# netstat -rn

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              192.168.188.2        UG        1          0
192.168.188.0        192.168.188.22       U         1          1 e1000g0
224.0.0.0            127.0.0.1            U         1          0 lo0
127.0.0.1            127.0.0.1            UH        9        463 lo0

Por último, vamos a configurar al equipo para que esta configuración quede en forma permanente, para la configuración de la interfaz, vamos a crear en el directorio /etc un archivo llamado hostname.nic donde nic es el nombre de la interfaz, en este ejemplo: hostname.e1000g0. En este archivo podemos, simplemente, agregar la dirección IP. Sin embargo, en muchos manuales encontrarán que en este archivo por lo regular se escribe un nombre de host (hostname) en la forma canónica, dicho hostname debe existir en el archivo /etc/hosts. Adicional a esto, lo normal es que una de las interfaces utilice como hostname el mismo nombre definido para el equipo (a esta interfaz se le conoce como la interfaz principal). Para este ejemplo, en el que solo va a quedar configurada una sola interfaz, vamos a utilizar el modo canónico escribiendo en el archivo hostname.e1000g0 el nombre del equipo (solaris10) y el archivo /etc/hosts lo dejaremos de la siguiente forma:

# cat /etc/hosts
#
# Internet host table
#
::1     localhost
127.0.0.1       localhost
192.168.188.22  solaris10       loghost

También es importante indicar la máscara de red, para lo cual, utilizamos el archivo /etc/inet/netmasks para indicar la máscara que corresponde a la red, recuerden que la máscara para este ejemplo es la 255.255.255.0, por lo que la red es la 192.168.188.0/24 (en un artículo anterior se muestra cómo se definen los segmentos). El archivo quedará en la siguiente forma:

# cat /etc/inet/netmasks
#
# The netmasks file associates Internet Protocol (IP) address
# masks with IP network numbers.
#
#       network-number  netmask
#
# The term network-number refers to a number obtained from the Internet Network
# Information Center.
#
# Both the network-number and the netmasks are specified in
# "decimal dot" notation, e.g:
#
#               128.32.0.0 255.255.255.0
#
192.168.188.0   255.255.255.0

Y por último, el ruteador por default se define mediante el archivo /etc/defaultrouter, al cual, contendrá la dirección del ruteador, en este ejemplo, la 192.168.188.2.

De esta forma, nuestra interfaz quedará configurada con una IP fija, en el siguiente artículo veremos como utilizar una IP dinámica.

martes, 5 de octubre de 2010

Activar el uso de sesiones gráficas remotas en Solaris 10 (XDMCP)

Esta es la forma de permitir el uso de sesiones gráficas remotas a un servidor Solaris 10 que fue instalado dándole “si” a la opción de cerrar servicios remotos.

En un servidor así, solo se permite el inicio de sesiones gráficas desde la consola, pero si es necesario el poder iniciar sesión desde otras estaciones de trabajo, lo que debemos hacer es activar al administrador de sesiones para que permita la conexión remota.

Esta sesión remota se logra mediante el protocolo XDMCP, el cual, utiliza el puerto 177 UDP, este servicio lo proporciona el cde-login, por lo que vamos a realizar una modificación en este servicio utilizando el comando svccfg:

svccfg -s cde-login

Al ejecutar este comando vamos a entrar a “una consola” que nos permitirá modificar los atributos del servicio, ejecutamos lo siguiente:

svc:/application/graphical-login/cde-login> setprop dtlogin/args = astring: ""
svc:/application/graphical-login/cde-login> end

Después, le indicamos al servicio que vuelva a “leer” sus atributos y que reinicie:

svcadm refresh cde-login
svcadm restart cde-login

Por último, vamos a activar el servidor de fuentes, el cual, es necesario para algunos servidores X.

svcadm enable xfs

image

lunes, 13 de septiembre de 2010

Configuración de un servidor DNS BIND


Este servidor nos va a permitir implementar el servicio DNS dentro de nuestra red, lo cual, nos va a facilitar el encontrar los servidores con las aplicaciones a las que necesitamos entrar y esto va a ser el punto de partida para nuestra intranet.

Normalmente el BIND se encuentra ya instalado en Solaris y casi en cualquier distro de Linux, lo recomendable es utilizar versiones nuevas de sistema operativo y que sea el mismo sistema de actualización del S.O. el que se encargue de actualizar, la desventaja de esto es que las versiones y funcionalidades disponibles son a criterio del fabricante. Si queremos hacer nuestra propia instalación es muy sencillo, solo se debe obtener el archivo fuente de ISC, compilarlo e instalarlo; la desventaja de esto es que debemos estar muy pendientes de las actualizaciones, especialmente, aquellas en las que la seguridad del servidor se vea comprometida.

En este ejemplo vamos a habilitar un servidor BIND 9 para que pueda resolver direcciones del internet, además de crear una zona para el dominio "unixymas.com.mx".

En internet hay un conjunto de servidores que nos va a permitir resolver direcciones, a estos se les llama "servidores raíz", siempre que lo necesitemos podemos obtener una lista actualizada de estos servidores y que además nos puede ser útil para nuestro servidor, se puede obtener por un ftp anónimo a la IP 198.41.0.6, buscamos y bajamos el archivo named.root o db.cache, son el mismo.

Por convención, el directorio donde vamos a alojar a los archivos con las zonas es el /var/named, si no existe, lo creamos, es posible utilizar otro, siempre y cuando, sea para uso exclusivo del BIND.

También es lo usual nombrar a los archivos con las zonas cómo db.dominio. Por ejemplo, para la zona "unixymas.com.mx" el archivo se va a llamar db.unixymas.com.mx, el archivo con los servidores raíz va a llamarse db.cache, por lo que al archivo que bajamos por ftp lo vamos a renombrar así y lo vamos a depositar en /var/named.

El archivo db.unixymas.com.mx va a incluir en este ejemplo a todos los nodos de mi red interna, es muy recomendable que todos los nodos de nuestra red tengan un nombre, podemos hacer una especificación de nombres genéricos para la mayor parte de las IP's y solo emplear nombres específicos para IP's de servidores, en mi ejemplo, mi red es 192.168.188.0/24, esto quiere decir que tengo direcciones desde la 192.168.188.1 hasta la 192.168.188.254, por lo que decidí nombrar a las direcciones de la forma: 188-1.unixymas.com.mx, 188-2.unixymas.com.mx hasta 188-254.unixymas.com.mx y solo la 192.168.188.138 que es la de mi servidor la voy a llamar solaris10.unixymas.com.mx

$TTL 3h
@      IN SOA solaris10.unixymas.com.mx. webmaster.solaris10.uniymas.com.mx. (
           2010091201 ; serial
           3h ; refresh
           1h ; retry
           1w ; expire
           1h ) ; negative TTL
 
@      IN NS solaris10.unixymas.com.mx.
 
188-1  IN A 192.168.188.1
188-2  IN A 192.168.188.2

solaris10 IN A 192.168.188.138

 
El primer renglón corresponde al tiempo en el que los datos de esta zona deben permanecer en el cache de un servidor DNS (Time To Live), aquí se le indica que deben ser 3 horas.

El carácter @ es una abreviatura que se sustituye por el nombre definido para la zona.

Lo siguiente es el registro SOA, el cual, le otorga la autoridad sobre este dominio al servidor indicado, en este caso, solaris10.unixymas.com.mx, además, indica que la cuenta de correo a la que se puede recurrir para cualquier asunto relacionado a este dominio es webmaster@solaris10.unixymas.com.mx, nótese que no estamos utilizando el caracter @ para la dirección de correo y que al final de las direcciones estamos agregando un punto, es muy importante no olvidarlo. Después de esto hay un paréntesis y continua el registro en las siguientes líneas, en la que dice serial es un número cualquiera y que debe ser actualizado siempre que se realice una actualización sobre este archivo, no hay ninguna restricción en lo que respecta al número inicial, puede ser simplemente el número 1, yo en lo personal, utilizo la fecha en la que cree el archivo para tener una idea de cuándo fue que se creó. El siguiente es una indicación para los servidores esclavos del tiempo que debe transcurrir para que corroboren la información. A continuación, tiempo en el que debe hacer un reintento en el caso de que recibiera una respuesta incorrecta. El siguiente es el tiempo en el que el servidor esclavo va a dar respuestas a peticiones que tengan que ver con esta zona a pesar de no tener comunicación con el maestro, después de ese tiempo, se considera la zona como ya muerta. Finalmente el TTL negativo se refiere al tiempo de permanencia en caso de tener respuesta negativa (honestamente, no sé qué diferencia hay con el refresh).

El siguiente registro es el NS el cual, indica el nombre del servidor con la información de la zona, aunque en este caso es el mismo, no siempre es igual, se puede ser un servidor con autoridad y obtener las direcciones de otro.

Finalmente, esta toda la lista de direcciones de nuestro dominio en registros A, estos son lo que indican que IP corresponde a cada dirección del dominio, aquí debemos tomar nota que las direcciones no tienen punto final, esto es porque al no tener un punto final, el servidor va a agregar toda la zona a estas direcciones, es decir, el 188-1 va ser llamado 188-1.unixymas.com.mx.

Omití el agregar todo el archivo, solo destaco el registro que corresponde a la dirección del servidor.

Otra zona que vamos a agregar es en la que se encuentra la IP 127.0.0.1, al archivo lo vamos a llamar db.127.0.0, Esta dirección se reserva para el "loopback" es decir, la IP se traduce como "yo mismo".

$TTL 3h
@      IN SOA solaris10.unixymas.com.mx. webmaster.solaris10.uniymas.com.mx. (
            2010091201 ; serial
            3h ; refresh
            1h ; retry
            1w ; expire
            1h ) ; TTL
 
@      IN NS solaris10.unixymas.com.mx.
 
1      IN PTR localhost.
 
En este caso, tenemos el TTL, un registro SOA, un registro NS y para el número 1, el cual corresponde a 127.0.0.1, hay un registro PTR (apuntador) al cual se le llama dirección inversa, es decir, una IP que apunta a una dirección, las zonas que se refieren a IP's son parte de un dominio reservado "in-addr.arpa" y su nomenclatura es inversa a la dirección IP, en este ejemplo, la zona es: "0.0.127.in-addr.arpa".

Terminado todo esto, procedemos a "activar" nuestras zonas por medio del archivo de configuración /etc/named.conf

options {
     directory "/var/named";
};

zone "." in {
     type hint;
     file "db.cache";
};
 
zone "0.0.127.in-addr.arpa" in {
     type master;
     file "db.127.0.0";
};
 
zone "unixymas.com.mx" in {
     type master;
     file "db.unixymas.com.mx";
};

La directiva "options" es la que corresponde las opciones globales, aquí solamente estamos indicando el directorio de trabajo.

Después aparecen directivas zone para cada una de las zonas que definimos, dentro de las directivas tenemos la opción type, la cual indica la relación de este servidor con la zona (aquí utilizamos solo 2, "hint" que indica que para la zona "." (raíz) el archivo proporciona los servidores raíz y "master" que indica que el servidor es el maestro) y la opción file, la cual, corresponde al archivo con la zona.

Ya configurado, podemos ejecutar el programa named, el cual, se va a ejecutar en forma de demonio, van a aparecer en bitácora mensajes similares a estos:

Sep 13 16:20:19 solaris10 named[877]: [ID 873579 daemon.notice] starting BIND 9.6.1-P3
Sep 13 16:20:19 solaris10 named[877]: [ID 873579 daemon.notice] built with --prefix=/usr --with-libtool --bindir=/usr/sbin --sbindir=/usr/sbin --libdir=/usr/lib/dns --sysconfdir=/etc --localstatedir=/var --with-openssl=/usr/sfw --enable-threads=yes --enable-devpoll=yes --enable-fixed-rrset --disable-openssl-version-check -DNS_RUN_PID_DIR=0
Sep 13 16:20:22 solaris10 named[877]: [ID 873579 daemon.notice] command channel listening on 127.0.0.1#953
Sep 13 16:20:22 solaris10 named[877]: [ID 873579 daemon.notice] couldn't add command channel ::1#953: address not available
Sep 13 16:20:22 solaris10 named[877]: [ID 873579 daemon.notice] running
 
Hay un error que menciona que no puede abrir el Puerto 953, esto quiere decir que no tiene activo el servicio rndc para su administración remota, por lo que no afecta para este ejemplo, lo importante es el último que dice: running

Con esto damos por finalizado este ejemplo, espero no haberme extendido mucho.