cambios en la búsqueda en el historial, que integrada en la barra de direcciones permite buscar mediante título, URL o, he aquí la novedad, texto como si de Google se tratara; mayor rapidez y estabilidad de su aplicación de correo que además incorpora soporte para IMAP o mejor integración con BitTorrent.

Respecto a la protección contra malware, estará activa para todos aquellos que tengan activada la protección contra fraude, la cual también incluye avisos en casos de páginas de phishing. Además, próximamente se le integrará un sistema para que los usuarios puedan avisar de nuevas páginas que aún no estén añadidas a la base de datos de páginas malignas.

Fuente:
http://my.opera.com/desktopteam/blog/

El vídeo, de 4 minutos de dirección, se puede ver en cualquier navegador que soporte Flash. Durante su reproducción nos encontraremos con la explicación de las principales novedades que se han incluido en Firefox 3.

Entre ellas destaca el nuevo método predictivo de introducción de URLs que hace más sencillo encontrar la web que queríamos visitar. La organización de favoritos es también más rápida, ya que por ejemplo disponemos de una estrella en la parte derecha de la barra de direcciones que al pulsarla incluirá dicha URL en nuestra lista de favoritos en una lista especial al estilo de una miscelánea de favoritos que luego podemos organizar tranquilamente.

Los filtros antiphishing y el nuevo gestor de descargas (que incluye un campo de búsqueda que nos permite saber qué nos hemos bajado basándonos en términos de búsqueda) son algunas mejoras adicionales que harán de Firefox 3 uno de los navegadores más potentes de toda la historia.

Deseas consultar el video:
http://people.mozilla.com/~beltzner/overview-of-firefox3.swf

Con sus GoogleDocs y asi poder brindar servicio a todo tipo de empresas. El servicio seria respaldado por la popularidad y prestigio de la cual se ha hecho Google.

Según palabras de Preston Gralla, el redactor que recientemente analizó la beta de la suite de ofimática de software libre y código abierto OpenOffice 3 afirma que si Google integrara estos servicios en sus Google Docs.

Los ingresos de Microsoft procedentes de las suites Office estarían en peligro.
Las empresas podrían obtener equipos más económicos con GNU/Linux, ahorrándose enormes cantidades de dinero en licencias de Windows, Office y hardware de alto nivel.

Fuente:
http://www.theinquirer.es/2008/06/05/google_debe_adoptar_openoffice_para_nokear_a_microsoft.html

Se espera que el 29 de julio sea lanzada la primera versión Alpha de Fedora 10 y culminara el día 28 de Octubre con el lanzamiento oficial de Fedora 10. Si te interesa conocer esta alpha o quieres contribuir solo tienes que acceder al portal web de Fedora y descargarla.

Fuente:
http://fedoraproject.org/wiki/Releases/10/Schedule

Novell ha anunciado la disponibilidad de SUSE Linux Enterprise 10 Service Pack 2 (SP2), que incluye mejoras en virtualización, gestión, capacidad de hardware e interoperabilida, tambien cuenta con soporte de Microsoft para huéspedes de Windows Server 2008 y Windows Server 2003.

Y migración en vivo de estos sistemas huéspedes entre máquinas físicas. SP2 también ha incluido varias mejoras específicas de SUSE Linux Enterprise Desktop 10 y SUSE Linux Enterprise Real Time 10.

“Este pack de servicio para SUSE Linux Enterprise 10 ofrece ventajas a clientes, colaboradores y desarrolladores. Los beneficios de Linux para las empresas están empezando a ser muy conocidos y, por su parte, Novell sigue centrada en simplificar la experiencia del cliente y, al mismo tiempo, reducir los costes”, señaló Holger Dyroff, vicepresidente de Gestión de Productos de SUSE Linux Enterprise de Novell”.

Fuente:
http://www.diarioti.com/gate/n.php?id=17828

Para la conexión en si, en el ordenador cliente teclee lo siguiente:

ftp
open <IP-servidor> / open <nombre-servidor>
login: anonymous
password: uncorreo@undominio.algo

para conocer los comandos FTP simplemente teclee help o help <comando> para información más específica.

Por regla general los ficheros y directorios se cuelgan del subdirectorio /var/ftp/pub a cuyo contenido se dará los permisos necesarios (por lo general sólo lectura), algunos sitios FTP también tienen una carpeta incoming colgando de pub para que la gente suba ficheros, esta carpeta también ha de tener permisos de escritura.

