Disparar un script desde otra maquina
Hola: Quiero desde un script corrriendo en la máquina A (como root) hacer que se lance, automáticamente, otro script en otra maquina conectada por red local casera, también como root. Como la red es local y casera no hay problemas de seguridad. En otra ocasión esto lo he hecho mandando un correo desde una maquina a la otra, y funciona. Pero, por un lado me pregunto si hay más maneras, y por otro, cuando el MTA es postfix, el root no puede recibir correos, y eso me lo complica un poco. -- Saludos Carlos Robinson
Prueba con el servicio rexec que permite hacer ejecución de comandos remota aunque es super inseguro, pero como dices que no tendrías problemas de seguridad lo puedes usar. Por defecto no se instala el servidor rexec en ningún linux así que lo tienes que instalar manualmente junto con el rlogin. Después debes crear una entrada en cada uno de los /etc/hosts de los servidores y agregar rlogin y reexec en /etc/securetty, además crear una entrada con el nombre del servidor remoto en /etc/hosts.equiv No śe si hay alguna alternativa usando ssh, te recomiendo que busques la solución con esas alternativas. On Sat, 8 Jan 2005 00:01:22 +0100 (CET), Carlos E. R. <robin1.listas@tiscali.es> wrote:
Quiero desde un script corrriendo en la máquina A (como root) hacer que se lance, automáticamente, otro script en otra maquina conectada por red local casera, también como root. Como la red es local y casera no hay problemas de seguridad.
-- Saludos Oscar
El 2005-01-07 a las 16:10 -0800, Oscar Gosdinski escribió:
Prueba con el servicio rexec que permite hacer ejecución de comandos remota aunque es super inseguro, pero como dices que no tendrías problemas de seguridad lo puedes usar.
Es verdad, no me acordaba de rexec. No me gusta, pero es una alternativa... En realidad no me hace falta ni interesa que el proceso sea controlado desde el "cliente", me basta con que se dispare. Puede que al final lo haga por email...
No ?e si hay alguna alternativa usando ssh, te recomiendo que busques la solución con esas alternativas.
Hay un rsh, que es un poco más seguro (usa kerberos), y en realidad se menciona en la página del ssh. Pero no usa ssh (creo). Mira, contaré exactamente lo que trato de hacer ;-) Inciso explicativo: en el 9.1, que todavía estoy usando, el modem no trabaja bien, va lento (+/- 1.5 kbps). Eso ya lo reporté hace tiempo. Por eso tengo el modem conectado a mi antiguo PC (un pentium I a 130) con SuSE 7.3, y por ethernet me conecto desde el otro PC (P-IV) Bien. En el P-IV debo disparar ip-up manualmente para que recoja el correo, después de que ejecute wvdial en el P-I, también manualmente. Lo que trato de automatizar es que al activar la conexión por modem en el P-I, desde su script ip-up (que se ejecuta automáticamente) haga algo para que arranque a su vez el ip-up del ordenador P-IV. El proceso ha de repetirse cuando cae la conexión para ip-down, pero es la misma idea. La solución que estoy desarrollando, vagamente, es la siguiente: ip-up del P-I envia un correo con el tema "conectting" al root del P-IV. Allí, el procmail lo detecta, con la regla: :0 * ^Delivered-To: root@nimrodel.valinor { .... varias reglas :0 * ^FROM.*root@telperion.valinor * ^Subject: Connecting|Disconnecting { :0 * ^Subject: Connecting $HOME/Mail/in_root # Lanzar /etc/ppp/ip-up.local eth0 :0 * ^Subject: Disconnecting $HOME/Mail/in_root # Lanzar /etc/ppp/ip-kill } } Eso debería funcionar, sólo me falta la parte de lanzar los scripts, probablemente con sudo. Y, si quisiera añadir seguridad, debería añadir una firma PGP o algo parecido. En realidad, bastaría con que el contenido del correo fuera un fichero clave, aunque fuese simplemente algo aleatorio firmado con pgp, con la firma correcta O sea, un robot. -- Saludos Carlos Robinson
El Sábado, 8 de Enero de 2005 00:01, Carlos E. R. escribió:
Quiero desde un script corrriendo en la máquina A (como root) hacer que se lance, automáticamente, otro script en otra maquina conectada por red local casera, también como root.
Yo lo hago así: ssh usuario@máquina_remota script Para evitar teclear la contraseña, copio el fichero $HOME/.ssh/id_rsa.pub del usuario en la "máquina_local" en el home de "usuario@máquina_remota" y, finalmente, en "máquina_remota": cat id_rsa.pub >> $HOME/.ssh/authorized_keys Saludos. Miquel.
Miquel A. Noguera escribió:
El Sábado, 8 de Enero de 2005 00:01, Carlos E. R. escribió:
Quiero desde un script corrriendo en la máquina A (como root) hacer que se lance, automáticamente, otro script en otra maquina conectada por red local casera, también como root.
Yo lo hago así:
ssh usuario@máquina_remota script
Para evitar teclear la contraseña, copio el fichero $HOME/.ssh/id_rsa.pub del usuario en la "máquina_local" en el home de "usuario@máquina_remota" y, finalmente, en "máquina_remota":
cat id_rsa.pub >> $HOME/.ssh/authorized_keys
Saludos. Miquel.
Por otro lado, si lo que quieres es ejecutar un comando que existe en la maquina remota, has de introducirlo entre comillas: ssh usuario@máquina_remota "script" Por si alguien no sabe como se crean las claves pública y privada: ssk -keygen -t rsa y para copiar la clave desde el cliente al servidor: ssh usuario@maquina_remota "cat >> .ssh/authorized_keys" < .ssh/id_rsa.pub la primera vez te pide contraseña (porque aun no esta copiada la clave) y las demas no. Salut. Beto
Miquel A. Noguera escribió:
El Sábado, 8 de Enero de 2005 00:01, Carlos E. R. escribió:
Quiero desde un script corrriendo en la máquina A (como root) hacer que se lance, automáticamente, otro script en otra maquina conectada por red local casera, también como root.
Yo lo hago así:
ssh usuario@máquina_remota script
Para evitar teclear la contraseña, copio el fichero $HOME/.ssh/id_rsa.pub del usuario en la "máquina_local" en el home de "usuario@máquina_remota" y, finalmente, en "máquina_remota":
cat id_rsa.pub >> $HOME/.ssh/authorized_keys
Saludos. Miquel.
Por otro lado, si lo que quieres es ejecutar un comando que existe en la maquina remota, has de introducirlo entre comillas: ssh usuario@máquina_remota "script" /**********************************************************************/ PERDON, ME HABIA EQUIVOCADO EN EL COMANDO, NO ERA SSK, SINO SSH, EVIDENTEMENTE. HACE UN POCO DE FRIO Y EL DEDO ÍNDICE NO QUIERE TRABAJAR DEMASIADO... Por si alguien no sabe como se crean las claves pública y privada: ssh -keygen -t rsa /**********************************************************************/ y para copiar la clave desde el cliente al servidor: ssh usuario@maquina_remota "cat >> .ssh/authorized_keys" < .ssh/id_rsa.pub la primera vez te pide contraseña (porque aun no esta copiada la clave) y las demas no. Salut. Beto
El Sábado, 8 de Enero de 2005 10:52, J M Betoret escribió:
Por otro lado, si lo que quieres es ejecutar un comando que existe en la maquina remota, has de introducirlo entre comillas:
ssh usuario@máquina_remota "script"
Yo no noto ninguna diferencia poniendo las comillas o no. Por otro lado, la única "pega" es que tengo que poner la ruta completa del script. Aunque no es nada grave, ya por simple curiosidad, ignoro si hay alguna manera de emplear el $PATH del sistema remoto o si está desactivado por alguna razón de seguridad. Miquel.
Miquel A. Noguera escribió:
El Sábado, 8 de Enero de 2005 10:52, J M Betoret escribió:
Por otro lado, si lo que quieres es ejecutar un comando que existe en la maquina remota, has de introducirlo entre comillas:
ssh usuario@máquina_remota "script"
Yo no noto ninguna diferencia poniendo las comillas o no.
Por otro lado, la única "pega" es que tengo que poner la ruta completa del script.
Aunque no es nada grave, ya por simple curiosidad, ignoro si hay alguna manera de emplear el $PATH del sistema remoto o si está desactivado por alguna razón de seguridad.
Miquel.
OK. Aceptamos barco como animal de compañía. Me equivoqué... La única diferencia que veo yo es que al usar comillas puedes utilizar espacios, por ejemplo: ssh usuario@máquina_remota ". /etc/profile.local ; if [ 1 ] then script1 ; else script2" (no sé si he puesto bien los \; del if, pero la idea seria esa) por eso, un caso en el que sí es necesario el uso de comillas es para copiar el id_rsa.pub como he indicado antes: ssh usuario@maquina_remota "cat >> .ssh/authorized_keys" < .ssh/id_rsa.pub
El 2005-01-08 a las 10:36 +0100, Miquel A. Noguera escribió:
Yo lo hago así:
ssh usuario@máquina_remota script
Para evitar teclear la contraseña, copio el fichero $HOME/.ssh/id_rsa.pub del usuario en la "máquina_local" en el home de "usuario@máquina_remota" y, finalmente, en "máquina_remota":
cat id_rsa.pub >> $HOME/.ssh/authorized_keys
Esa parte no me va, no funciona: me pide siempre el password. El cliente es 9.1 y el servidor un suse 7.3. En cambio, del cliente al "cliente" (o sea, dentro del 9.1), si funciona, aunque entonces me pide la "passphrase" en vez del password: Enter passphrase for key '/home/cer/.ssh/id_dsa': Supongo que eso es porque en su dia la generé con frase clave. Puedo generar otra llave sin ella, pero el problema con el servidor 7.3 seguirá existiendo. Al revés, desde el 7.3 al 9.1 me pasa lo mismo, me pide la "password", ignora la llave dsa. ¿Habrá que hacerlo con rsa? -- Saludos Carlos Robinson
¿Y por que no usas ssh-agent? El Sábado, 8 de Enero de 2005 17:57, Carlos E. R. escribió:
El 2005-01-08 a las 10:36 +0100, Miquel A. Noguera escribió:
Yo lo hago así:
ssh usuario@máquina_remota script
Para evitar teclear la contraseña, copio el fichero $HOME/.ssh/id_rsa.pub del usuario en la "máquina_local" en el home de "usuario@máquina_remota" y, finalmente, en "máquina_remota":
cat id_rsa.pub >> $HOME/.ssh/authorized_keys
Esa parte no me va, no funciona: me pide siempre el password. El cliente es 9.1 y el servidor un suse 7.3.
En cambio, del cliente al "cliente" (o sea, dentro del 9.1), si funciona, aunque entonces me pide la "passphrase" en vez del password:
Enter passphrase for key '/home/cer/.ssh/id_dsa':
Supongo que eso es porque en su dia la generé con frase clave. Puedo generar otra llave sin ella, pero el problema con el servidor 7.3 seguirá existiendo.
Al revés, desde el 7.3 al 9.1 me pasa lo mismo, me pide la "password", ignora la llave dsa.
¿Habrá que hacerlo con rsa?
-- Saludos Carlos Robinson
El 2005-01-11 a las 08:31 +0100, chakal escribió:
¿Y por que no usas ssh-agent?
Sigues teniendo que dar la clave al menos una vez; y recuerda que se trata de un script, no hay consola para preguntarla. Estoy viendo que mi sistema del mail es el más práctico después de todo. -- Saludos Carlos Robinson
El Martes, 11 de Enero de 2005 14:26, Carlos E. R. escribió:
¿Y por que no usas ssh-agent?
Sigues teniendo que dar la clave al menos una vez; y recuerda que se trata de un script, no hay consola para preguntarla.
Estoy viendo que mi sistema del mail es el más práctico después de todo.
* Pues no he seguido el hilo, asi que no se que quieres hacer, pero lo del correo seguro que no es la mejor idea ni mucho menos, supongamos que quieres ejecutar una serie de comandos de administracion en un pool de servidores de forma remota. * En /etc/ssh/sshd_config RSAAuthentication yes PubkeyAuthentication yes y cuales son los ficheros de autorizacion (suele venir habilitado por defecto) * Ejemplo para pares de claves rsa del tipo host ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Created directory '/root/.ssh'. Enter passphrase (empty for no passphrase): (intro sin contraseña si no te la pedira) Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: x1:7[.....................]:v0:c0 Distribuye la clave pública (/root/.ssh/id_rsa.pub) al fichero /root/.ssh/authorized_keys de cada maquina scp /root/.ssh/id_rsa.pub root@maquina:~/.ssh/authorized_keys con ssh maquina te podras autentificar o ejecutar un comando ssh maquina "shutdown -h 10 Guarden sus trabajos y a cascársela, \ que ya es muy tarde " * No obstante hay un quilo de opciones, sin cifrado expect, mira el script autoexpect que viene en el paquete, nc o netcat, fsh, etc
El 2005-01-11 a las 20:43 +0100, jose maria escribió:
Estoy viendo que mi sistema del mail es el más práctico después de todo.
* Pues no he seguido el hilo, asi que no se que quieres hacer, pero lo del correo seguro que no es la mejor idea ni mucho menos,
Pues deberías leer el hilo para ver las especificaciones del problema, y saber porqué digo lo del correo, que ya lo tengo casi hecho.
supongamos que quieres ejecutar una serie de comandos de administracion en un pool de servidores de forma remota.
No, no quiero ejecutar ningún comando. Quiero que el script ip-up de una máquina haga que se ejecute en otra máquina (conectada por red local segura) su script ip-up, de manera automática inatendida (o sea, sin abrir ninguna sesión).
o ejecutar un comando
ssh maquina "shutdown -h 10 Guarden sus trabajos y a cascársela, \ que ya es muy tarde "
Como ya dije en otro correo de este hilo, el ssh entre las dos máquinas en cuestion pide la password, y no la frase clave correspondiente a la llave dsa instalada, luego no me vale. Revisa el hilo para ver los detalles que dije de como no funciona, a ver si das con el porqué. -- Saludos Carlos Robinson
En/na Carlos E. R. ha escrit:
El 2005-01-11 a las 20:43 +0100, jose maria escribió:
Estoy viendo que mi sistema del mail es el más práctico después de todo.
* Pues no he seguido el hilo, asi que no se que quieres hacer, pero lo del correo seguro que no es la mejor idea ni mucho menos,
Pues deberías leer el hilo para ver las especificaciones del problema, y saber porqué digo lo del correo, que ya lo tengo casi hecho.
supongamos que quieres ejecutar una serie de comandos de administracion en un pool de servidores de forma remota.
No, no quiero ejecutar ningún comando. Quiero que el script ip-up de una máquina haga que se ejecute en otra máquina (conectada por red local segura) su script ip-up, de manera automática inatendida (o sea, sin abrir ninguna sesión).
suponiendo que quieres lanzar un comando en la otra máquina cuando cambia la ip del ADSL... El script en cuestión tendría más o menos la siguiente forma: MI_IP=$(ip a | grep ppp0 | tail -1 | sed "s/ */ /g" | cut -f3 -d" ") if [ $MI_IP -ne $ANTIGUA_IP ] then ssh maquina "script_remoto" fi No sé lo que querías hacer, pero seguro que hay un script para ello..... (Siempre lo hay...) Saludos, Beto
o ejecutar un comando
ssh maquina "shutdown -h 10 Guarden sus trabajos y a cascársela, \ que ya es muy tarde "
Como ya dije en otro correo de este hilo, el ssh entre las dos máquinas en cuestion pide la password, y no la frase clave correspondiente a la llave dsa instalada, luego no me vale.
Revisa el hilo para ver los detalles que dije de como no funciona, a ver si das con el porqué.
El 2005-01-12 a las 13:21 +0100, J M Betoret escribió:
El script en cuestión tendría más o menos la siguiente forma:
MI_IP=$(ip a | grep ppp0 | tail -1 | sed "s/ */ /g" | cut -f3 -d" ")
if [ $MI_IP -ne $ANTIGUA_IP ] then ssh maquina "script_remoto" fi
Todo eso está muy bien, no tengo ningún problema en hacer el script - es más, existe y es mucho más fácil que todo ese follón con el grep. El único problema es que el ssh PIDE la password, y por tanto NO funciona en un script. Eso ya lo dije hace dias, y lo volví a decir ayer. ¿Es que no lo leeis? :-/ -- Saludos Carlos Robinson
¿Cuál fue el procedimiento detallado que seguiste para crear tus claves? Ahora que recuerdo yo he hecho un script que se ejecutaba remotamente por ssh, sólo configuré las llaves pública y privada y se conectaba sin pedir password ni frase secreta. On Wed, 12 Jan 2005 18:44:31 +0100 (CET), Carlos E. R. <robin1.listas@tiscali.es> wrote:
Todo eso está muy bien, no tengo ningún problema en hacer el script - es más, existe y es mucho más fácil que todo ese follón con el grep. El único problema es que el ssh PIDE la password, y por tanto NO funciona en un script.
-- Saludos Oscar
El 2005-01-12 a las 17:47 -0500, Oscar Gosdinski escribió:
¿Cuál fue el procedimiento detallado que seguiste para crear tus claves?
En el 7.3: ssh-keygen -t dsa -C "cer@telperion.valinor" En el 9.1, copypaste del ~/.ssh/id_dsa.pub del cliente (7.3) al final del fichero ~/.ssh/authorized_keys Ese procedimiento hecho en el 9.1 funciona. Y acabo de probarlo con llave rsa (en vez de dsa) y tampoco funciona. -- Saludos Carlos Robinson
*This message was transferred with a trial version of CommuniGate(tm) Pro* On Wed, 12 Jan 2005 00:47:36 +0100 (CET) "Carlos E. R." <robin1.listas@tiscali.es> wrote:
No, no quiero ejecutar ningún comando. Quiero que el script ip-up de >una máquina haga que se ejecute en otra máquina (conectada por red local segura) su script ip-up, de manera automática inatendida (o sea, >sin abrir ninguna sesión).
* Osea ejecutar un comando en una maquina remota, en ip-up una linea que llame al script de ssh en cuestion, mejor que el script tenga un sleep antes de nada o que compruebe que la conexion esta util.
Como ya dije en otro correo de este hilo, el ssh entre las dos má quinas en cuestion pide la password, y no la frase clave correspondiente a la llave dsa instalada, luego no me vale.
Revisa el hilo para ver los detalles que dije de como no funciona, a ver si das con el porqué.
* Evidentemente o el par de claves ha sido creado con contraseña, o en el servidor /etc/ssh/sshd_config no esta habilitada la conexion por claves, o no permites empty password, o no las has copiado en su sitio correcto, o en /etc/ssh/sshd_config no esta la ruta correcta a autorized_keys.
El 2005-01-12 a las 20:23 +0100, jose maria escribió:
No, no quiero ejecutar ningún comando. Quiero que el script ip-up de una máquina haga que se ejecute en otra máquina (conectada por red local segura) su script ip-up, de manera automática inatendida (o sea, sin abrir ninguna sesión).
* Osea ejecutar un comando en una maquina remota, en ip-up una linea que llame al script de ssh en cuestion, mejor que el script tenga un sleep antes de nada o que compruebe que la conexion esta util.
Correcto. Aunque el sleep no es necesario porque el ip-up ya lo incluye "de serie", y en ese punto ya he lanzado otras cosillas antes.
Como ya dije en otro correo de este hilo, el ssh entre las dos má quinas en cuestion pide la password, y no la frase clave correspondiente a la llave dsa instalada, luego no me vale.
Revisa el hilo para ver los detalles que dije de como no funciona, a ver si das con el porqué.
* Evidentemente o el par de claves ha sido creado con contraseña,
Si, eso es cierto, pero puedo crear otro sin "frase clave" sin problemas. Pero no pide la frase clave, sino que pide la password de usuario (que es distinta). O sea, no llega a usar autentificación por par de llaves.
o en el servidor /etc/ssh/sshd_config no esta habilitada la conexion por claves, o no permites empty password, o no las has copiado en su sitio correcto, o en /etc/ssh/sshd_config no esta la ruta correcta a autorized_keys.
Verás. Hago una tabla. cliente servidor ¿funciona? 9.1 9.1 si 9.1 sourceforge si 7.3 9.1 no 9.1 7.3 no 7.3 7.3 no O sea, en todos los casos en que interviene el 7.3, me pide la password de usuario. Y no puedo cambiar de versión, que ya me gustaría, porque es un pentium 133 con 32 megas de ram y no traga más el pobre. Luego compruebo los sitios que me dices que mire. Pero no he podido localizar nada en el log, creo que aumentaré el nivel de registro. [...] Con verbose, nada: Jan 12 21:07:05 nimrodel sshd[4326]: Received signal 15; terminating. Jan 12 21:07:05 nimrodel sshd[11112]: Server listening on 0.0.0.0 port 22. Jan 12 21:07:05 nimrodel sshd[11112]: socket: Address family not supported by protocol Jan 12 21:07:05 nimrodel sshd[11112]: Generating 768 bit RSA key. Jan 12 21:07:05 nimrodel sshd[11112]: RSA key generation complete. 07:05 nimrodel sshd[11112]: RSA key generation complete. Jan 12 21:07:14 nimrodel sshd[11116]: Connection from 192.168.100.1 port 1032 Jan 12 21:07:14 nimrodel sshd[11116]: Failed none for cer from 192.168.100.1 port 1032 Jan 12 21:07:17 nimrodel sshd[11116]: Failed password for cer from 192.168.100.1 port 1032 Jan 12 21:07:22 nimrodel sshd[11116]: Accepted password for cer from 192.168.100.1 port 1032 Vale, pues aumento a debug: Jan 12 21:09:16 nimrodel sshd[11112]: Received signal 15; terminating. Jan 12 21:09:16 nimrodel sshd[11165]: debug1: Bind to port 22 on 0.0.0.0. Jan 12 21:09:16 nimrodel sshd[11165]: Server listening on 0.0.0.0 port 22. Jan 12 21:09:16 nimrodel sshd[11165]: socket: Address family not supported by protocol (se refiere a ipv6, creo) Jan 12 21:09:16 nimrodel sshd[11165]: Generating 768 bit RSA key. Jan 12 21:09:16 nimrodel sshd[11165]: RSA key generation complete. Jan 12 21:09:26 nimrodel sshd[11118]: Closing connection to 192.168.100.1 Jan 12 21:09:34 nimrodel sshd[11169]: Connection from 192.168.100.1 port 1033 Jan 12 21:09:34 nimrodel sshd[11165]: debug1: Forked child 11169. Jan 12 21:09:34 nimrodel sshd[11169]: debug1: Client protocol version 1.5; client software version OpenSSH_2.9p2 Jan 12 21:09:34 nimrodel sshd[11169]: debug1: match: OpenSSH_2.9p2 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1* Jan 12 21:09:34 nimrodel sshd[11169]: debug1: Local version string SSH-1.99-OpenSSH_3.8p1 Jan 12 21:09:34 nimrodel sshd[11169]: debug1: PAM: initializing for "cer" Jan 12 21:09:34 nimrodel sshd[11169]: debug1: PAM: setting PAM_RHOST to "telperion.valinor" Jan 12 21:09:34 nimrodel sshd[11169]: debug1: PAM: setting PAM_TTY to "ssh" Jan 12 21:09:34 nimrodel sshd[11169]: Failed none for cer from 192.168.100.1 port 1033 ¿Será este failed? Jan 12 21:09:40 nimrodel sshd[11169]: Accepted password for cer from 192.168.100.1 port 1033 Jan 12 21:09:40 nimrodel sshd[11169]: debug1: monitor_child_preauth: cer has been authenticated by privileged process Jan 12 21:09:40 nimrodel sshd[11171]: debug1: PAM: reinitializing credentials Jan 12 21:09:40 nimrodel sshd[11171]: debug1: permanently_set_uid: 500/100 Jan 12 21:09:40 nimrodel sshd[11171]: debug1: session_new: init Jan 12 21:09:40 nimrodel sshd[11171]: debug1: session_new: session 0 Jan 12 21:09:40 nimrodel sshd[11171]: debug1: Installing crc compensation attack detector. Jan 12 21:09:40 nimrodel sshd[11171]: debug1: Allocating pty. Jan 12 21:09:40 nimrodel sshd[11169]: debug1: session_new: init Jan 12 21:09:40 nimrodel sshd[11169]: debug1: session_new: session 0 Jan 12 21:09:40 nimrodel sshd[11171]: debug1: session_pty_req: session 0 alloc /dev/pts/18 Jan 12 21:09:40 nimrodel sshd[11171]: debug1: PAM: setting PAM_TTY to "/dev/pts/18" Jan 12 21:09:40 nimrodel sshd[11172]: debug1: Setting controlling tty using TIOCSCTTY. Jan 12 21:09:40 nimrodel sshd[11171]: debug1: Entering interactive session. Jan 12 21:09:40 nimrodel sshd[11171]: debug1: server_init_dispatch_13 Jan 12 21:09:40 nimrodel sshd[11171]: debug1: server_init_dispatch_15 ¿Alguna idea? Debe ser algo en el cliente del 7.3, porque del servidor 9.1 a sí mismo si que funciona. o alguna incompatibilidad entre versiones... -- Saludos Carlos Robinson
*This message was transferred with a trial version of CommuniGate(tm) Pro* -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 12 Jan 2005 22:37:26 +0100 (CET) "Carlos E. R." <robin1.listas@tiscali.es> wrote:
Jan 12 21:09:34 nimrodel sshd[11169]: Failed none for cer from >192.168.100.1 port 1033
¿Será este failed?
Jan 12 21:09:40 nimrodel sshd[11169]: Accepted password for cer from 192.168.100.1 port 1033 Jan 12 21:09:40 nimrodel sshd[11169]: debug1: monitor_child_preauth: cer has been authenticated by privileged process Jan 12 21:09:40 nimrodel sshd[11171]: debug1: PAM: reinitializing credentials Jan 12 21:09:40 nimrodel sshd[11171]: debug1: permanently_set_uid: 500/100 Jan 12 21:09:40 nimrodel sshd[11171]: debug1: session_new: init Jan 12 21:09:40 nimrodel sshd[11171]: debug1: session_new: session 0 Jan 12 21:09:40 nimrodel sshd[11171]: debug1: Installing crc compensation attack detector. Jan 12 21:09:40 nimrodel sshd[11171]: debug1: Allocating pty. Jan 12 21:09:40 nimrodel sshd[11169]: debug1: session_new: init Jan 12 21:09:40 nimrodel sshd[11169]: debug1: session_new: session 0 Jan 12 21:09:40 nimrodel sshd[11171]: debug1: session_pty_req: session 0 alloc /dev/pts/18 Jan 12 21:09:40 nimrodel sshd[11171]: debug1: PAM: setting PAM_TTY to "/dev/pts/18" Jan 12 21:09:40 nimrodel sshd[11172]: debug1: Setting controlling tty using TIOCSCTTY. Jan 12 21:09:40 nimrodel sshd[11171]: debug1: Entering interactive session. Jan 12 21:09:40 nimrodel sshd[11171]: debug1: server_init_dispatch_13 Jan 12 21:09:40 nimrodel sshd[11171]: debug1: server_init_dispatch_15
¿Alguna idea? Debe ser algo en el cliente del 7.3, porque del servidor 9.1 a sí mismo si que funciona. o alguna incompatibilidad entre versiones...
* Pentium 133 con 32 Mb, permite versiones de SuSE muy superiores, por lo menos con 8.2 los tengo, simplemente asegurate de terner una particion de swap antes de la instalacion, te pedira activarla y ya esta. * Yo empezaria en el 7.3, por habilitar en el cliente solamente el Protocol 2 , tanto en sshd_config como en ssh_config, despues si sigue sin funcionar, revisa /etc/pam.d/sshd que dependiendo de lo que uses, estara de una manera y otra. auth required pam_stack.so service=system-auth auth required pam_nologin.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_selinux.so session required pam_stack.so service=system-auth session required pam_limits.so session optional pam_console.so -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB5qWFAXFL65CppEIRAjDUAJ4x3kpftDNPjwHDbZpZhKchnCJHdQCfX2mv tqWQaDpswTpT/7vwlRa2iP0= =kiad -----END PGP SIGNATURE-----
El 2005-01-13 a las 17:44 +0100, jose maria escribió:
¿Alguna idea? Debe ser algo en el cliente del 7.3, porque del servidor 9.1 a sí mismo si que funciona. o alguna incompatibilidad entre versiones...
* Pentium 133 con 32 Mb, permite versiones de SuSE muy superiores, por lo menos con 8.2 los tengo, simplemente asegurate de terner una particion de swap antes de la instalacion, te pedira activarla y ya esta.
Mmmm... cuando actualicé de 7.1 a 7.3 creo que me tardó un dia entero (y había swap). Y tuve que luchar para instalarlo, porque el instalador no quería arrancar, exigía memoria, me suena 42. Ya en uso, en modo texto es aceptable, pero en modo gráfico es muy lento, el kde es casi inutil, el gnome pse, tengo que usar fwmn o similar.
* Yo empezaria en el 7.3, por habilitar en el cliente solamente el Protocol 2 , tanto en sshd_config como en ssh_config, despues si sigue sin funcionar, revisa /etc/pam.d/sshd que dependiendo de lo que uses, estara de una manera y otra.
He estado probando en el cliente con "ssh -v -v -v servidor", y he dado con el quid de la cuestión: hace falta añadirle un "-2" para forzar la versión 2. Después de eso, lo he añadido en el fichero .ssh/config, que ahora está así (no existía): host nimrodel.valinor IdentityFile /home/cer/.ssh/id_dsa Protocol 2 y ya entra automáticamente desde el ssh del suse 7.3. Curioso. Y ya sé porqué ocurre así: porque el sshd del 9.1 no acepta conexiones entrantes versión uno; es el mismo problema que les pasaba a la gente de windows con el putty, y que se ha comentado en las listas muchas veces. No es por tanto realmente un problema con el 7.3. -- Saludos Carlos Robinson
El Viernes, 14 de Enero de 2005 22:29, Carlos E. R. escribió:
Mmmm... cuando actualicé de 7.1 a 7.3 creo que me tardó un dia entero (y había swap). Y tuve que luchar para instalarlo, porque el instalador no quería arrancar, exigía memoria, me suena 42. Ya en uso, en modo texto es aceptable, pero en modo gráfico es muy lento, el kde es casi inutil, el gnome pse, tengo que usar fwmn o similar.
* hombre kde aunque sea el 2, es complicarse la vida lo mismo con gnome, funcionara aceptablemente, con icewm y mejor con tinywm, sylpheed para correo y news y abyword para los textos, pero lo prudente seria PXES o lo siguiente, ya puestos que sirva para quien lo necesite y especialmente a quienes yo me se, que no se hagan los suecos el proximo dia, añado terminal server ltsp, al asunto: * La configuracion en SLES y SLSS es en la practica igual. * En el 9.2 suponiendo un rango 192.168.0.0/24 siendo w.x.y.1 el servidor 9.2 * Con yast instalar servidores dhcpd , nfs, portmap y tftp * bajar las utilidades y el paquete para sonido, vlc serviria como servidor de streaming de video. http://www.ltsp.org/ltsp-utils-0.10-0.noarch.rpm http://www.ltsp.org/ltsp-4.1/ltsp-sound-1.0-0.1.noarch.rpm rpm -ivh ltsp*.rpm * Esto instala las herramientas, ltspcfg, ltspadmin y ltspinfo y el asunto del sonido ejecutar como root ltspadmin , ----------ltspadmin-------------------------------------- ltspadmin - v0.12 LTSP dir: /home/root/ltsp LTSP Administration Utility Install/Update LTSP Packages Configure the installer options Configure LTSP Quit the administration program ------------------------FIN----------------------------------- * Seleccionar Configure the installer options * en la interfaz de texto, primero configurar la conexion, proxy si lo hay y donde queremos que se nos instale ltsp nos invita a instalarlo en /proc/ltsp/ cuestion de gustos, por ejemplo en /home/root/ para este ejemplo, seleccionar Install/update y marcar todos los paquetes, iniciar la descarga de los paquetes, se los bajara y los instalara en el sitio indicado. --------- /etc/dhcp.conf ------------------------ option subnet-mask 255.255.255.0; option broadcast-address 192.168.0.255; option root-path "192.168.0.1:/home/root/ltsp/i386"; option option-128 code 128 = string; option option-129 code 129 = text; option domain-name "tucasa"; option domain-name-servers 192.168.0.1; option routers 192.168.0.1; # # Sample configuration file for ISC dhcpd # # Make changes to this file and copy it to /etc/dhcpd.conf # ddns-update-style none; max-lease-time 21600; default-lease-time 21600; subnet 192.168.0.0 netmask 255.255.255.0 { option log-servers 192.168.0.1; use-host-decl-names on; default-lease-time 14400; max-lease-time 172800; # ejemplo usando PXE para el arranque host pc21 { hardware ethernet 00:0A:5E:4D:8B:92; #mac de la tarjeta fixed-address 192.168.0.21; filename "/lts/2.4.26-ltsp-2/pxelinux.0"; } # ejemplo usando una rom en disquete host pc22 { hardware ethernet 00:E0:29:73:1A:81; #hacer el cambio oportuno fixed-address 192.168.0.22; filename "/lts/vmlinuz-2.4.26-ltsp-2"; # supongamos que se necesitan opciones para algunas # tarjetas de red, aqui seria el lugar, tirar de lspci si se tiene un linux # ya instalado, es conveniente usar alguna ejecutable desde cdrom, o instalar # alguna distribucion con lo fundamental, configurarlo , cuando OK copiarse # las configuraciones de tarjetas, video, modulos, etc y apuntarselas, puede # ahorrarnos, andar con la prueba y error hasta dar con las opciones correctas # del hardware de los clientes. option option-128 code 128 = a3:f2:etc.etc ; option option-129 code 129 = NE=ne; } range 192.168.0.20 192.168.0.25; # si se quiere limitar el rango de asignacion # nota: Si se tiene un dns y ltsp tampoco es el gateway, ajustense la opciones # de este fichero. } -------------- FIN ------------------- ------------- /etc/hosts ----------------- # añadir los terminales 192.168.0.21 pc21.tucasa pc21 etc.... etc..... lopispo ------------------------------- FIN -------------------------- ---------------------- /etc/exports ----------------- /home 192.168.0.0/24(rw,no_root_squash,sync) /bin 192.168.0.0/24(rw,no_root_squash,sync) /dev 192.168.0.0/24(rw,no_root_squash,sync) /etc 192.168.0.0/24(rw,no_root_squash,sync) /lib 192.168.0.0/24(rw,no_root_squash,sync) /opt 192.168.0.0/24(rw,no_root_squash,sync) /root 192.168.0.0/24(rw,no_root_squash,sync) /sbin 192.168.0.0/24(rw,no_root_squash,sync) /usr 192.168.0.0/24(rw,no_root_squash,sync) /var 192.168.0.0/24(rw,no_root_squash,sync) /media/wilson *(ro,root_squash,sync) # por si se quiere acceder a alguna particion de wilson, montada evidentemente /tftpboot 192.168.0.0/255.255.255.0(ro,no_root_squash,sync) /home/root/ltsp 192.168.0.0/255.255.255.0(ro,no_root_squash,sync) /var/opt/ltsp/swapfiles 192.168.0.0/255.255.255.0(rw,no_root_squash,async) ------------------------ FIN ------------------------ * Queda a tu eleccion la exportacion con unos u otros permisos ---------------- /home/root/ltsp/etc/lts.conf --------------------- Aqui simplemente configurar especificaciones para el video, uso de las unidades locales de los clientes, hay un demonio profile que que se ejecuta en el cliente al que el servidor interrogara para ver opciones del cliente etc... , un poco de lectura. # la seccion General , tres modos de video por ejemplo, practicamente no hay # que tocar el generado por ltsp. LTSP_BASEDIR=/opt/ltsp # el directorio de montaje nfs en los clientes [Default] SERVER = 192.168.0.1 XSERVER = auto X_MOUSE_PROTOCOL = "PS/2" X_MODE_0 = 640x480 31.5 640 664 704 832 480 489 492 520 +hsync +vsync X_MODE_1 = 800x600 40 800 840 968 1056 600 601 605 628 +hsync +vsync X_MODE_2 = 1024x768 44.9 1024 1048 1208 1264 768 776 784 817 interlace X_MOUSE_PROTOCOL = "PS/2" X_MOUSE_DEVICE = "/dev/psaux" X_MOUSE_RESOLUTION = 400 X_MOUSE_BUTTONS = 3 # Si se quiere usar un servidor de fuentes, ha de estar a la escucha, no es # necesario en la mayoria de los casos, en mi caso si y lo quiero asi por # razones que no vienen a cuento N, la otra opcion, si se usa hay que # especificar un parametro mas, ver /home/root/ltsp/i386/etc/lts.conf.readme # para esta y otras opciones de interes o necesarias, por ejemplo el uso de # DRI. USE_XFS = N # Se pueden correr aplicaciones locales LOCAL_APPS = Y RUNLEVEL = 5 SCREEN_01 = startx # Como los clientes sin disco seran variopintos, una seccion para ellos. [pc21] XSERVER = auto X_COLOR_DEPTH = 16 X_MODE_0 = 800x600 LOCAL_APPS = Y USE_NFS_SWAP = Y SWAPFILE_SIZE = 64m RUNLEVEL = 5 # Si runlevel 3 , arrancara en consola, esta opcion esta obsoleta, usense las # lineas comentadas posteriores, aunque con runlevel tambien funciona, si se # quieren ejecutar aplicaciones locales corranse via ssh generando claves # para los clientes, si no se da con la tecla preguntar, basicamente habria # tambien que copiar un monton de bibliotecas en el # arbol /home/root/ltsp ........ # SCREEN_01 = startx # SCREEN_02 = telnet # etc... # Usar el hardware local, cdroms y floppys ide y usb, el asunto es que el # cliente tonto se convierte en servidor y entrega su hardware al servidor # principal, este lo pone a disposicion del cliente/s de nuevo via samba, # no emocionarse, que yo sepa, creo que NO se puedan grabar cedeses en una # grabadora del cliente sin disco "todavia", esto chupa recursos de memoria # del cliente, generalmente un cutre-pc casi sin memoria, asi que sed # generosos en estos casos de uso de hardware local en los clientes, con los # swapfiles de la configuracion anterior. LOCAL_DEVICE_01 = /dev/hdc:cdrom LOCAL_DEVICE_02 = /dev/fd0:floppy # Para dispositivos usb locales # MODULE_01 = usbcore # MODULE_02 = usb-uhci # MODULE_03 = usb-storage # LOCAL_DEVICE_01 = /dev/sr0:cdrom # LOCAL_DEVICE_02 = /dev/sda1:floppy --------------------------FIN ---------------------- # estas unidades estaran disponibles via samba mas supermount # habilitar en /etc/sysconfig/autofs # AUTOFS_OPTIONS="--timeout 60" --------------/etc/auto.misc ------------ pc21cd -fstype=smbfs,workgroup=TUCASA,guest ://pc21/cdrom \ pc21fd \ -fstype=smbfs,workgroup=TUCASA,fmask=666,dmask=777,guest,username=nobody,rw ://pc21/floppy ------------------FIN----------------------- * configuramos tcp_wrappers --------- /etc/hosts.allow -------------- bootpd: 0.0.0.0 in.tftpd: 192.168.0. portmap: 192.168.0. # con lo anterior deberia ser suficiente si observais problemas en los # montajes, uso de NIS, etc, habilitad lo necesario. # mountd: 192.168.0. # statd: 192.168.0. # rpc.mountd: 192.168.0. # rpc.ugidd: 192.168.0. ---------------------------FIN ----------------------------- * insertamos en el arranque, dhcp, nfs, portmap, xdm, insserv -d dhcpd insserv -d nfsserver insserv -d portmap insserv -d xdm * con yast ponemos en marcha el servidor tftp, la raiz del servidor sera /tftpboot , o bien editamos /etc/xinetd.d/tftp y lo habilitamos, SIEMPRE con la opcion -s . --------------------/etc/xinet.d/tftp ------------------ service tftp { socket_type = dgram protocol = udp wait = yes user = root server = /usr/sbin/in.tftpd server_args = -s /tftpboot disable = no } ------------------FIN---------------------------- * Insertamos a xinetd en el arranque insserv -d xinetd * arrancamos los servidores, los que no tengan rc... , con /etc/init.d/fichero-servidor start rcdhcpd start rcportmap start rcnfsserver start rcxinetd start rcxdm start * Ejecutar ltscfg, todos los servicios deberian estar utilies, con esta herramienta se podrian configurar la mayoria de las cosas e iniciarlas, otras fallarian, por eso lo mejor es meterle mano a los ficheros de texto y despues con ltscfg comprobar que todo esta en orden. -------------------------- ltscfg ------------------------ ltspcfg v0.10 The Linux Terminal Server Project (http://www.LTSP.org) S - Show the status of all services C - Configure the services manually Q - Quit Make a selection: ------------------------------------------------- * pulsar S y ver como esta la jugada si no con C intentar configurarlo, o mejor editar los ficheros en cuestion a mano y revisarlos, recordad que casi todos los servidores tienen un /etc/sysconfig/servidor para darle alguna opcion de vuestro interes, pero nada fuera de lo comun lo que hay por defecto vale. * El cortafuegos del servidor debe permitir al menos conexiones a los siguientes puertos: portmap UDP 111 portmap TCP 111 rpc.mount UDP 896 rpc.mount TCP 899 xinetd UDP 69 <---tftp dhcpd UDP 67 * Con esto el servidor estaria configurado, una vez tratado el asunto de los clientes, si surge algun problema lsof -i -n -P os dira el estado de los puertos, iptraf para depurar las conexiones y ajustar el cortafuegos. * y ahora los clientes, los clientes se pueden arrancar de varias formas, via PXE soportado en la bios, no es habitual en hardware antiguo, por tanto no suele ser una opcion. * via el proyecto PXES que simula este metodo y otros descritos a continuacion utilizandolo desde diskete o cd esto puede trabajar contra casi todos los protocolos, microsoft TS, VPN, RFB, XDMCP es una opcion muy interesante en linux no se necesita NFS , etc..., * via una tarjeta de red con su rom se venden con esta rom ya cargada a precios ridiculos, el problema en este caso es que si la bios no soporta este tipo de arranque hay que utilizar un diskete para habilitar esta caracteristica de la tarjeta, via disco duro lease utilizar grub o lilo para arrancar por red y finalmente la opcion mas comun en hardware de deshecho, un disquete que incluya la rom de nuestra tarjeta y haga el pre-arranque. * El proyecto PXES , basicamente es una minidistribucion para crear el arranque de los clientes, con varias formulas. http://pxes.sourceforge.net http://kent.dl.sourceforge.net/sourceforge/pxes/pxes-0.9-1PB.iso * Lo mas comun es crearse una rom con el paquete etherboot, disponible en SuSE o crearla en rom-o-matic.net, la base de datos de tarjetas soportadas http://www.etherboot.org/db/ , hay un formulario web para generar la rom con vuestras opciones, al final da la opcion de bajarla y con dd if=fichero.xxx of=/dev/fd0 la colocais en un disquete. * para los vagos, otra opcion es usar el universal boot floppy , preparado para una gran cantidad de tarjetas comunes. http://heanet.dl.sourceforge.net/sourceforge/thinstation/BootDisk522b.zip unzip y con dd al disquete. * Es importante una buena gestion de grupos y ususarios si se va a usar en un cibercafe, empresas con muchos clientes sin disco, etc, configurar bien xdmcp , la gestion de los inicios, los ficheros kdmrc, etc, usar kiosk es lo mas recomendable para gestionar a que utilidades pueden acceder los clientes y que configuraciones pueden cambiar. * Puede haber problemas con algunas tarjetas, por ejemplo algunas realtek de 10MB, estas tienen un buffer ridiculo y el tamaño del paquete ip de NFS puede ser el doble, el protocolo se ve obligado a fragmentarlo, el cliente queda a la espera con el primer trozo, envia el ACK y no puede reconstruir los paquetes con los siguientes fragmentos, tambien suele pasar en las Digital-equipament DC22142/43 , esto la solucion mas facil es comprar tarjetas mas decentes rtl8139 o 3com estan tiradas y buscar a algun enemigo cercano que quiera poner ltsp y regalarsealas, tratar de generar paquetes de menor tamaño no deberiais ni plantearoslo.
El 2005-01-15 a las 19:14 +0100, jose maria escribió:
El Viernes, 14 de Enero de 2005 22:29, Carlos E. R. escribió:
Mmmm... cuando actualicé de 7.1 a 7.3 creo que me tardó un dia entero (y había swap). Y tuve que luchar para instalarlo, porque el instalador no quería arrancar, exigía memoria, me suena 42. Ya en uso, en modo texto es aceptable, pero en modo gráfico es muy lento, el kde es casi inutil, el gnome pse, tengo que usar fwmn o similar.
* hombre kde aunque sea el 2, es complicarse la vida lo mismo con gnome, funcionara aceptablemente, con icewm y mejor con tinywm, sylpheed para correo y news y abyword para los textos,
Para el correo, Pine me va muy bien: tengo la misma versión que en la 9.1 compilada por mi. Vive en runlevel 3. Cuando necesito ver gráficos, pues balsa, o Netscape 4.7, pues el mozilla tarda como un cuarto de hora en arrancar, y minutos para cada menu. Para textos, el star office, si realmente me hace falta: tarda en arrancar, pero a partir de ahí es usable. El abiword me gusta, pero en el 7.3 estaba verde.
pero lo prudente seria PXES o lo siguiente, ya puestos que sirva para quien lo necesite y especialmente a quienes yo me se, que no se hagan los suecos el proximo dia, añado terminal server ltsp, al asunto:
* La configuracion en SLES y SLSS es en la practica igual.
* En el 9.2 suponiendo un rango 192.168.0.0/24 siendo w.x.y.1 el servidor 9.2 * Con yast instalar servidores dhcpd , nfs, portmap y tftp * bajar las utilidades y el paquete para sonido, vlc serviria como servidor de streaming de video.
Me acabo de perder. O:-) Se trata de un viejo ordenador, el que tenía antes, un pentium 133 con 32 megas de ram tan sólo, que lo uso para hacer pruebas de red, o en caso de necesidad. Si alguna vez consiguiera ampliarle la memoria (me parece que sólo admite 64) pues iría hasta rapidillo: pero en su dia más ram estaba fuera de mi alcance, y ahora es todavía mucho más cara. Y decía que el SuSE 7.3 me costó lo suyo ponerselo; un 8.x sería una temeridad. Ya me gustaría que SuSE mantuviera actualizada una miniversión para viejas máquinas (porque me gusta el estilo de SuSE, simplemente). Sería muy util para firewalls, routers caseros, pero también para reciclar tanto ordenador de segunda mano que se exporta al "tercer mundo". -- Saludos Carlos Robinson
El Martes, 18 de Enero de 2005 02:05, Carlos E. R. escribió:
* En el 9.2 suponiendo un rango 192.168.0.0/24 siendo w.x.y.1 el servidor 9.2 * Con yast instalar servidores dhcpd , nfs, portmap y tftp * bajar las utilidades y el paquete para sonido, vlc serviria como servidor de streaming de video.
* Pues que si esa maquina, la haces trabajar contra el grande que tendras, pues tendra la potencia del grande y te ahorras un disco, no obstante tambien puedes hacerlo con disco.
El 2005-01-18 a las 17:35 +0100, jose maria escribió:
* Pues que si esa maquina, la haces trabajar contra el grande que tendras, pues tendra la potencia del grande y te ahorras un disco, no obstante tambien puedes hacerlo con disco.
Ah! Ya. Pero no me interesa, la prefiero como máquina independiente. De vez en cuando me llevo mi máquina principal a otra ciudad, y si me vuelvo un par de dias prefiero tener un PC operativo para necesidades. Cosas de no tener un portatil ;-) -- Saludos Carlos Robinson
El Martes, 18 de Enero de 2005 02:05, Carlos E. R. escribió:
Se trata de un viejo ordenador, el que tenía antes, un pentium 133 con 32 megas de ram tan sólo, que lo uso para hacer pruebas de red, o en caso de necesidad. Si alguna vez consiguiera ampliarle la memoria (me parece que sólo admite 64) pues iría hasta rapidillo: pero en su dia más ram estaba fuera de mi alcance, y ahora es todavía mucho más cara.
Tal vez puedas conseguir más memoria EDO o FPM, la que use tu mmx -incluso he tengo uno en el que se puede elegir poner módulos DIMM a elección-, a través de ebay. Yo he conseguido hacerme por dos veces con 128 MB de RAM-EDO a un precio "razonable": por ej., este verano en pcgreen en bcn vendían cada módulo EDO -cuando había- de 32 MB por unos 19 € más el IVA; y las dos veces que he comprado a través de ebay, he conseguido los cuatro módulos de 32 MB (=128 MB) por unos veinte tantos (contando dos envíos de 64 cada uno) y otra vez por 28 € los 128 (incluidos costes de envío). Y están en perfectas condiciones, vamos pasando test de memoria. Una vez a "tope" de memoria, puedes por ejemplo instalar perfectamente el 9.0, que con esa cantidad de memoria lo hace hasta con entorno gráfico. (Creo recordar que en uno tengo instalado el 9.2, y con un disco duro de 80 GB; no tengo el monitor a mano para comprobarlo). Y te puedo asegurar que, evidentemente, le cuesta instalarse y arrancar, pero una vez en el entorno gráfico, si únicamente los vas a utilizar para alguna tarea puntual y esporádica, te puede servir perfectamente. Otra cuestión interesante es deseleccionar algunos paquetes devoradores de recursos -como el OOo- y seleccionar algunos más llevabas -como abiword. Y otra cuestión más interesante todavía -que se la he visto hacer a "jose maria" el de la lista con el KDE, si no recuerdo mal en algún pentium 2, con 64 MB de RAM- es descargar el entorno, entrando en el Centro de Control y quitando todas las funcionalidades superfluas. En otro de los mmx ellos le tengo puesto tres discos duros (de 1, 1.1, y 2.5 GBytes=menos de 5). Y este por ejemplo ha quedado: - hda hda1 /boot hda2 /usr hda3 swap - hdb hdb1 /home hdb2 swap - hdc hdc1 / hdc2 /usr/lib hdc3 swap En el primero que te he comentado -supongo que estas cosas dependerán de la placa base y/o el chipset- me parece que tuve que particionar el disco duro previamente desde otro ordenador, para crearle /boot, /, y swap (el asunto del "cilindro 1024") para que pudiera instalarse. Pero en el último, lo hago directamente con el programa gráfico de instalación. Otra alternativa, si no se dispone de suficiente memoria que exige el YaST, es realizar la instalación manual, y una vez instalado, si lo necesitas para alguna cosa especial, arrancar el entorno gráfico desde la línea de comandos. Saludos.
Porque no le cuelgas un programita tuyo a xinet para que dispare el script??? No seria muy complicado de hacer. Un saludo Lluis El mar, 11-01-2005 a las 14:26 +0100, Carlos E. R. escribió:
El 2005-01-11 a las 08:31 +0100, chakal escribió:
¿Y por que no usas ssh-agent?
Sigues teniendo que dar la clave al menos una vez; y recuerda que se trata de un script, no hay consola para preguntarla.
Estoy viendo que mi sistema del mail es el más práctico después de todo.
-- Saludos Carlos Robinson
El 2005-01-11 a las 21:47 +0100, lmartinez escribió:
Porque no le cuelgas un programita tuyo a xinet para que dispare el script???
Eso sería ideal... si supiera como se hace O:-) -- Saludos Carlos Robinson
En/na Carlos E. R. ha escrit:
El 2005-01-11 a las 21:47 +0100, lmartinez escribió:
Porque no le cuelgas un programita tuyo a xinet para que dispare el script???
Eso sería ideal... si supiera como se hace O:-)
En SuSE, los scripts que se inician al arrancar el sistema están en /etc/init.d/ Para abreviar, si quieres poner alguno nuevo tú, ponlo en /etc/init.d/rc5.d/ Verás que hay algunos que son de la forma: KXXnombre_script (esos son los que se lanzan antes de apagar el PC, "K" viene de "Kill") hay otros que son de la forma "SXXnombre_script" (esos son los que interesan). Para poner un script al inicio del arranque: crea el script y muévelo a ese directorio con el nombre, por ejemplo S50miscript. Se ejecutan por orden, primero S01, después S02.... poner el propio el último sería lo ideal.... Y ya está....
El 2005-01-12 a las 13:15 +0100, J M Betoret escribió:
Porque no le cuelgas un programita tuyo a xinet para que dispare el script???
Eso sería ideal... si supiera como se hace O:-)
En SuSE, los scripts que se inician al arrancar el sistema están en /etc/init.d/
Para abreviar, si quieres poner alguno nuevo tú, ponlo en /etc/init.d/rc5.d/
Ahhyyyy... [largo suspiro]. Vuelves a confundirte. lmartinez me habla del demonio XINET, que se encarga de arrancar programas cuando detecta un intento de establecer conexión por red en un puerto determinado. No tiene nada que ver con los scripts de cambio de niveles de ejecución. Hay que leerse bien las cosas.
Verás que hay algunos que son de la forma: KXXnombre_script (esos son los que se lanzan antes de apagar el PC, "K" viene de "Kill") hay otros que son de la forma "SXXnombre_script" (esos son los que interesan).
Para poner un script al inicio del arranque: crea el script y muévelo a ese directorio con el nombre, por ejemplo S50miscript. Se ejecutan por orden, primero S01, después S02.... poner el propio el último sería lo ideal....
Y ya está....
Y no está, porque eso no está hecho a la manera de SuSE, y el Yast se encargará de borrar ese enlace - porque son enlaces, no se mueven los scripts - que has creado en cuanto tenga una oportunidad. Los scripts de inicio en SuSE hay que insertarlos mediante el programa perl 'chkconfig', o mediante 'insserv', o incluso el propio Yast - pero para todo ello, el script hay que crearlo con una cabecera especial, compatible con el estandar LSB (Linux Standar Base). Lo puedes ver en el ejemplo que viene con el sistema: '/etc/init.d/skeleton': ### BEGIN INIT INFO # Provides: FOO # Required-Start: $syslog $remote_fs # Should-Start: $time ypbind sendmail # Required-Stop: $syslog $remote_fs # Should-Stop: $time ypbind sendmail # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: FOO XYZ daemon providing ZYX # Description: Start FOO to allow XY and provide YZ # continued on second line by '#<TAB>' # should contain enough info for the runlevel editor # to give admin some idea what this service does and # what it's needed for ... # (The Short-Description should already be a good hint.) ### END INIT INFO Leete el capítulo 12 del manual de administración, "Capítulo 12. El concepto de arranque de SUSE LINUX". Ahí tienes explicado todo eso - que por cierto, no sirve de nada para el problema que hablamos en este hilo. -- Saludos Carlos Robinson
Buenos dias, saben anduve buscando la mejor forma de agregar un script propio, para que se ejecute al bootear mi SuSE 9.2, y me encontre con este mail que respondio Carlos Robinson y me dio varias ideas, aqui les comparto la que si funciono :D 1.- Primero revise que mi script funcionara y no me dejara congelado mi SuSE (no vaya a ser que al momento de bootear se quede congelada y nunca entre). 2.- Copie el script que iba a usar a /etc/init.d y revise que se pudiera ejecutar. 3.- Edite mi script y le agregue la cabecera basica que viene en http://www.polinux.upv.es/~vfernandez/suse/manuales/suselinux-adminguide-9.2... y que se los anexo aqui tambien : ***************** #!/bin/sh ##SCRIPT de iptables para Firewall ( ASI COMIENZA MI SCRIPT ) ***************** ***************** ### BEGIN INIT INFO # Provides: FOO =============== > (AQUI SE LE CAMBIA POR EL NOMBRE DE NUESTRO SCRIPT) # Required-Start: $syslog $remote_fs # Required-Stop: $syslog $remote_fs # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Description: Start FOO to allow XY and provide YZ ### END INIT INFO ****************** ****************** Y AQUI PUES EL CONTENIDO DE NUESTRO SCRIPT ****************** 4.- Despues dentro de /etc/init.d ejecute el comando insserv <nombre de mi script> y listo a volar.(la reinicie y ya estaban jalando mis scripts) : ) PD: Para verificar se haya realizado bien nuestro comando revisamos las carpetas rc3.d y rc5.d pues son las que corresponden a los niveles de ejecucion de la cabecera que se especifico anteriormente. Bueno es algo simple pero me funciono muy bien.... Saludos Victor Flores ----- Original Message ----- From: "Carlos E. R." <robin1.listas@tiscali.es> To: "suse-s" <suse-linux-s@suse.com> Sent: Wednesday, January 12, 2005 12:56 PM Subject: Re: [suse-linux-s] Disparar un script desde otra maquina
El 2005-01-12 a las 13:15 +0100, J M Betoret escribió:
Porque no le cuelgas un programita tuyo a xinet para que dispare el script???
Eso sería ideal... si supiera como se hace O:-)
En SuSE, los scripts que se inician al arrancar el sistema están en /etc/init.d/
Para abreviar, si quieres poner alguno nuevo tú, ponlo en
/etc/init.d/rc5.d/
Ahhyyyy... [largo suspiro].
Vuelves a confundirte. lmartinez me habla del demonio XINET, que se encarga de arrancar programas cuando detecta un intento de establecer conexión por red en un puerto determinado. No tiene nada que ver con los scripts de cambio de niveles de ejecución.
Hay que leerse bien las cosas.
Verás que hay algunos que son de la forma: KXXnombre_script (esos son
los que
se lanzan antes de apagar el PC, "K" viene de "Kill") hay otros que son de la forma "SXXnombre_script" (esos son los que interesan).
Para poner un script al inicio del arranque: crea el script y muévelo a ese directorio con el nombre, por ejemplo S50miscript. Se ejecutan por orden, primero S01, después S02.... poner el propio el último sería lo ideal....
Y ya está....
Y no está, porque eso no está hecho a la manera de SuSE, y el Yast se encargará de borrar ese enlace - porque son enlaces, no se mueven los scripts - que has creado en cuanto tenga una oportunidad. Los scripts de inicio en SuSE hay que insertarlos mediante el programa perl 'chkconfig', o mediante 'insserv', o incluso el propio Yast - pero para todo ello, el script hay que crearlo con una cabecera especial, compatible con el estandar LSB (Linux Standar Base). Lo puedes ver en el ejemplo que viene con el sistema: '/etc/init.d/skeleton':
### BEGIN INIT INFO # Provides: FOO # Required-Start: $syslog $remote_fs # Should-Start: $time ypbind sendmail # Required-Stop: $syslog $remote_fs # Should-Stop: $time ypbind sendmail # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: FOO XYZ daemon providing ZYX # Description: Start FOO to allow XY and provide YZ # continued on second line by '#<TAB>' # should contain enough info for the runlevel editor # to give admin some idea what this service does and # what it's needed for ... # (The Short-Description should already be a good hint.) ### END INIT INFO
Leete el capítulo 12 del manual de administración, "Capítulo 12. El concepto de arranque de SUSE LINUX". Ahí tienes explicado todo eso - que por cierto, no sirve de nada para el problema que hablamos en este hilo.
-- Saludos Carlos Robinson
-- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.10 - Release Date: 10/01/2005
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.0 - Release Date: 29/04/2005
Carlos E. R. escribió:
El 2005-01-11 a las 21:47 +0100, lmartinez escribió:
Porque no le cuelgas un programita tuyo a xinet para que dispare el script???
Eso sería ideal... si supiera como se hace O:-)
Estimado El como se hace lo ha mencionado Beto en otro mensaje: ssh maquinaremota scriptname Lo que entiendo que no te "convence" es que con esa forma te requiere el ingreso de la password en la maquina remota, y eso lo puedes obviar ejecutando un script local con expect, mas o menos asi: #!/usr/bin/expect -f set site "maquinaremota" set passwd "mipasswdremota" spawn ssh $site scriptremoto expect "*password:*" send "$passwd\r" expect "*$*" exit Debes asegurarte que el script local lo ejecute la misma cuenta de usuario que necesitas que ejecute el script remoto Debes asegurarte que en el directorio home del usuario remoto contenga el script con los respectivos permisos de ejecucion Lo probe y funciona Saludos LRP
El 2005-01-12 a las 14:06 -0300, Luis Roa P. escribió:
Porque no le cuelgas un programita tuyo a xinet para que dispare el script???
Eso sería ideal... si supiera como se hace O:-)
Estimado
El como se hace lo ha mencionado Beto en otro mensaje:
ssh maquinaremota scriptname
Eso no es el como de "como colgar un programita a xinetd", o sea, como hacer un programa en C al cual le entran conexiones por internet y hace cosas. Y lo de ssh ya he dicho que no funciona, pide la clave.
Lo que entiendo que no te "convence" es que con esa forma te requiere el ingreso de la password en la maquina remota, y eso lo puedes obviar ejecutando un script local con expect, mas o menos asi:
Buff, eso es una chapuza, con perdón: tener la password de root de mi maquina principal escrita en un script de mi máquina auxiliar (que es un 7.3), no me gusta nada nada nada... El ssh está preparado para no pedir password si se usa un par de llaves adecuadas... pero no funciona. -- Saludos Carlos Robinson
Carlos E. R. escribió:
El 2005-01-12 a las 14:06 -0300, Luis Roa P. escribió:
Y lo de ssh ya he dicho que no funciona, pide la clave.
Lo que entiendo que no te "convence" es que con esa forma te requiere el ingreso de la password en la maquina remota, y eso lo puedes obviar ejecutando un script local con expect, mas o menos asi:
Buff, eso es una chapuza, con perdón: tener la password de root de mi maquina principal escrita en un script de mi máquina auxiliar (que es un 7.3), no me gusta nada nada nada... El ssh está preparado para no pedir password si se usa un par de llaves adecuadas... pero no funciona.
Yo he leido todo el thread, y la respuesta que te di soluciona tu problema. En ningun momento haz mencionado lo que dices en tu ultimo parrafo, recien ahora. Ademas, el que tengas ese script expect en tu maquina auxiliar NO es sinonimo de que la password de root de tu maquina principal este a disposicion de todo el mundo, pues para eso existen las propiedades y permisos de acceso de los archivos. Basta que tu script sea propiedad de root, lo ubiques en un directorio de acceso restringido y no le des permisos de lectura a NADIE que no sea root (chmod 500 tuscript, el cual es propiedad de root) Sin embargo, tienes razon en una cosa, si configuras ssh de acuerdo a tu necesidad, puedes obviar la password. Si no haz podido hacerlo, una de las razones que puede haber es que tengas distintas versiones de ssh en las dos maquinas (version 1 en el 7.3 y version 2 en tu maquina principal) Lamento que mi intencion de cooperar te haya parecido una chapuza, sorry... Saludos LRP
El 2005-01-12 a las 17:35 -0300, Luis Roa P. escribió:
Carlos E. R. escribió:
El 2005-01-12 a las 14:06 -0300, Luis Roa P. escribió: Y lo de ssh ya he dicho que no funciona, pide la clave.
Lo que entiendo que no te "convence" es que con esa forma te requiere el ingreso de la password en la maquina remota, y eso lo puedes obviar ejecutando un script local con expect, mas o menos asi:
Buff, eso es una chapuza, con perdón: tener la password de root de mi maquina principal escrita en un script de mi máquina auxiliar (que es un 7.3), no me gusta nada nada nada... El ssh está preparado para no pedir password si se usa un par de llaves adecuadas... pero no funciona.
Yo he leido todo el thread, y la respuesta que te di soluciona tu problema. En ningun momento haz mencionado lo que dices en tu ultimo parrafo, recien ahora.
El que, ¿que el ssh no funciona? Si que lo dije. A ver [...] aqui, las dos lineas del final: |> Date: Sat, 8 Jan 2005 17:57:12 +0100 (CET) |> From: Carlos E. R. |> Subject: Re: [suse-linux-s] Disparar un script desde otra maquina |> |> |> El 2005-01-08 a las 10:36 +0100, Miquel A. Noguera escribió: |> |> > Yo lo hago así: |> > |> > ssh usuario@máquina_remota script |> > |> > Para evitar teclear la contraseña, copio el fichero $HOME/.ssh/id_rsa.pub del |> > usuario en la "máquina_local" en el home de "usuario@máquina_remota" y, |> > finalmente, en "máquina_remota": |> > |> > cat id_rsa.pub >> $HOME/.ssh/authorized_keys |> |> Esa parte no me va, no funciona: me pide siempre el password. El cliente |> es 9.1 y el servidor un suse 7.3.
Ademas, el que tengas ese script expect en tu maquina auxiliar NO es sinonimo de que la password de root de tu maquina principal este a disposicion de todo el mundo, pues para eso existen las propiedades y permisos de acceso de los archivos. Basta que tu script sea propiedad de root, lo ubiques en un directorio de acceso restringido y no le des permisos de lectura a NADIE que no sea root (chmod 500 tuscript, el cual es propiedad de root)
Si, ya lo se. Eso es la teoría. Pero si me despisto, o si hay un agujero - y teniendo en cuenta que esa es la máquina que se conecta a internet, y que al ser un 7.3 no se actualiza - me lo pueden freir.
Sin embargo, tienes razon en una cosa, si configuras ssh de acuerdo a tu necesidad, puedes obviar la password. Si no haz podido hacerlo, una de las razones que puede haber es que tengas distintas versiones de ssh en las dos maquinas (version 1 en el 7.3 y version 2 en tu maquina principal)
El 7.3 usa openssh-2.9p2-39, y el 9.1 openssh-3.8p1-33. Ambos soportan protocolo versión uno y dos. No, no es eso.
Lamento que mi intencion de cooperar te haya parecido una chapuza, sorry...
Perdóname, por motivos personales ando más cansado de la cuenta, y estoy un poco mosca teniendo que ver varias veces las mismas soluciones que desde el principio del hilo dije que no iban y porqué. -- Saludos Carlos Robinson
Carlos E. R. wrote: Escribio mucho mucho........................ :-) Si te sirve de consuelo, que supongo que no, aunque estar acompañado en los problemas ayuda A mi me ha pasado algo muy parecido pero en mi caso era entre un Debian bastante antiguo y un Suse 8.0. Ahora no recuerdo exactamente si lo llegué a solucionar, lo que si te puedo decir es que la conclusion a la que llegué era que el formato de las claves era totalmente distinto cuando se generaban con uno y con otro a pesar de indicarle el mismo tipo de clave. El resto de configuracion del sshd_config supongo que estará correcto, porque como comentas ya lo has mas que revisado. Tu la clave del Suse la usas para mucho? porque igual lo que puedes hacer es crear una clave en el suse 7.3 y pasar las claves generadas al Suse 9.1 haciendo como que pasen a ser esas las claves de identificacion del usuario en el 9.1. Prueba con un usuario de prueba, no con root, no vaya a ser que la lies. de paso ejecuta el comando ssh -vvv para que te haga una traza de todo lo que pasa en la conexion ssh a ver si te da mas pistas. Finalmente seria genial que alguien comentara lo de lanzar el proceso desde el xinetd, aunque me da que eso no va a ser tan sencillo como parece a simple vista, porque digo yo que habla que lanzar algún socket o algo para que el xinetd lo maneje como un servidor.... Espero haberte ayudado algo Saludos Emi
El 2005-01-13 a las 10:16 +0100, Emiliano Sutil escribió:
Si te sirve de consuelo, que supongo que no, aunque estar acompañado en los problemas ayuda A mi me ha pasado algo muy parecido pero en mi caso era entre un Debian bastante antiguo y un Suse 8.0. Ahora no recuerdo exactamente si lo llegué a solucionar, lo que si te puedo decir es que la conclusion a la que llegué era que el formato de las claves era totalmente distinto cuando se generaban con uno y con otro a pesar de indicarle el mismo tipo de clave. El resto de configuracion del sshd_config supongo que estará correcto, porque como comentas ya lo has mas que revisado.
Tu la clave del Suse la usas para mucho? porque igual lo que puedes hacer es crear una clave en el suse 7.3 y pasar las claves generadas al Suse 9.1 haciendo como que pasen a ser esas las claves de identificacion del usuario en el 9.1. Prueba con un usuario de prueba, no con root, no vaya a ser que la lies. de paso ejecuta el comando ssh -vvv para que te haga una traza de todo lo que pasa en la conexion ssh a ver si te da mas pistas.
El problema es que el 9.1 exige protocolo versión 2, y el 7.3 ofrece el uno. Forzando a que ofrezca el 2 directamente ha funcionado. Lo de las tres 'v'ha ayudado mucho a resolverlo.
Finalmente seria genial que alguien comentara lo de lanzar el proceso desde el xinetd, aunque me da que eso no va a ser tan sencillo como parece a simple vista, porque digo yo que habla que lanzar algún socket o algo para que el xinetd lo maneje como un servidor....
Algo de eso. Pero si, me gustaría saber hacerlo :-)
Espero haberte ayudado algo
Sip :-) -- Saludos Carlos Robinson
participants (11)
-
Carlos E. R. -
chakal -
Emiliano Sutil -
J M Betoret -
JOSANable -
jose maria -
lmartinez -
Luis Roa P. -
Miquel A. Noguera -
Oscar Gosdinski -
Victor Flores