Buenas, Problema: - una red (entre 6 y 10) máquinas que deben tener los escritorios capados y el contenido web también capado. Solución: - un servidor entre los clientes y internet que capa el escritorio mediante kiosktool y el contenido web mediante squid. Ahora bien, el kiosktool se puede configurar en cada máquina localmente; el único problema que tienes es que vas de máquina en máquina como un tonto para crear el mismo perfil. Lo ideal sería crear los perfiles en el servidor y que al arrancar los clientes se copien el perfil correspondiente. Además, los archivos en este en el caso de kiokstool están muy bien localizado en /etc/kde-user-profile y el directorio /var/lib/kde-profiles. Así pues sólo se trata de "machacar" ese contenido cada ves que arranquen los clientes. Ya sé que hay métodos más limpios como un LDAP y bla bla... pero me da igual que los usuarios esten logeados en local. Lo que me importa es que los perfiles estén en el servidor. ¿Cómo lo hariáis? Yo había pensado poner un sencillísimo FTP en el servidor con una copia de esos archivos y crear un script en el boot.local de los servidores que conecte al FTP y copie esos archivos, machacando a los locales. Pero claro, también podría hacerse con SFTP (eso si, activando al agent-key para el tema de clave desatendida), NFS y alguno más. ¿Ideas? Gracias por adelantado. PD. Soy aquiles_4@softhome.net... lo que pasa es que desgraciadamente los de SoftHome.net han retirado el soporte gratuito POP, así que bueno... el amigo yahoo es ideal. Además, a medida que entras en año te va dando más pereza firmar con otra cosa que no sea tu nombre real. ;) -- Salut, Jordi Espasa
El Miércoles 14 Diciembre 2005 12:06, Jordi Espasa Clofent escribió:
Ya sé que hay métodos más limpios como un LDAP y bla bla... pero me da igual que los usuarios esten logeados en local. Lo que me importa es que los perfiles estén en el servidor.
¿Cómo lo hariáis?
* Configurando en kiosktool, a la hora de guardar el perfil la maquina en donde se quiere guardar.
* Configurando en kiosktool, a la hora de guardar el perfil la maquina en donde se quiere guardar.
Si claro, eso es evidente. Los perfiles se crean en el servidor mediante kiosktool y se guardan ahí mismo. Lo que quiero es que las máquinas cliente, al arrancar, importen esos perfiles. PD. Lógicamente los perfiles creados en el servidor corresponderan con los usuarios/grupos necesarios en los clientes. :P -- Salut, Jordi Espasa
El Miércoles 14 Diciembre 2005 13:01, Jordi Espasa Clofent escribió:
* Configurando en kiosktool, a la hora de guardar el perfil la maquina en donde se quiere guardar.
Si claro, eso es evidente. Los perfiles se crean en el servidor mediante kiosktool y se guardan ahí mismo.
Lo que quiero es que las máquinas cliente, al arrancar, importen esos perfiles.
PD. Lógicamente los perfiles creados en el servidor corresponderan con los usuarios/grupos necesarios en los clientes. :P
* kiosktool puede guardar los perfiles localmente o guardarlos en otra maquina al terminar, ergo en los clientes configura y envia al servidor los perfiles (digo esto, por que te va a ser muy dificil generar perfiles en el servidor para los clientes a menos que sean muy "iguales" y una complicacion mas), estos perfiles (ubicados en distintos directorios (cliente1, cliente2, etc), en el servidor, estaran disponibles para la exportacion, en el arranque pc1 pedira cliente1, pc2 pedira cliente2, y en pc1 y pc2 estaran montados donde kiosktool espere encontrar los ficheros. * Tambien lo puede hacer scripts que tiren de tftp o ssh, incluso el servidor dhcp podria indicarle el fichero a bajar del servidor tft, no hara falta script que los borre en la parada por que en el arranque los reescribira con los que baje del servidor. * Supongo lo que pretendes, pero esto ya se hacia incluyendo en /etc/bash_bashrc la jugada por cliente (no todos tienen por que tener el mismo perfil), pero ojo que esto es pedestre, propenso a fallos de red, no evita mantenimiento (vigilancia y administracion), para esto esta, thin client + kiosktool con los que nada te impide dar uso a los discos "locales", osea que no te arriendo las ganancias.
* kiosktool puede guardar los perfiles localmente o guardarlos en otra maquina al terminar, ergo en los clientes configura y envia al servidor los perfiles (digo esto, por que te va a ser muy dificil generar perfiles en el servidor para los clientes a menos que sean muy "iguales" y una complicacion mas), estos perfiles (ubicados en distintos directorios (cliente1, cliente2, etc), en el servidor, estaran disponibles para la exportacion, en el arranque pc1 pedira cliente1, pc2 pedira cliente2, y en pc1 y pc2 estaran montados donde kiosktool espere encontrar los ficheros.
Si, en el caso que comentas (perfiles heterogéneos) tienes toda la razón. De hecho se me había pasado por alto esa opción tan básica de kiosktool de guardarlos en local o en máquina remota.... Aunque otra cosa sería mirarme que *%$%$ es el protocolo fish:// ... primera notícia. Sin embargo en el caso que me ocupa sólo se utilizará un perfil (red de 7-10 máquinas con acceso público a Internet prestada por un Ayuntamiento), con lo cual me da menos faena realizar dicho perfil en el servidor y después simplemente exportarlo a los clientes al arrancar. Lo que quiero ahorrarme precisamente es instalar kiosktool en los clientes y tener que configurar los perfiles en cada una de las máquinas. El único inconveniente que veo es que tendré que crear el mismo "usuario genérico" en el servidor que el que usarán los clientes; para el tema de la asociación correcta de perfil, claro.
* Tambien lo puede hacer scripts que tiren de tftp o ssh, incluso el servidor dhcp podria indicarle el fichero a bajar del servidor tft, no hara falta script que los borre en la parada por que en el arranque los reescribira con los que baje del servidor.
Ajá.
* Supongo lo que pretendes, pero esto ya se hacia incluyendo en /etc/bash_bashrc la jugada por cliente (no todos tienen por que tener el mismo perfil), pero ojo que esto es pedestre, propenso a fallos de red, no evita mantenimiento (vigilancia y administracion), para esto esta, thin client + kiosktool con los que nada te impide dar uso a los discos "locales", osea que no te arriendo las ganancias.
Estudiaré la posibilidad. ¿Tienes algún link por ahí? -- Salut, Jordi Espasa
El Jueves 15 Diciembre 2005 08:59, Jordi Espasa Clofent escribió:
Estudiaré la posibilidad. ¿Tienes algún link por ahí?
* ¿Un link de que?, si es de ltsp o PXES, ven un dia, con la mac de cada cliente apuntada y la cpu del servidor y te lo llevas puesto, es lo que ha hecho josan y sole, kiosktool soporta ltsp directamente, (actualmente), de todas maneras si no recuerdo mal, ya mande a esta lista un mensaje con instrucciones de instalacion y configuracion, busca en http://marc.theaimsgroup.com/?l=suse-linux-s&r=1&w=2 http://www.2x.com/pxes/ www.ltsp.org terminales.hispalinux.es
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-12-14 a las 12:06 +0100, Jordi Espasa Clofent escribió:
¿Cómo lo hariáis?
Yo había pensado poner un sencillísimo FTP en el servidor con una copia de esos archivos y crear un script en el boot.local de los servidores que conecte al FTP y copie esos archivos, machacando a los locales.
Pero claro, también podría hacerse con SFTP (eso si, activando al agent-key para el tema de clave desatendida), NFS y alguno más.
Puedes crear un servicio en cada cliente, que arranque después del nfs (client), y que se encargue de importarlos. /etc/init.d/importar: ### BEGIN INIT INFO # Provides: importar # Required-Start: $nfs # Required-Stop: # Default-Start: 3 5 # Default-Stop: # Description: Importa ficheros necesarios desde el servidor ### END INIT INFO . /etc/rc.status case "$1" in start|reload) cp lo que sea rc_status -v ;; esac Y para hacerlo bien, pon el copy en una función que tenga los códigos de salida (0..5) adecuados. Mas info, /etc/init.d/skeleton.
PD. Soy aquiles_4@softhome.net... lo que pasa es que desgraciadamente los de SoftHome.net han retirado el soporte gratuito POP, así que bueno... el amigo yahoo es ideal. Además, a medida que entras en año te va dando más pereza firmar con otra cosa que no sea tu nombre real.
Me parece muy bien, porque eso de no saber con quien me escribo, me da cosilla :-) - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDoBgotTMYHG2NR9URAozSAJwPDq/WKRjDjzzxTgCyT/Cry1hrowCdFny0 ROn5wWY/7NyjSzoMMPMuB7I= =LjhR -----END PGP SIGNATURE-----
El 14/12/05, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2005-12-14 a las 12:06 +0100, Jordi Espasa Clofent escribió:
¿Cómo lo hariáis?
Yo había pensado poner un sencillísimo FTP en el servidor con una copia de esos archivos y crear un script en el boot.local de los servidores que conecte al FTP y copie esos archivos, machacando a los locales.
Pero claro, también podría hacerse con SFTP (eso si, activando al agent-key para el tema de clave desatendida), NFS y alguno más.
Puedes crear un servicio en cada cliente, que arranque después del nfs (client), y que se encargue de importarlos.
/etc/init.d/importar:
### BEGIN INIT INFO # Provides: importar # Required-Start: $nfs # Required-Stop: # Default-Start: 3 5 # Default-Stop: # Description: Importa ficheros necesarios desde el servidor ### END INIT INFO
. /etc/rc.status
case "$1" in start|reload) cp lo que sea rc_status -v ;; esac
Y para hacerlo bien, pon el copy en una función que tenga los códigos de salida (0..5) adecuados. Mas info, /etc/init.d/skeleton.
mmmm.. creo que vuestro esquema no seria el mas ideal.. ya que utilizas cp y siempre tendras que copiar "todo" el contenido desde el servidor hasta los clientes, independente se hay cambios o no!!!! personalmente, recomendaria utilziar rsync + ssh para poder sincronizar los datos entre servidor y clientes.... segun mi punto de vista, seria una mejor solucion ya que no copiaria todo los archivos desde el servidor, mas solamente los datos que fueron alterados... y esto colocaria en un cron para que se ejecutara a N horas/minutos.. ya que en el ejemplo del servicio anteiror, seria necesario apagar/encender la maquina para que los datos se sincronizen... y que pasaria se los usuarios simplesmente hiceran un logout y la maquina siempre estuvera encendida ??? salu2 -- -- Victor Hugo dos Santos Linux Counter #224399
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-12-14 a las 21:03 -0300, Victor Hugo dos Santos escribió:
mmmm.. creo que vuestro esquema no seria el mas ideal.. ya que utilizas cp y siempre tendras que copiar "todo" el contenido desde el servidor hasta los clientes, independente se hay cambios o no!!!!
Bueno, es que yo no se cuanto tienes que copiar, pensaba que eran solo unos ficheritos de configuración, que suelen ser pequeños; en ese caso se pierde menos tiempo machacandolos que pensandolo.
personalmente, recomendaria utilziar rsync + ssh para poder sincronizar los datos entre servidor y clientes.... segun mi punto de vista, seria una mejor solucion ya que no copiaria todo los archivos desde el servidor, mas solamente los datos que fueron alterados...
Si, claro, si tienen cierto peso.
y esto colocaria en un cron para que se ejecutara a N horas/minutos.. ya que en el ejemplo del servicio anteiror, seria necesario apagar/encender la maquina para que los datos se sincronizen... y que pasaria se los usuarios simplesmente hiceran un logout y la maquina siempre estuvera encendida ???
Pero eso es lo que pidió Jordi. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDoU/6tTMYHG2NR9URAv0CAJ9OIxEs+6zreKKChHb5Qcnih4UqOACgg1pj OOyWuVLw5OqWTjl/1GfsEHA= =YrXJ -----END PGP SIGNATURE-----
Bueno, es que yo no se cuanto tienes que copiar, pensaba que eran solo unos ficheritos de configuración, que suelen ser pequeños; en ese caso se pierde menos tiempo machacandolos que pensandolo.
Bueno, el tema es machacarlos, porqué, efectivamente, son poca cosa.
Pero eso es lo que pidió Jordi.
Exactamente. Al final he hecho lo siguiente: SERVIDOR - creo los perfiles de turno - mkdir /perfiles - cp /etc/kde-user-profile /perfiles - cp -r /var/lib/kde-profile /perfiles - yast nfs-sever y pongo a exportar /perfiles CLIENTE - mkdir /perfiles_cliente - yast-nfs client e importo /perfiles en /perfiles_cliente - .... aquí es donde tengo el problema (si si, ya sé que es un mísero copy, pero quiero hacerlo de forma automática cuando arranque el cliente). Lo que pasa es que cree el servicio a partir de /etc/init.de/skeleton tal y como recomendó Carlos, pero el problema es que dicho servicio (de nombre importar_perfil) se ejecuta *ANTES* de que se importe el directorio NFS, con lo cual peta. Y lo raro es que en # Requires-Start le he pueso $nfs Hay alguna cosilla que se me escapa.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-12-15 a las 15:03 +0100, Jordi Espasa Clofent escribió:
Lo que pasa es que cree el servicio a partir de /etc/init.de/skeleton tal y como recomendó Carlos, pero el problema es que dicho servicio (de nombre importar_perfil) se ejecuta *ANTES* de que se importe el directorio NFS, con lo cual peta.
Y lo raro es que en # Requires-Start le he pueso $nfs
Hay alguna cosilla que se me escapa.
¿Lo has instalado con "chkconfig importar_perfil on"? ¿Te da algún mensaje al hacerlo? - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDocrktTMYHG2NR9URAiGUAJ9KZQ3QFbo44g52SZnQmmgFPxCybgCbBPlC ilPuH2nf4A5htqIejcbrtlE= =jzEb -----END PGP SIGNATURE-----
Hola :) Jordi Espasa Clofent wrote:
Buenas,
Problema: - una red (entre 6 y 10) máquinas que deben tener los escritorios capados y el contenido web también capado.
Solución: - un servidor entre los clientes y internet que capa el escritorio mediante kiosktool y el contenido web mediante squid.
Ahora bien, el kiosktool se puede configurar en cada máquina localmente; el único problema que tienes es que vas de máquina en máquina como un tonto para crear el mismo perfil.
Lo ideal sería crear los perfiles en el servidor y que al arrancar los clientes se copien el perfil correspondiente. Además, los archivos en este en el caso de kiokstool están muy bien localizado en /etc/kde-user-profile y el directorio /var/lib/kde-profiles. Así pues sólo se trata de "machacar" ese contenido cada ves que arranquen los clientes.
Ya sé que hay métodos más limpios como un LDAP y bla bla... pero me da igual que los usuarios esten logeados en local. Lo que me importa es que los perfiles estén en el servidor.
¿Cómo lo hariáis?
Yo había pensado poner un sencillísimo FTP en el servidor con una copia de esos archivos y crear un script en el boot.local de los servidores que conecte al FTP y copie esos archivos, machacando a los locales.
Pero claro, también podría hacerse con SFTP (eso si, activando al agent-key para el tema de clave desatendida), NFS y alguno más.
¿Ideas?
Yo te aconsejo rsync, es muy potente, sólo transfiere las deltas, puedes usarlo en combinación con ssh, establecer permisos, ... échale un vistazo: rápido, potente y seguro. Los clientes, al arrancar van al servidor actualizan su config y no se tarda nada, consume poco ancho de banda, ... Rafa -- Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia , 120 - Planta Baja 28003 Madrid, Spain Tel: +34 91 3984200 Fax: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com
Yo te aconsejo rsync, es muy potente, sólo transfiere las deltas, puedes usarlo en combinación con ssh, establecer permisos, ... échale un vistazo: rápido, potente y seguro.
Si, alguna vez lo he utilizado. Ahora bien, en la parte servidor, digo tyo que tendré que levantar el servicio de alguna manera ¿no?
Los clientes, al arrancar van al servidor actualizan su config y no se tarda nada, consume poco ancho de banda, ...
Si, lo estudiaré. Es una buena alternativa. -- Salut, Jordi Espasa
Hola :) Jordi Espasa Clofent wrote:
Yo te aconsejo rsync, es muy potente, sólo transfiere las deltas, puedes usarlo en combinación con ssh, establecer permisos, ... échale un vistazo: rápido, potente y seguro.
Si, alguna vez lo he utilizado. Ahora bien, en la parte servidor, digo tyo que tendré que levantar el servicio de alguna manera ¿no?
Si lo haces en plan "pull": - dejas en el servidor el rsyncd corriendo - en el cliente te haces un script de arranque que descarga la "nueva versión" Si lo haces en plan "push": - justo al revés Personalmente optaría por la primera opción.
Los clientes, al arrancar van al servidor actualizan su config y no se tarda nada, consume poco ancho de banda, ...
Si, lo estudiaré. Es una buena alternativa.
HTH Rafa -- Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia , 120 - Planta Baja 28003 Madrid, Spain Tel: +34 91 3984200 Fax: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com
2005/12/16, Rafa Grimán
Hola :)
Jordi Espasa Clofent wrote:
Yo te aconsejo rsync, es muy potente, sólo transfiere las deltas, puedes usarlo en combinación con ssh, establecer permisos, ... échale un vistazo: rápido, potente y seguro.
Si, alguna vez lo he utilizado. Ahora bien, en la parte servidor, digo tyo que tendré que levantar el servicio de alguna manera ¿no?
Si lo haces en plan "pull": - dejas en el servidor el rsyncd corriendo - en el cliente te haces un script de arranque que descarga la "nueva versión"
Si lo haces en plan "push": - justo al revés
Personalmente optaría por la primera opción.
oiga... rsync trabaja sin necesidad de llevantar/configurar el servidor rsync!!! por esto tenia recomendado esta solucion.. ya que no era necesario ninguna configuracion extra de servicios ademas del servicio sshd (que cuase siempre esta activo por defecto) !!! por ejemplo (escrito de memoria) : rsync -e ssh -av --delete /carpeta/origen pepito@maquina_remota:/carpeta/respaldo con esto, tu sincronizas la carpeta de origen con la de destino, todo pasando por un canal seguro (ssh) y utilizando el usuario "pepito"... salu2. -- -- Victor Hugo dos Santos Linux Counter #224399
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-12-16 a las 16:53 -0300, Victor Hugo dos Santos escribió:
oiga... rsync trabaja sin necesidad de llevantar/configurar el servidor rsync!!!
¿Seguro? :-? - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDo037tTMYHG2NR9URApGXAJsGZxyRlDT7Jz8fjawTulV/Y0NekwCeLNSb A0/3UtKPYg6A7YJvJ0KSkVg= =dPR1 -----END PGP SIGNATURE-----
El 16/12/05, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2005-12-16 a las 16:53 -0300, Victor Hugo dos Santos escribió:
oiga... rsync trabaja sin necesidad de llevantar/configurar el servidor rsync!!!
¿Seguro? :-?
segurito... segurito !!! haga la prueba usted mismo !!!! :-) rsync -e ssh -av --delete /carpeta/origen pepito@maquina_remota:/carpeta/respaldo salu2. -- -- Victor Hugo dos Santos Linux Counter #224399
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-12-16 a las 22:16 -0300, Victor Hugo dos Santos escribió:
oiga... rsync trabaja sin necesidad de llevantar/configurar el servidor rsync!!!
¿Seguro? :-?
segurito... segurito !!!
haga la prueba usted mismo !!!! :-)
rsync -e ssh -av --delete /carpeta/origen pepito@maquina_remota:/carpeta/respaldo
Pero, ¿sin ejecutar el servidor rsync en la máquina remota? - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDo29QtTMYHG2NR9URAio/AKCVXe9yLD/ciytjV6D5sohP1XF+kQCfTaWl 0Y/6XcEDNqF0wUhEbR1ifkI= =h1tQ -----END PGP SIGNATURE-----
El 16/12/05, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2005-12-16 a las 22:16 -0300, Victor Hugo dos Santos escribió:
oiga... rsync trabaja sin necesidad de llevantar/configurar el servidor rsync!!!
¿Seguro? :-?
segurito... segurito !!!
haga la prueba usted mismo !!!! :-)
rsync -e ssh -av --delete /carpeta/origen pepito@maquina_remota:/carpeta/respaldo
Pero, ¿sin ejecutar el servidor rsync en la máquina remota?
hombre de poca fe !!!!! ;-) -- -- Victor Hugo dos Santos Linux Counter #224399
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-12-17 a las 16:18 -0300, Victor Hugo dos Santos escribió:
oiga... rsync trabaja sin necesidad de llevantar/configurar el servidor rsync!!!
¿Seguro? :-?
segurito... segurito !!!
haga la prueba usted mismo !!!! :-)
rsync -e ssh -av --delete /carpeta/origen pepito@maquina_remota:/carpeta/respaldo
Pero, ¿sin ejecutar el servidor rsync en la máquina remota?
hombre de poca fe !!!!! ;-)
Vale, vale, funciona, acabo de probarlo :-) El demonio sshd se encarga de arrancar rsync y funciona. Aunque esa linea copia a la maquina remota, que es al revés de lo que se intenta. GENERAL There are eight different ways of using rsync. They are: ... o for copying from the local machine to a remote machine using a remote shell program as the transport (such as ssh or rsh). This is invoked when the destination path contains a single : separator. ... o for copying from a remote machine to the local machine using a remote shell program. This is invoked when the source contains a : separator. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDpX9RtTMYHG2NR9URAjf+AJ9ukFZu/6nINT/g7pigik7rnWrNDgCdHRSa inSbmEU4LxoimdCbe9RIJR8= =7PeB -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-12-17 a las 16:18 -0300, Victor Hugo dos Santos escribió:
El 16/12/05, Carlos E. R.
escribió:
Se me olvidaba. En la linea ^^^ de arriba, debes reconfigurar tu correo para que sólo ponga el nombre de la persona a la que respondas, pero no su dirección de correo. Ten encuenta que estos correos aparecen en archivos y paginas webs que son exploradas rutinariamente por los spammers para obtener nuestras direcciones y acribillarnos. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDp0DftTMYHG2NR9URAk4EAJ9dyUZsShEFMwubB99ZNid10LsrkwCaAw97 mpgpyImw5hU5j22kZT8K4+w= =V0DF -----END PGP SIGNATURE-----
El 19/12/05, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2005-12-17 a las 16:18 -0300, Victor Hugo dos Santos escribió:
El 16/12/05, Carlos E. R.
escribió: Se me olvidaba. En la linea ^^^ de arriba, debes reconfigurar tu correo para que sólo ponga el nombre de la persona a la que respondas, pero no su dirección de correo. Ten encuenta que estos correos aparecen en archivos y paginas webs que son exploradas rutinariamente por los spammers para obtener nuestras direcciones y acribillarnos.
carlos y todos.... ya tenia mirado esto hace algun tiempo... y de verdad lo lamento mucho, pero por motivos que no puedo comentar aca en la lista, necesito utilizar mi cuenta de correo (gmail) directamente de su interface web... y hasta el momento, no existe posibilidad de personalizar esto !!!! pero as mirado el historico de la lista, o no ??? mismo cambiando el campo que mencionas, apareceran nuestras direcciones de correo que estan en el campo "from" http://lists.suse.com/archive/suse-linux-s/2005-Dec/0772.html o sea... de todas maneras irian capturar nuestra direccion de corrreo... :-( existe un plugin en mailman, que convierte "automagicamente" todas las @ (arrobas) que encuentra en los correos para "_at_" antes de publicarlo en historico... pero va uno intentar mencionar/pedir dicha caracteristica al administrador. por cierto, referente a vuestro correo anterior (mismo hilo), donde menciona que el destino/origen estan al reves... la respuesta es: "quería ver se estaban atentos" :-D salu2. -- -- Victor Hugo dos Santos Linux Counter #224399
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-12-19 a las 21:37 -0300, Victor Hugo dos Santos escribió:
Se me olvidaba. En la linea ^^^ de arriba, debes reconfigurar tu correo para que sólo ponga el nombre de la persona a la que respondas, pero no su dirección de correo. Ten encuenta que estos correos aparecen en archivos y paginas webs que son exploradas rutinariamente por los spammers para obtener nuestras direcciones y acribillarnos.
carlos y todos.... ya tenia mirado esto hace algun tiempo... y de verdad lo lamento mucho, pero por motivos que no puedo comentar aca en la lista, necesito utilizar mi cuenta de correo (gmail) directamente de su interface web... y hasta el momento, no existe posibilidad de personalizar esto !!!!
Argh. También he probado ese webmail, pero no me fijé mucho.
pero as mirado el historico de la lista, o no ??? mismo cambiando el campo que mencionas, apareceran nuestras direcciones de correo que estan en el campo "from" http://lists.suse.com/archive/suse-linux-s/2005-Dec/0772.html
Si, es cierto, pero no es el único archivo.
o sea... de todas maneras irian capturar nuestra direccion de corrreo... :-(
Ya, es inevitable, pero se trata de quitarles facilidades.
existe un plugin en mailman, que convierte "automagicamente" todas las @ (arrobas) que encuentra en los correos para "_at_" antes de publicarlo en historico... pero va uno intentar mencionar/pedir dicha caracteristica al administrador.
No, ne pas posible, se lo han pedido muchas veces; y daba unas explicaciones que me indican que nunca se enteró de lo que le pedían. El caso es que las direcciones aparecen en dos sitios; en uno están camufladas, y en otro no. Otra de las explicaciones era que nosotros podemos "falsificar" el from, manteniendo correcto el "envelope from", que es el único que verifica el ezmlm. Eso es cierto, se puede, pero el único cliente de correo que lo permite es el mutt.
por cierto, referente a vuestro correo anterior (mismo hilo), donde menciona que el destino/origen estan al reves... la respuesta es: "quería ver se estaban atentos" :-D
Ya ya... pos no, no me fijé, lo vi en su actuación. Si que le quité el delete, por si las moscas. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDp18itTMYHG2NR9URArBWAJ9XTrEeoZlMX91CfIYWz+Nz8y+IRwCdH/zi ibaIqRMQfWOp6i90Mxulff0= =9oJo -----END PGP SIGNATURE-----
El Viernes 16 Diciembre 2005 20:53, Victor Hugo dos Santos escribió:
oiga... rsync trabaja sin necesidad de llevantar/configurar el servidor rsync!!! por esto tenia recomendado esta solucion.. ya que no era necesario ninguna configuracion extra de servicios ademas del servicio sshd (que cuase siempre esta activo por defecto) !!!
por ejemplo (escrito de memoria) : rsync -e ssh -av --delete /carpeta/origen pepito@maquina_remota:/carpeta/respaldo
con esto, tu sincronizas la carpeta de origen con la de destino, todo pasando por un canal seguro (ssh) y utilizando el usuario "pepito"...
* Solo decir que como script desatendido se precisa autentificacion por claves exportadas, generadas SIN contraseña.
participants (5)
-
Carlos E. R.
-
Jordi Espasa Clofent
-
jose maria
-
Rafa Grimán
-
Victor Hugo dos Santos