Si queremos que los amigos usen nuestro propio ftp, nos aseguramos que:

• que nuestros amigos conocen nuestra IP en este momento ( ifconfig ),
• que tenemos instalado el paquete wu-ftp ( rpm -qa | grep wu-ftp ),
• que en el fichero /etc/xinetd/wu-ftp tenemos la línea: disable = no ,
• que tenemos reactivado correctamente el servicio xinetd , ya sea de forma permanente con ntsysv o temporalmente usando el comando /etc/rc.d/init.d/xinetd restart
• comprobar que el firewall no corta este tipo de transferencias ( lokkit )

Para subir cosas debemos añadir en el archivo /etc/ftpaccess , sección User Clases , la línea:

upload /var/ftp /incoming yes root ftp 0444

Las cosas se subirán a la carpeta /var/ftp/incoming , que desde el ftp se ve como /incoming

Conexión a un directorio de otro ordenador con linux usando NFS:

Debes de hacer una serie de operaciones, unas en el servidor y otras en el cliente para poder usar NFS.

EN EL ORDENADOR SERVIDOR

• Desconecta el firewall (pon ninguno en su configuración)
• Edita el fichero /etc/exports y añade la siguiente línea:

/ruta_directorio_compartido maquina_cliente(rw,all_squash)

• Activa el servicio NFS
• Volver a activar el firewall cuando se termine con NFS

EN EL ORDENADOR CLIENTE

• esconecta el firewall (pon ninguno en su configuración)
• Si se va a usar de forma temporal tecleamos el comando:

mount servidor:/ruta_directorio_compartido /punto_montaje -t nfs

• Si se va a usar de manera permanente añadimos al fichero /etc/fstab la siguiente línea:
  servidor:/ruta_directorio_compartido punto_montaje nfs  rsize=8192,wsize=8192,timeo=14,intr

La version 3.2 está ahora en fase beta y es multihilo, tiene mucho más rendimiento que la antigua 3.1, y además tiene una sintaxis más cómoda, por lo que, a pesar de ser una beta, la recomiendo porque funciona muy bien.

Compilación e instalación

Lo primero de todo será bajarnos la última versión disponible. Actualmente es la Unreal3.2-Selene[beta2], la que estoy usando en mi servidor braindead.fromdahell.org .

Lo primero será crear un usuario en nuestro servidor para que ejecute UnrealIRCD (nunca lo hagas como root). Una vez creado el usuario ircd descomprimimos el fichero Unrealircd.3.2.tar.gz en el directorio home, haciendo un tar zxvf Unrealircd.3.2.tar.gz . Nos creará un directorio, entramos en el y ejecutamos ./Config . Nos irá haciendo una serie de preguntas (incluyo mis respuestas):

Do you have an insecure operating system and therefore want to use the server anti-spoof protection? [No] -> [enter] What directory are all the server configuration files in? [/home/ircd/Unreal3.2] -> [enter] What is the path to the ircd binary including the name of the binary? [/home/ircd/Unreal3.2/src/ircd] -> [enter] Would you like to compile as a hub or as a leaf? Type Hub to select hub and Leaf to select leaf. [Hub] -> [enter]

* Nota: La diferencia entre Hub y Leaf radica en que el primero lo debemos elegir si tenemos un servidor al que vamos a linkar varios servidores. Si a nuestro servidor no se va a linkar nadie, debemos compilarlo como leaf.

What is the hostname of the server running your IRCd? [braindead.fromdahell.org] -> [enter] What should the default permissions for your configuration files be? (Set this to 0 to disable) It is strongly recommended that you use 0600 to prevent unwanted reading of the file [0600] -> [enter] Do you want to support SSL (Secure Sockets Layer) connections? [No] -> [enter] Do you want use encrypted oper {} passwords? [Yes] -> [enter] Do you want use encrypted incoming link {} passwords? [No] -> [enter] Do you want to use encrypted drpass {} passwords? [No] -> [enter] Do you want to use encrypted allow {} passwords? [No] -> [enter] Do you want to enable IPv6 support? [No] -> [enter] What listen() backlog value do you wish to use? Some older servers have problems with more than 5, others work fine with many more. [5] -> [enter] How far back do you want to keep the nickname history? [2000] -> [enter] What is the maximum sendq length you wish to have? [3000000] -> [enter] How many buffer pools would you like? This number will be multiplied by MAXSENDQLENGTH. [9] -> [enter] How many file descriptors (or sockets) can the IRCd use? [1024] -> [enter] Would you like any more parameters to configure? Write them here: []-> [enter]

