32 33 34_35_36_37_38_39_domino

linux en la empresaWindows contra Linux

32 Linux+ 2/2007


33www.lpmagazine.org

linux

@so

ftwar

e.co

m.p

lControladores de dominioUn controlador de dominio es una entidad administrativa, esto es, no es un ordenador en concreto, sino un conjunto de ordenadores agrupados que se ciñen a unas reglas de seguridad y autenticación comunes. Para regular un dominio, se precisa al menos de un equipo que sea el controlador principal, la fuente primera donde se almacenan las reglas del dominio, y donde serán consultadas esas reglas en última instancia. Un controlador primario de dominio (PDC) puede implementarse tanto bajo Windows como bajo Linux. En este artículo vamos a contrastar ambas implementaciones.

Santiago Gómez Ruiz

Los servidores a enfrentar correrán respectiva-mente Windows Small Business Server 2003 Standard y Debian 3.1 Sarge R2. Ambos siste-mas están cercanos a su renovación. En el mo-

mento de escribir este artículo parece inminente la libe-ración como versión estable de Debian 4 Etch. Del mismo modo, Microsoft ha anunciado que podría comercializar su nueva versión de sistema operativo para servidores (codename Longhorn) para 2007, aunque teniendo en cuen-ta los años de retrasos sucesivos que ha sufrido Windows Vista, no parece muy fiable esa información.

No obstante, en un asunto tan crítico como sistemas operativos de servidor, siempre es más prudente dejar una versión nueva en la calle unos meses antes de ponerla en producción, para pulir posibles errores. En este aspecto, a Debian le precede una fama de solidez inquebrantable, e incluso en entornos donde se puede asumir cierto riesgo, la versión inestable se está utilizando con plena satisfac-ción (de hecho, Ubuntu procede de la rama inestable de Debian). No se puede decir lo mismo de Microsoft, que ha acompañado cada lanzamiento de cada versión de Windows con uno o dos años de Service Packs (revisiones

mayores), parches y demás correcciones sobre aspectos fundamentales del sistema, intentando dotarles de una mínima estabilidad. Así, a Windows 95, famoso por sus constantes cuelgues, le sucedió OSR2, a Windows 98, el rey de las pantallas azules, 98SE, Windows XP va por su segundo Service Pack, intentando cerrar sus interminables agujeros de seguridad, Windows NT tuvo hasta 6 Service Packs, y Windows Millenium nunca llegó a ser usable, siendo probablemente el peor producto que ha salido de Redmond.

Cada una de las instalaciones de prueba atenderán veinte clientes Windows XP SP2.

Los aspectos a comparar entre ambos sistemas ope-rativos serán funcionalidades, rendimiento, instalación, mantenimiento y precio.

FuncionalidadesPara que un ordenador con Linux pueda explorar una red Windows, acceder a sus recursos, compartir los propios, autenticarse o, como en el caso actual, ser el controlador de un dominio, tiene que ejecutar un conjunto de programas agrupados bajo el nombre Samba. El nombre del protocolo


32 Linux+ 2/2007


33www.lpmagazine.org

que se utiliza para ello es SMB, pero al estar el acrónimo registrado por Microsoft, no se pudo utilizar y se sustituyó por Samba. La his-toria completa se puede encontrar en http://es.wikipedia.org/wiki/Samba_(programa)

Samba tiene una limitación muy impor-tante gestionando dominios, y es que en su versión estable actual no puede manejar polí-ticas de grupo, ni soporta active directory. La versión 4, en desarrollo sí podrá hacerlo, pero aún no está en condiciones de ser usada en un entorno de producción.

Esto quiere decir que si para la insta-lación prevista es imprescindible el uso de active directory o de políticas de grupo, NO podrá usarse Linux.

Por lo tanto, y muy superficialmente, las diferencias funcionales más evidentes entre los dos modelos son:

