Re: Dudas generales acerca de progracion en linux.
El Martes, 12 de abril de 2016 23:41:51 Ala de Dragón escribió: > >(...) > > Hola :D > Os contesto un poco a todos, mil gracias por vuestros aportes. Quien > me conoce sabe que investigare cada uno de ellos. > > La idea es por ejemplo, no tener que recompilar mi juego favorito cada > vez que actualizo debian, el cliente standar resulta que no se puede > compilar mas alla de debian 7 (pero el desarrollador del juego > proporciona un binario que corre sobre cualquier chisme que tenga > linux, openGL y aceleracion 3D) > > Igual me ocurre con otros tantos programas que tenia compilados. > > Son programas sencillos corriendo en un entorno domestico, no creo que > mi computadora domestica sea muy segura hoy en dia, si la tarea es > firmar digitalmente codigo fuente. > Pero considero que para leer esta lista, almacenar mis fotos, y > echarme unas partidas es mas que suficiente. > El volumen de la aplicacion no me importa si ocupa 2 megas o 20 gigas > disco duro me sobra. > > La cuestion que me surge tras leeros es que si se puede hacer un > chroot para compilar en deb7 para deb8, ¿se puede hacer un chroot > sobre mi vieja particion de deb7 y correr alli mis viejas aplicaciones > desde deb8/9.? > Yo tenía entornos de desarrollo en chroot, para no 'ensuciar' mi distribución principal con librerias y demás herramientas. Es perfectamente posible utilizarlos como tu pretendes. Hoy en día, no obstante, personalmente considero mas cómodo lxc. Es muy fácil de utilizar, y tiene plantillas predefinidas para instalar con un solo comando la distribución Debian que quieras, así como otras muchas. Si lo que pretendes es ejecutar programas sueltos, te recomiendo chroot. Si lo que quieres es emular lo mas fielmente posible un sistema completo, con sus demonios al inicio y demás cosas, lxc es lo tuyo. En cualquier caso, son necesarios ciertos pasos adicionales, como permitir conexiones X remotas por TCP para poder utilizar el sistema gráfico. Lo único de lo que no estoy seguro es de que puedas ejecutar juegos. No se si la aceleración openGL funciona sobre TCP, sin memória compartida. Como último recursos, podrias intentar virtualizar; no se como anda el tema de la aceleración gráfica sobre entornos virtualizados. Échale un ojo a VirtualBox, Xen, o QEMU. Una pregunta tonta. ¿ Has intentado copiar el programa que quieres utilizar en /usr/local/bin y ejecutarlo ? ¿ Porqué no funciona ? ¿ Que fallos da ? Si el programa que quieres ejecutar está en paquete .deb, puedes extraerlo 'a mano' bajo /usr/local y mediante enlaces hacer que funcione, instalando los paquetes que necesite, pasando por alto todo lo que el paquete diga que necesita. Un ejemplo: en mi servidor casero, tengo instalado cierto paquete privativo que depende de libc6-i386. Sin embargo, en mi sistema, no hay instalado ningún paquete de esta arquitectura. El paquete en cuestión, para soportar ciertos modelos de servidor, require ciertas utilidades que solo están disponibles para i386. Comprobe las dependencias del binario en cuestión con ldd, y resulta que lo que yo uso no requiere de esas dependencias. Sencillamente copié el binario en /usr/local/bin, y desinstalé el paquete y sus dependencias. Resultado: el binario funciona, y no tengo paquetes i386 instalados. Contras: el binario no se actualiza a nuevas versiones de forma automática; es decir, pierdo la ventaja de los paquetes. De todas formas, hace mas de 2 años que no se actualiza en su página original ... > > En caso contrario lo mas parecido seria utilizar los programas y > libreiras que utiliza la version 7. Voy a husmear dlopen a ver que es. > dlopen es la función de biblioteca que carga librerías dinámicas. Para usarla hay que modificar el código fuente de los programas, que creo que no es lo que estás buscando. Hay que modificar MUCHO los programas. Ya nos contarás.
Re: Dudas generales acerca de progracion en linux.
El Lunes, 11 de abril de 2016 21:50:39 Ala de Dragón escribió: > Hola :D > > Ando un par de días preguntándome acerca de unas dudas en cuanto a compilar. > > Supongamos que tengo un sistema, llamémosle debian 7, que tendrá lo > necesario para compilar un programa. Por ejemplo firefox. > Si lo compilo desde las fuentes lo hago con las versiones de lasa > librerías y programas que están instaladas en mi computadora. Con lo > que en un debian 8 no funcionara bien. > entonces, ¿como se hace para compilar un programa, empaquetarlo en un > tar y hacer que funcione en cualquier debian? > Es simple curiosidad > > Salu2s > > :) Como ya te han respondido, eso es poco menos que imposible. Las combinaciones de ( librerias + programas + archivos auxiliares ) son demasiadas. Si quieres ALGO mas de portabilidad, puedes utilizar un lenguaje interpretado, como perl o incluso bash, que te darán algo más de juego. En Debian, python puede no estar instalado, pero bash y perl lo están siempre, porque el propio sistema de paquetes de Debian los usa. Hay (o hubo) intentos de crear aplicaciones auto-empaquetadas, tipo archivo .ISO, y que el kernel ejecuta con ayuda de binfmt. Registras el controlador adecuado, y puedes empaquetar lo que quieras y lanzarlo como quieras. También puedes utilizar aplicaciones auto-descomprimibles; son scripts de Bash que tienen 'embebido' un archivo .tar, que se descromprime al ejecutar el script. Creo que los paquetes originales de los drivers privativos de ATI utilizaban algo así; hay un paquete que incluye la utilidad, pero no recuerdo el nombre. Ya rizando el rizo, puedes utilizar docker. Las últimas 3 soluciones son estáticas; una vez empaquetado el código, es independiente del sistema en el que se ejecuta. No aprovechas posibles soluciones a errores ni actualizaciones del sistema. Por último, pasando de todo lo anterior, puedes enlazar tu código con una pequeña parte estática, y comprobar a mano la presencia o ausencia de las librerias que necesites (y sus versiones), y cargarlas a mano con 'dlopen'. Suerte con eso ;-) Saludos.
Re: Portal cautivo ZeroShell
El Martes, 5 de abril de 2016 14:34:14 JAP escribió: > El 05/04/16 a las 14:04, Juan José López escribió: > > El Martes, 5 de abril de 2016 11:09:16 JAP escribió: > > > > Llego tarde a la conversación, así que no se de que va el resto. Solo un > > > > apunte: > >> (Nota mental: averiguar cómo identificarme ante ZeroShell con un script > >> en el arranque en vez de un navegador, en forma similar a lo que hace > >> cntlm.sourceforge.net). > > > > Supongo que será un 'portal cautivo' de esos; échale un vistazo a > > > > http://www.vicente-navarro.com/blog/2013/02/28/configurando-routers-domest > > icos-desde-la-linea-de-comandos-con-wget/ > > > > wget y un script en /etc/network/if-up.d/ te podría servir. > > Antes que nada, cambio el "Asunto", dado que esto no tiene que ver con > el hilo original. > > Sí, Juan José, se trata que en el trabajo tengo un portal cautivo > controlado por un ZeroShell (http://www.zeroshell.org/) que me obliga a > identificarme con una página de "log-on" mediante un navegador WEB. > > Ayer se me dio una situación risible, si no fuera porque terminé con un > dolor de cabeza. > Estaba haciendo la actualización de todos los lunes a "jessie", que > dicho sea de paso esta semana estuvo bastante pesadita, y se cortó el > suministro eléctrico unos momento, quedando a medio actualizar. > Lo "gracioso" del tema es que me quedé sin consola gráfica, y no podía > identificarme en el portal cautivo ni con lynx ni con links. > Por ende, no pude continuar con el proceso. > La solución: me llevé la máquina a casa y lo arreglé. > > Lo único que encontré del tema es un script en python de este sitio > http://www.zeroshell.org/forum/viewtopic.php?t=1109 > Bajé los primeros, y no logro hacerlo funcionar, y no entiendo mucho de > python para arreglarlo, considerando que es "viejo". > Los más "nuevos" no puedo bajarlos, pues el sitio http://aljufry.org > parecería que está fuera de línea. > > Con lo que me has pasado, lo estudiaré y veré si puedo de alguna manera > habilitar el paso por el portal cautivo en forma automática y modo > consola, para evitar otros "inconvenientes" de los que solemos trastear > con la pantalla en blanco y negro. > > Muchas gracias. > > JAP Ok. Ya se sobre que era la conversación :-) Si tienes problemas habituales con el suministro eléctrico, un pequeño 'trick'. No actualices de golpe; primero descarga los paquetes con 'apt-get -d upgrade', y solo cuando termine de descargar haz la actualización real con 'apt-get upgrade'. En caso de fallo de corriente, por lo menos tendrás todos los paquetes ya descargados y podras continuar la actualización sin problemas. Te puedes hacer un pequeño script que lo automatice; o incluso un alias en Bash. Lo del portal cautivo es simple, si tienes unos conocimientos básicos de html. Miras el código fuente de la página, y en algún lugar estará el formulario que se usa, con la página real a la que se mandan los datos junto con las variables. Te montas un pequeño script en /etc/network/if-up.d/ que compruebe si estas conectado a la red del trabajo (por la IP, o con algún comando que lo compruebe, por ejemplo bajando la página web de autorización de ZeroShell ), y, si estas efectivamente en el trabajo, que lance WGET con los argumentos y el URL necesario. Así dicho parece más complicado de lo que en realidad es ;-) ya verás que no es para tanto. Yo tenía algo similar para obtener mi IP real desde la página de mi router, y actualizar mi cuenta de DynDns (cuando era gratis). Saludos.
Re: Problemas con DHCP corporativo [¿SOLUCIONADO?]
El Martes, 5 de abril de 2016 11:09:16 JAP escribió: Llego tarde a la conversación, así que no se de que va el resto. Solo un apunte: > > (Nota mental: averiguar cómo identificarme ante ZeroShell con un script > en el arranque en vez de un navegador, en forma similar a lo que hace > cntlm.sourceforge.net). > Supongo que será un 'portal cautivo' de esos; échale un vistazo a http://www.vicente-navarro.com/blog/2013/02/28/configurando-routers-domesticos-desde-la-linea-de-comandos-con-wget/ wget y un script en /etc/network/if-up.d/ te podría servir.
Segmentation faul en akregator
Hola listeros. Después de varios años, he vuelto a Debian (Jessie), con KDE como escritorio. La aplicación Akregator se cierra al salir. Funciona todo correctamente, y el fallo no aparenta tener ninguna repercusión, excepto el mensaje del manejador de fallos de KDE cada vez que la cierro. Exactamente, el error es el siguiente: akregator PID: 2808 Señal: Segmentation fault (11) Hora: 05-04-16 13:14:38 El error se produce siempre, tanto si he actualizado los canales como si no. He limpiado toda la configuración de mi usuario ( todos los archivos ocultos de mi directorio , excepto algunos que conservo, como el .config/mc ). El error se repite, desde el primer uso de la aplicación. Todos los paquetes están actualizados a fecha de hoy. En Google aparecen multiples informes de este fallo, pero todos están cerrados y el error (supuestamente) subsanado. Además, son de hace un par de años (2014 el mas reciente que he observado). No hay mas errores en KDE-PIM ni KDE en general. Es el único error que he tenido. ¿ Alguna sugerencia ?
Re: herramientas para proceso de archivos por lineas [ERA: SIN ASUNTO]
El Sábado 04 octubre 2014 09:58:11 Debia Linux escribió: Esto funciona bien, siempre que haya 5 intereses, pero cuando deja de haber uno, es como si le dijera a egrep que busque todas las lineas que contengan una letra... Trate con un bucle para que cuando no hubiera respuesta, enviara la informacion por mail de los intereses que si fueron ingresados. Pero me enrede tanto que ya no supe ni que ni como (por eso no posteo el bucle). Intente hacer una Estructura de Control pero mi seso ya no dio para mas y cai dormido despues de tantas horas por tratar de resolver el problema. ¿Alguna idea? Hay mejores herramientas para eso, que te facilitaran bastante la tarea: paquetes gawk o mawk (suele haber instalado por lo menos 1). paquete sgrep. Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3970898.8KvrVzpXei@danika
Re: Problemas en Debian Wheezy con conky
El Sábado 04 octubre 2014 11:04:30 Frederit Mogollon escribió: Gracias Camaleón, en alguno de los link que colocaste hacían referencia a otro en el que ocurría algo similar, y era porque se estaban usando muchas fuentes distintas en la sección TEXTO del conkyrc. Así que opté por ser tajante y usé una sola fuente para todo, variando en algunos casos el tamaño de la misma, y funcionó, ya no se cierra. :) Ahora otro problemilla con el bendito conky... Al iniciar el sistema, conky se ejecuta por duplicado (uso una sola instancia), es decir, mismo nombre y ruta, pero diferente PID. Siguiendo los mismos links que amablemente Camaleón puso en la respuesta anterior, y corroborando lo que ya había leído en búsquedas previas en la www, borro las sesiones y reinicio guardando sesión (uso Debian Wheezy con Xfce 4.8). Pero sigue iniciando conky duplicado...!!o.O Usé un script anti fork de conky indicado por éste sitio: http://hackingthesystem4fun.blogspot.com/2012/05/script-inicio-de-conky-mejo rado-para.html y aún así el sistema arranca con el conky duplicado. No sé mucho de programación, y no hallo solución en la internet, no sé si es que no sé buscar. Que opinan los listeros...? fdm Mira en las opciones de inicio de sesión - recuperar la sesión anterior. (mas o menos, no recuerdo exacto). Intenta iniciar con una sesión vacía. Los autoarranques de XFCE creó recordar que están en $HOME/.config/autoexec. Mira por su hubiera mas de un archivo .desktop que lance conky. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431502.fUmCVQmBnO@danika
[OT?] Normas de la lista
Hola listeros. Es un tema que suele salir muy a menudo, que si un determinado tema es o no OT (Off-Topic). Es un tema que nunca me ha quedado lo suficientemente claro. Realmente, ¿ que es un OT ? Copiando de https://wiki.debian.org/es/NormasLista La lista debian-user-spanish se ha creado para: Support for Debian users that speak Spanish. (High-volume mailing list.) Es decir, es la lista de ayuda a usuarios de Debian en castellano. Esta definición, a mi humilde entender, es extremadamente ambigua. * ¿ Solo se debe considerar On-Topic temas relacionados exclusivamente con la distribución Debian ? En este caso, destilando la pregunta, tan solo se deberían entender como correctas las consultas sobre temas únicos en Debian: + El sistema de paquetería (dpkg-deb, dpkg, apt-get, aptitude, las bases de datos implicadas, sus configuraciones, ... ). + Los mecanismos de inicio y apagado ( /etc/init.d, /etc/networking/interfaces, ... ). + Temas relativos a los propios paquetes: bugs, modificación de la localización de los archivos de configuración, roturas del sistema debido a actualizaciones, ... + Otras cuestiones similares que distingan a Debian de cualquier otra distribución. * ¿ Se pueden considerar On-Topic temas relativos a la CONFIGURACIÓN de paquetes PRESENTES en Debian ? Aquí se pierde la exclusividad, salvo contadas ocasiones en las que el paquete es 'customizado' por los mantenedores Debian para adecuarlo a sus propias políticas (ubicación de ciertos archivos, nombres de ciertos comandos, ... ). - Se aceptan consultas sobre ARCHIVOS DE CONFIGURACIÓN; es decir, consultas que involucren un determinado archivo de texto, sea cual sea su ubicación. - La configuración de los programas suele estar bien documentada en los propios programas, o en sus páginas WEB, y no suele depender de la distribución, excepción hecha de los casos mencionados antes. - Se aceptan consultas sobre TODOS LOS PROGRAMAS, no solos aquellos que involucren a determinados demonios del sistema; es decir, es lo mismo que la consulta verse sobre un escritorio (kde, gnome, xfce) que sobre ciertos servicios muy usados en servidores (postfix, slapd, samba). - ¿ Un script (guión ejecutable por un determinado programa) es un archivo de configuración ? * ¿ Se pueden considerar On-Topic temas relativos al uso de paquetes PRESENTES en Debian ? El uso de los programas suele ser 'Universal', entendiendo como tal que no depende de la distribución ni, en muchos casos, del propio sistema operativo (como siempre, hay excepciones). - Por el punto anterior, no se puede considerar relativo a Debian. Ni siquiera a Linux (como siempre, hay excepciones). - Las variaciones entre distribuciones suelen ser mínimas; es mucho más notable la diferencia entre las máquinas que ejecutan el programa y las propias opciones de configuración que cada usuario establezca. - ¿ La configuración de un programa mediante un cuadro de diálogo mostrado por el mismo se puede considerar configuración o uso ? - ¿ Un script (guión ejecutable por un determinado programa) es un modo de uso ? * ¿ Se pueden considerar On-Topic temas relativos a la infraestructura de la propia Debian ? Esporádicamente surgen algún que otro mensaje sobre ciertos servidores caídos, o problemas legales en cierto país, o algún tema similar. - No suelen interesar a usuarios 'de a pié', poco involucrados en temas internos. - No suelen ser preguntas. Más podrían ser considerados como 'notificaciones'. * ¿ Se pueden considerar On-Topic temas relativos a la infraestructura de soporte de la propia lista ? Es una concreción del apartado anterior. He de hacer notas que algunas veces es difícil saber, por el que realiza la pregunta, si el tema es exclusivo de Debian o no. Como he comentado, el uso de los programas suele ser 'Universal'; pero, ¿ y si un determinado programa tiene como tecla por defecto Alt+Ctrl+F1 para una determinada tarea ? En sistemas Gúindo$, funciona bien. Pero un nuevo usuario Debian (o Linux en general) puede mandar un mensaje diciendo que Debian cierra todas sus ventanas cuando imprime (es ficticio, pero mi hija entraría en ese perfil). Yo mismo he realizado consultas sobre temas que estoy plenamente seguro no son exclusivos a Debian; es decir, podría haber enviado la consulta a la lista de cualquier otra distribución y las respuestas podrían haber sido perfectamente aplicables sin realizar la más mínima modificación. Es que he notado que no siempre se trata igual el mensaje (ni al emisor). Algunas preguntas reciben el típico esto deberías de haberlo marcado como OT ... , mientras que otras han sido perfectamente contestadas; en muchos casos, me ha resultado difícil establecer una diferencia entre las consultas, salvo el hecho del programa implicado. Pedazo de rollo que acabo de soltar xD. Hala, ya esta. Saludos.
Re: [OT?] Normas de la lista
El Thu, 2 Oct 2014 15:56:59 +0200 fernando sainz fernandojose.sa...@gmail.com escribió: El día 2 de octubre de 2014, 15:42, Camaleón noela...@gmail.com escribió: El Thu, 02 Oct 2014 10:38:51 +0200, Juan José López escribió: Hola listeros. Es un tema que suele salir muy a menudo, que si un determinado tema es o no OT (Off-Topic). Es un tema que nunca me ha quedado lo suficientemente claro. Realmente, ¿ que es un OT ? (...) Todo lo que no tenga que ver con Debian. Sí, es una definición ambigua por lo que aplicar el sentido común es la mejor forma de tratar ese tema en una lista de correo sin olvidar que por encima de los OT está el respeto y la libertad de los demás. Esta es una lista abierta por lo que hay spam, hay OT, hay html, hay respuestas que van dirigidas al remitente en lugar de ir a la lista, hay errores y aciertos, vamos, hay de todo. Si algo no te gusta, no lo leas y listo :-) ¿Has oído hablar del Gato de Schrödinger? Saludos, -- Camaleón ¿ Ese que hace poco fotografiaron sin fotografiarlo ? http://vozpopuli.com/next/48461-mas-dificil-todavia-como-fotografiar-al-gato-de-schr-dinger-sin-verlo -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141002165158.66e3697e@danika.localdomain
Re: [OT?] Normas de la lista
El Thu, 2 Oct 2014 11:07:54 +0200 fernando sainz fernandojose.sa...@gmail.com escribió: Hola. Cada uno tenemos nuestro criterio sobre lo que es OT o no. De hecho en las normas por ejemplo se dice que hay algunos OT que son comúnmente aceptados, como preguntas sobre scripting. La verdad que lo que más molesta es que se hagan preguntas que son fácilmente resolubles usando un buscador o leyendo simplemente el manual. Otra cosa que es muy molesta es que algunos OT se convierten en una especie de chat entre dos o tres usuarios interesados en ese tema en particular despreciando además al resto de la gente a la que están molestando con su OT. Luego están los OT que se convierten en una ristra de descalificaciones insultos, etc... Por norma, si un usuario manda un OT esporádicamente y lo marca como tal, no será reprendido. Si no se marca como tal, es más probable que alguno advierta que se trata de un OT. Según mi criterio, la forma correcta de actuar ante un OT es solo responder a la lista si realmente vamos a aportar algo de interés a la misma, si no se debería contestar al privado. La idea es que los mensajes a la lista, que se guardan y pueden ser consultados a posteriori, sirvan para resolver los problemas que podamos encontrarnos y que ya han sido resueltos antes. Por eso lo ideal es que los hilos de las respuestas sean lo mas limpios posibles. Es muy desagradable buscar una solución a un problema y encontrar un hilo de 60 mensajes en los que no se aporta nada sobre el tema buscado. En fin, que no te rompas la cabeza, que creo que con todo lo que has escrito eres mas o menos consciente de lo que es un OT y como decían por ahí, en caso de duda pones el [OT] en el asunto y no serás muy reprendido. OJO: Los OT no son bienvenidos en la lista... S2. A lo que venía toda la parrafada de antes es que considero el tema OT una inutilidad; depende tanto del que envía como del que responde; es prácticamente imposible aplicarlo a una lista como esta, con preguntas de todo tipo y acceso público; y, por lo tanto, no se puede establecer una norma estricta. O, mejor dicho, no una que puntualice hasta los extremos que se ven por aquí de vez en cuando. Y, como les digo a mis hijos, en plena edad de hacer lo que les da la real gana: - Una norma es una norma porque se tiene que cumplir SIEMPRE. Si no se hace así, deja de ser una norma y se convierte en un CAPRICHO. Considero infinitamente más importante especificar claramente el asunto (si, se que también está en las normas de la lista) que marcar o no marcar como OT. Sin hablar del mensaje de respuesta que duda sobre si es o no OT, o aquel que se queja porque una vez se quejaron de el, ... En fin, voy a dejarlo ya. Si marcar o no OT es irrelevante, el hecho de opinar sobre ello es más irrelevante aún, si cabe. Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141002172440.28ec6ab0@danika.localdomain
Re: Sincronizar /var/www de tres servidores script en debian
El Wed, 1 Oct 2014 10:09:24 +0200 Maykel Franco maykeldeb...@gmail.com escribió: El día 1 de octubre de 2014, 9:08, C. L. Martinez carlopm...@gmail.com escribió: 2014-09-30 19:42 GMT+00:00 Maykel Franco maykeldeb...@gmail.com: Gracias por contestar. No me gustan los sistemas distribuidos o compartidos para este fin. Pierden peefoemance. Y concretamente /var/www necesito que se sirva rápido. Aparte de usar sistema de cache opcode como xcache y similares. Además necesitaría otra máquina en el caso de iscsi. Ocfs2 o gfs lo he usado para drbd activo/activo y sinceramente no me fio. Me gusta esta opción, lsyncd. No lo he probado nunca pero se ejecuta a nivel de demonio y se sincronizan solo los cambios. En /var/www se sincroniza todo menos los los, que con uníson los tenia excluidos. Solo sincronizaba el contenido estático, que no cambia. Voy a mirar el enlace que me has pasado. Gracias. Uhmm .. No me imagino porque no te fias de DRBD o OCFS2 o GFS2. Yo los llevo utilizando durante años en clusters de producción (web, correo, BBDD, etc..) y van finos finos ... Y siempre es mejor utilizar algo así que tirar de scripts, porque siempre pueden fallar muchas cosas y no tienes la info actualizada en tiempo real (otra cosa es que necesites que esté replicada en tiempo real). De hecho aparte de esas opciones tienes otra más: GlusterFS. Yo me las miraría antes de implementar nada basado en scripts ... Y si no terminan de convencerte tienes otra más: DragonflyBSD+HAST o FreeBSD+HAST, otras pequeña maravillas :)) Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caejqa5kwjmd-aftvr9534ae3_du0txl2ovwa+yxbqayhhvg...@mail.gmail.com Porque no necesito que los ficheros estén sincronizados en tiempo real, es un contenido estático, que se cambia de higos a ramos, y sólo necesito que se sincronice cuando se realiza un cambio en un fichero o una subida de producción... No veo necesario montar sistemas de archivos distribuidos. Si quisiera un samba activo/activo pues todavía. Que lo he montado en otra empresa, con drbd y cuando reiniciabas las máquinas eso era una lotería con el famoso split-brain. Además sino recuerdo mal, drbd sólo permite 2 servidores de replica, es un raid1 TCP/IP y un tercer servidor de backup. En el caso de ocfs de oracle, gfs2 de red hat, no lo sé imagion que soportarán ḿas de 2, al igual que glusterfs. Gracias por la respuesta. Saludos. Prueba con incron. Es el que yo utilizo para sincronizar archivos entre varios chroots. Cada vez que un archivo MODIFICADO se cierra, te permite ejecutar un comando. Dependiendo de como lo tengas montado, puedes hacer rsync, scp, un simple cp, ... puedes montarte un mini-script que lo copie y te avise por correo ... No es en tiempo real, pero casi. Ejecuta DESPUÉS DE CERRAR EL ARCHIVO MODIFICADO, así que no usa ancho de banda durante las modificaciones en sí. Y no depende de programaciones temporales, por lo que la sincronización es casi perfecta. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141001115824.54aaf5d6@danika.localdomain
Re: Sincronizar /var/www de tres servidores script en debian
El Wed, 1 Oct 2014 12:11:19 +0200 Maykel Franco maykeldeb...@gmail.com escribió: El día 1 de octubre de 2014, 11:58, Juan José López juanjolistascor...@gmail.com escribió: El Wed, 1 Oct 2014 10:09:24 +0200 Maykel Franco maykeldeb...@gmail.com escribió: El día 1 de octubre de 2014, 9:08, C. L. Martinez carlopm...@gmail.com escribió: 2014-09-30 19:42 GMT+00:00 Maykel Franco maykeldeb...@gmail.com: Gracias por contestar. No me gustan los sistemas distribuidos o compartidos para este fin. Pierden peefoemance. Y concretamente /var/www necesito que se sirva rápido. Aparte de usar sistema de cache opcode como xcache y similares. Además necesitaría otra máquina en el caso de iscsi. Ocfs2 o gfs lo he usado para drbd activo/activo y sinceramente no me fio. Me gusta esta opción, lsyncd. No lo he probado nunca pero se ejecuta a nivel de demonio y se sincronizan solo los cambios. En /var/www se sincroniza todo menos los los, que con uníson los tenia excluidos. Solo sincronizaba el contenido estático, que no cambia. Voy a mirar el enlace que me has pasado. Gracias. Uhmm .. No me imagino porque no te fias de DRBD o OCFS2 o GFS2. Yo los llevo utilizando durante años en clusters de producción (web, correo, BBDD, etc..) y van finos finos ... Y siempre es mejor utilizar algo así que tirar de scripts, porque siempre pueden fallar muchas cosas y no tienes la info actualizada en tiempo real (otra cosa es que necesites que esté replicada en tiempo real). De hecho aparte de esas opciones tienes otra más: GlusterFS. Yo me las miraría antes de implementar nada basado en scripts ... Y si no terminan de convencerte tienes otra más: DragonflyBSD+HAST o FreeBSD+HAST, otras pequeña maravillas :)) Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caejqa5kwjmd-aftvr9534ae3_du0txl2ovwa+yxbqayhhvg...@mail.gmail.com Porque no necesito que los ficheros estén sincronizados en tiempo real, es un contenido estático, que se cambia de higos a ramos, y sólo necesito que se sincronice cuando se realiza un cambio en un fichero o una subida de producción... No veo necesario montar sistemas de archivos distribuidos. Si quisiera un samba activo/activo pues todavía. Que lo he montado en otra empresa, con drbd y cuando reiniciabas las máquinas eso era una lotería con el famoso split-brain. Además sino recuerdo mal, drbd sólo permite 2 servidores de replica, es un raid1 TCP/IP y un tercer servidor de backup. En el caso de ocfs de oracle, gfs2 de red hat, no lo sé imagion que soportarán ḿas de 2, al igual que glusterfs. Gracias por la respuesta. Saludos. Prueba con incron. Es el que yo utilizo para sincronizar archivos entre varios chroots. Cada vez que un archivo MODIFICADO se cierra, te permite ejecutar un comando. Dependiendo de como lo tengas montado, puedes hacer rsync, scp, un simple cp, ... puedes montarte un mini-script que lo copie y te avise por correo ... No es en tiempo real, pero casi. Ejecuta DESPUÉS DE CERRAR EL ARCHIVO MODIFICADO, así que no usa ancho de banda durante las modificaciones en sí. Y no depende de programaciones temporales, por lo que la sincronización es casi perfecta. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141001115824.54aaf5d6@danika.localdomain Que bueno... Muchas gracias, a probar se a dicho!! Gracias nuevamente a todos, un placer esta lista lo que se aprende. Saludos. Nota aclaratoria: Su propia funcionalidad es su mayor inconveniente. Se limita a ejecutar órdenes al realizar ciertas acciones con los archivos; no 'sincroniza' nada. En otras palabras; si los archivos no son ya idénticos, incrond no ejecutará la orden correspondiente hasta que no ocurra algún evento de los indicados. Si la orden falla por cualquier motivo, incrond no volverá a hacer nada hasta que vuelva a ocurrir el evento lanzador. Yo los sincronizo al iniciar el equipo, desde rc.local. Como son chroots en el mismo equipo, un rsync me va de perlas. Si ya están sincronizados, no molesta. Y, si no lo están, me aseguro de que comiencen en un 'estado conocido', que dicen los que saben. Manejo pocos archivos, y los tengo incluidos directamente. Si manejas muchos, te recomendaria un script que lea directamente desde /etc/incron.d/ y ejecute la orden. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141001125153.02fc2174@danika.localdomain
Re: Saber que paquetes dependen de un determinado repositorio
El Thu, 25 Sep 2014 12:38:02 -0300 Mauro Antivero mauro.antiv...@gmail.com escribió: Estimados, tengo un par de equipos corriendo Debian Squeeze con los repositorios Backports y Proposed Updates activados. Me gustaría saber si es posible determinar que paquetes instalados dependen de estos repositorios, de manera tal de saber si puedo desactivarlos tranquilamente o no. Es posible esto que deseo hacer? Una posible solución es comentar en sources.list un repositorio cualquiera. Si alguno de los paquetes de ese repositorio se encuentra instalado, la herramienta 'aptitude' te lo mostrará bajo la rama 'Paquetes obsoletos o creados localmente'. Desde ahí los puedes desinstalar. Descomentas ese repositorio y comentas otro, saliendo y volviendo a ejecutar 'aptitude' en cada vez. O los dejas comentados, si no los necesitas o has desinstalado los paquetes. Saludos y muchas gracias, Mauro. Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140925191959.2594b23f@danika.localdomain
Re: instalar guake
El Mon, 22 Sep 2014 21:30:09 +0200 Etemenanki etemena...@openmailbox.org escribió: Adrià wrote: Hola, no conocía la herramienta, y a raíz de este hilo me he aficionado a ella :-) On Sun, Sep 21, 2014 at 04:45:13PM -0430, Yang wrote: ademas q puedo ver que dice algo de el demnio D-Bus no esta en ejecucion como puedo ejecutarlo?? Con /etc/init.d/dbus start lo podrás arrancar si no lo está. De todas formas, especifica si estás en modo gráfico y qué versión usas (stable, etc). richard@stallman ~/# service dbus start ← Esto es más práctico ;-) Por otro lado, de los terminales desplegables, Yakuake es el más potente y configurable. Entre otras cosas permite skins, partir o dividir el terminal en varios trozos (al estilo terminator), etc... Otra cosa interesante es que permite usar las características mediante atajos de teclado y personalizarlos. Agrandar y reducir el tamaño, mover las pestañas de lugar, cambiar el foco, moverte por los terminales partidos, etc... Usar el mouse es perder el tiempo. :-D Saludos, Yakuake Rox! Yo probé tilda, bastante bueno pero con un par de fallos en los iconos de los botones del dialogo de configuración. Actualmente uso STJerm. Creo que es el que meno recursos consume de los 'terminales desplegables'; eso sí, no permite reconfigurar al vuelo. Cambiando un poco de tema, para sesiones en segundo plano usaba dtach; no se puede comparar con screen, pero para ir dejando sesiones abiertas sin muchas complicaciones, es perfecto. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014092723.131fff10@danika.localdomain
Era: Escritorio mas limpio
El Sat, 20 Sep 2014 05:33:01 +0200 Etemenanki etemena...@openmailbox.org escribió: Si instalas algo con un interfaz y ese algo luego lo desinstalas con otro, eso otro interfaz no tiene los datos de instalación en sus registros y ahí empieza el problema de que no se desinstalen bien los paquetes. Desterrando mitos que arrastra el pobre e incomprendido Aptitude por blogs y redes sociales incoming... :-D No estoy de acuerdo. Suelo utilizar aptitude como norma; ocasionalmente apt-get; y después de desinstalar paquetes 'para pruebas', paso deborphan. Ídem en lo de aptitude. apt-get y deborphan no los suelo usar, nada más alguna vez por curiosidad. aptitude es mi centro de paquetes, y no entiendo como es que no ha desterrado ya a 'apt-get' (excepto usos ocasionales). La facilidad que da para examinar paquetes y sus dependencias es tremenda. Para mantener un entorno mínimo, es tremendamente práctica. Miras un paquete, entras en sus dependencias, y buscas paquetes con dependencias comunes que se adapten a las tareas que quieres. apt-get y deborphan no tienen una 'base de datos' propia. Se limitan a utilizar la base de datos global de dpkg, que a su vez se limita a indicar los paquetes presentes en el sistema y sus dependencias. deborphan ni idea por que no lo uso, apt-get no tiene una base propia, pero usa la de APT, que a su vez usa la de dpkg. deborphan instala una utilidad llamada 'orphaner'. Se limita a buscar paquetes que no son utilizados por ningún otro, lo que permite desinstalarlos. A diferencia de 'aptitude', no utiliza datos propios. 'aptitude' recuerda los paquetes que el usuario instaló el mismo (no como dependencias de otros), y los mantiene en el sistema. 'deborphan' no tiene en cuenta como se instaló el paquete; si ningúno depende de él, lo propone para desinstalar. Por ejemplo, si instalas un paquete para alguna tarea puntual, y luego olvidas desinstalarlo, 'deborphan' te lo muestra como paquete susceptible de eliminar. Otro uso: algunos paquetes dependen de una de entre varias opciones; 'phonon' (de KDE) depende de 'phonon-backend-vlc' o de 'phonon-backend-gstreamer'. En mi caso, suelo instalar primero el backend. Si lo hago con 'aptitude' y selecciono 'phonon-backend-vlc', cuando desinstale 'phonon' me mantiene el backend, porque lo instale yo (no fue automatico). deborphan no tiene en cuenta eso, y siempre me propondra el backend como paquete a eliminar. Aquí muestro algunas localizaciones para confirmarlo: aptitude /var/log/aptitude /var/lib/aptitude/pkgstates apt-get que como no tiene base propia usa la de APT /var/log/apt/history.log + term.log /var/lib/apt/... dpkg (herramienta principal también sus registros) /var/log/dkpg.log /var/lib/dpkg/... Estamos de acuerdo en que dpkg es la herramienta base (herramienta de bajo nivel), APT es una biblioteca considerada un frontend de dpkg (herramienta de alto nivel) y apt-get, aptitude, etc... son a su vez frontends de APT (más alto nivel aún xD). aptitude si tiene datos propios, pero tan solo se percata de paquetes ELIMINADOS; es decir, si recuerda que un paquete estaba instalado y ya no lo está, propondrá su instalación. Solo propondrá desinstalar un paquete, sea cual sea el método de instalación, si se ha configurado para eliminar paquetes no utilizados por otros. Aptitude se percata de más cosas que solamente de los paquetes eliminados, mira por cada paquete los diferentes estados que hay en su base de datos: /var/lib/aptitude/pkgstates Package: linux-source-3.14 Architecture: amd64 Unseen: yes State: 1 Dselect-State: 1 Remove-Reason: 0 De cualquier forma, todos los front-ends (que eso son) terminan llamando a dpkg con las opciones pertinentes; es este el que realiza el verdadero trabajo. La verdad es que el hecho de que 'aptitude' y 'apt-get' guarden bases de datos separadas en una mala solución, desde el punto de vista de mantener un sistema limpio de paquetes no usados. 'autoclean' de uno y otro, según eso, borran paquetes distintos. OJO, que no se esto a ciencia cierta, pero es lo que se desprende de su organización. Cierto, el camino completo es, frontends → APT → dpkg. Eso implica que no quedan paquetes 'mal instalados' ni dependencias incumplidas, instalemos como instalemos. dpkg se encarga de ello. Yo no he dicho que haya problemas al instalar, ni que queden los programas mal instalados, ni que queden dependencias incumplidas por mezclar los frontends. Lo que he dicho es que los problemas vienen al desinstalar. Que te pueden quedar resquicios por ahí, pero nada que un buen administrador no sepa resolver, claro está. Es lo que sobrentendí referente a la frase 'y ahí empieza el problema de que no se desinstalen bien los paquetes'. No confundir lo anterior con la diferencia entre 'desinstalar' y 'purgar'. Lo primero deja los
Re: XFCE 4.8
El Sat, 20 Sep 2014 15:25:57 -0300 Alexis Saucedo alexissauc...@gmail.com escribió: buenas tardes para todos, voy a hacerles una consulta sobre el entorno de escritorio XFCE 4.8, cuando ingreso al mismo menu de aplicaciones/configuracion no me aperece en ninguna oprion Hardware, y cuando ingreso a administrador de configuracion tampoco, salguien sabe si este viene por default asi (no creo) o debo activar algo para poder ver todas las configuraciones?, se que se trata de una info muy basica pero busque en la web y no encontre nada realcionado a eso. XFCE no tiene ninguna opción 'Hardware'. Como ya habrás observado, hay na para el teclado, otra para el ratón/dispositivos de entrada, otra para la pantalla, y otra para la gestión de energía Si lo que quieres en una vistazo a los componentes hardware de tu equipo (sin modificar nada), tienes que instalar algún paquete extra; prueba con hardinfo, que usa Gtk2. Da más detalles si buscas modificar algo concreto. Saludos y gracias! Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140920212913.039c918a@danika.localdomain
Re: Escritorio mas limpio
El Fri, 19 Sep 2014 22:04:09 +0200 Etemenanki etemena...@openmailbox.org escribió: Un consejo a los novatos, hay que elegir un interfaz forever en cada instalación si no queréis acabar con un buen lío en la gestión de la paquetería, puesto que cada interfaz tiene su propia base de datos. Si instalas algo con un interfaz y ese algo luego lo desinstalas con otro, eso otro interfaz no tiene los datos de instalación en sus registros y ahí empieza el problema de que no se desinstalen bien los paquetes. Desterrando mitos que arrastra el pobre e incomprendido Aptitude por blogs y redes sociales incoming... :-D No estoy de acuerdo. Suelo utilizar aptitude como norma; ocasionalmente apt-get; y después de desinstalar paquetes 'para pruebas', paso deborphan. apt-get y deborphan no tienen una 'base de datos' propia. Se limitan a utilizar la base de datos global de dpkg, que a su vez se limita a indicar los paquetes presentes en el sistema y sus dependencias. aptitude si tiene datos propios, pero tan solo se percata de paquetes ELIMINADOS; es decir, si recuerda que un paquete estaba instalado y ya no lo está, propondrá su instalación. Solo propondrá desinstalar un paquete, sea cual sea el método de instalación, si se ha configurado para eliminar paquetes no utilizados por otros. De cualquier forma, todos los front-ends (que eso son) terminan llamando a dpkg con las opciones pertinentes; es este el que realiza el verdadero trabajo. Eso implica que no quedan paquetes 'mal instalados' ni dependencias incumplidas, instalemos como instalemos. dpkg se encarga de ello. No confundir lo anterior con la diferencia entre 'desinstalar' y 'purgar'. Lo primero deja los archivos de configuración, mientras que lo segundo elimina todo. Además de lo anterior, algunos paquetes crean datos durante su uso. Esto es normal. dpkg, al desinstalar o purgar, compara los datos presentes el el paquete con el contenido real del sistema de archivos. Si en este último encuentra archivos que no deberían de estar, muestra un aviso y los deja sin eliminar. Es responsabilidad del administrador de la máquina comprobar estos archivos y decidir si eliminarlos o no. Adicionalmente a los anterior, algunos paquetes preguntan directamente si eliminar ciertos archivos de datos creados por los paquetes durante su normal uso. Por ejemplo, si usamos bases de datos y las desinstalamos, es normal que nos pregunte si deseamos también borrar las bases de datos creadas. Esto es también gestionado indirectamente por dpkg. En realidad, son órdenes indicadas en el propio paquete, y son ejecutadas por dpkg al eliminarlo. Moraleja: podemos instalar los paquetes con la herramienta que queramos; lo único a lo que nos arriesgamos es a dejar el sistema 'sucio', con archivos de configuración, de datos, o directamente paquetes, que no son utilizados y ocupan espacio en disco. Tengamos presente que si un paquete no se utiliza, sus archivos nunca se cargan en memória ni utilizan tiempo de CPU. Se limita a ocupar espacio para nada. (servicios al inicio aparte, pero me estoy enrollando demasiado). Saludos! Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140919225802.7f7a1ab5@danika.localdomain
Re: Script para asignar tareas al teclado alfanumerico
El Fri, 19 Sep 2014 16:20:32 -0500 Debia Linux debianer...@gmail.com escribió: 2014-09-19 9:29 GMT-05:00 Camaleón noela...@gmail.com: El Thu, 18 Sep 2014 21:44:29 -0500, Debia Linux escribió: Alguna sugerencia que pudieran darme para hacer un script en bash para asignar tareas especificas al teclado alfanumerico. Me gustaria que al presionar la tecla A sonara un archivo de audio de 1 minuto de duracion. Que despues al tocar la tecla S pudiera sonar otro audio (sin que dejara de sonar el primero) y que alto car la tecla D se reprodujera un video. (...) Por aquí preguntan algo similar: In bash, how do I bind a function key to a command? http://stackoverflow.com/questions/4200800/in-bash-how-do-i-bind-a-function-key-to-a-command Me parece excelente, ya estuve realizando pruebas y efectivamente funciona, sin embargo solo funciona en la consola de comandos. A mi me gustaria que pudiera yo ejecutar un script, minimizarlo (uso icewm) y ejecutar la combinacion de teclas fuera de la terminal. Es decir que funcione. Encontre que icewm permite configurar mediante el el archivo keys. Esto me parece aun mejor. Intentare ver que es posible. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.09.19.14.29...@gmail.com No termino de comprender lo que buscas, pero me parece que estás confundiendo cosas. Una cosa es el terminal, otra el interprete de comandos (Bash en tu caso), y otra el gestor de ventanas. En tu caso, me parece que con 'Atajos globales de teclado' o el mecanismo equivalente en tu gestor de ventanas, debe de funcionar. A cada tecla, asocias un orden y listo. Esas teclas dejan de estar disponibles para otras tareas, claro está. Si necesitas que las teclas solo funcionen bajo un script, no creo que puedas hacerlo con la ventana minimizada; la secuencia completa sería, más o menos, 1 Pulsas una tecla. 2 El gestor de ventanas comprueba si él mismo utiliza esa tecla. 3 Si no la utiliza, envia esa tecla a la ventana activa (no puede estar minimizada). 4 La ventana recibe la tecla, y la interpreta. 5 Si no es una tecla usada por el emulador de terminal, se la pasa a la entrada estandar de la aplicación que esté ejecutando. Bash en tu caso. 6 Bash interpreta la tecla y actua en consecuencia. Hay pasos adicionales: conversión de código de tecla a UTF8 o ASCII, intercepción de la tecla a nivel X por alguna utilidad, ... Lo anterior es válido solo para las X. Si estás en una consola, la cosa se simplifica. Resumiendo: enviar una tecla concreta a una ventana minimizada para que el bash que se esta ejecutando la interprete, me parece que va a ser que no, al menos así por las buenas. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140920004401.0aef66b8@danika.localdomain
Re: Pregunta... Sobre Paquetes INSTALADORES
El Sat, 13 Sep 2014 19:45:21 -0300 Rivera Valdez riveraval...@ysinembargo.com escribió: Pregunto (desde mi evidente ignorancia): Cuando se empaqueta el programa y se genera el .deb, ¿no es posible hacerlo de modo tal que contenga todas las dependencias necesarias (en alguna versión apropiada) para que se instalen en tanto A. no haya una versión más reciente o apropiada disponible en el sistema y B. no entre en conflicto con otros paquetes? ¿No es posible añadir las dependencias como archivos extra al .deb y permitir que el instalador las use como una fuente/repositorio más en tanto no entre en conflicto con otros paquetes? Como dijo Jack el destripador, vamos por partes: * Los paquetes ya contienen un listado con referencias a sus dependencias. Incluir las dependencias completas es totalmente impracticable por mas de una razón; pensemos en el paquete libc6, que contiene una librería básica del sistema: ¿ Incluimos el contenido de esa librería en todos los paquetes que la necesiten ? estamos hablando de 6 paquetes con información duplicada y tamaño extra. Si actualizamos la librería, ¿ reempaquetamos los 6 paquetes para que sigan conteniendo la nueva versión ? Y solo estamos usando la libc6. El sistema tiene muchas más librerías compartidas y programas auxiliares. * Añadir las dependencias como archivos extra es exactamente lo que hace el sistema actual, solo que los archivos extra están en Internet, en el repositorio Debian. * Hay utilidades que permiten mantener un repositorio local, manteniendolo actualizado, con los paquetes (y sus dependencias) que se le indiquen. Esto permite no necesitar Internet permanentemente, y actualizar el sistema completo cuando tengamos ocasión. * Hay utilidades que permiten mantener un repositorio local de paquetes fuente, compilandolos a medida, para generear un repositorio local de paquetes adaptados a nuestro sistema. Una forma de traer el mundo Gentoo a Debian. El sistema de repositorio central es uno de los más óptimos. Hay algunas variaciones aún mejores. No recuerdo que distribucion es, que en las actualizaciones no baja el nuevo paquete completo, sino tan solo las partes del paquete que han cambiado, minimizando las descargas. Crear paquetes independientes y completos, sin dependencias externas, puede ser útil para ciertas tareas; hay una distribución que utiliza solo KDE - Qt, y las aplicaciones Gtk las empaquetaba de forma distinta, autocontenidas, para no 'ensuciar' el sistema. Digo empaquetaba porque ya no lo hacen así, y han eliminado esos paquetes autocontenidos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140914073658.4fd50ea4@danika.localdomain
Re: Pregunta...
El Fri, 12 Sep 2014 16:13:17 -0400 Haylem Candelario Bauzá hay...@inor.sld.cu escribió: He estado leyendo sobre los programas .pbi de PC-BSD. Este tipo de programa viene en este formato de paquete y se instalan con un solo click, teniendo dentro todo lo necesario para funcionar. Como en Mac. Mi pregunta es, si existe algo parecido en GNU/Linux, miren el ejemplo de Android con los apk, algo así existe?. De hecho si no existe conozco como hacerlo. tambien he visto en GNU los paquetes .run que traen un instalador. Pero específicamente que uno pinche y la aplicación se instale como tal exactamente como los apk en GNU/Linux sería bueno tenerlo en cuenta. incluso facilitaría la instalacion de aplicaciónes. Una vez pensé en implementarlo de la manera siguiente. formato: .apg Se crea una carpeta con el nombre de la aplicación, se comprime en formato tar.gz, luego se cambia el tar.gz por .apg (esta carpeta contiene el ejecutable mas las librerias mas las shares y los archivos de configuracion) al lado de este comprimido va un script con el mismo nombre del .apg que se encarga de descomprimirlo en la carpeta /opt/ luego el mismo script crea las entradas de menú para cada escritorio. El problema radica precisamente en que la ubicación de los compartidos pudiera tener conflicto si el mismo programa estuviera instalado por el gestor de paquete reemplazando sus archivos. Cómo hacer que la aplicación busque los archivos de configuración y las /usr/share en la misma carpeta donde está el ejecutable? Sé como hacerlo con los libs y los bins pero faltan estos. Así a pelo, se me ocurre empaquetar los programas, junto a todo lo necesario (configuración, librerias, etc ) en un formato montable mediante fuse. Creo que varias distribuciones lo hacen así. Pero piensa que los paquetes así empaquetados son completamente independientes entre si y aparte del sistema. No reutilizan librerias, por lo que el tamaño aumenta, asi como el consumo de recursos al utilizarlos. Si lanzar 3 ejecutables, aunque los 3 utilicen la misma librería, tendrias en memoria 3 copias de dicha librería. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140913003157.350f2c67@danika.localdomain
Re: OT capar un usuario que solo ejecute un script
El Tue, 26 Aug 2014 12:33:28 +0200 Juan Guil erj...@gmail.com escribió: Hola Me han pedido hacer una cosilla. (Todo en servidores Debian, Ubuntu y un CENTOS) Tengo una serie de servidores, que hacen backup de unos directorios atraves de un script diariamente atraves de un crontab. La historia es que: Quiero que estos backups, en vez que lo haga la propia maquina, haya una maquina externa que se va a encargar de hacer los backups de los diferentes servidores, remotamente a estos scrits de backup Para eso, necesitaria crear en cada servidor un usuario que no pueda ejecutar nada en el dicha maquina, y que solamente pueda ejecutar ese script, ni tan siquiera un ls. esto me serviria para que el servidor que se va encargar de hacer los backups, lo haga haciendo una llamada con este usuario ejecutando este script de backup, como he dicho antes. ¿es posible hacer eso con sudo? ¿habria que caparle la shell? Alguna idea interesante? Estoy diciendo alguna burrada? Muchas Gracias! Yo añadiria un shell en /etc/shells, añadiendo el script a utilizar, y modificaria /etc/passwd poniendo a ese usuario, como shell, el susodicho script. El usuario no puede hacer nada despues del login; es decir, cada vez que se loguee, automaticamente lanza el script. No tiene acceso a un shell real ni nada. Cuando el script termina, se cierra la sesion. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826193832.4be91d20@danika.localdomain
Re: [OT] Red Hat 7: XFS como sistema de archivos predeterminado
El Fri, 13 Jun 2014 20:15:31 +0200 Manolo Díaz diaz.man...@gmail.com escribió: Hola Hace unos días leí que había salido una nueva versión de Red Hat¹ (hasta aquí nada nuevo) pero me llamó la atención el cambio que habían hecho para el sistema de archivos que se instala como predeterminado pasando de Ext4 a XFS. Pues a mí también me intriga. Tenía entendido que ext4 era más estable que XFS en Linux, y desde luego está mucho más probado. Tal vez sea que un máximo de 16 TB por fichero y 50 TB para todo el sistema de fichero se les queda corto. Esto es lo más parecido a una justificación que parecen dar: Llevo usando XFS en entornos de escritorio durante más de 1 año, y no tengo absolutamente ninguna queja sobre el. Tengo entendido que en versiones antiguas, la implementación en el núcleo dejaba bastante que desear (y una correcta implementación es tan importante como un correcto diseño), pero actualmente tiene un magnífico rendimiento. Existen algunas razones para utilizar EXT4; principalmente que, tal y como comentáis, está más extendido, lo cual ha permitido la existencia de ciertas aplicaciones especializadas (no recuerdo el nombre, pero había una que agrupaba los datos mediante 'extents' para facilitar su lectura secuencial; en mi caso particular, el aumento de velocidad en el arranque era brutal). Aparte de esos casos particulares, la única ventaja que tiene es que se puede utilizar sin log, perdiendo las transacciones. Para algunos tipos de discos, como los SSD, puede ser una ventaja (a costar de perder fiabilidad). En resumen, que XFS es un magnífico sistema de archivos. Ciertamente procede de Oracle (que no es muy de fiar), pero creo recordar que había una organización encargada de mantener su libertad. Siento no poder dar mas detalles. P.D.- Hay muchas tablas comparando rendimientos, pero, como he dicho, implementaciones antiguas dejan mucho que desear. Con un kernel actual, XFS se puede medir cara a cara con cualquier otro sistema. http://diegocg.blogspot.com.es/2013/06/red-hat-xfs-es-mejor-sistema-de.html http://diegocg.blogspot.com.es/2012/06/el-renacer-de-xfs.html -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140613212351.3be1831f@danika.localdomain
Re: Mapeos de disco Por usuarios
El Thu, 13 Mar 2014 18:55:11 -0430 Edward Villarroel (EDD) edward.villarr...@gmail.com escribió: //192.168.0.106/Movies /home/edward/Nube/Vid cifs guest,uid=1000,iocharset=utf8 0 0 //192.168.0.106/Music /home/edward/Nube/Mus cifs guest,uid=1000,iocharset=utf8 0 0 //192.168.0.106/Download /home/edward/Descargas cifs guest,uid=1000,iocharset=utf8 0 0 //192.168.0.106/Documents /home/edward/Nube/Doc cifs guest,uid=1000,iocharset=utf8 0 0 //192.168.0.106/Backups /home/edward/Nube/Bak cifs guest,uid=1000,iocharset=utf8 0 0 //192.168.0.106/Pictures /home/edward/Nube/Pic cifs guest,uid=1000,iocharset=utf8 0 0 pero la pregunta es si asi como se configura este para toda la pc existe uno para cada usuario para la parte de los mapeos de /Nube/ sean distinto para cada usuario * En cada directorio /home/USUARIO, crea una carpeta que se llame, por ejemplo, .EXTERN (con el punto al principio). * En cada directorio /home/USUARIO, crea enlaces para los directorios a montar que apunten a los mismos nombres dentro de la carpeta .EXTERN. Es muy importante NO CREAR ESAS CARPETAS dentro de .EXTERN /home/USUARIO/Pictures - enlace a /home/USUARIO/.EXTERN/Pictures, donde /home/USUARIO/.EXTERN sigue estando vacio. * Edita /etc/auto.master, y añade una lína al final por cada usuario (si son 20 usuario, son 20 líneas) /home/USUARIO/.EXTERN /etc/auto.USUARIO * Crea un archivo /etc/auto.USUARIO para cada usuario, que contenga los mapeos reales. No dispongo de un servidor SAMBA en el que probar, así que puede que los datos no sean 100% correctos. Descargas -fstype=cifs,username=USER,password=PASS,OTRAS_OPCIONES ://Nube/pic ( lo anterior es una sola lína, con 3 campos separados con espacios ) Lo anterior admite múltiples variaciones. El ejemplo es similar al que yo uso. Autofs tiene la ventaja de que no monta los directorios hasta que no son realmente usados, y los desmonta tras un periodo sin uso configurable (por defecto 10 minutos). Autofs soporta el uso de NIS, NIS+, LDAP y scripts de usuario para obtener los archivos /etc/auto.USUARIO, además de varias variables internas (HOST,ARCH,USER,HOME), con lo que se puede minimizar el número y tamaño de los archivos de configuración /etc/auto.USUARIO, además de centralizar la configuración. Más info: https://wiki.archlinux.org/index.php/autofs man autofs man auto.master man 5 autofs -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140314062433.234c507c@danika.localdomain
Re: Mapeos de disco Por usuarios
El Wed, 12 Mar 2014 22:38:38 -0430 Edward Villarroel (EDD) edward.villarr...@gmail.com escribió: tengo varios usuarios en un equipo y quiero q dependiendo del usuario mapee distintos disco de red se que si modifico el fstab y coloco las condiciones del mapeo son para todos los usuarios pero como se hace en el caso de que tenga varios usuarios debo programar el mapeo? No estoy muy seguro de lo que quieres hacer, pero puedes probar con autofs, que te permite definir mapeos dependiendo del usuario que acceda a los directorios, entre otras cosas. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140313060044.1446aa8e@danika.localdomain
Re: OT - autofs y /dev/pts
El Fri, 7 Mar 2014 16:19:03 + (UTC) Camaleón noela...@gmail.com escribió: (...) Todo funciona perfecto, a excepción del /dev/pts dentro del chroot. Siempre se encuentra vacio. /dev/pts está montado como un sistema de ficheros aparte, del tipo devpts, y autofs no es capaz de acceder a él fuera del chroot. ¿ Alguna forma de gestionar esto ? no encuentro el modo de indicarle a autofs que /dev/pts (dentro del chroot) debe ser tratado de forma independiente. ¿Has probado a montar el recurso directamente con mount --bind como dicen aquí¹ en lugar de dejar que sea autofs el que lo haga? Digo, para empezar a determinar el punto de fallo (error de sintaxis/configuración, error de concepto...). Ah, y revisa también los registros (syslog, dmesg, daemon) a ver si te dan alguna pista. ¹https://wiki.debian.org/chroot#Mounting_pseudo_filesystems Saludos, El problema está localizado. Es autofs, que solo gestiona 1 nivel de anidamiento. Es decir, si autofs monitoriza /home/Devel, se encarga de montar automáticamente todos los directorios DE UN SOLO NIVEL INFERIOR: /home/Devel /etc /sys /proc /dev . . . No he sido capaz de localizar por ningún lado como indicarle que también gestione, a su vez, /home/Devel/dev/pts De hecho, creo que, sencillamente, no es posible. Me duelen los ojitos de tanto mirar documentación, y no he encontrado referencias a esto por ninguna parte. De momento, está solucionado mediante el script que utilizo para entrar al chroot: #!/bin/bash rsync $HOME/.Xauthority $HOME/Devel$HOME test -c $HOME/Devel/dev/pts/ptmx || sudo mount -o bind /dev/pts $HOME/Devel/dev/pts exec sudo chroot $HOME/Devel /bin/login -f juanjo \ XAUTHORITY=$XAUTHORITY DISPLAY=$DISPLAY LANG=$LANG \ LS_COLORS=$LS_COLORS TERM=$TERM Compruebo la existencia de un dispositivo de caracteres en el chroot y, si no está, lo monto con -o bind. Si no lo compruebo y lo monto varias veces, da mensajitos de error al apagar el sistema :-( El porqué de todo esto es que una parte de este chroot esta en un disco aparte; disco que solo se monta al acceder al chroot. Es un equipo compartido, y mi mujer y mi hija no 'customizan' paquetes Debian. Asi, si no está montado, es más dificil que se dañe por un apagón (en mi pueblo la electricidad es muy dependiente del viento, en pleno 2014 que estamos). -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140307185944.705347b0@danika.localdomain
OT - autofs y /dev/pts
Hola a todos. Estoy experimentando con autofs, y he creado un chroot para cuestiones de compilación de paquetes, donde he instalado herramientas de desarrollo. Una de ellas es 'geany'. A geany no le funciona el terminal, y otras aplicaciones dicen que no está montado /dev/pts. Este chroot está parcialmente gestionado por autofs; en concreto, los directorios /dev, /proc, /sys, y /tmp son automontados como 'bind' a los directorios normales del sistema. El esquema completo es el siguiente: /home/.devel - chroot. proc, sys, tmp y dev son enlaces a los directorios reales del sistema. /home/Devel - gestionado por autofs. contenido de /etc/auto.master: /home/Devel /etc/auto.devel contenido de /etc/auto.devel: * -fstype=bind :/home/.devel/ Todo funciona perfecto, a excepción del /dev/pts dentro del chroot. Siempre se encuentra vacio. /dev/pts está montado como un sistema de ficheros aparte, del tipo devpts, y autofs no es capaz de acceder a él fuera del chroot. ¿ Alguna forma de gestionar esto ? no encuentro el modo de indicarle a autofs que /dev/pts (dentro del chroot) debe ser tratado de forma independiente. Gracias. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306224725.085132e4@danika.localdomain
Re: OT - autofs y tmpfs
El Sun, 23 Feb 2014 14:30:31 + (UTC) Camaleón noela...@gmail.com escribió: Mucho mejor, gracias. Por cierto, me encanta tu X-face :-D Gracias. Creo recordar que lo saqué de uno de los emoticonos que vienen con KDE o con Kopete. Te paso algunos enlaces que te pueden dar más ideas para minimizar las escrituras en la SSD, aunque supongo que ya les habrás echado un ojo: https://wiki.debian.org/SSDOptimization https://wiki.archlinux.org/index.php/Solid_State_Drives#Tips_for_Minimizing_SSD_Read.2FWrites No he llegado a mirarlos, pero me imagino que serán similares a los muchipico que he mirado ya: todo lo que se pueda en tmpfs, noop como IO-scheduler de la unidad, opciones de montaje noatime, nodiratime, discard, ... De todas formas, si se trata de una unidad de disco SSD moderna y dado el uso casero que le das al equipo, el número de escrituras en disco no debería ser un factor relevante, vamos, que no deberías preocuparte por dónde tienes los directorios. Si es solo por matar el tiempo. Desgraciadamente, dispongo de mucho más tiempo libre del que quisiera ... En lo referente a los problemas que comentas, de momento me estoy asegurando (revisando con 'ps') que el script real que se ejecuta no se ejecute varias veces simultaneamente (por ejemplo, que coincida una escritura cada 15 minutos con un cierre de session). No había caido en lo de no copiar archivos que están abiertos por otros procesos. Tengo que mirarlo ... Saludos, Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223192047.520e943a@lilu
Re: OT - autofs y tmpfs
El Fri, 21 Feb 2014 15:15:32 + (UTC) Camaleón noela...@gmail.com escribió: El Thu, 20 Feb 2014 22:19:02 +0100, Juanjo López escribió: Hola. (ese html...) Perdón; envié envie desde el cliente WEB de GMail, y hace mucho que no lo uso. Esta respuesta va desde claws-mail :-) Recientemente, he instalado un SSD como segundo disco duro, con una partición F2FS para /. /home se encuentra en esa misma partición. El objetivo es minimizar las escrituras en este disco SSD, por lo que había pensado en lo siguiente: * Para cada usuario, crear un archivo .tar en /var/local, que contenga todos los archivos de su home. * En auto.master, crear un mapa para el directorio /home: '/home program:/usr/local/bin/autohome' Cada vez que un usuario entre al sistema, el script que genera el mapa se encarga de extraer el tar bajo /tmp/home ( /tmp es tmpfs ), y devuelve a su vez un mapa del tipo '$NAME -fstype=bind :/tmp/home/$NAME'. Uhhh... uséase, que la /home esté en la memoria RAM, pero ¿no es un poco arriesgado? Si la sincronización falla podrías perder datos :-? Es un equipo doméstico. Ni mis niños ni sus padres trabajan con 'datos críticos'. De todas formas, un pequeño script desde cron minimiza pérdidas. ;-) Hasta aquí, todo OK. El problema es: ¿ como actualizar el tar con los datos de cada usuario al desmontar su /home ?? No encuentro ninguna forma de ejecutar ningún tipo de script al desmontar el directorio, con lo que los datos de cada usuario no son volcados a su archivo .tar correspondiente, y cualquier cambio se pierde. He pensado en poner un script en cron que actualice los datos del usuario cada cierto tiempo (si es que hay cambios), por ejemplo con rsync (y eliminar el tar del esquema), pero no me parece una solución elegante, y siempre puede suceder que un usuario salga antes de que el cron llame al script de sincronización y se pierdan los últimos cambios. ¿ Alguna sugerencia ? Lo del archivo .tar se me escapa, pero creo que este sistema te podría servir: Ubuntu thumb drive http://robwicks.com/tag/tmpfs/ Lo del tar es una 'pijada'. En vez de guardar los datos en un directorio, hacerlo dentro de un archivo tar. Ya lo he eliminado del esquema. Efectivamente, lo que quiero realizar es algo como lo que explican en el enlace. En un principio, la idea era utilizar autofs para montar los directorios de los usuarios en tmpfs, sincronizandolos con un archivo tar (eliminado del esquema), o desde un directorio. Este sistema tiene un inconveniente: algunos programas, como por ejemplo 'lightdm', acceden a TODOS los directorios de los usuarios buscando ciertos archivos. Por ejemplo, 'lightdm' busca los archivos '.face' para mostrar las imágenes de los usuarios. Si utilizo autofs, se cargan en memória todos los directorios /home/, lo cual no es aceptable. Actualmente, estoy experimentando con otra secuencia, en varios pasos: 1.- Arranque del sistema. Se crean y sincronizan los directorios /home/ de todos los usuarios, copiando tan solo ciertos datos (archivos .face en este caso). 2.- libpam-script, que a su vez ejecuta un script cada vez que un usuario INICIA sesión. Un rsync y listo. 3.- Un script en cron, que periodicamente (cada 15 minutos) realice un rsync de los directorios /home/ de los USUARIOS LOGUEADOS. 4.- libpam-script, que a su vez ejecuta un script cada vez que un usuario FINALIZA sesión. Otro rsync. Estoy en ello; si os resulta interesante, cuando lo termine posteo los detalles exactos. Creo que puede resultar útil para algunos. En lo referente a la pregunta inicial, alguna forma de ejecutar algo al desmontar una unidad, no he encontrado nada relevante. Aparece por ahí algo sobre programas auxiliares, del tipo umount.smb, pero no he profundizado. Como ya he comentado, el automontaje presenta ciertos inconvenientes, por lo que he descartado esa ruta de acción. Saludos, Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2014020325.25c94537@lilu
Re: Mandar comando ejecutado a segundo plano mientras se está ejecutando
El Wed, 5 Feb 2014 18:03:38 +0100 Maykel Franco maykeldeb...@gmail.com escribió: Hola buenas, pregunto una cosilla que siempre me ha gustado saber, que desde luego yo no sé. Ya sé que se puede mandar la salida de un comando a segundo plano con , nohub ...y se puede recuperar con fg, o incluso usar screen para lanzar comandos y salir y luego recuperar la consola virtual, pero imaginaros que lanzo un rsync o scp desde mi equipo a un servidor. Tengo prisa porque me quiero ir a casa, o tengo que reiniciar mi pc, reiniciar la red...etc por cualquier circunstancia necesito que ese comando se siga ejecutando aunque yo reinicie, apagague, me vaya a casa con el portatil apagado... y quiero mandarlo a segundo plano mientras lo estoy lanzando... ¿Se podría de alguna forma? Sé que la solución fácil es mandarlo a segundo plano según lo lanzas, pero a veces no nos acordamos y lanzamos el comando y dura bastante Saludos. No estoy seguro, pero creo que lo que pretendes es volcar un proceso completo a disco y restaurarlo luego, para que siga como estaba, no ? Lo vuelcas, apagas el equipo, haces lo que tengas que hacer, y que cuando lo vuelvas a encender no tener que empezar de nuevo desde el principio, sino que continue lo que estaba haciendo. Lo más parecido que se me ocurre es que suspendas/hibernes el equipo completo. Hacerlo con un solo proceso creo que no se puede hacer, a no ser que el propio programa incorpore alguna opción para 'guardar su estado' y volver a cargarlo; algo parecido a las sesiones de XWindows. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140205221822.30871b96@lilu
Re: OT: Nombre de equipo en fondo de escritorio...
El Tue, 19 Nov 2013 00:52:57 -0300 Walter O. Dari wlin...@gmail.com escribió: Hola: No se si se entiende y la verdad es que no se ya como buscarlo. Lo que quería saber es si hay alguna forma de incorporarle automáticamente el nombre del equipo en algún lugar de la imagen usada como fondo de pantalla o de escritorio. Tengo 4 equipos que manejo con un switch KVM o algo así (un monitor, un teclado y un ratón para los 4) y me sería práctico que me apareciera el nombre de cada equipo en el fondo de escritorio: debsw1, debsw2, debsw3 o debsw4. Será posible ? Gracias y saludos, Se me ocurren 2 maneras: *Opción simple y fácil: Lanzar una aplicación capaz de mostrarnos la información: conky, gkrellm, xmessage `hostname` , ... Aquí se incluyen los applets propios del escritorio que estemos utilizando. Lo colocamos en .config/autostart o en nuestro .xsession. *Opción larga, para gente con tiempo libre: 1- Buscar como almacena nuestro escritorio la imagen de fondo: archivo en .config, enlace en .cache, ... 2-Utilizar imagemagik para añadir otra imagen superpuesta. 3-Script en autostart o .xsession para lanzar el proceso en cada inicio de sessión. Lo anterior se puede completar con varias opciones: alguna utilidad que elimine el botón de cerrar de la ventana que nos muestra la información, alguna utilidad que reconozca cuando cambia determinado archivo y automatice el proceso. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131119095036.2f0526d5@lilu
Re: Desinstalar Apache, PHP5, MySql
El Wed, 21 Aug 2013 13:20:25 -0300 Juan jawif...@gmail.com escribió: No, pero lo que noto es que los desinstalo y por ejemplo al volver a instarlar mysql ya tiene el usuario, las bases de datos, etc no borra todo, lo mismo apache, lo desinstalé, lo instale de nuevo y al apache2.conf tenia las modificaciones que le habia hecho antes... Vamos por partes. Como comentan por aquí, no sabemos lo que estas viendo en el monitor. El apt-get remove --purge puede dejar archivos y directorios sin borrar. Normalmente sucede con directorios NO DE CONFIGURACIÓN, tipo /var/lib, /var/cache, y similares, cuando el contenido ha sido modificado añadiendo algún archivo no presente en el paquete original. En el caso de /etc, puede ser que las configuraciones no las maneje el paquete principal, sino algún auxiliar, tipo XXX-common, XXX-base, o algo así. Para estas cosas, yo suelo utilizar aptitude, que me permite ver las dependencias de los paquetes y eliminarlas a la vez, avisandome cuando algún otro paquete las usa para no equivocarme. Creo que apt-get autoremove también hace algo así. Los archivos de configuración que dependan de estos auxiliares se borraran al eliminar el paquete responsable. Algunos paquetes de bases de datos, al eliminarlos, preguntan si eliminar también los directorios con las bases de datos que hayamos creado. Para futuras referencias, /var/lib/dpkg/info contiene la base de datos del contenido de todos los paquetes. Seguro que hay utilidades apt-XXX para inspeccionarlas, pero yo los consulto directamente con cat y fgrep. Como último recurso, puedes eliminar los directorios y archivos a mano. En el siguiente arranque del sistema, seguramente apareceran mensajes de error. Puedes buscar los paquetes problemáticos a partir de ahí. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130821190842.622454a5@lilu
Re: [OT] Sandbox de uso sencillo para aplicaciones de Escritorio
El Mon, 12 Aug 2013 11:31:12 -0500 Carlos Zuniga carlos@gmail.com escribió: 2013/8/12 jors j...@enchufado.com: On 12/08/13 17:06, Carlos Zuniga wrote: 2013/8/11 jorsj...@enchufado.com: Buenas lista, ¿Alguien conoce alguna aplicación de sandboxing para apps de Escritorio (en realidad, que soporte cualquier app)? En mis dias de Windows recuerdo usaba Sandboxie [1] y me gustaba, y me temo no hay nada o no he sabido encontrar nada parecido en Linux (concretamente en Debian GNU/Linux). Y cual es tu objetivo? Evitar que la aplicación modifique o cree archivos en tu usuario? Idealmente que no cree/modifique nada. Y si lo hace, que sea sobre archivos temporales que no son en realidad los del sistema. Tal vez sería más sencillo simplemente crear otro usuario de prueba y correrla ahí. Si por lo que sea se ejecuta una aplicación maliciosa que consigue sobrepasar las barreras estandar del sistema para ese usuario (p.ej. aprovechando un bug en alguna aplicación), la jodimos. Entonces concuerdo con los demás listeros que te recomiendan usar una máquina virtual. Además, idealmente la aplicación no tendría que poder cambiar nada y sin embargo creer que sí lo hizo. ¿Algún desarrollador se anima con un soft de sandboxing de este tipo? :D Eso suena similar a lo que hace fakeroot, utiliza un wrapper sobre las llamadas al sistema para hacer creer a la aplicación que tiene los permisos necesarios, si piensas hacer una aplicación, podrías ver como lo hacen ellos. Y creo que es un método similar el que utiliza SandboxIE. Para lo de los cambios a los ficheros, sobre la VM podrías simplemente sacar un md5 a todos los ficheros y ver cuales han cambiado tras correr la aplicación, o algo más elaborado sería crear un repositorio git y ver un diff de los cambios. Saludos Lo que pretendeis hacer no es tan sencillo. fakeroot carga un librería que envuelve algunas llamadas al sistema, para que parezca que el proceso llamante tiene permisos de root (udi=0), aunque realmente no los tenga. Es decir, el proceso cree llamar a la función 'getuid()' del sistema, cuando en realidad está llamando a la función 'getuid()' de la librería cargada. Esta técnica es relativamente fácil de implementar, permitiendo envolver cualquier llamada a la librería libc (en general, a cualquier librería), pero presenta un MUY GRAVE problema de seguridad. Nada impide a una aplicación realizar llamadas directas a las funciones del núcleo, saltandose la librería libc y cualquier otra que este cargada. Si la seguridad es prioritaria, esta técnica está descartada. Otro enfoque es utilizar herramientas del tipo AppArmor, SELinux, e incluso Linux Containers. No tengo experiencia práctica con ellas, y no se hasta que punto se pueden configurar para que intercepten ciertas llamdas al sistema y emulen un entorno aislado. Son multitud las llamadas a interceptar, y los resultados han de ser coherentes y persistentes durante todo el tiempo de ejecución de la aplicación, si queremos que esta funciones con normalidad. Es decir, si la aplicación crea un archivo y realiza lecturas y escrituras, ese archivo y esos datos han de existir durante el tiempo que la aplicación esté activa. Este método puede considerarse el mas seguro, a costa de limitar la integración general con el sistema. Llamadas a servicios esperados por la aplicación (dbus, por ejemplo, o el socket de X), lectura de archivos estandar (/dev/nul, /etc/services, /etc/passwd ). Librerías compartidas necesarias, ... Un enfoque similar es utilizar chroot. Configurar un entorno chroot es practicamente igual a configurar nuestro entorno 'real'. Una escalada de privilegios se produce de igual forma tanto en el entorno real como en el chrooteado. Un bug de una aplicación o del propio kernel presenta los mismos problemas, y si se consigue acceso root, el chroot no sirve para nada. Los chroot ofrecen más facilidades de integración entre las 'jaulas' y el entorno real. Se pueden compartir sistemas de ficheros, incluso hacer que los cambios a un archivo se realicen en realidad en un sistema de archivos distinto. UnionFS, ROFS, 'mount -o ro,bind', ... y los sockets son accesibles, pero se pueden filtar de varias maneras. Creo que hay por ahí un módulo para IPTABLES que permite filtrar los paquetes por usuario. Un chroot, un usuario específico para las pruebas de aplicaciones, un sistema de archivos tipo UnionFS, que escriba en un volumen distinto, filtros IPTABLES especiales para ese usuario, ... las posibilidades son múltiples. Cualquier opción necesita su propio espacio. A mayor seguridad, mayor espacio requerido para proporcionar a la aplicación un entorno más 'aislado'. La aplicación puede leer las librerías compartidas del sistema, o proporcionarle unas propias. Si utilizas copias de librerias, se necesita espacio para ellas. Si utilizar las librerías del entorno 'real', asegurate de que no pueda escribir en ellas. Si no
Re: Suspender programas en X
El Wed, 14 Aug 2013 17:53:59 -0300 Debian GMail javier.debian.bb...@gmail.com escribió: Estimados: Dado mi (mala) costumbre de tratar al equipo como si fuera infinito en facultades, suelo sobrecargar el procesador a límites insospechados. El tema es que a veces dejé a la máquina haciendo algo muy demandante, y tengo necesidad de recuperar algo del sistema, pero tampoco quiero perder el tiempo ya invertido. Es por eso que se me ocurrió ver si existe alguna forma de pausar o hibernar a memoria una aplicación que está corriendo en las X, o sea, pantalla gráfica. De las tty tengo en claro que se puede hacer con Ctrl-z, y eso pausa la aplicación que se esté corriendo, pasándola a segundo plano. También sé de CryoPID que puede suspender a un archivo para luego recuperarlo en su estado de ejecución. Pero no es lo que estoy buscando. Por suerte, con memoria no tengo muchos problemas hoy, lo que me está limitando son los tristes 4 núcleos sobrecargados, los cuales a veces quiero liberarlos. La pregunta se resume a: ¿Existe algo que en consola gráfica pause la ejecución de un programa (lo congele), liberando capacidad de cómputo, sin necesidad de bajarlo a disco? Otra pregunta podría ser: ¿Existe forma de asignarle un núcleo específico de la UCP al proceso, y que no toque los otros tres? Tardará más, pero me deja el sistema más liviano. Como ejemplo de lo que trato de hacer, VirtualBox me permite pausar la ejecución de una máquina virtual, pasando a un consumo ínfimo de recursos. Al necesitar nuevamente dicha máquina virtual, la activo nuevamente. Muchas gracias JAP kill -19 PID --- pausa el proceso. kill -18 PID --- continua el proceso. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130815002225.47869129@lilu
Re: [OT] Sandbox de uso sencillo para aplicaciones de Escritorio
El Sun, 11 Aug 2013 14:37:32 +0200 jors j...@enchufado.com escribió: Buenas lista, ¿Alguien conoce alguna aplicación de sandboxing para apps de Escritorio (en realidad, que soporte cualquier app)? En mis dias de Windows recuerdo usaba Sandboxie [1] y me gustaba, y me temo no hay nada o no he sabido encontrar nada parecido en Linux (concretamente en Debian GNU/Linux). He probado la app de Gentoo sandbox [2] y el script sandfox [3], y a parte de que no tienen nada que ver, tampoco parece que me hayan funcionado. Baste decir que los probé lanzando desde ellos Iceweasel y he podido guardar páginas web en mi Escritorio. Se que Redhat/CentOS tiene una sandbox en SELinux (que no me suena haber visto en Debian) y que también hay algo parecido de Suse llamado AppArmor (hay paquetes en Debian), pero no he sabido ver si tiene sandbox. En fin, agradecido de cualquier idea/orientación al respecto. [1] http://www.sandboxie.com/ [2] https://wiki.debian.org/Sandbox [3] http://igurublog.wordpress.com/downloads/script-sandfox/ Salut, jors Yo utilizo algo parecido basado en chroot para los entornos de desarrollo, para no 'ensuciar' la jerarquia principal con los paquetes -dev y -doc, y autofs para montar la partición solo cuando la necesito. Como desventaja, como tú comentas, el aumento de espacio. En mi caso particular no me preocupa mucho esto ni la seguridad, así que no te puedo comentar sobre esta última. Si el espacio es determinante, se me ocurre que podrias montar un script que, a partir de la información en /var/lib/dpkg/info/XXX.list, copie los archivos relevantes en un directorio para poder hacer chroot en él, y modifique el APPLICATION.desktop para poder acceder de forma trasparente mediante el chroot. No se si hay algo por ahí así, pero me suena de un paquete 'reducelibs' que hace algo parecido, mostrando las librerias necesarias para una aplicación. Siento no poder darte paquetes ni nombres de aplicaciones concretas. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130812105506.1a0abd43@lilu
Re: OT - Múltiples máquinas compartiendo IP
Para montar un servidor de lo que sea, en la mayoría de los casos ( a menos que seas un ISP o un servicio a lo google o algo por el estilo) solo se necesita una =) Digamos que ojalá me quede sin puertos. Es para un proyecto comercial que estoy bosquejando. Vamos, que con 65535 usuarios, no hacemos nada. Como mínimo, hacen falta 5.000.000. Así, sin anestesia ni nada. Nunca he instalado Jabber para mas de 100-200 personas, que por lo general me basta con lo básico, pero, me imagino que si en tu caso esperas una cantidad tal de usuarios que te preocupas que se te acaben los puertos (cosa que la verdad me voy a permitir dejar en duda), tu siguiente nivel de solución debería ser un cluster de maquinas de tal manera que te provean de características de alta disponibilidad, esa suele ser la solucion, ya que, el solo pensar que tus usuarios deberán dirigirse a distintos CNAME en el DNS para conectarse al mismo servicio, no suele ser de fácil implementacion, ni de fácil entendimiento de los usuarios. Lo de Jabber es solo como ejemplo. No tiene nada que ver. En realidad, se utilizará el protocolo HTTP 1.1, con servidores web modificados (para retransmitir a la trasera), y la comunicación con los clientes será mediante JSon (fácil, multiples lenguajes). Si esto sale p'alante, tengo intención de publicar todas las especificaciones y protocolos utilizados. Si sale, claro. La trasera del servicio ya está más o menos ideada; había pensado en utilizar Amazon EC2 que, aunque sea hacerle propaganda, está bastante bién. Y con los servicios extras (mensajes, almacenamiento, mencached), ofrece una plataforma perfecta. Solo echo en falta PostgreSql, pero en fín, que se le va ha hacer... Además, utilizando Amazon Elastic IP se solucionan todos mis problemas, así que todo este hilo ha sido para nada ;-) Los del UDP venia a cuento de que, si por algún motivo, es necesario conectar DESDE EL SERVIDOR al cliente, y este último está detrás de un firewall. De todas formas, eso se ha solucionado de otra forma. Y mi inquietud era por si había más de un cliente detrás del firewall; para un solo cliente, no hay más que configurar el firewall adecuadamente. Hombre, esta parte si no la entiendo. Nada nada, ni caso. No me explico bién, y ya no es necesario. De nuevo, muchas gracias por contestar. Pues nada, a leer documentación a ver de que forma puedes implementar un cluster, pero repito, dudo que ese escenario de quedarte sin puertos sea fácil de alcanzar, porque creo que ( a menos que este implementado en un servidor con muy buenas prestaciones) se te cae el servicio, o cuelga la maquina, mucho antes de alcanzar ese limite. Hombre, en un principio se planteó la idea de utilizar servicios de housing y montar las máquinas por nuestra cuenta; se pensó en utilizar máquinas con mucha memória y virtualizar los servidores, con 20 máquinas virtuales por host físico, y unas cuantas más para tareas de proceso y control. Pero, claro, comparando costes de máquinas físicas (salen aprox. a 7000€, con 256Gb de RAM y un Opteron de 2x12 núcleos, + los costes del housing y el ancho de banda) y los servicios de Amazon EC2, se optó por este último. En cuanto al servicio en sí, lo único que hacen las máquinas del frontend es mantener las conexiones abiertas y retransmitir lo que dicten las máquinas del backend. El mayor problema serán las conexiones SSL, que no se cuanta CPU consumirán. No obstante, aún falta muuucho para evaluar rendimientos. Bueno, de nuevo muchas gracias a todos por las respuestas. Ya está todo solucionado. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120521195639.1dd176f5@lilu
Re: OT - Múltiples máquinas compartiendo IP
El Mon, 21 May 2012 17:19:58 + (UTC) Camaleón noela...@gmail.com escribió: El tiempo en la respuesta no es problema, pero si abres un hilo nuevo se pierde por completo la referencia de lo que estabas hablando ;-( Siento lo del nuevo hilo. Ha sido, simplemente, para no responder individualmente a cada uno y agruparlo. Intentaré no repetirlo. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120521200314.2ddb9bd1@lilu