Una vez hecho esto, ejecutamos make , con esto compilaremos UnrealIRCD. Una vez compilado tendremos que escribir nuestro propio unrealircd.conf y arrancar el ircd con ./ircd , ya estará funcionando.

Configuración

Aquí tenéis mi fichero de configuración de UnrealIRCD: unrealircd.conf .

Ahora os explicaré parte por parte qué hace el fichero de configuración:

me { name “braindead.fromdahell.org”; info “Braindead IRC Server”; numeric 1; };

Aquí definimos el nombre del servidor y la información. numeric 1 indica el número de servidor (1-254); cuando tengamos dos o más servidores linkados no pueden tener igual número.

admin { “Zug”; “zug@fromdahell.org”; };

Aquí ponemos nuestra información, la información del administrador del ircd. Se puede ver tecleando el comando /admin. Es el equivalente a las A lines de otros ircds.

class clients { pingfreq 90; maxclients 500; sendq 100000; };

En esta seccion definimos la clase clients; en ella la frecuencia a la que se comprobará si el usuario sigue “vivo” (pingfreq), el máximo de clientes que aceptamos (maxclients) y sendq, que es el límite de información enviada por el usuario de esta clase.

class servers { pingfreq 90; maxclients 4; sendq 1000000; };

Aquí hemos definido una nueva clase: servers. La frecuencia de ping será 90, máximo 4 servidores linkados a nosotros y 1000000 de límite de envio.

allow { ip *; hostname *; class clients; maxperip 2; };

Con esta línea aceptamos conexiones de clientes desde cualquier IP (*), cualquier hostname (*) y con un máximo de dos conexiones por IP (clones).

allow { ip *; hostname *@deneb.freedomshell.com; class clients; maxperip 10; };

Con esto permitimos 10 clones desde el host deneb.freedomshell.com.

oper zug { class clients; from { userhost *@192.168.0.2; }; password “aAtCDSu1zCb4k”; flags { netadmin; global; }; };

Aquí definimos los operadores de red que habrá en nuestra red: definimos operador zug que se conecta desde la IP 192.168.0.2, será admnistrador de red (netadmin). El password no es aAtCDSu1zCb4k, está encriptado. Para generar passwords encriptados entraremos en el directorio crypt de Unreal3.2, y a continuación haremos un make , se generará la utilidad mkpasswd ; con ella podemos generar los passwords encriptados. Nota: si quisieramos que zug fuese solamente ircop, sustituiríamos netadmin por ircop en la seccion flags. Os incluyo aquí la lista completa de flags, sacada del fichero unrealircd.conf.txt incluido en UnrealIRCD:

Old | New |Description ——- |—————- |—————————— N | netadmin | Network Admnistrator T | techadmin | Technical Administrator A | admin | Server Administrator a | sadmin | Services Operator C | coadmin | Co Administrator o | local | Local IRC Operator O | global | Global IRC Operator r | can_rehash | Is able to rehash the server e | eyes | Can use the eyes message mode D | can_die | Can shutdown the server (with password) R | can_restart | Can restart the server (with password) h | helpop | ..is available for help. Can see /helpops g | can_globops | Can use /globops w | can_wallops | Can use /wallops l | locop | Can’t kill remote users c | can_localroute | Can locally /connect and /squit servers L | can_globalroute | Can globally /connect and /squit servers k | can_localkill | Can do local /kills K | can_globalkill | Can do global /kills b | can_kline | Can set a /kline B | can_unkline | Can unset a /kline n | can_localnotice | Can send local notices G | can_globalnotice| Can send global notices z | can_zline | Can set /zlines ^ | can_stealth | Is invisible to /names

Para hacernos oper, ejecutaríamos /oper usuario clave . Una vez que somos opers, podemos releer la configuración de unreal sin tener q matar el proceso e iniciarlo de nuevo, con un simple /rehash .

listen *:6600; listen *:6667; listen *:8888;

