CONFIGURAR RED, NTFS y SSH: * HARDWARE: La idea es conectar 2 ordenadores a traves de las tarjetas de red. Para ello es importante el tener un cable de red de par trenzado = cable "crossover" = cable cruzado. El resto de informacion sobre el hardware utilizado esta en los documentos info-hardware-garraxiN.txt. * CONFIGURAR LA RED: Para ello sigo las instrucciones del Howto: Redes-En-Linux-Como y de la Guia de Referencia de Debian (sobre todo el cap. 10 Configuración de la red). Creo que es lo mismo para la maquina servidor y la maquina cliente, solo que cambiando las direcciones IP de cada una. 1. Arranco un ordenador con kernel Debian 2.4.27 (que tiene soporte para red con modulos). Despues pruebo todo esto con un kernel que tiene una configuracion estandar del kernel de garraxi, mas el soporte para la tarjeta de red del ordenata y para nfs. Reconoce la tarjeta de red en el arranque como (pillado con lspci): 0000:01:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) Subsystem: Dell: Unknown device 00b4 Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at ec00 [size=128] Memory at fdfffc00 (32-bit, non-prefetchable) [size=128] Expansion ROM at fe000000 [disabled] [size=128K] Capabilities: 2. Compruebo que tengo instalados paquetes importantes listados en Redes-En-Linux-Como: root# dpkg -i hostname_x.xx-y.yy.deb -> SI root# dpkg -i netbase_x.xx-y.yy.deb -> SI root# dpkg -i netstd_x.xx-y.yy.deb -> NO (no esta en Sarge) Ademas tambien tengo el paquete ifupdown, que segun la guia de referencia de debian se utiliza para configurar la red. Tambien tengo net-tools, citado en la misma guia. 3. Compruebo que el script que arranca las interfaces de red en el inicio es /etc/init.d/networking. Si lo hago arrancar a mano me dice: martintxo@fundy:~$ sudo /etc/init.d/networking start Setting up IP spoofing protection: rp_filter. Configuring network interfaces...ifup: interface lo already configured done. Esto es porque la unica interfaz de red configurada en /etc/network/interfaces es lo (loopback: la máquina consigo misma). 4. Edito /etc/network/interfaces para añadir una interfaz eth0, con un numero IP fijo (que sera la direccion IP que tendrá esta maquina en la "red") y una mascara de red (ambos pillados de la Guia de referencia de Debian). La dir IP tiene que ser diferente en ambas maquinas cliente/servidor (por ejemplo, yo pongo 192.168.0.1 en el server y 192.168.0.2 en el cliente), pero se puede elegir cualquier numero que venga bien. La mascara de red tiene que ser la misma?, y parece ser que se recomienda 255.255.255.0: iface eth0 inet static address 192.168.0.1 netmask 255.255.255.0 Despues activo esta interface con 'ifup eth0'. De esta manera aparece otra interfaz de red, ademas de la loopback que viene por defecto (la que asigna al ordenata local la IP 127.0.0.1). Esto se puede ver con 'ifconfig -a': martintxo@fundy:~$ sudo ifconfig -a eth0 Link encap:Ethernet HWaddr 00:B0:D0:16:53:53 inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:1 errors:0 dropped:0 overruns:0 carrier:1 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:60 (60.0 b) Interrupt:10 Base address:0xec00 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:345 errors:0 dropped:0 overruns:0 frame:0 TX packets:345 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:513106 (501.0 KiB) TX bytes:513106 (501.0 KiB) De la forma que se ha puesto el archivo /etc/network/interfaces (definiendo a eth0 sin poner auto), esta interfaz de red solo se levantara cuando se haga explicitamente con 'ifup eth0'. Para que la interfaz eth0 se levante en el arranque del ordenata (importante en el server para que este arrancada antes de que se vallan a exportar los dir con nfs, y tambien en el cliente para que este arrancada antes de que se vallan a montar los dirs exportados), poner la configuracion como: auto eth0 iface eth0 inet static address 192.168.0.1 netmask 255.255.255.0 * NFS: Para ello sigo las instrucciones de la Guia de Referencia de Debian (cap. 3.4 Configuración NFS). 1. Instalar nfs-kernel-server y nfs-common en en el server, y solo nfs-common en el cliente. El paquete nfs-kernel-server es el que proporciona el servidor que exporta los directorios que se quieren compartir. El paquete nfs-common tiene programas para poder montar los dir exportados en el cliente. De esta manera, el kernel del server debe tener soporte para nfs filesystem y para ser servidor de nfs. El kernel del cliente solo necesita tener soporte para nfs filesystem. Otra manera seria usando en el server que el servidor en vez de ser del kernel (nfs-kernel-server) sea un programa de usuario (paquete nfs-user-server), pero en el propio paquete dice que de esta manera es mas lento y tiene otros problemas. 2. Configurar /etc/exports en la maquina servidor de directorios compartidos para que se indiquen que directorios se exportan a la maquina cliente. Atencion a esta nota, para que no valla lento: martintxo@fundy:~$ zless /usr/share/doc/nfs-kernel-server/NEWS.Debian.gz nfs-utils (1:1.0.1-1) unstable; urgency=low * Exports default to "sync", that is, synchronous writes. This is safer but MUCH SLOWER than the old default of "async". All exports should be marked as either "sync" or "async" to avoid a warning from exportfs. Asi, en el archivo /etc/exports se puede poner, por ejemplo: /home/garraxi/Biltegi 192.168.0.2(async,rw,nohide,no_root_squash) Donde: '/home/garraxi/Biltegi' es el dir exportado 192.168.0.2 es la IP del ordenador que se permite que se conecte (se podria poner * que significa que puede ser exportado a todos los clientes que se conecten a ese servidor) async: es para que valla mas rapido (ver arriba) rw: que el dir exportado sea leible y escribible nohide: que no "esconda" los otros sistemas de ficheros que estan montados en algun subdir del dir exportado. Para que esto funcione se debe de expecificar el ordenador que se permite conectarse al server (con su IP por ejemplo), no vale utilizar wildcards (asteriscos y tal). no_root_squash: permitir que el root actue como tal en los directorios exportados. El por defecto en NFS es que el root no pueda actuar como tal (por seguridad), pero en nuestro caso eso impedia que funcione el 'sudo' en por ejemplo el script para proteger la musica cambiandola a usuario garraxi2. Para que funicione esto desde el ordenador auxiliar le pongo esta opcion. Ver 'man exports' para mas info sobre otras posibles opciones. Pero finalmente intentando exportar todo el dir Biltegi (donde se montan los discos de musica, cuñas y programas en 3 subdirs) no permite que "no se escondan" estos montajes. Por eso finalmente exporto directamente los tres subdirs indicados: /home/garraxi/Biltegi/Kunyas 192.168.0.2(async,rw,nohide,no_root_squash) /home/garraxi/Biltegi/Musica 192.168.0.2(async,rw,nohide,no_root_squash) /home/garraxi/Biltegi/Programas 192.168.0.2(async,rw,nohide,no_root_squash) 3. Arrancar los servidores necesariios en el server: - el portmap (etc/init.d/portmap start) - el nfs-server (/etc/init.d/nfs-kernel-server start). Es necesario que antes de arrancar los servidores este levantada la interfaz de red, para lo que se debe de poner que se levante automaticamente en el inicio. Despues es importante tambien que primero se levante portmap (viene con nº 18 en /etc/rc2.d) y despues nfs-server (nº 20). En el auxiliar (cliente) tambien debe de estar levantado portmap, para que asi se pueda levantar statd (parte del paquete nfs-common) que parece ser necesario para poder montar los dir exportados. 4. Montar los directorios exportados del server en el cliente con mount y tipo de ficheros nfs. Ejemplo: mount -t nfs 192.168.0.1:/home/garraxi/Biltegi /home/garraxi/Biltegi El 1º es el dir que se monta, que viene con la IP del server (tambien puede ser el nombre de la maquina, creo), seguido de dos puntos (:) y de la ruta que esta exportando. El 2º es el punto de montaje en la maquina cliente. Si se quiere que sea permanente y se monten en el inicio, Se pondra en el fstab. Ejemplo: 192.168.0.1:/home/garraxi/Biltegi/Musica /home/garraxi/Biltegi/Musica nfs user,auto,rsize=8192,wsize=8192,timeo=14,intr 0 0 Las opciones significan: rsize=8192: nº de bites usados para leer un archivo. El por defecto es 4096, pero el manual dice que se mejora el rendimiento si se pone 8192. wsize=8192: nº de bites usados para escribir a un archivo. El por defecto es 4096, pero el manual dice que se mejora el rendimiento si se pone 8192. timeo=14: El tiempo que se tarda en intentar una reconexion? si hay problemas en el server. El manual dice que se puede mejorar el rendimiento si se aumenta ese valor en servers muy cargados. El por defecto es 7. intr: Si el server falla, notifica al programa de ese fallo?. Las 4 opciones las he pillado de lo que ponian otras personas en los grupos de google :-). Los directorios y archivos exportados por nfs mantienen el numero indicativo del usuario y grupo (uid y gid) que tienen en el servidor. De esta manera, por defecto seran propiedad de los usuarios y grupos que tengan las mismas ui's en el cliente. En nuestro caso, tanto en el server como en el cliente existen los mismos usuarios, con las mismas contraseñas (dado que el S.O. del cliente es copia del servidor). De esta manera, en el cliente los archivos mantienen los mismos permisos que en el servidor y para poder trabajar con ellos hay que utilizar las mismas tecnicas que si estuvieras en el servidor directamente (esto es, no hay problema para tocar archivos no protegidos por garraxi2, pero es necesario autentificarse como garraxi2 para poder trabajar (que no solamente leer) con los archivos protegidos). * SSH: Info de que forma utilizar para arrancar remote apps. pillada del /usr/share/doc/HOWTO/en-txt/Networking-Overview-HOWTO.gz. Con esta info primero pruebo un poco todas las opciones que da para arrancar las aplicaciones remotas, y me quedo finalmente con ssh porque me resulta mas sencillo configurarla. En principio ssh necesita mas recursos que telnet, pero muchos menos que VNC. Ssh permite logearse en una maquina remota (y utilizar entonces esa maquina para correr los comandos que quieras) y tambien ejecutar directamente un comando cualquiera en la maquina remota (en este caso se usa ssh como: ssh [user@]hostname [command]. El paquete ssh contiene tanto el demonio sshd (para aceptar conexiones remotas) y el cliente ssh (para iniciar las conexiones). El demonio se arranca como 'sudo /etc/init.d/ssh start', aunque puede estar desactivado de dos modos: * Borrando el enlace simbolico /etc/rc2.d/S20ssh (con update-rc.d por ejemplo). * Si existe el archivo /etc/ssh/sshd_not_to_be_run creado en la instalacion. Instalo en el server y en el aux: ssh y ssh-askpass (aunque creo que este ulltimo no va ha hacer falta). En el aux no permito que se sshd se inicie en el arranque, en el server si (cambiable con root$dpkg-reconfigure ssh). Para conectarme con ssh al server desde el aux con user garraxi corro el comando 'ssh 192.168.0.1'. La primera vez me dice que si quiero añadir el host 192.168.0.1 a la lista de hosts confiables, le digo que si y ya no lo pregunta mas para ese usuario. Para logearme me pide la pass de garraxi. Para conectarme como user root corro 'ssh -l root 192.168.0.1', y para garraxi2 'ssh -l garraxi2 192.168.0.1'. En ambos casos pide las respectivas pass. Para acabar la conexion y volver a la shell normal del aux hacer un logout. Es mejor que el prompt del server y el del aux sean diferentes para reconocer mas facil donde estas. Para ello edito el archivo $HOME/.bashrc de cada usuario (garraxi, garraxi2 y root), y donde habla del prompt (PS1) le añado \[Aux1:\] en el ordenata aux, y \[Serv:\] en el server. Para no tener que utilizar la contraseña se pueden generar unas claves publicas y privadas, en el ordenador cliente (el aux.). Generar las claves se hace con el comando 'ssh-keygen -t rsa' como usuario. Despues te pide donde guardarla y se acepta el por defecto, te pide una passphrase y la he dejado vacia, con lo que finalmente guarda la clave pridada como id_rsa y la publica como id_rsa.pub. En internet he visto varias recetas que utilizan el mismo sistema (exactamente, incluso sin passphrase). Genero las claves publicas y privadas para garraxi, garraxi2 y root. Entonces cojo el contenido de este ultimo archivo y lo añado EN EL SERVIDOR al contenido del archivo $HOME/.ssh/authorized_keys (se crea con este nombre si no existe). martintxo@fundy:~$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/martintxo/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/martintxo/.ssh/id_rsa. Your public key has been saved in /home/martintxo/.ssh/id_rsa.pub. The key fingerprint is: c1:c0:db:fa:70:64:47:a7:69:b5:f1:45:b2:1b:0b:87 martintxo@fundy Asi ya no me pide pass si intento logearme en el server como garraxi desde una shell de garraxi, o lo mismo como garraxi2, pero sigue pidiendola para logearme como garraxi2 desde una shell de garraxi (y a la inversa). Hecho esto puedo mandarle comandos al server y los ejecuta sin pedir autentificacion, los comandos se mandan del tipo: ssh user@host command ssh garraxi@192.168.0.1 somaclient -p -ssl --readpalinsesto Pero esto de momento solo vale para aplicaciones de consola, no de las X, donde da un error del tipo: martintxo@fundy:~$ ssh martintxo@127.0.0.1 gtkedit Gtk-WARNING **: cannot open display: Esto es porque el asunto de las X en ssh y Debian esta desactivado por defecto. Nota que aparece con 'dpkg-reconfigure ssh': x NOTA: Reenvío de X11 y Autorización desactivadas por defecto. x x x x Por razones de seguridad, la versión de ssh de Debian tiene por defecto x x ForwardX11 y ForwardAgent desactivadas. x x x x Puede activar estas opciones para los servidores en los que confíe, en los x x ficheros de configuración o con la opción -X en línea de comandos. x x x x Puede encontrar más detalles en /usr/share/doc/ssh/README.Debian. x Para cambiarlo modifico en el servidor el archivo /etc/ssh/sshd_config, poniendo lo siguiente: X11Forwarding yes # estaba a no. Tambien pongo en ese archivo que solo se permita la conexion a los usuarios garraxi, garraxi2 y root del ordenata auxiliar1 (por motivos de seguridad, por si alguna vez hay internet y que haya algun problema mas para ataques remotos): AllowUsers garraxi@192.168.0.2 garraxi2@192.168.0.2 root@192.168.0.2 Reiniciar el servidor sshd: Serv:root@garraxi:~# /etc/init.d/ssh restart Restarting OpenBSD Secure Shell server: sshd. Despues hay que logearse como 'ssh -X garraxi@192.168.0.1'. La opcion -X significa que se pone en marcha la conexion con el X11 forwarding activado. Para que funcione bien, el archivo ~/.Xauthority de garraxi (el que arranca las X) debe de ser propiedad de garraxi y solo leible y escribible por el. De esta manera podemos abrir aplicaciones X remotas con los usuarios garraxi y root logeados correctamente en el server, pero no con garraxi2. Con este al intentar iniciar la conexion da un error (pero se conecta al cabo de un tiempo): Aux1:garraxi2@garraxi:~$ ssh -X garraxi2@192.168.0.1 Warning: No xauth data; using fake authentication data for X11 forwarding. Y cuando se intenta arrancar una aplicacion X, da el error: Serv:garraxi2@garraxi:~$ gtkedit .zoinks Xlib: connection to "localhost:12.0" refused by server Xlib: Invalid MIT-MAGIC-COOKIE-1 key Gtk-WARNING **: cannot open display: localhost:12.0 La 1º solucion que encuentro es correr en el aux con el usuario que arranca las X (garraxi) el comando 'xhost +'. El problema que da poner 'xhost +' es que permite a cualquier ordenador (tanto de una red local, como de internet) que logre conectarse a nuestro equipo, que utilice sus X. Esto puede ser un riesgo de seguridad. Despues compruebo que poniendo en el aux 'xhost +local:' con el user que corre las X (garraxi), esto si permite que garraxi2 arranque apps graficas del server. Este comando lo que hace es que se permite a todos los usuarios en la maquina donde se corre a mostrar ventanas en el desktop (cuando se ejecuta dice: "non-network local connections being added to access control list"). Asi que para hacer esto permanente pongo en /home/garraxi/.xinitrc del aux: 'xtoolwait xhost +local:' Y lo mantengo para cuando tenga que abrir una cuenta a pelo, sin gksu. Otra solucion para que garraxi2 se logee en el server sin problemas de autenticacion (con lo que no hay un tiempo de espera al logearse) es que para cambiarse al usuario garraxi2 en el aux (antes de logearse) se debe de hacer con 'su - garraxi2'. De esta manera no se heredan parte de las settings de garraxi al pasar a garraxi2 como pasa si utilizamos 'su garraxi2'. Para esto no vale lo de utilizar 'xhost +local:'. Antes de logearse en el server hay que establecer la variable $DISPLAY, y despues logearse normalmente. Osea, en este orden todos los comandos: $ su - garraxi2 password: $ export DISPLAY=:0.0 $ ssh -X garraxi2@192.168.0.1 Pero el panel del Admin de la Emision lo abrimos con gksu y no con su. En gksu(1) dice que si hay problemas con SSH, se utilize la opcion --ssh-fwd. Asi que para que el panel del Admin de la Emision funcione bien utilizo el comando (puesto en el menu de icewm): gksu --ssh-fwd --user garraxi2 --message "Mete la contrasenya del \ Administrador de la Emision" garraxi2-tareas-aux.sh * AUMENTAR LA ESCALABILIDAD DE LA RED: Mas tarte preparo la red para mas ordenadores y que sea escalable. Para ello realizo los siguientes cambios: * Cambiar los nombres de las maquinas (hostname). Tanto server como aux se llamaban·garraxi" (que coincide ademas con el nombre del usuario normal, para mas complicacion). Se ponen como nombres "gserver" para el servidor y "gaux1", "gaux2" ... para los ordenadores auxiliares (los nombres de los usuarios no se tocaran: "garraxi" el user normal, "garraxi2" el admin de la emision y "root" el admin general). Para cambiarlos, como root: - Editar /etc/hostname y cambiar el viejo hostname por el nuevo donde aparece. - Editar /etc/hosts y cambiar el viejo hostname por el nuevo donde aparece. - Correr de nuevo '/etc/init.d/hostname.sh start' para hacer que ese nombre sea el actual (o reiniciar el ordenata). - Mirar si hay mas sitios donde el viejo hostname aparece, con grep: 'grep -r -i viejo_hostname /etc'. Editarlos directamente si se ve sencillo o si no probar a buscar de que paquete son (dpkg -S archivo) y despues hacer un 'dpkg-reconfigure -plow paquete'. Pero en realidad compruebo que el unico cambio necesario es en el script copiaseg-server/aux. Cambio el script para cron copiaseg-server/aux porque ibackup guarda las copias de seguridad con el nombre del host, y en el script tengo puesto que savelog rote esas copias de seguridad (con ese nombre). Asi que cambio los nombres del archivo de copia de seguridad. De esta manera guardo solo un par de los archivos viejos (con nombre garraxi.tar.gz) y los nuevos se llaman gserver.tar.gz y gaux1.tar.gz. * Cambiar IP del auxiliar (en el server mantenemos la misma IP): editar /etc/network/interfaces y cambiar el address de eth0 (cambiar a 192.168.0.100). Reiniciar el ordenata para ver donde falla: - No se montan los directorios exportados por el server via NFS. Esto es porque en el server (en /etc/exports) tenemos puesto que solo se le permitia el acceso a la IP antigua, la que hemos cambiado. Cambiar en todos los directorios exportados la nueva IP. Despues pondremos la del futuro gaux2 en lineas aparte. Esto es asi porque compruebo en man exports que con IPs no funcionan las wilcards (asteriscos) y que poniendo la opcion "nohide" no se pueden utilizar wildcards, ni nombres de "grupos", solo con exports a single hosts (y creo que necesitamos el nohide para poder montar los sistemas de ficheros que tenemos en los diferentes discos del server).. - No se permiten las conexiones por SSH. Esto es porque tenemos puesto en el server (en /etc/ssh/sshd_config) que solo se permita la conexion a los users de la maquina con la IP vieja que hemos cambiado. Pongo que se permita la conexion a los users garraxi@192.165.0.100, garraxi2@192.165.0.100 y root@192.165.0.100. Por otra parte, tambien rehago las claves privadas y publicas de garraxi, garraxi2 y root en el aux, y copio las publicas a los $HOME~/.ssh/autorized_keys respectivos, borrando las antiguas (esto porque en ellas venia el hostname del ordenata auxiliar). Tambien tengo puesto en el auxiliar los siguientes alias de bash para el usuario garraxi (para no tener que escribir el comando completo): g1c: conectar garraxi al server (nu txuta, ver a continuacion) g2c: conectar garraxi2 al server (pide contraseña). rootc: conectar el root al server (pide contraseña). Otro problema es que la conexion del user garraxi al server ya no es posible. Es debido a que ahora arrancamos las X con xinit y de manera que si se caen las X, estas se vuelven a arrancar ellas solas. Esto es bueno porque asi si se caen las X del server se podria matar al somad, pero de esta manera volveria a arrancar (aunque no esta tan claro que esto suceda siempre, a veces queda en background y no vuelve a arrancar...). Pero de esta manera, es imposible abrir otra sesion (tanto local como remota) con el user garraxi que arranca las X. Esto no es mucho problema, porque se arreglaria cuando quitemos al server del uso y ya no tenga X (entonces no habra problemas para conectarse con ningun user). De momento seguiremos asi dado que lo normal es conectarse al server con user garraxi2 o root. Otra cosa que tambien tenia puesta era que en el prompt de las consolas de los 3 user en ambos ordenadores apareciera la maquina en la que estabas. Eso ahora ya no es necesario al haber cambiado el nombre de las maquinas y aparece por defecto, por lo que deshago esos cambios. * Permitir utilizar los nombres de maquina en vez de las IPs. Esto se hace añadiendo a /etc/hosts entradas del tipo: 192.168.0.100 gaux1 (en el server) 192.168.0.1 gserver (en los aux) * AÑADIR OTRA TARJETA DE RED AL SERVIDOR: Añado otra tarjeta de red al servidor para que de esta manera se puedan conectar a el 2 ordenadores, sin necesidad de poner un hub/swich o como se llame. Se trata de una Intel 82557/8/9 [Ethernet Pro 100] PCI, por lo que es de igual modelo que la integrada en la placa. De esta manera ambas utilizan el mismo modulo del kernel (que esta compilado dentro del kernel). Mas info sobre el harware en info-hardware-garraxi3.txt. Para evitar que el kernel en cada reinicio pueda asignarles diferentes interfaces de red (eth0, eth1...) intento utilizar un sistema que se indica en el 'man interfaces': The ifup and ifdown programs work with so-called "physical" interface names. These names are assigned to hardware by the kernel. Unfortu- nately it can happen that the kernel assigns different physical inter- face names to the same hardware at different times; for example, what was called "eth0" last time you booted is now called "eth1" and vice versa. This creates a problem if you want to configure the interfaces appropriately. A way to deal with this problem is to use mapping scripts that choose logical interface names according to the properties of the interface hardware. See the get-mac-address.sh script in the examples directory for an example of such a mapping script. See also Debian bug #101728. Pero probando estas ideas, no me acaba de funcionar el script get-mac-address.sh. Asi que busco info en google y encuentro que ahora se esta llevando ese tema con udev. Asi sigo la receta "Rename Network Interface using udev in Debian" de www.debianhelp.co.uk. - Crear el archivo /etc/udev/rules.d/010_netinterfaces.rules, con el siguiente esquema: KERNEL="oldnameprefix*", SYSFS{address}=="MACaddress", NAME="newname" donde - oldnameprefix: prefijo del nombre que le da el kernel a las intrefaces (eth) - MACaddress: la direccion MAC de cada tarjeta (ver con ifconfig -a), pero con todas las letras en minusculas. - newname: el nuevo nombre que tendra la interfaz Asi el archivo queda: KERNEL=="eth*", SYSFS{address}=="00:90:27:e0:63:d1", NAME="eth-aux1" KERNEL=="eth*", SYSFS{address}=="00:90:27:63:10:ec", NAME="eth-aux2" - Volver a configurar las redes en /etc/network/interfaces, poniendo los nuevos nombres de interface definidos arriba: #Red en tarjeta integrada en placa Intel 82557/8/9 [Ethernet Pro 100], # que conecta con el ordenata auxiliar 1. auto eth-aux1 iface eth-aux1 inet static address 192.168.0.1 netmask 255.255.255.0 #Red en tarjeta PCI Intel 82557/8/9 [Ethernet Pro 100], # que conecta con el ordenata auxiliar 2. auto eth-aux2 iface eth-aux2 inet static address 192.168.0.2 netmask 255.255.255.0 De esta manera se configuran las 2 interfaces de red (eth-aux1 y eth-aux2), pero solo se pone en marcha la primera, independientemente de donde este enchufada la clavija de red. Para conseguir que las conexiones de red desde el aux1 al server funcionen por la 2º intrefaz debo de hacer un 'ifdown --all' y despues un 'ifup eth-aux2' (o chapuzas parecidas). De todas formas ESPERAR A PONER 2 PCs EN RED, CADA UNO EN UNA INTERFAZ PARA VER COMO SE COMPORTA. Otra forma de hacer lo mismo sin crear ningun archivo nuevo es editando el archivo /etc/udev/rules.d/z25_persistent-net.rules. Ver: http://www.esdebian.org/article.php/20080109162314685 ----------------------------------------------------------------------------- (Del: Redes en Linux Como) Introducción a las direcciones IP. Las direcciones del Protocolo Internet (IP) están compuestas por cuatro bytes. La convención es escribir estas direcciones en la denominada «notación decimal puntuada» (dotted decimal notation). De esta forma cada byte es convertido en un número decimal (0-255), despreciando los ceros a la izquierda a menos que el número en sí sea cero. Por convención, cada interfaz de una máquina o encaminador tiene una dirección IP. Es válido usar la misma IP para cada interfaz de una sola máquina en algunas circunstancias, pero normalmente cada interfaz tiene su propia dirección. Las Redes basadas en Internet Procotol son secuencias contiguas de direcciones IP. Todas las direcciones dentro de una red tienen un número de dígitos de en común. A la porción de la red que es común a todas las direcciones llama la «porción de la red». Los dígitos restantes son llamados «porción de la máquina». Al número de bits que comparten todas las direcciones de una red se le llama máscara de red (netmask), y su papel es determinar qué direcciones pertenecen a la red y cuáles no. Consideremos el siguiente ejemplo: --------------------- --------------- Dirección Host 192.168.110.23 Máscara de red 255.255.255.0 Porción de red 192.168.110. Porción de Host .23 --------------------- --------------- Dirección de Red 192.168.110.0 Dirección de Difusión 192.168.110.255 --------------------- --------------- Cualquier dirección a la que se aplique una operación and de bits con su máscara de red, revelará la dirección de la red a la que pertenece. La dirección de red es por tanto siempre el menor número de dirección dentro de el rango de la red y siempre tiene la porción de máquina codificada toda con ceros. La dirección «de difusión» (broadcast) es una especial a la que escucha cada máquina en la red además de a la suya propia. Esta dirección es a la que se envían los datagramas si se supone que todas las máquinas de la red lo deben recibir. Ciertos tipos de datos, como la información de encaminamiento y los mensajes de aviso son transmitidos a la dirección de difusión para que cada estación en la red pueda recibirlo simultáneamente. Hay dos estándares usados comúnmente al respecto de la dirección de difusión. El más ampliamente aceptado es el de usar la dirección más alta posible en la red. En el ejemplo anterior sería 192.168.110.255. Por alguna razón, otras estaciones han adoptado la convención de usar las direcciones de red como direcciones de difusión. En la práctica no importa mucho cual use, pero asegúrese de que cada máquina en la red está configurada con la misma. Por razones administrativas, durante el desarrollo inicial del protocolo IP se formaron, de forma arbitraria, algunos grupos de direcciones como redes, y estas redes se agruparon en las llamadas «clases». Estas clases proporcionan un cierto número de redes de tamaño estándar que pueden ser reservadas. Los rangos reservados son: ---------------------------------------------------------- | Clase | Máscara de | Direcciones de red | | de red | red | | ---------------------------------------------------------- | A | 255.0.0.0 | 0.0.0.0 - 127.255.255.255 | | B | 255.255.0.0 | 128.0.0.0 - 191.255.255.255 | | C | 255.255.255.0 | 192.0.0.0 - 223.255.255.255 | |Multicast| 240.0.0.0 | 224.0.0.0 - 239.255.255.255 | ---------------------------------------------------------- Las direcciones que deberá usar dependen de lo que vaya a hacer exactamente. Puede que tenga que realizar varias de las siguientes actividades para obtener las direcciones que necesite: Instalar una máquina Linux en una red IP existente Si desea instalar una máquina Linux en una red IP existente entonces debería contactar con los administradores de la red y preguntarles por la siguiente información: * Dirección IP del Host * Dirección IP de la red * Dirección IP de broadcast * Máscara de red IP * Dirección del encaminador (router) * Dirección del Servidor de Nombre de Dominio (DNS) Debería configurar entonces el dispositivo de red Linux con esos detalles. No puede inventarlos y esperar que la configuración funcione. Construir una nueva red propia que nunca conectará con Internet Si está construyendo una red privada y no tiene intención de conectar nunca esa red a Internet entonces puede elegir las direcciones que quiera. De todas maneras, por razones de seguridad y consistencia, se han reservado algunas direcciones IP de red específicamente para este propósito. Están descritas en el RFC1597 y son las que siguen: ----------------------------------------------------------- | DIRECCIONES RESERVADAS PARA REDES PRIVADAS | ----------------------------------------------------------- | Clase | Máscara de | Direcciones de red | | de red | red | | ----------------------------------------------------------- | A | 255.0.0.0 | 10.0.0.0 - 10.255.255.255 | | B | 255.255.0.0 | 172.16.0.0 - 172.31.255.255 | | C | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 | ----------------------------------------------------------- Primero debería decidir cuán grande quiere que sea su red para entonces elegir tantas direcciones como necesite.