• Linux integra administración remota con Webmin, que admite todo tipo de módulos, y puede accederse desde cual-quier equipo corriendo cualquier plata-forma. Windows se administra desde la consola de Microsoft, que está limitada a los módulos predefinidos por Micro-soft y sólo funciona en plataformas Win-dows;

• Windows soporta active directory y Li-nux aún no;

• Aunque ambos sistemas soportan su pro-pia versión de terminal server, las sesio-nes serán del propio sistema. Es decir, no podemos pedir que un equipo con Linux sirva sesiones terminal server de Windo-ws, ni lo inverso.

El rendimientoExisten las pequeñas mentiras, las grandes mentiras y los benchmarks

Un servidor son sus recursos. Cualquier puesto de trabajo suele correr con al menos 256 ó 512 MB de RAM, mientras el servidor puede que disponga de 2 GB para atender 30 puestos, gestionar comunicaciones, ficheros, web, email y dos docenas de servicios más. Por esto, el rendimiento es fundamental en la elección del sistema.

En 1999, Microsoft empezó a considerar seriamente la amenaza del software libre a su hegemonía sobre el mercado. Desde entonces se han sucedido infinidad de campañas pu-blicitarias, cada una con su correspondiente batería de pruebas, testeos y argumentos más o menos escandalosos. El factor común de to-das estas campañas ha sido su fracaso, ya que no han frenado en absoluto el crecimiento y el desarrollo de productos libres alternativos a los de la multinacional.

Tras examinar una decena larga de ben-chmarks comparando servidores Windows con servidores Linux, he llegado a la con-clusión de que éstos se podrían clasificar si-guiendo dos criterios. El primer criterio sería su financiación, esto es, testeos financiados directa o indirectamente por Microsoft, o eje-cutados por sus proveedores inmediatos (Ve-ritest, Mindcraft...), y testeos ejecutados por entidades independientes (Itweek, ZD...). El segundo criterio sería el resultado; hay ben-chmarks tanto favorables a Windows como favorables a Linux.

Sorprendentemente (o no), los dos crite-rios coinciden, de modo que las pruebas su-

fragadas por Microsoft demuestran sin lugar a dudas una gran superioridad de los siste-mas Windows, mientras que aquellas reali-zadas de forma independiente muestran de forma general que los sistemas Linux son más rápidos, estables y seguros.

Idealmente la prueba de rendimiento debería hacerse en la propia instalación final, lo cual es irreal, ya que obligaría a mucho más trabajo y a adquirir previamente un conjunto de licencias nada baratas que probablemente nunca lleguen a usarse.

Independientemente de la guerra de los benchmarks, hay una serie de hechos objeti-vos que deben tenerse en cuenta para estimar el rendimiento final:

• Los servidores Windows no pueden ce-rrar sus sesiones gráficas (GUI en Windo-ws). Una sesión gráfica ocupa una can-tidad nada desdeñable de recursos, gas-tados absurdamente en un equipo que estará casi toda su vida con la pantalla apagada;

• Ya que los sistemas operativos de Mi-crosoft son vulnerables a los virus, usar-los obliga a la instalación de un antivi-rus. Aparte de los gastos de licencia y el tiempo de instalación y mantenimien-to (actualizaciones, nuevas versiones...), hay que considerar que un antivirus es probablemente el tipo de software más intrusivo que existe. Ya que tiene que intervenir en todos los procesos del sis-tema que impliquen lectura, escritura o transmisión entre otros, ralentiza sen-siblemente la máquina. Ninguno de los benchmarks que he consultado se han realizado en equipos con antivirus ins-talado, pero es evidente que hubiesen afectado de forma notable a los resulta-dos.

InstalaciónLos productos Microsoft tienen fama de ser fáciles de instalar. En este caso es cierto. Es mucho más fácil instalar un servidor de do-minio sobre Windows que sobre Linux.

En windows, un par de asistentes y el sistema queda listo para funcionar. Para un equipo de escritorio, eso es una gran ventaja, ya que la optimización del sistema, la elec-ción de los servicios que ejecuta y multitud de parámetros no son importantes. Pero ins-talar en cuatro clics un servidor sólo puede significar que no se ha optimizado, que no se han cuidado multitud de aspectos. Si luego se quiere afinar ese equipo, habremos de vernos con el registro de Windows, y con el Figura 1. El escritorio por defecto de la distribución Debian, su aspecto ascético esconde su gran usabilidad

34


Linux+ 2/2007 35


www.lpmagazine.org

riesgo de dejar el sistema hecho un trapo si nos equivocamos de clave. Y no lo digo yo, en cualquier página de soporte de Microsoft donde se trate de alguna modificación del registro, se puede leer textualmente:

ADVERTENCIA: si utiliza incorrectamente el Editor del Registro, puede causar serios pro-blemas que tal vez requieran volver a instalar el sistema operativo. Microsoft no garantiza que pueda solucionar los problemas resultantes del uso incorrecto del Editor del Registro. Utilice el Editor del Registro bajo su responsabilidad.

Evidentemente, entran ganas de no mo--dificar nada, nada, nada. Por otra parte, la ins-talación de un dominio en Linux no es difícil, pero si es una tarea tediosa. Se echa en falta un proceso que automatice algunos proce-dimientos, algún asistente como los de Win-dows. Sin duda, llevará algunas horas po-nerlo en marcha totalmente a nuestro gusto, pero una vez instalado, funciona con una suavidad pasmosa.

MantenimientoEn este aspecto está muy claro que los ser-vidores Windows requieren de muchas más horas de trabajo que sus homólogos Linux. Casi cada actualización de seguridad de Win-dows obliga a un reinicio. Muchos antivirus requieren reiniciar tras una actualización del programa. Además, no es raro que tras una actualización, el ordenador no funcione correctamente. Esto obliga a realizar estas la-bores de mantenimiento fuera de las horas de producción, lo cual normalmente significa de noche o en fines de semana, ya que si después

de actualizar el equipo, este simplemente no arranca, la red estará detenida hasta encon-trar la solución o reinstalar completamente el servidor.

Por el contrario, las actualizaciones en los servidores Linux no precisan de reinicio (salvo la instalación de un nuevo kernel, y si se decide reiniciar, ya que no afecta a la fun-cionalidad del sistema). Incluso si es una ac-tualización de un servicio vital como Samba, este se detiene, se actualiza y se vuelve a ini-ciar en apenas unos segundos. Personalmen-te no conozco ningún caso en que una ac-tualización de un sistema Linux de servidor (léase Debian, RHEL, SUSE Linux Enterpri-se Server...), haya obligado a una reinstala-ción.

PrecioLa estructura de las licencias de Microsoft es al menos una licencia de servidor, y lue-go una licencia más o CAL por cada equipo o usuario que se va a conectar al servidor. No confundir estas CAL con las licencias del sistema operativo que tenga instalado la estación de trabajo, hay que pagarlas las dos:

• Licencia de Servidor más 5 CAL's : 490,24 €;

• Cada conjunto de 5 CAL's extra (3): 457,36 €;

• Antivirus NOD32, versión profesional monousuario: 45,24 €Por lo tanto, la ins-talación de servidor + licencias + antivi-rus: 1907,56.

El sistema Linux que instalaremos es una dis-tribución Debian, de licencia gratuita, y todo el software propuesto para esta instalación es libre y gratuito, por lo que el coste seríacero.

Resumen de la comparativa

• Funcionalidades: A día de hoy y como con-trolador de dominio, Windows 2000/2003 es más completo que una instala-ción Linux + Samba. No obstante, las fun-cionalidades de Linux son mucho más flexibles y configurables;

• Rendimiento: Tanto en rendimiento punta como en estabilidad (las interrupciones también afectan al rendimiento), los sis-temas Linux superan ampliamente a los Windows;

• Instalación: Mucho más sencilla en los equipos Windows. Mucho más tediosa pero también flexible en los equipos Li-nux;

• Mantenimiento: Los equipos Linux requie-ren menos mantenimiento y son menos susceptibles a catástrofes;

• Precio: La instalación Linux propuesta tiene coste cero, la instalación Windows 1907,56 €.

Por lo tanto:

• Es sensato elegir Windows si alguna fun-cionalidad imprescindible aún no está im-plementada en Linux. Aunque a prime-ra vista parezca la elección para alguien sin demasiados conocimientos, la facili-dad de la instalación oculta un mante-nimiento y unos problemas posteriores mucho más difíciles de superar;

• Es sensato elegir Linux en cualquier otro caso menos en el anterior.

Instalación de un dominio Windows 2000 sobre LinuxAl describir este proceso de instalación y con-figuración, se presupone una cierta soltura en edición de ficheros y arranque y parada de servicios.

La instalación de una distribución Debian de GNU/Linux es hoy en día muy sencilla. Una de las escasas dificultades que podemos encontrar es que el instalador no encuentre el disco duro. Si ocurre, y nuestro equipo tiene discos Serial ATA, la solución es configurar la BIOS en modo compatibilidad, y lo encontra-rá sin problemas. Por lo demás, facilitará la labor si le indicamos que queremos instalar el equipo como:

Figura 2. Al unir un equipo XP a un dominio, este solicita varios conjuntos de usuario/clave, correspondientes al usuario del equipo, a un administrador del dominio y al administrador del equipo

34


Linux+ 2/2007 35


www.lpmagazine.org

• Servidor de archivos;• Servidor DNS;• Servidor de impresoras;• Entorno de escritorio, que aunque una

vez instalado lo dejemos desactivado, ha-rá más fáciles algunas tareas de configu-ración.

Listas de control de accesoTerminada la instalación, hay que configu-rar cada aspecto del sistema. Ya que proba-blemente deseemos asignar permisos per-sonalizados para cada usuario o grupo en los recursos compartidos por el servidor, la manera más sencilla de hacerlo es mediante listas acl. Para ello instalamos el paquete acl (bien desde Synaptic, bien haciendo unsencillo apt-get acl desde una consola de root).

Para activar las listas de control de ac-ceso, es necesario editar el fichero /etc/fstab y añadir acl a los parámetros de la partición donde se ubicarán los recursos compartidos, por ejemplo:

/dev/hda6 /home ext3

defaults,acl 0 2

Para que los cambios tengan efecto, es necesa-rio desmontar y volver a montar la partición, y para ello es necesario haber cerrado la se-sión gráfica. En el ejemplo anterior, se iría a una consola con Ctrl+Alt+F1, se haría logon con el usuario root, y los comandos a ejecutar serían :

/etc/init.d/gdm stop

umount /home

mount /home

/etc/init.d/gdm start

Y ya quedaría montada la partición con so-porte para listas de control de acceso.

Configuración de SambaSamba es una suite bastante amplia y com-pleja. A continuación se detallarán los dis-tintos pasos para configurar Samba como controlador de dominio, con una explica-ción muy somera del parámetro, no obstan-te, para entender cómo funciona (y mucho más importante, qué puede estar fallando en un momento dado), es muy reco-mendable leer la documentación de Sam-ba.

La configuración de Samba se realiza en el fichero /etc/samba/smb.conf. Este es el punto más importante de la implementación del do-

minio, por lo que hay que prestarle máxima atención. Se recomienda hacer copia de este fichero antes de cada cambio. Tras cada mo-dificación en el fichero, y en aras de probarlo, es necesario reiniciar el servicio samba con la orden:

/etc/init.d/samba restart

Abrimos el fichero smb.conf para editarlo, y buscamos o creamos las siguientes líneas:

workgroup = el_dominio

Siendo el_dominio el nombre del dominio a crear:

wins support = yes

Con esta directiva le indicamos que debe de dar soporte para wins. Wins es el acró-nimo de Windows Internet Name Service, y es el protocolo de resolución de nombres en una red que usa principalmente Win-dows 98, pero sigue siendo necesario en las versiones posteriores. De hecho, si co-nectamos clientes con Windows 98 a nues-tro servidor, resolverán mucho mejor si en las propiedades de TCP/IP le indicamos la IP de nuestro servidor como servidor Wins:

wins server = yes

Nuestro servidor actuará como servidor wins:

netbios name = el_nombre

Indicamos el nombre del equipo tal y como aparecerá en la red:

security = user

El tipo de compartición será por usuario, no por recurso:

Unix password sync = yes

Samba intentará sincronizar las contraseñas con el sistema:

domain master = yes

Nuestro equipo se erige así como controlador primario del dominio.:

domain logons = yes

Se admitirán accesos de dominio:

socket options = TCP_NODELAY

SO_RCVBUF=8192

SO_SNDBUF=8192

Esta opción, según la documentación, me-jora el rendimiento en equipos GNU/Li-nux:

os level = 65

Es el nivel de sistema operativo que se anun-cia. Un valor de 65 debe de ser totalmente su-ficiente.:

dns proxy=yes

Figura 3. Finalizado con éxito el agregado del equipo al dominio, ahora toca reiniciar otra vez

36


Linux+ 2/2007 37


www.lpmagazine.org

El servidor intentará resolver por DNS aque-llas peticiones que no pueda resolver de otra manera.:

null passwords=yes

Debe admitir contraseñas nulas. Los siste-mas operativos Windows 2000 y XP regis-tran la máquina además del usuario en el dominio, y las máquinas no tienen contrase-ña.:

admin users= fulanito, menganito

Los usuarios que actuarán como administra-dores del dominio (por ejemplo, para añadir equipos al mismo). No se recomienda utilizar el usuario root para esto, por motivos de seguridad.:

invalid users = root

De hecho, es prudente invalidar a root para acceder como usuario del dominio.:

guest account=nobody

El nombre de la cuenta de invitado.:

add machine script= /usr/sbin/

useradd -c 'Comentario' -d /dev/

null -s /bin/false -g Maquinas

%u'$' && smbpasswd -a -m %u

Esta línea contiene el comando a ejecutar cuando se añade una máquina al dominio, y presupone que cuando añadamos un equi-po deseamos que la máquina se añada au-tomáticamente. La alternativa es añadir ma-nualmente las máquinas además de los usu-arios (es la práctica en Windows). Detallada-mente, el encadenamiento de estos dos co-mandos sería:

• /usr/bin/useradd -> añadir un usuario Unix;

• c Comentario -> comentario del usuario, descripción de la máquina en la red, en este caso;

• d /dev/null -> sin directorio de inicio;• s /bin/false -> sin shell (por seguridad);• g Maquinas -> perteneciente al grupo Ma-

quinas, que crearemos antes de empezar a usar el dominio;

• %u'$' -> nombre de la máquina, más el símbolo del dólar (los nombres de equi-po van seguidos de dólar en Windows);

• smbpasswd -> crear/modificar un usuario samba;

• a -> vamos a añadir;• m -> es una cuenta de máquina;• %u -> nombre de la máquina, como se ha

especificado -m, no es necesario añadir el símbolo del dólar.

A continuación, se configuraría el recurso net-logon, los scripts de inicio si se desean, y los recursos compartidos e impresoras en el fi-chero smb.conf. Cada caso sería completa-mente diferente, y es relativamente sencillo. La configuración base del dominio está deta-llada.

Configuración de WebminWebmin es un entorno potentísimo de admi-nistración remota, que permite crear y aña-dir módulos nuevos para cada tarea. La ver-sión de Webmin que viene con Debian ha quedado superada por la nueva. La instala-ción es muy sencilla, desde una consola de root:

apt-get install libio-pty-pear

Este paquete es necesario para la ejecución de esta versión de Webmin.: wget http://pr-downloads.sourceforge.net/webadmin/webmin_1.300_all.deb

Se descarga el paquete desde la web del proyecto Webmin.:

dpkg -i webmin_1.300_all.deb

Se instala el paquete.

Por defecto, y por motivos de seguri-dad, Webmin viene configurado para serusado sólo desde el equipo en el que esté instalado. Para permitir su uso desde cual-quier equipo, hay que editar el fichero /etc/webmin/miniserv.conf, buscar la clave allow=127.0.0.1 y cambiar por allow=0.0.0.0 Esta clave también permite determinar o restrin-gir los equipos desde los cuales se tendrá acceso.

La instalación por defecto habrá creado un sólo usuario de Webmin, root, y con la cla-ve de root. Los usuarios de Webmin son in-dependientes de los de Linux, por lo que si cambiamos la clave de root, en Webmin quedaría la clave antigua.

Para acceder a Webmin, abrimos cual-quier navegador e introducimos: https://1.2.3.4:10000

Sustituyendo 1.2.3.4 por la IP de nues-tro servidor. Vale la pena echar un rato con-figurando Webmin, empezando por el idio-ma (Webmin->change language and theme->language).

Para poder administrar remotamente de forma visual los permisos de cada car-peta, es preciso instalar un módulo concre-to. Para ello, nos situamos en Webmin->configuración de Webmin->módulos de Webmin. Elegimos “configuración estándar dewww.webmin.com”, pulsamos el botón de ex-ploración que aparece a la derecha y elegi-mos el módulo file manager. Antes de pulsar sobre “instalar módulo”, es conveniente marcar la opción “Permitir acceso a todos

Figura 4. Administrando los permisos de un directorio de forma remota mediante Webmin

36


Linux+ 2/2007 37


www.lpmagazine.org

38


Linux+ 2/2007 39


www.lpmagazine.org

los usuarios de Webmin”. Ya que estamos en Webmin, es el momento de configurar la sincronización de cuentas Unix y Samba y de crear en ambos sistemas el grupo “Ma-quinas” donde se añadirán los pc's del do-minio. Para la primera tarea, seleccionamos la sección “Servidores”, y dentro de ella, “Compartición de archivos de Windows mediante Samba”. Se muestra una pantalla en la cual la parte superior es la lista de recursos compartidos. Desde aquí es muy sencillo configurar recursos y permisos ge-néricos a los mismos. Bajo la sección “Con-figuración global” se encuentra Samba users. Accedemos a “Configuración de la sincro-nización automática de usuarios de Unixy Samba”, marcamos todas las casillas y sal-vamos los cambios. Repetimos la opera-ción con la opción de sincronización de gru-pos.

Para verificar dicha sincronización, se puede acceder desde el índice de Webmin a “Sistema”, “Usuarios y grupos”, donde se muestran todos los usuarios y grupos Unix. Pulsando sobre “Crear un nuevo grupo”, nos permitirá crear el grupo “Maquinas”. Si vol-vemos a comprobarlo a la sección, veremos que el grupo se ha creado también en Sam-ba.

Cuando un usuario accede a un recur-so determinado tiene que atravesar tres niveles de permisos, que son los permisos de Unix, los de Samba y las listas de con-trol de acceso. Si uno de los tres niveles le deniega el permiso en concreto (escritura, lectura, ejecución), no podrá acceder. Pue-de parecer confuso, y para recursos trivia-les la solución es definirlos con todos los permisos activos a nivel de Unix y de Sam-ba, y refinar con ACL los accesos que que-remos permitir para cada usuario o gru-po.

Los permisos de Unix se definen a ni-vel del sistema operativo, es decir, con una simple consola. Los permisos de samba se modifican en la definición del recurso en el fichero smb.conf, o más fácilmente, desde esta misma página de Webmin, al editar los permisos de los recursos. Ahora, bajo la opción general “otros” del menú principal de Webmin, tenemos el “explorador de ar-chivos”, que nos permitirá con su opción “ACL” administrar las listas de control de acceso de cada archivo y directorio de una forma cómoda. Es importante aplicar esos permisos antes de empezar a utilizarlos, de otro modo, y a fin de que se apliquen recur-sivamente, habría que usar el comando de consola setfacl.

Nos queda un pequeño detalle que hará que nuestro servidor funcione con la flui-dez deseada; optimizar el rendimiento de Samba. Para ello, será necesario editar el fi-chero /etc/sysctl.conf y añadir la siguiente lí-nea:

vm.bdflush = 95 1000 64 64 15 6000

6000 1884 2

El significado de cada uno de los parámetros cae fuera del ámbito de este artículo, pero fun-damentalmente modifica el comportamien-to de la gestión de la memoria virtual, ya que por defecto su configuración es muy con-servadora. Una explicación detallada de lo que significa esta línea se podrá encontrar en http://www.redhat.com/magazine/001nov04/features/vm/

Para que el sistema tenga en cuenta los nuevos valores, hay que reiniciar el servicio networking:

/etc/init.d/

networking restart

Bien, ahora tenemos un dominio perfecta-mente usable, sólo quedaría añadir los usu-arios (ya que las máquinas se añadirán au-tomáticamente), y los recursos. Ambas ope-raciones se pueden realizar cómodamente en Webmin, añadiendo los usuarios desde Sistema/Usuarios y Grupos/Crear nuevo usu-ario, y los recursos desde Servidores/Com-partición de archivos de Windows mediante

Samba/Crear una nueva compartición de ar-chivo.

Añadiendo equipos al dominioNos vamos a encontrar con tres formas típi-cas de añadir equipos al dominio, que son la de Windows 98, la de Windows 2000 y la de Windows XP Professional.

Los equipos Windows 98 entran en do-minio muy fácilmente. Se modifican las pro-piedades de red, entrando en propiedades de TCP/IP de forma que tanto el primer servidor DNS como WINS sea la IP de nues-tro servidor. En Windows 98 no es im-prescindible (en los otros dos sistemas sí), pero ayudará a encontrar más rápidamente a otros equipos en la red a través de la op-ción DNS PROXY del fichero smb.conf. Tras modificar la dirección del servidor DNS, y salvando los cambios de las propiedades de TCP/IP en la pestaña identificación nos da a elegir entre iniciar sesión en un grupo de trabajo y un dominio. Elegimos dominio y escribimos el nombre de nuestro domi-nio. Aceptamos y reiniciamos el equipo. Al arrancar de nuevo pedirá usuario y contra-seña de un usuario del dominio. Los equi-pos Windows 98 no precisan de dar de alta la máquina en el dominio.

Para añadir al dominio los equipos Win-dows 2000, en primer lugar hay que modi-ficar la dirección del primer servidor DNS, como en el caso anterior, posteriormente es necesario hacer clic con el botón derecho del

Figura 5. Creando un nuevo recurso compartido de forma remota mediante Webmin

38


Linux+ 2/2007 39


www.lpmagazine.org

ratón sobre el icono “Mi Pc”, y elegir “pro-piedades”. En la pestaña “Identificación deRed”, pulsar el botón “Propiedades”, y apa-recerá una ventana donde indicar el nom-bre de la máquina así como el del dominio. Pedirá que se autorice dicha unión median-te el usuario y contraseña de un administra-dor del dominio (uno de los que se especifi-caron en ADMIN USERS=.... en el fichero smb.conf). Si todo es correcto, mostrará un mensaje de que el equipo se ha unido al dominio, pedirá reiniciar y listo.

Antes de unir un equipo con XP al dominio es conveniente modificar una cla-ve del registro, concretamente, dentro de HKEY_LOCAL_MACHINE\SYSTEM<CharStyle:FOREIGN>CurrentControlSet<CharStyle:FOREIGN>Services<CharStyle:FO-REIGN>netlogon<CharStyle:FOREIGN>parameters, la clave RequireSignOrSeal debe de tener un valor de tipo dword y conteni-do 0. Para facilitar esta labor, la propia ins-talación de Samba contiene el fichero quemodifica este cambio; /usr/share/doc/samba-doc/registry/WinXP_SignOrSeal.reg.

Sólo es necesario copiar este fichero a un disquete, y ejecutarlo desde el mismo en el cliente Windows XP.

Los equipos con Windows XP Profes-sional son los más enrevesados a la hora de entrar en dominio, a pesar de contar con un asistente. En primer lugar, como en los dos casos anteriores, será necesario modifi-car la dirección IP del primer servidor DNS para hacerla coincidir con la de nuestro ser-

vidor. Posteriormente, haciendo clic con el botón derecho del ratón sobre el icono “Mi Pc”, eligiendo la pestaña “identificación de red” y pulsando el botón “Id. de red”, se lanzará el asistente que nos preguntará en primer lugar el usuario, la contraseña y el dominio del usuario “normal” del domi-nio, a continuación, el nombre de equipo y de nuevo el dominio, después el nombre de usuario, la contraseña y el dominio de un usuario administrador del dominio. Si el nombre de usuario normal del dominio, es decir, el primero especificado no existe en el equipo, preguntará si se crea tal usua-rio, y el tipo de usuario (normal, adminis-trador...). Para que funcione bien, hay que permitirle crear el usuario; para esa tarea nos pedirá el usuario y la contraseña de un usuario administrador del equipo (no del dominio, no confundir). Si no nos hemos confundido unos usuarios con otros en el proceso, bastará reiniciar para que todo funcione.

ConclusionesExponiendo de otra forma las mismas con-clusiones de la comparativa, tendríamos que.

Las ventajas de un dominio montado so-bre un equipo con Windows 2000/2003 son:

• Facilidad de instalación (aunque a veces lleve al error de considerar que “cual-quiera puede hacerlo”);

• Plena funcionalidad.

Los inconvenientes de un dominio monta-do sobre un equipo con Windows 2000/3 son:

• Coste altísimo;• Poca optimización;• Es vulnerable a virus;• Menor rendimiento;• Mantenimiento alto;• Menor estabilidad.

Las ventajas de un dominio montado sobre un equipo GNU/Linux Debian 3.1 “Sarge” son:

• Licencia gratuita, no requiere coste por licencias ni por servidor ni por pues-tos;

• La optimización dependerá de los co-nocimientos del administrador, incluso llegando a poder recompilar el núcleo del sistema si es necesario;

• Es invulnerable a virus;• El rendimiento es considerablemente más

alto;• El mantenimiento es muy bajo;• Altísima estabilidad. La necesidad de re-

iniciar será casi inexistente.

Las desventajas de un dominio montado sob-re un equipo GNU/Linux Debian 3.1 “Sarge” son:

• Es difícil y tedioso de instalar. No sola-mente quien lo hace tiene que saber muybien lo que hace, sino que podría perfec-tamente estar más asistido sin necesidad de perder detalle;

• Aún carece de algunas de las funcionali-dades de los dominios Windows 2000/3 puros.

Lógicamente, las ventajas de uno son las des-ventajas del otro y viceversa, aunque ha-bría que reflexionar sobre la primera ven-taja de los sistemas Windows, ¿Realmente es una ventaja que alguien sin los mínimos conocimientos de administración pueda implementar un dominio? Si bien le apor-ta facilidad al procedimiento, no parece muy conveniente que alguien no suficiente-mente preparado administre algo tan deli-cado como el corazón de una red. Es como si a una persona con el carnet de condu-cir ciclomotores le animasen a pilotar un Boeing ayudado por un par de “asisten-tes”. Tal vez por eso hay redes que se estre-llan.

Figura 6. Agregando un nuevo usuario al dominio de forma remota mediante Webmin

32 33 34_35_36_37_38_39_domino

Education