Aquí decimos a través de qué puertos se podrá conectar a nuestro servidor. He definido el puerto 6600 para linkar con los services (chanserv, nickserv, memoserv…), el puerto 6667 que es el más habitual y el 8888, para que se pueda entrar desde sitios donde chapan conexiones al puerto 6667, por ejemplo universidades .

link servicez.fromdahell.org { username *; hostname *; bind-ip *; port 6600; hub *; password-connect “servpass”; password-receive “servpass”; class servers; options { autoconnect; }; };

Este bloque es opcional, solamente si vas a añadir services a tu servidor. Aquí definimos el nombre de los services: servicez.fromdahell.org, en el puerto 6600 (el que reservamos para estos). El password de conexion y recepción será el mismo, en este caso servpass.

link alamut.fromdahell.org { username *; hostname 213.37.65.30; bind-ip *; port 6667; password-connect “clavedelink”; password-receive “clavedelink”; class servers; options { autoconnect; }; };

Esta sección es también opcional, solamente si vais a linkar varios servidores. En este caso linkaremos con el servidor alamut.fromdahell.org , con IP 213.37.65.30, por el puerto 6667 y con la clave clavedelink . Ten en cuenta que la configuración del servidor alamut debe tener numeric 2 , ya que el numeric de braindead es 1, y no pueden ser iguales. Debes tener tambien a tener en cuenta que, si tienes services puestos, en alamut no debes añadir el link a los services, solamente la linea ulines que comentamos más abajo.

ulines { servicez.fromdahell.org; };

Debemos incluir esta línea para que los services funcionen, en este caso son servicez.fromdahell.org .

drpass { restart “restartpass”; die “diepass”; };

Aquí ponemos los passwords de reinicio y “muerte” del servidor.

ban nick { mask “*C*h*a*n*S*e*r*v*”; reason “Reserved for Services”; };

Con esta línea reservamos los nicks que contengan chan para los services.

ban user { mask *PhAnATiC*@*; reason “scripts no permitidos”; }; ban user { mask *ircap*@*; reason “scripts no permitidos”; }; ban user { mask *DTP*@*; reason “scripts no permitidos”; }; ban user { mask *x-cript*@*; reason “scripts no permitidos”; }; ban user { mask *MESIAS*@*; reason “scripts no permitidos”; }; ban user { mask *orbital*@*; reason “scripts no permitidos”; }; ban user { mask *zombie*@*; reason “scripts no permitidos”; };

Esto también es opcional, es un ejemplo de como banear los malditos scripts que abundan por irc-hispano.

vhost { vhost my.sample.vhost; from { userhost *@*; }; login user; password password; };

Con esto definimos un vhost, con user “user” y password “password”, disponible para cualquier usuario. Para usarlo sería: /vhost user password

set { network-name “irc.fromdahell.org”; default-server “braindead.fromdahell.org”; services-server “servicez.fromdahell.org”; stats-server “statz.fromdahell”; help-channel “#fromdahell”; hiddenhost-prefix “fromdahell”; prefix-quit “”; cloak-keys { 10000; 20000; 30000; }; /* on-oper host */ hosts { local “locop.fromdahell.org”; global “ircop.fromdahell.org”; coadmin “coadmin.fromdahell.org”; admin “admin.fromdahell.org”; servicesadmin “csops.fromdahell.org”; techadmin “techadmin.fromdahell.org”; netadmin “netadmin.fromdahell.org”; host-on-oper-up “yes”; }; }; set { kline-address “zug@fromdahell.org”; modes-on-connect “+xwG”; oper-auto-join “#opers”; dns { nameserver 127.0.0.1; timeout 2s; retries 2s; }; options { enable-opermotd; enable-chatops; hide-ulines; webtv-support; identd-check; }; socks { ban-message “Insecure SOCKS server”; quit-message “Insecure SOCKS server”; ban-time “4d”; }; maxchannelsperuser 10; };

Aquí definimos la información de la red.

loadmodule “src/modules/m_sethost.so”; loadmodule “src/modules/commands.so”;

Y finalmente cargamos los modulos m_sethost y commands ; el primero de ellos para que un operador se pueda poner el vhost que quiera sin tener que modificar la configuración mediante /sethost my.virtual.host ; el segundo añade una serie de comandos como /who.

Eso es todo. Esto es una configuración básica, para iniciarte en UnrealIRCD. Si quieres saber más, léete la documentación oficial, y si tienes alguna duda puedes preguntarme a mí o en irc.unrealircd.com .

Voy a escribir un artículo en el que se trata de hacer que un linux corriendo samba haga de servidor como Controlador Primario de Dominio.
La razón por la que escribo esto estriba en que he tenido varios problemas a la hora de configurarlo, y mi deseo consiste en que no os pase a vosotros lo mismo.
La cuestión no es baladí pues hay que tener configurado nuestro samba no solo con las características habituales para usarlo en una red de windows diferentes (95, 98, 2000 etc) sino que además hay que “retocar” varias cosas más.
Este artículo seguirá los siguientes pasos:

• Configurar unas cuantas opciones por defecto en samba

• Configurar samba como PDC en el fichero smb.conf

• Crear las cuentas de confianza de las máquinas que tenemos en la red.

• Configurar las estaciones de trabajo para que se “autentiquen” con el PDC

Empezamos pues.

2 Configurar opciones por defecto

Aquí poco vamos a colocar, símplemente vamos a darle un nombre al servidor y al grupo de trabajo, además vamos a crear un recurso “homes” para que los usuarios vean su directorio home cuando se conecten.

global netbios name = servidor workgroup = grupo wins support = yes homes writable = yes browseable = no

En la primera opción le ponemos nombre netbios al servidor. Si teneis DNS ponedle el mismo nombre que el que figura en el dns, sin la coletilla del dominio DNS.

En la segunda opción le decimos a samba que pertenezca al grupo de trabajo “grupo”. Este dato es importante que lo tengamos en cuenta, pues a la hora de ajustar los clientes, el dominio se va a llamar “grupo”, que es el mismo que el etiquetado en workgroup.

La opción wins support = yes es de propina. Que samba haga de soporte wins no perjudica a nadie y a samba no le cuesta nada, además es recomendado para que actúe de PDC.

El recurso homes, no home, no hay que confundirse, es un recurso especial pues si está presente hacemos que los usuarios accedan a su directorio home en el servidor.

Decimos que browseable = no para que no se vean en los Windows dos recursos: homes y la carpeta del usuario apuntando los dos al mismo contenido.

La opción writable = yes es para que se pueda escribir y crear elementos en el recurso, pues samba por defecto hace los recursos no escribibles y, en consecuencia, solo lectura.

3 Configurar Samba como PDC

Para ello debemos:

• Hacer que sea visualizador maestro local y de dominio en la red.

• Poner la seguridad a nivel de usuario

• Soportar las passwords encriptadas

• La más importante: decirle a samba que él es el PDC

Además no estaría de más crear el servicio (recurso más bien) netlogon aunque no es estrictamente necesario.

3.1 Visualizador maestro

Un visualizador maestro de dentro de una red windows sirve para proporcionar información a los demás sobre dos aspectos:

• qué puestos hay en la red windows

• qué recursos ofrecen esos puestos a los demás.

Esta facilidad puede soportarla cualquier windows integrado en la red. No es necesario que sea un server. Para ser visualizador maestro solamente se requiere que le toque al equipo de marras.

Nosotros vamos a hacer que esta visualización le toque a nuestro Samba siempre.

Pare ello debemos añadir las líneas siguientes a la sección global :

os level = 64 preferred master = yes domain master = yes local master = yes

Pero ¡cuidado! porque debemos asegurarnos de que no exista ningún otro PDC en la red, y tampoco debe haber en la red ningún visualizador maestro de dominio. Si somos los únicos, no hay problema, pero vigilad de forma concienzuda si hay algún servidor w2000 server, o WNT server o algo peor; en caso de que existan no les dejeis que hagan de visualizadores, porque de lo contrario habrá problemas a la hora de ver qué equipos existen en la red y sus recursos.

La opción os level hace referencia a la información del sistema operativo que ofrece Samba. Me explico: cuanto mayor sea este número más avanzado pensarán los demas windows que es el SO de Samba. Para citar un ejemplo si pusieramos el número 34, los windows pensarán que se trata de un Windows NT. Es decir, que con este número engañamos miserablemente a los puestos sobre la versión (windows) de nuestro SO.

Las opciones prefered, domain y local master hacen referencia de que se prefiera a este servidor como visualizador maestro de dominio, local y master sucesivamente.

3.2 Poner la seguridad a nivel de usuario

Esta parte es fácil.

Samba tiene cuatro niveles de seguridad: recurso, usuario, servidor y domain.

La seguridad a nivel de usuario quiere decir que el usuario cuando se autentica en el cliente solo tiene acceso a lo que se le deje tener. En contraposición a nivel de recurso significa que se tiene acceso al recurso cuando pinchando en este desde windows y una vez iniciada la sesión, se nos pide la clave. Si conocemos la clave (seamos quien seamos) entraremos al recurso, si no la conocemos, no entraremos. A nivel de servidor y a nivel de dominio es lo mismo que a nivel de usuario con la diferencia que cuando iniciamos la sesión quien nos autentica es un servidor (no el samba) o un PDC (tampoco el mismo que samba).

Basta añadir en la sección global esto:

security = user

Y con esto ya está.

3.3 Soportar las passwords encriptadas

Es lo más correcto. Las passwords pueden dar vueltas por la red interna encriptadas o no. Le decimos que encriptadas para que nadie las esnife.

Se escribe esto, simplemente:

encrypt passwords = yes

Pero aprovecho este párrafo para añadir y comentar cómo se crean usuarios samba.

Para crear un usuario debemos crearlo anteriormente como usuario unix y, posteriormente darle una contraseña para samba.

adduser usuario

Nos crea un usuario unix, y

smbpasswd -a usuario

Nos crea un usuario samba, que servirá para que los puestos nos autentiquen contra esta contraseña. Mi recomendación es que la contraseña que creemos en windows sea la misma que la que tengamos en samba ¿de acuerdo? Así nos quitamos líos de encima.

Luego volveré a repetir lo que voy a decir ahora: debemos crear una cuenta de root en samba para que después agreguemos el cliente al dominio.

smbpasswd -a root

Luego indicamos la contraseña dos veces.

Después de agregar todas las máquinas al dominio ¡borra esa cuenta de root!, elimina esa línea del usuario root que aparecerá en el fichero smbpasswd. Es más, en la opción global “invalid users = usuarios inválidos” poner por si las moscas a root y demás usuarios que no pertenezcan exclusivamente al dominio de esa red. Símplemente lo digo porque no nos va a apetecer que alguien ande enredando como root (u otro usuario de sistema) por nuestra querida red.

3.4 La más importante: decirle a samba que él es el PDC

Esta es facilita. En la sección global añadir:

domain logons = yes

Con esto el servidor samba dice a la red que él es el PDC.

3.5 Crear el servicio (recurso más bien) netlogon

Este servicio sirve para ejecutar diversos scripts cuando se conecta un windows al servidor. Los scripts son pequeños programas “por lotes” escritos desde windows para ejecutar en windows. Digo que hay que escribirlos en windows por las diferentes formas de entender los retornos de carro de un sistema operativo a otro. Y digo que se ejecuta en windows porque se trata de sencillas instrucciones (p.e. ponte en hora con respecto al servidor o net time \\nombre_netbios_servidor_o_IP /set /yes ) que solo entiende MSWindows.

En la sección global se escribe esto:

logon script = netlogon.bat

Y se crea un recurso llamado netlogon:

netlogon path = /home/netlogon read only = yes

En el path copiamos el fichero netlogon.bat construido por nosotros. Si este fichero no existe, no importa pues samba sigue leyendo su configuración.

De esta forma cuando se conecta alguien, se ejecuta el script netlogon.bat y ejecuta lo que deseemos (o podamos) en el cliente.

Solamente un apunte más. Este recurso NO es estrictamente necesario para que funcione la cosa (el PDC), pero me quiero curar en salud pues en todos los manuales que he visto me colocan esta sección como si fuera indudable su uso.

4 Crear las cuentas de confianza de las máquinas que tenemos en la red.

Aquí empezamos con el cogollo de la cuestión.

Resulta que para crear un dominio windows (es decir grupo de trabajo + PDC) en caso de clientes NT, W2000 y XP pro hay que crear lo que se llama cuentas de confianza de las máquinas.

Esas cuentas de confianza es algo que podríamos definir como “esta máquina y esta otra están en mis dominios”. No solamente los usuarios se autentican y se tienen en cuenta, sino que también las mismas máquinas han de ser tenidas en cuenta.

Para ello hay que crear usuarios en Linux con el nombre netbios de las clientes seguidos del símbolo de dolar.

Lo explico por pasos.

• Crearemos un grupo, y para evitar líos, con el mismo nombre que le hemos puesto en el smb.conf en la opción workgroup:

• groupadd grupo

• Hay que crear un usuario Unix con el nombre netbios de la máquina y (ojo con esto) seguido del símbolo dolar, sin shell, sin directorio home e integrado en un grupo. El nombre de la máquina es el que figura en el cliente en Panel de Control -> Sistema – Nombre de equipo. Imaginemos el grupo que se llama grupo y la máquina se llame máquina

• adduser -g grupo -d /dev/null -s /dev/null -c “cliente XP” maquina$

Si observamos el fichero /etc/password, veremos una entrada que empieza por maquina$ que es la cuenta de la máquina.

• Hay que crear la cuenta de confianza añadiendo a smbpasswd la máquina:

• smbpasswd -a -m maquina

Observa con cuidado que aquí no hace falta poner el símbolo de dólar. Hay que indicar, eso sí, que se trata de una máquina (la opción -m). No va a pedir contraseñas.

Si hay más máquinas, pues lo mismo para cada una de ellas.

5 Configurar las estaciones de trabajo para que se “autentiquen” con el PDC

5.1 Preparar el cliente

Esta es la parte más diferenciada con respecto a clientes W2000, WNT y W98/95.

Resulta que WXP home no puede integrarse en un dominio Windows. En cambio el XP profesional sí.

Hay que hacer y comprobar los siguientes pasos:

• Ir a Panel de Control -> Herramientas Administrativas -> Directivas de Seguridad local y mirar Directivas Locales -> Opciones de seguridad

• Miembro de dominio: descifrar o firmar digitalmente datos de un canal seguro (siempre): Deshabilitar

• Miembro de dominio: Deshabilitar cambios password en cuenta máquina -> deshabilitar

• Miembro de dominio: Requerir clave de sesión protegida (W2000 o más reciente) -> deshabilitar

• Cambiar una cosilla del registro. Esto merece comentario aparte.

Hay un archivo en /usr/share/doc/samba.XXXX/docs/Registry/ que se llama WinXP_SignOrSeal.reg. Este archivo lo guardamos en un diskette y en cada cliente le damos dos clicks para que se agregue su información al registro de windows.

Simplemente cambia esta línea del registro dejándola así:

HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\Netlogon\Parameters “requiresignorseal”=dword:00000000

Con esto hemos preparado el cliente. Solo falta agregarlo a nuestro dominio.

5.2 Agregar el cliente al dominio.

Vamos a Panel de Control -> Sistema y pinchamos en la pestaña “Nombre del equipo”

Vereis una descripción del equipo. Pues escribís lo que deseéis.

Pincháis en el botón “Cambiar”

Nombre del equipo: en nuestro ejemplo maquina.

Miembro de: elegimos dominio.

El nombre del dominio es el nombre “WorkGroup” del archivo smb.conf.

Le damos a aceptar y nos pide un usuario y una contraseña.

Esto me dio guerra.

Hay que poner root (sí root) y la contraseña de root del servidor.

Nos dará la bienvenida.

Una cosa: el usuario root tiene que estar agregado en el fichero smbpasswd, para que el cliente pueda autenticarlo y así tenerlo en el dominio, pero agregad root solamente para esta cuestión, luego (una vez configurada toda la red) es recomendable borrarlo, porque ¿no querremos que exista un usuario samba que se llame root?¿verdad? a partir de allí root no tiene que estar agregado a smbpasswd. No sé si repetirlo más veces … si: root NO tiene que estar agregado a smbpasswd.

6 Agradecimientos

A mis alumnos: que me hacen moverme por mundos en los que no deseo moverme y que si no fuera por ellos yo no hubiera instalado un Windows XP ni de broma para probar esto. A mi esposa: que no se por qué obscura razón no deja de una vez de utilizar Windows.

El  “Software Libre” es un asunto de libertad, no de precio. Para entender el concepto, debes pensar en “libre” como en “libertad de expresión”, no como en “cerveza gratis” [N. del T.: en inglés una misma palabra ( free ) significa tanto libre como gratis, lo que ha dado lugar a cierta confusión].

“Software Libre” se refiere a la libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software. De modo más preciso, se refiere a cuatro libertades de los usuarios del software: