Re: [OT] Sistema de Archivos
El 01/08/2014 21:19, Emmanuel Brenes escribió: Buenas, buenas, compañeros. Estos días he notado como Ext4 ya no da mucho de sí en cuanto a rendimiento y velocidad, ya que manejo archivos muy grandes (por lo mínimo 10 GB) necesito acceso a los mismos rápidamente. Aclaro que tampoco es un servidor, es un computador de escritorio, pero por cuestiones de trabajo/estudio, manejo archivos de considerable tamaño. Hice la tarea e investigué acerca de los FS con más atributos -útiles- para mi caso. Tengo interés en que el FS tenga 'journal' o algo que lo iguale, según el caso, y que al menos sea más rápido que Ext4 en lectura y escritura. Btrfs queda descartado por el simple hecho de que lo considero demasiado nuevo, y quiero algo que estable. Aparte, tengo entendido -si no es así me dicen- que los tres de abajo, tienen adjudicación dinámica de inodos, detalle que me interesa bastante, si recomiendan algún otro FS. Mi lista la conforman pocos FS: XFS, ZFS o JFS. Me gustaría conocer su opinión. ¡Saludos! Buenas, buenas, compañeros. Siguiendo las recomendaciones de optimizar un poco al viejo Ext4, logré una mejora a nivel de lecto/escritura, no obstante, sigo considerando aún un cambio de sistema de archivos, por lo que alguna experiencia similar con los sistemas de archivos (JFS o XFS) me sería de gran ayuda. ¡Gracias a todos! 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/blu437-smtp61b53d2f8a59366b5a04e9a1...@phx.gbl
Sin sonido. Drivers Alsa.
Buenas. Tengo problemas con el sonido de mi pc. Lo he intentado configurar con los drivers Alsa y he seguido esta url https://wiki.debian.org/ALSA sin éxito ninguno. Mi Debian es la 7.6. Cuando pulso en Alsamixergui me da el siguiente error: Alxamixer: function snd_mixer_load failed: Invalid argument Cuando ejecuto alsactl init me da el siguiente error: Found hardware: HDA-Intel Realtek ALC887-VD HDA:10ec0887,1458a002,00100302 0x1458 0xa002 Hardware is initialized using a generic method /usr/share/alsa/init/default:26: control element not found /usr/share/alsa/init/default:26: control element not found /usr/share/alsa/init/default:48: control element not found Cuando ejecuto /etc/init.d/alsa-utils start me da el siguiente error: amixer: Mixer hw:0 load error: Invalid argument Kernel usado: 3.2.0-4-amd64 Los módulos están cargados: snd_hda_codec_realtek 188851 1 snd_hda_intel 26259 1 snd_hda_codec 78031 2 snd_hda_intel,snd_hda_codec_realtek snd_hwdep 13186 1 snd_hda_codec snd_pcm68083 2 snd_hda_codec,snd_hda_intel snd_page_alloc 13003 2 snd_pcm,snd_hda_intel snd_seq45126 0 snd_seq_device 13176 1 snd_seq snd_timer 22917 2 snd_seq,snd_pcm snd52889 10 snd_timer,snd_seq_device,snd_seq,snd_pcm,snd_hwdep,snd_hda_codec,snd_hda_intel,snd_hda_codec_realtek soundcore 13065 1 snd Alguien me puede arrojar algo de luz a ver por donde puedo seguir mirando? -- 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/CAJs4OpspEV0L8vvgzqqd40L�3dL_oTAeN5Q_fePbhtvh+=k...@mail.gmail.com
Re: Consulta sobre infraestructura en Debian, Brouter, etc
On 03/08/14 08:33, José Miguel (sio2) wrote: El Sat, 02 de Aug de 2014, a las 03:19:08PM +0200, Mariano Cediel dijo: Si quisieras enrutar ... openvpn ... pero como no es el caso ... openvpn también se puede usar en capa 2, y los extremos estarán en la misma red. Ahora bien, tiene buena pinta el enlace que has puesto. A ver si tengo un poco de tiempo y hago probaturas con lo que propone. De todos modos, no he entendido muy bien el objeto del hilo: si toda la infraestructura es suya, ¿qué diferencia hay entre este tramo de red y cualquier otro tramo para buscar soluciones de seguidad adicionales a las que se implementan en el resto de la red? Un saludo. Jose, el objeto del hilo se desvirtua siempre cuando alguien responde algo que no se preguntó... Te reitero. Tengo 2 oficinas distanciadas a 100 mts. Tengo 2 enlaces de fibra (por redundancia) que terminan en un switch en cada extremo que también yo administro. Yo solo pregunté que se podría poner en cada extremo para securizar TODO el tráfico. Aclaro, no pedi que me digan como hacerlo, solo opiniones como si fuera una mesa de colegas donde cada uno aporta su opinión en función de su criterio. Eso era todo... :( -- 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/53df7308.1080...@gmail.com
Re: Consulta sobre infraestructura en Debian, Brouter, etc
On 03/08/14 08:05, Camaleón wrote: El Sat, 02 Aug 2014 19:48:14 -0300, ciracusa escribió: On 02/08/14 11:07, Camaleón wrote: Es que verás, si no sabes lo que quieres proteger malamente te podemos Como llegas a esta conclusión? Pues leyendo tu pregunta ya que no aportas ningún tipo de dato. Yo si se lo que quiero proteger, solo que no me pareció necesario mencionarlo justamente para no hacer tan complicado el post. Pero hombre ¿cómo no va a ser necesario? O_o Si no sabemos qué servicios vas a proporcionar, qué infraestructuras vas a instalar (más allá de un par de cables de fibra) ni con qué componentes de harwdare va a contar tu red pues ya me dirás qué tipo de respuesta te podemos ofrecer. dar indicaciones cómo protegerlo. Nunca se puede lograr un debate pleno sobre esto que nos enriquezca a todos. No hay debate posible sin argumentos y en este caso no es que no haya argumento es que ni quiera hay pregunta :-/ Pero de donde sacas que no hay pregunta? No, no la hay, tienes que concretarla mucho más para que sea útil porque no podemos darte un tratado de seguridad en la red en una lista de correo. Camaleon, un amigo decía... las batallas contra las mujeres son las únicas que se ganan huyendo... cuanta razón tenía... Y lo decía hace 200 años... Pues ya puedes empezar a correrX-) Y si, si asumes que tu criterio es el único que vale no tiene sentido seguir dialogando contigo. 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/53df734f.1030...@gmail.com
Re: [OT] Sistema de Archivos
El día 4 de agosto de 2014, 8:00, Emmanuel Brenes brenil...@hotmail.com escribió: El 01/08/2014 21:19, Emmanuel Brenes escribió: Buenas, buenas, compañeros. Estos días he notado como Ext4 ya no da mucho de sí en cuanto a rendimiento y velocidad, ya que manejo archivos muy grandes (por lo mínimo 10 GB) necesito acceso a los mismos rápidamente. Aclaro que tampoco es un servidor, es un computador de escritorio, pero por cuestiones de trabajo/estudio, manejo archivos de considerable tamaño. Hice la tarea e investigué acerca de los FS con más atributos -útiles- para mi caso. Tengo interés en que el FS tenga 'journal' o algo que lo iguale, según el caso, y que al menos sea más rápido que Ext4 en lectura y escritura. Btrfs queda descartado por el simple hecho de que lo considero demasiado nuevo, y quiero algo que estable. Aparte, tengo entendido -si no es así me dicen- que los tres de abajo, tienen adjudicación dinámica de inodos, detalle que me interesa bastante, si recomiendan algún otro FS. Mi lista la conforman pocos FS: XFS, ZFS o JFS. Me gustaría conocer su opinión. ¡Saludos! Buenas, buenas, compañeros. Siguiendo las recomendaciones de optimizar un poco al viejo Ext4, logré una mejora a nivel de lecto/escritura, no obstante, sigo considerando aún un cambio de sistema de archivos, por lo que alguna experiencia similar con los sistemas de archivos (JFS o XFS) me sería de gran ayuda. ¡Gracias a todos! Saludos. Aunque estoy un poco oxidado en este tema, lo que deberías hacer si tienes opción y tiempo es probar :-D. En cualquier caso, mi recomendación sería XFS o JFS, en su momento yo me decante por el primero, pero son igualmente válidos. Hablo de memoria, pero como desventajas puedes apuntar que generan más carga de CPU que otras opciones, y algunas operaciones son algo más lentas en comparación con ext?, borrar miles de pequeños ficheros puede suponer un pico de carga. A su favor, encontré que el resto de operaciones suelen ser más rápidas y estables. El journal y las quotas por ejemplo, son nativos y las estructuras son completamente dinámica, cosa que no ocurría en ext? que usaba bitmaps. En cualquier caso, a diferencia de ext? y de reiserfs con los que he tenido algún problema de inconsistencia de datos, con XFS siempre ha ido perfectamente incluso con cortes eléctricos reiterados, la recuperación ha sido siempre satisfactorias y mucho más rápida que con ext?, y el único problema que recuerdo achacarle al final era un problema del disco que lo contenía. Todo lo anterior como digo es basado en mi experiencia de hace años, con lo que el panorama actual seguro que es diferente para todos los FS, como decía, si tienes oportunidad, coge unos datos de muestra del uso que vas a dar, y prueba los FS tu mismo y toquetea los parámetros. Ya nos contarás y así nos actualizamos un poco. ;-). Un FS en XFS que uso con una configuración creo que casi por defecto: xfs (rw,nosuid,nodev,noexec,noatime,nodiratime,attr2,delaylog,quota) Un saludo -- 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/CAALjaLWz01iCCDoiScPJDCMsd3+a6T4bLaJ8-AR=kvwerbn...@mail.gmail.com
Re: Consulta sobre infraestructura en Debian, Brouter, etc
El 4 de agosto de 2014, 8:49, ciracusa cirac...@gmail.com escribió: On 03/08/14 08:05, Camaleón wrote: El Sat, 02 Aug 2014 19:48:14 -0300, ciracusa escribió: On 02/08/14 11:07, Camaleón wrote: Es que verás, si no sabes lo que quieres proteger malamente te podemos Como llegas a esta conclusión? Pues leyendo tu pregunta ya que no aportas ningún tipo de dato. Yo si se lo que quiero proteger, solo que no me pareció necesario mencionarlo justamente para no hacer tan complicado el post. Pero hombre ¿cómo no va a ser necesario? O_o Si no sabemos qué servicios vas a proporcionar, qué infraestructuras vas a instalar (más allá de un par de cables de fibra) ni con qué componentes de harwdare va a contar tu red pues ya me dirás qué tipo de respuesta te podemos ofrecer. dar indicaciones cómo protegerlo. Nunca se puede lograr un debate pleno sobre esto que nos enriquezca a todos. No hay debate posible sin argumentos y en este caso no es que no haya argumento es que ni quiera hay pregunta :-/ Pero de donde sacas que no hay pregunta? No, no la hay, tienes que concretarla mucho más para que sea útil porque no podemos darte un tratado de seguridad en la red en una lista de correo. Camaleon, un amigo decía... las batallas contra las mujeres son las únicas que se ganan huyendo... cuanta razón tenía... Y lo decía hace 200 años... Pues ya puedes empezar a correrX-) Y si, si asumes que tu criterio es el único que vale no tiene sentido seguir dialogando contigo. 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/53df734f.1030...@gmail.com Si se puede tiene alguna logica al menos que labures en un lugar que tu info valga millones (muchos) por que violar la seguridad de una fibra no es facil (para nada) complicado , costoso y muy ovio yo optaria por violar la seguridad en otro lado en los switch (por ejemplo) -- MrIX Linux user number 412793. http://counter.li.org/ las grandes obras, las sueñan los santos locos, las realizan los luchadores natos, las aprovechan los felices cuerdo, y las critican los inútiles crónicos,
Re: [OT] Sistema de Archivos
El lunes, 4 ago 2014 a las 13:53 horas (UTC+2), Francisco SG escribió: En cualquier caso, a diferencia de ext? y de reiserfs con los que he tenido algún problema de inconsistencia de datos, con XFS siempre ha ido perfectamente incluso con cortes eléctricos reiterados, ¿Sin SAI (UPS)? Hace ya unos cuantos años, 8 ó 9, decidí cambiar ext3 que era muy lento y fragmentaba que daba gusto. Uno de los SF que probé, durante un breve tiempo, fue XFS. Todo iba bien hasta un corte de electricidad: el sistema de ficheros se mantuvo incorrupto pero un fichero que estaba modificando fue truncado. No sé si ese era, o sigue siendo, el comportamiento a esperar. Saludos. -- Manolo Díaz -- 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/20140804141739.263cb...@gmail.com
Re: [OT] Sistema de Archivos
El día 4 de agosto de 2014, 14:17, Manolo Díaz diaz.man...@gmail.com escribió: El lunes, 4 ago 2014 a las 13:53 horas (UTC+2), Francisco SG escribió: En cualquier caso, a diferencia de ext? y de reiserfs con los que he tenido algún problema de inconsistencia de datos, con XFS siempre ha ido perfectamente incluso con cortes eléctricos reiterados, ¿Sin SAI (UPS)? Hace ya unos cuantos años, 8 ó 9, decidí cambiar ext3 que era muy lento y fragmentaba que daba gusto. Uno de los SF que Las pruebas eran precisamente para eso, comprobar hasta donde aguantaba, ahora el panorama debe ser diferente, pero entonces, un fallo completo podía acabar con el SF corrupto. Y efectivamente, la no-fragmentación era otra ventaja, ahora que ext4 usa extents supongo que ha mejorado :-) probé, durante un breve tiempo, fue XFS. Todo iba bien hasta un corte de electricidad: el sistema de ficheros se mantuvo incorrupto pero un fichero que estaba modificando fue truncado. No sé si ese era, o sigue siendo, el comportamiento a esperar. Yo entiendo que ese comportamiento es el deseable, en un caso así, pierdes los últimos cambios (esto es inevitable), luego se reconstruye el journal, se aplica si es posible y si no se descarta y a funcionar. En todo caso el SF queda operativo y consistente, sin parada para recuperar, todo lo hace el sólo al arrancar de nuevo. Aunque me reitero, seguro que ahora el panorama en todos los FS es mucho mejor que entonces y debería actualizarme un poco ;-). Saludos. -- Manolo Díaz Un saludo -- 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/CAALjaLXwGjwbKzTdd47qXwKwV2_PqNuwvDxhmtS2GFb2+q=y...@mail.gmail.com
Re: Consulta sobre infraestructura en Debian, Brouter, etc
El Mon, 04 de Aug de 2014, a las 08:48:24AM -0300, ciracusa dijo: Jose, el objeto del hilo se desvirtua siempre cuando alguien responde algo que no se preguntó... Bueno, la respuesta creo que sí va encaminada a responderte: si quieres seguridad cifra la información. Con ese tunel o con vpn en capa 2. Te reitero. Tengo 2 oficinas distanciadas a 100 mts. Tengo 2 enlaces de fibra (por redundancia) que terminan en un switch en cada extremo que también yo administro. Yo solo pregunté que se podría poner en cada extremo para securizar TODO el tráfico. Yo no haría nada de particular: la fibra es tuya. No sé si ese espacio de 100 metros de separación no es vuestro, pero ¿cómo van a sacar información de esos dos conductos de fibra? Eso no es un cable de cobre que en un momento se corte. Como no esté detrás de vosotros el servicio secreto de algún país, me parece a mí que te calientas la cabeza demasiado. Si, pese a lo cual, quieres ponerte conspiranoico, cifra. Un saludo -- Y mis desdichas son como cerezas, que voy por una y, de una en otra asidas, vuelvo con todo un plato de tristezas. --- Tomé de Burguillos --- -- 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/20140804125322.ga17...@cubo.casa
Re: OT: IDE para C++
El 29/07/14 10:27, Haylem Candelario Bauzá del INOR escribió: Realmente la solucion para ti es QT creator, es lo mejor que te puedas encontrar, ademas que es multiplataforma, puedes compilar tus programas en windows/linux/mac sin tocar el codigo. Ademas puedes compilar tus apps para mobiles android. Al aprenderlo te va a durar el conocimiento puesto que este programa avanza mucho no pasa de moda facilmente porque ya esta extendido QT Creator será. Me gusta eso de compilar en forma cruzada. Gracias a todos. -- 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/53df825d.3050...@gmail.com
Re: [OT] Sistema de Archivos
El lunes, 4 ago 2014 a las 14:40 horas (UTC+2), Francisco SG escribió: Yo entiendo que ese comportamiento es el deseable, en un caso así, pierdes los últimos cambios (esto es inevitable), luego se reconstruye el journal, se aplica si es posible y si no se descarta y a funcionar. Entiendo entonces que la restauración a partir del journal había que hacerla manualmente y que perdí ese fichero por ignorancia. ¿Es así? Saludos. -- Manolo Díaz -- 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/20140804145505.78c49...@gmail.com
Re: Consulta sobre infraestructura en Debian, Brouter, etc
El Mon, 04 Aug 2014 08:49:35 -0300, ciracusa escribió: On 03/08/14 08:05, Camaleón wrote: El Sat, 02 Aug 2014 19:48:14 -0300, ciracusa escribió: On 02/08/14 11:07, Camaleón wrote: Es que verás, si no sabes lo que quieres proteger malamente te podemos Como llegas a esta conclusión? Pues leyendo tu pregunta ya que no aportas ningún tipo de dato. Yo si se lo que quiero proteger, solo que no me pareció necesario mencionarlo justamente para no hacer tan complicado el post. Pero hombre ¿cómo no va a ser necesario? O_o Si no sabemos qué servicios vas a proporcionar, qué infraestructuras vas a instalar (más allá de un par de cables de fibra) ni con qué componentes de harwdare va a contar tu red pues ya me dirás qué tipo de respuesta te podemos ofrecer. (...) Y si, si asumes que tu criterio es el único que vale no tiene sentido seguir dialogando contigo. No sé a qué viene eso. En fin hijo, que te vaya bien securizando tus conexiones de fibra. 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.08.04.13.14...@gmail.com
Re: [OT] Sistema de Archivos
El día 4 de agosto de 2014, 14:55, Manolo Díaz diaz.man...@gmail.com escribió: El lunes, 4 ago 2014 a las 14:40 horas (UTC+2), Francisco SG escribió: Yo entiendo que ese comportamiento es el deseable, en un caso así, pierdes los últimos cambios (esto es inevitable), luego se reconstruye el journal, se aplica si es posible y si no se descarta y a funcionar. Entiendo entonces que la restauración a partir del journal había que hacerla manualmente y que perdí ese fichero por ignorancia. ¿Es así? Me temo que no... por defecto, las escrituras se considera realizada cuando se escribe a disco, se escriben los metadatos y se elimina del log, esto era una operación de tal modo que la interrupción abrupta no deje una operación a la mitad lo que provoca una inconsistencia en el FS que es lo que hay que evitar a toda costa, así, sólo pierdes los últimos cambios, y te quedas con ficheros quizás con información antigua (unos segundos) pero operativos, lo cual es maravilloso comparado con tener que reconstruir el árbol y buscar bloques etc, etc. Aunque todo este funcionamiento se puede variar con parámetros, incluso puedes poner el journal ¿en un SSD? por ejemplo ;-) pero te tiene que gustar el riesgo o conocer bien lo que se hace, que no es mi caso :-D Por lo tanto, entiendo que lo normal es quedarte con la información del FS consistente y si tienes suerte recuperar el journal... cosa creo que bastante improbable. Pero tampoco me creas del todo que veo que las cosas han mejorado bastante. Saludos. -- Manolo Díaz Un saludo -- 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/CAALjaLW6UGokHa-PTfwV72WLeAUtaaaNMSD=sdpmuj9r...@mail.gmail.com
Re: Sin sonido. Drivers Alsa.
El Mon, 04 Aug 2014 12:01:06 +0200, Usuario Lista escribió: Buenas. Tengo problemas con el sonido de mi pc. Lo he intentado configurar con los drivers Alsa y he seguido esta url https://wiki.debian.org/ALSA sin éxito ninguno. Convendría que mandaras a la lista los resultados de los comandos y pruebas que hayas hecho para que veamos la salida, principalmente aplay - l. Mi Debian es la 7.6. ¿Y qué entorno de escritorio usas (KDE, GNOME, XFCE...)? Cuando pulso en Alsamixergui me da el siguiente error: Alxamixer: function snd_mixer_load failed: Invalid argument Cuando ejecuto alsactl init me da el siguiente error: Found hardware: HDA-Intel Realtek ALC887-VD HDA:10ec0887,1458a002,00100302 0x1458 0xa002 Hardware is initialized using a generic method /usr/share/alsa/init/default:26: control element not found /usr/share/alsa/init/default:26: control element not found /usr/share/alsa/init/default:48: control element not found Cuando ejecuto /etc/init.d/alsa-utils start me da el siguiente error: amixer: Mixer hw:0 load error: Invalid argument Kernel usado: 3.2.0-4-amd64 ¿Has pensando en probar un kernel superior? Por ejemplo, el que hay en los backports, para descartar que la tarjeta no esté soportada :-? Los módulos están cargados: (...) Alguien me puede arrojar algo de luz a ver por donde puedo seguir mirando? Todo parece correcto, al menos en cuando a la detección de la tarjeta de sonido por lo que sigo pensando que puede deberse a un problema de compatibilidad con la versión del kernel (o de ALSA) que lleva wheezy de serie. Googleando he encontrado un par de enlaces que te podrían servir: [solved] I can hear clearly now the pain is gone http://crunchbang.org/forums/viewtopic.php?id=30381 [SOLVED] Sound Problem - Realtek ALC887 http://www.debianuserforums.org/viewtopic.php?f=55t=2433 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.08.04.13.28...@gmail.com
Re: [OT] Sistema de Archivos
El lunes, 4 ago 2014 a las 15:24 horas (UTC+2), Francisco SG escribió: El día 4 de agosto de 2014, 14:55, Manolo Díaz diaz.man...@gmail.com escribió: El lunes, 4 ago 2014 a las 14:40 horas (UTC+2), Francisco SG escribió: Yo entiendo que ese comportamiento es el deseable, en un caso así, pierdes los últimos cambios (esto es inevitable), luego se reconstruye el journal, se aplica si es posible y si no se descarta y a funcionar. Entiendo entonces que la restauración a partir del journal había que hacerla manualmente y que perdí ese fichero por ignorancia. ¿Es así? Me temo que no... por defecto, las escrituras se considera realizada cuando se escribe a disco, se escriben los metadatos y se elimina del log, esto era una operación de tal modo que la interrupción abrupta no deje una operación a la mitad lo que provoca una inconsistencia en el FS que es lo que hay que evitar a toda costa, así, sólo pierdes los últimos cambios, y te quedas con ficheros quizás con información antigua (unos segundos) pero operativos, lo cual es maravilloso comparado con tener que reconstruir el árbol y buscar bloques etc, etc. Aunque todo este funcionamiento se puede variar con parámetros, incluso puedes poner el journal ¿en un SSD? por ejemplo ;-) pero te tiene que gustar el riesgo o conocer bien lo que se hace, que no es mi caso :-D Por lo tanto, entiendo que lo normal es quedarte con la información del FS consistente y si tienes suerte recuperar el journal... cosa creo que bastante improbable. Pero tampoco me creas del todo que veo que las cosas han mejorado bastante. Un saludo Gracias por la aclaración. Saludos. -- Manolo Díaz -- 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/20140804161258.39367...@gmail.com
Galera clustering
Buenos dias, Quisiera saber si alguien ha utilizado y/o tiene experiencia con Galera en Debian? (http://galeracluster.com/products/) Basicamente, quisiera saber si - la experiencia ha sido satisfactoria - se adapta sin inconvenientes a Debian - performance en comparacion a una configuracion standalone - como ven la posibilidad de una configuracion de alta disponibilidad en 2 sitios alejados geograficamente (con load balancing) (Se apreciaran los comentarios basados en experiencias concretas)
solo una prueba
[OT] Re: solo una prueba
El Mon, 04 Aug 2014 16:50:32 +0200, sergio escribió: div dir=ltrbr/div Vale, pero ya que pruebas mejor que sea con mensajes en formato *texto plano* ;-P 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.08.04.14.58...@gmail.com
Re: [OT] Re: solo una prueba
2014-08-04 16:58 GMT+02:00 Camaleón noela...@gmail.com: El Mon, 04 Aug 2014 16:50:32 +0200, sergio escribió: div dir=ltrbr/div Vale, pero ya que pruebas mejor que sea con mensajes en formato *texto plano* ;-P Saludos, -- Camaleón Si lo que vas a decir no es más bello que el silencio: no lo digas. --- Proverbio árabe --- Hay algunas normas (no sé si escritas) en las listas. - No se contesta a mensajes mal formulados o incomprensibles. - No se hace el trabajo a los demás, búsquedas incluidas. - No se contesta a mensajes de prueba. ( O se contesta al privado) - No se espera que los demás entiendan tu sentido del humor. - No se contesta a todo... S2. -- 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/CAGw=rHgQ6NT6427bVTA+Xfb6rrRw--grvL3rARfdQQPXj1mw=q...@mail.gmail.com
Re: [OT] Re: solo una prueba
El lunes, 4 ago 2014 a las 17:42 horas (UTC+2), fernando sainz escribió: 2014-08-04 16:58 GMT+02:00 Camaleón noela...@gmail.com: El Mon, 04 Aug 2014 16:50:32 +0200, sergio escribió: div dir=ltrbr/div Vale, pero ya que pruebas mejor que sea con mensajes en formato *texto plano* ;-P Saludos, -- Camaleón Si lo que vas a decir no es más bello que el silencio: no lo digas. --- Proverbio árabe --- Hay algunas normas (no sé si escritas) en las listas. - No se contesta a mensajes mal formulados o incomprensibles. - No se hace el trabajo a los demás, búsquedas incluidas. - No se contesta a mensajes de prueba. ( O se contesta al privado) - No se espera que los demás entiendan tu sentido del humor. - No se contesta a todo... S2. Me gustaría añadir la de - No se ayuda a las personas que sistemática y conscientemente incumplen las normas. Regañar tontamente para después ayudar es una forma de afianzar su comportamiento. Saludos. -- Manolo Díaz -- 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/20140804181434.11310...@gmail.com
Re: [OT] Re: solo una prueba
El día 4 de agosto de 2014, 12:42, fernando sainz fernandojose.sa...@gmail.com escribió: 2014-08-04 16:58 GMT+02:00 Camaleón noela...@gmail.com: El Mon, 04 Aug 2014 16:50:32 +0200, sergio escribió: div dir=ltrbr/div Vale, pero ya que pruebas mejor que sea con mensajes en formato *texto plano* ;-P Saludos, -- Camaleón Si lo que vas a decir no es más bello que el silencio: no lo digas. --- Proverbio árabe --- Hay algunas normas (no sé si escritas) en las listas. - No se contesta a mensajes mal formulados o incomprensibles. - No se hace el trabajo a los demás, búsquedas incluidas. - No se contesta a mensajes de prueba. ( O se contesta al privado) - No se espera que los demás entiendan tu sentido del humor. - No se contesta a todo... -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Yo agregaría: -No responder a hilos ya resueltos No obviar la respuesta de los demás participantes del hilo. -- Guido Ignacio -BEGIN PGP SIGNATURE- Version: OpenPGP.js v0.5.1 Comment: http://openpgpjs.org wsBcBAEBCAAQBQJTvrWbCRDP17wMFuiP8AAAx6AH/Am/nHL7VjX3XGly/XU7 7Rg86KIuWLifNbxfgRERm9zpfe1s9LPskfOmXeUBL7vB8dQELIMS5xFwcGDp mxJ21hA2RoaOWEzH1ngRBSv0bak7rEBFsye82fKVw+VaFiNlnJ6hp+VjCoRQ 5JzVOBMnDILZisxvbWyrnoJ14VAL+4LlYxsF/E+QXDwVQGZqeGIRAnjQmexd NTQhhGi6x05BovvloHbzX8xctmC7I6t6ITc0t3b1eEIRTZE8Q9miZCFBPDQd d/PVjRB8OXdOWFFOfPKb6wfp596nWjJvjhh61R4NjI8IRsfpb/fwi6oilUgm GJr7jUQ2zzHQk4sH6PiAaVc= =16q3 -END PGP SIGNATURE- -- 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/CA+wiXxh=sddlpk95sarvezz+6vnatt5huivrb1rjb3ndu3q...@mail.gmail.com
Re: Consulta sobre infraestructura en Debian, Brouter, etc
El vie, 01-08-2014 a las 20:34 -0300, ciracusa escribió: On 01/08/14 15:31, Mariano Cediel wrote: Si va de switch a switch .. y es tu fibra quien es el enemigo que te puede hackear la red ? Desde mi movil chinaco Mariano, gracias por tu respuesta. Quien me asegura que no se corte la fibra en el medio y se pongan a escuchar el tráfico? pregunta desde la ignorancia: ¿se puede pinchar la fibra óptica?, y me respondo (también desde la ignorancia): tal vez si, poniendo un switch de fibra en el medio, pero eso implicaría tirar dos patch de fibra nuevos, y te vas a dar cuenta cuando estén instalando cosas raras. Y si es tan fácil entrar a ambas oficinas a armar toda esa conexión, poner un swith en medio del camino y demás sin que nadie se de cuenta... yo directamente me robo los equipos y listo no? -- (-.(-.(-.(-.(-.(-.-).-).-).-).-).-) -- 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/1407169823.18624.6.ca...@eeepc.ucasal.ar
Re: [OT] Sistema de Archivos
El 04/08/2014 08:12, Manolo Díaz escribió: El lunes, 4 ago 2014 a las 15:24 horas (UTC+2), Francisco SG escribió: El día 4 de agosto de 2014, 14:55, Manolo Díaz diaz.man...@gmail.com escribió: El lunes, 4 ago 2014 a las 14:40 horas (UTC+2), Francisco SG escribió: Yo entiendo que ese comportamiento es el deseable, en un caso así, pierdes los últimos cambios (esto es inevitable), luego se reconstruye el journal, se aplica si es posible y si no se descarta y a funcionar. Entiendo entonces que la restauración a partir del journal había que hacerla manualmente y que perdí ese fichero por ignorancia. ¿Es así? Me temo que no... por defecto, las escrituras se considera realizada cuando se escribe a disco, se escriben los metadatos y se elimina del log, esto era una operación de tal modo que la interrupción abrupta no deje una operación a la mitad lo que provoca una inconsistencia en el FS que es lo que hay que evitar a toda costa, así, sólo pierdes los últimos cambios, y te quedas con ficheros quizás con información antigua (unos segundos) pero operativos, lo cual es maravilloso comparado con tener que reconstruir el árbol y buscar bloques etc, etc. Aunque todo este funcionamiento se puede variar con parámetros, incluso puedes poner el journal ¿en un SSD? por ejemplo ;-) pero te tiene que gustar el riesgo o conocer bien lo que se hace, que no es mi caso :-D Por lo tanto, entiendo que lo normal es quedarte con la información del FS consistente y si tienes suerte recuperar el journal... cosa creo que bastante improbable. Pero tampoco me creas del todo que veo que las cosas han mejorado bastante. Un saludo Gracias por la aclaración. Saludos. Bastante enriquecedor salió el tema :-D eso es lo que quería ver :-P ¡Muchas gracias por contestar, Francisco! Ahora, según el entorno de pruebas que pretendo hacer (Máquinas virtuales, ni loco en mi máquina) tendré las opciones por defecto de cada FS, y les daré un archivo normal (10 GB) y lo moveré, borraré e incluso veré si puedo crearlo... el detalle sobre la carga, según he visto, JFS lo maneja mejor que los demás, un tipo de menos carga, pero un poco más lento, no obstante, las pruebas dirán que tanta verdad hay, así como la verdadera diferencia en entornos un poco más cargados. Claro, tampoco soy experto en temas de pruebas, así que será a la mano de Dios :-P Con gusto pondré mis resultados, trabajaré con XFS, JFS y Ext4, a ver qué es mejor. Al ser máquina virtual, supongo, es más sencillo aunque una prueba bare hardware (obvio, aplicado al contexto de directo sobre un computador, tipo Phoronix) sería ideal pero es lo que se tiene por ahora. ¡Saludos y gracias nuevamente! -- 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/blu437-smtp42a0a195c803489b321bb1a1...@phx.gbl
Re: Error información desconocida en ntp Debian Wheezy
El 04/08/14 01:05, Manolo Díaz escribió: El domingo, 3 ago 2014 a las 22:11 horas (UTC+2), Alberto escribió: El 03/08/14 21:42, Manolo Díaz escribió: ... Esas cifras que Maykel ha pegado no creo que difieran mucho a las que mostraría tu router que, a diferencia de tu ordenador, no tiene una conexión directa con el servidor de stratum 3 (por lo que muestras en tu correo). Si puedes logarte en tu router y ejecutar allí ntpq -p verás más claramente lo que te quiero decir. ntpd: resolved peer 1.debian.pool.ntp.org to 147.83.123.133 ntpd: sent query to 147.83.123.133 ntpd: reply from 147.83.123.133: reach 0x01 offset -0.005482 delay 0.047070 status 0x24 strat 3 refid 0xc0a83d05 rootdelay 0.002045 La orden usada importa, Alberto, porque las unidades mostradas pueden ser diferentes. Maykel usa ntpq -p, cuya salida viene dada en milisegundos, y tú has usado previamente ntpdc -p (acabo de darme cuenta), que muestra la salida en segundos y ahora los logs de ntpd, que no sé qué unidad de tiempo usa, supongo que también el segundo. Cierto, es que yo siempre uso el ntpdc -p, y no expresan en la misma unidad... ~$ ntpdc -p remote local st poll reach delay offsetdisp === *84.88.69.32 192.168.1.10 2 256 377 0.02856 0.000375 0.11035 ~$ ntpq -p remote refid st t when poll reach delay offset jitter == *84.88.69.32 193.67.79.2022 u 79 256 377 28.5700.375 1.558 -- 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/53dfb9b6.4010...@bersol.info
Re: Consulta sobre infraestructura en Debian, Brouter, etc
El Mon, 04 Aug 2014 13:30:23 -0300, Gonzalo Rivero escribió: pregunta desde la ignorancia: ¿se puede pinchar la fibra óptica?, y me respondo (también desde la ignorancia): tal vez si, poniendo un switch de fibra en el medio, pero eso implicaría tirar dos patch de fibra nuevos, y te vas a dar cuenta cuando estén instalando cosas raras. Me parece que os estáis ahogando en un vaso de agua :-) Ya sea fibra óptica o burro manchego, estamos hablando de un sistema físico de transmisión de datos, lo cual es completamente transparente para las aplicaciones. Es decir, si un paquete que contiene información que queremos proteger tiene que viajar de A hasta B, usando el canal de fibra irá muy rápido y en burro llegará más tarde a su destino pero en ambos casos puede haber bandoleros por el camino que se quieran hacer con el botín y en ese caso, o el paquete va cifrado en la fibra u oculto en el burro o te lo van a interceptar. Eso, traducido en un entorno informático significa que cualquier equipo conectado a una misma red (ya sea Internet, local, semi-privada -VPN-, UMTS, etc...) puede estar configurado para escuchar el tráfico que circula por ella y si los datos que se transmiten no están cifrados y van en texto claro (como p. ej., las contraseñas de las cuentas de correo, el login de una sesión FTP, etc...) un programa como snort (sniffer) te permite obtener información muy interesante. Y si es tan fácil entrar a ambas oficinas a armar toda esa conexión, poner un swith en medio del camino y demás sin que nadie se de cuenta... yo directamente me robo los equipos y listo no? Sólo con conectar un llave USB a uno de los equipos ya te puede montar un cristo de mucho cuidado. Por eso le decía a nuestro amigo que la seguridad empieza por un cable y termina por el servidor web. 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.08.04.17.25...@gmail.com
Problema en script de inicio de 'stunnel4'
Buenas tardes.
Me he encontrado con un error en uno de mis servidores y por muchas
vueltas que le dé a la cabeza no consigo encontrar el error.
El problema es con el paquete 'stunnel4', concretamente con el
script de inicio (start/stop/restart/reload):
cat /etc/init.d/stunnel4
#! /bin/sh -e
### BEGIN INIT INFO
# Provides: stunnel4
# Required-Start:$local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Should-Start: $syslog
# Should-Stop: $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start or stop stunnel 4.x (SSL tunnel for network daemons)
# Description: Starts or stops all configured SSL network
tunnels. Each *.conf file in
#/etc/stunnel/ will spawn a separate stunnel
process. The list of files
#can be overriden in /etc/default/stunnel, and
that same file can be used
#to completely disable *all* tunnels.
### END INIT INFO
DEFAULTPIDFILE=var/run/stunnel4.pid
DAEMON=/usr/bin/stunnel4
NAME=stunnel
DESC=SSL tunnels
OPTIONS=
ENABLED=0
get_pids() {
local file=$1
if test -f $file; then
CHROOT=`grep ^chroot $file|sed s;.*= *;;`
PIDFILE=`grep ^pid $file|sed s;.*= *;;`
if [ $PIDFILE = ]; then
PIDFILE=$DEFAULTPIDFILE
fi
if test -f $CHROOT/$PIDFILE; then
cat $CHROOT/$PIDFILE
fi
fi
}
startdaemons() {
if ! [ -d /var/run/stunnel4 ]; then
rm -rf /var/run/stunnel4
install -d -o stunnel4 -g stunnel4 /var/run/stunnel4
fi
for file in $FILES; do
if test -f $file; then
ARGS=$file $OPTIONS
PROCLIST=`get_pids $file`
if [ $PROCLIST ] kill -s 0 $PROCLIST 2/dev/null; then
echo -n [Already running: $file]
elif $DAEMON $ARGS; then
echo -n [Started: $file]
else
echo [Failed: $file]
echo You should check that you have specified the pid= in you
configuration file
exit 1
fi
fi
done;
}
killdaemons()
{
SIGNAL=${1:-TERM}
for file in $FILES; do
PROCLIST=`get_pids $file`
if [ $PROCLIST ] kill -s 0 $PROCLIST 2/dev/null; then
kill -s $SIGNAL $PROCLIST
echo -n [stopped: $file]
fi
done
}
if [ x$OPTIONS != x ]; then
OPTIONS=-- $OPTIONS
fi
test -f /etc/default/stunnel4 . /etc/default/stunnel4
if [ $ENABLED = 0 ] ; then
echo $DESC disabled, see /etc/default/stunnel4
exit 0
fi
# If the user want to manage a single tunnel, the conf file's name
# is in $2. Otherwise, respect /etc/default/stunnel4 setting. If no
# setting there, use /etc/stunnel/*.conf
if [ -n ${2:-} ]; then
if [ -e /etc/stunnel/$2.conf ]; then
FILES=/etc/stunnel/$2.conf
else
echo 2 /etc/stunnel/$2.conf does not exist.
exit 1
fi
else
if [ -z $FILES ]; then
FILES=/etc/stunnel/*.conf
fi
fi
test -x $DAEMON || exit 0
set -e
case $1 in
start)
echo -n Starting $DESC:
startdaemons
echo $NAME.
;;
stop)
echo -n Stopping $DESC:
killdaemons
echo $NAME.
;;
reopen-logs)
echo -n Reopening log files $DESC:
killdaemons USR1
echo $NAME.
;;
force-reload|reload)
echo -n Reloading configuration $DESC:
killdaemons HUP
echo $NAME.
;;
restart)
echo -n Restarting $DESC:
killdaemons
sleep 5
startdaemons
echo $NAME.
;;
*)
N=/etc/init.d/$NAME
echo Usage: $N {start|stop|reload|reopen-logs|restart}
[stunnel instance] 2
exit 1
;;
esac
exit 0
En resumidas cuentas, por lo que alcanzo a entender, el script:
- Busca todos los archivos de configuración (.conf) ubicados en
/etc/stunnel4/, y por cada uno de ellos, extrae unos parámetros
(CHROOT y PIDFILE). Si éstos existen, usa la función get_pids() para
obtener el pid del proceso stunnel. En caso contrario, devuelve un
valor vacío.
- Si se pide un 'START', comprueba si existe un pid activo y no es
así, lo levanta.
- Si se pide un 'STOP', lo contrario, etc.
El asunto es que, cada vez que lanzo un /etc/init.d/stunnel4
(start/stop/restart), me aparece el error:
Starting SSL tunnels : [started: test: 32: /var/lib/stunnel4]
unexpected operator
Tras comprobar los logs me consta que el script lee correctamente
mi fichero de configuración '/etc/stunnel4/stunnel.conf'.
He 'destripado' el script y he podido ratificar que, extrayendo
línea a línea y probándolo en la shell, todo funciona como debería
(toma correctamente los valores 'chroot = /var/lib/stunnel4/' y 'pid =
/stunnel.pid' del fichero de configuración). En cambio, si utilizo el
script tal cual, no funciona.
Como ejemplo, he probado un pequeño 'hack' en el que he modificado
la función get_pids(), evitando las comprobaciones y forzando
Re: Problema en script de inicio de 'stunnel4' [solucionado]
On Mon, Aug 4, 2014 at 7:40 PM, F. J. Blanco security.deb...@gmail.com wrote: ... Y el caso es que así, funciona. ¿Dónde puedo estar metiendo la pata? Perdón por el ladrillo, toda sugerencia será bienvenida. Saludos. P.D: Sé que no se trata de un bug del paquete, pues en otra máquina el script funciona perfectamente, con idéntica configuración. Asunto resuelto. No hay nada como meter unos cuantos 'echos' para depurar dónde se produce el error. Por si a alguien más le ocurriese, el fallo estaba en el fichero de configuración del stunnel4, concretamente en el parámetro: chroot = /var/lib/stunnel4 Simplemente, existía un 'invisible espacio' al final de la línea, que al lanzar el script, en: cat $CHROOT/$PIDFILE Convertía (al traducir las variables): cat /var/lib/stunnel4///stunnel.pid En: cat /var/lib/stunnel/[ ]//stunnel.pid Y ahí estaba el error. Un saludo. -- 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/cadgsyemqdxpgurykhhvxug7qek4ys95hmqyqy9szuy5thfm...@mail.gmail.com
Re: Problema en script de inicio de 'stunnel4'
2014-08-04 19:40 GMT+02:00 F. J. Blanco security.deb...@gmail.com:
Buenas tardes.
Me he encontrado con un error en uno de mis servidores y por muchas
vueltas que le dé a la cabeza no consigo encontrar el error.
El problema es con el paquete 'stunnel4', concretamente con el
script de inicio (start/stop/restart/reload):
cat /etc/init.d/stunnel4
#! /bin/sh -e
### BEGIN INIT INFO
# Provides: stunnel4
# Required-Start:$local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Should-Start: $syslog
# Should-Stop: $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start or stop stunnel 4.x (SSL tunnel for network
daemons)
# Description: Starts or stops all configured SSL network
tunnels. Each *.conf file in
#/etc/stunnel/ will spawn a separate stunnel
process. The list of files
#can be overriden in /etc/default/stunnel, and
that same file can be used
#to completely disable *all* tunnels.
### END INIT INFO
DEFAULTPIDFILE=var/run/stunnel4.pid
DAEMON=/usr/bin/stunnel4
NAME=stunnel
DESC=SSL tunnels
OPTIONS=
ENABLED=0
get_pids() {
local file=$1
if test -f $file; then
CHROOT=`grep ^chroot $file|sed s;.*= *;;`
PIDFILE=`grep ^pid $file|sed s;.*= *;;`
if [ $PIDFILE = ]; then
PIDFILE=$DEFAULTPIDFILE
fi
if test -f $CHROOT/$PIDFILE; then
cat $CHROOT/$PIDFILE
fi
fi
}
startdaemons() {
if ! [ -d /var/run/stunnel4 ]; then
rm -rf /var/run/stunnel4
install -d -o stunnel4 -g stunnel4 /var/run/stunnel4
fi
for file in $FILES; do
if test -f $file; then
ARGS=$file $OPTIONS
PROCLIST=`get_pids $file`
if [ $PROCLIST ] kill -s 0 $PROCLIST 2/dev/null; then
echo -n [Already running: $file]
elif $DAEMON $ARGS; then
echo -n [Started: $file]
else
echo [Failed: $file]
echo You should check that you have specified the pid= in you
configuration file
exit 1
fi
fi
done;
}
killdaemons()
{
SIGNAL=${1:-TERM}
for file in $FILES; do
PROCLIST=`get_pids $file`
if [ $PROCLIST ] kill -s 0 $PROCLIST 2/dev/null; then
kill -s $SIGNAL $PROCLIST
echo -n [stopped: $file]
fi
done
}
if [ x$OPTIONS != x ]; then
OPTIONS=-- $OPTIONS
fi
test -f /etc/default/stunnel4 . /etc/default/stunnel4
if [ $ENABLED = 0 ] ; then
echo $DESC disabled, see /etc/default/stunnel4
exit 0
fi
# If the user want to manage a single tunnel, the conf file's name
# is in $2. Otherwise, respect /etc/default/stunnel4 setting. If no
# setting there, use /etc/stunnel/*.conf
if [ -n ${2:-} ]; then
if [ -e /etc/stunnel/$2.conf ]; then
FILES=/etc/stunnel/$2.conf
else
echo 2 /etc/stunnel/$2.conf does not exist.
exit 1
fi
else
if [ -z $FILES ]; then
FILES=/etc/stunnel/*.conf
fi
fi
test -x $DAEMON || exit 0
set -e
case $1 in
start)
echo -n Starting $DESC:
startdaemons
echo $NAME.
;;
stop)
echo -n Stopping $DESC:
killdaemons
echo $NAME.
;;
reopen-logs)
echo -n Reopening log files $DESC:
killdaemons USR1
echo $NAME.
;;
force-reload|reload)
echo -n Reloading configuration $DESC:
killdaemons HUP
echo $NAME.
;;
restart)
echo -n Restarting $DESC:
killdaemons
sleep 5
startdaemons
echo $NAME.
;;
*)
N=/etc/init.d/$NAME
echo Usage: $N {start|stop|reload|reopen-logs|restart}
[stunnel instance] 2
exit 1
;;
esac
exit 0
En resumidas cuentas, por lo que alcanzo a entender, el script:
- Busca todos los archivos de configuración (.conf) ubicados en
/etc/stunnel4/, y por cada uno de ellos, extrae unos parámetros
(CHROOT y PIDFILE). Si éstos existen, usa la función get_pids() para
obtener el pid del proceso stunnel. En caso contrario, devuelve un
valor vacío.
- Si se pide un 'START', comprueba si existe un pid activo y no es
así, lo levanta.
- Si se pide un 'STOP', lo contrario, etc.
El asunto es que, cada vez que lanzo un /etc/init.d/stunnel4
(start/stop/restart), me aparece el error:
Starting SSL tunnels : [started: test: 32: /var/lib/stunnel4]
unexpected operator
Tras comprobar los logs me consta que el script lee correctamente
mi fichero de configuración '/etc/stunnel4/stunnel.conf'.
He 'destripado' el script y he podido ratificar que, extrayendo
línea a línea y probándolo en la shell, todo funciona como debería
(toma correctamente los valores 'chroot = /var/lib/stunnel4/' y 'pid =
Re: [OT] Re: solo una prueba
El día 4 de agosto de 2014, 12:20, Guido Ignacio guidoigna...@gmail.com escribió: El día 4 de agosto de 2014, 12:42, fernando sainz fernandojose.sa...@gmail.com escribió: 2014-08-04 16:58 GMT+02:00 Camaleón noela...@gmail.com: El Mon, 04 Aug 2014 16:50:32 +0200, sergio escribió: div dir=ltrbr/div Vale, pero ya que pruebas mejor que sea con mensajes en formato *texto plano* ;-P Saludos, -- Camaleón Si lo que vas a decir no es más bello que el silencio: no lo digas. --- Proverbio árabe --- Hay algunas normas (no sé si escritas) en las listas. - No se contesta a mensajes mal formulados o incomprensibles. - No se hace el trabajo a los demás, búsquedas incluidas. - No se contesta a mensajes de prueba. ( O se contesta al privado) - No se espera que los demás entiendan tu sentido del humor. - No se contesta a todo... Yo agregaría: -No responder a hilos ya resueltos No obviar la respuesta de los demás participantes del hilo. Y para que agregan tantas cosas, si ya sabemos que hace lo que quiere, incluso no estar suscrito a la lista. -- usuario linux #274354 normas de la lista: http://wiki.debian.org/es/NormasLista como hacer preguntas inteligentes: http://www.sindominio.net/ayuda/preguntas-inteligentes.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/caaizax7e71-tk+ykxdequs4odgtsecftm1amej8k3chjo15...@mail.gmail.com
Re: Sin sonido. Drivers Alsa.
El día 4 de agosto de 2014, 15:28, Camaleón noela...@gmail.com escribió: El Mon, 04 Aug 2014 12:01:06 +0200, Usuario Lista escribió: Buenas. Tengo problemas con el sonido de mi pc. Lo he intentado configurar con los drivers Alsa y he seguido esta url https://wiki.debian.org/ALSA sin éxito ninguno. Convendría que mandaras a la lista los resultados de los comandos y pruebas que hayas hecho para que veamos la salida, principalmente aplay - l. Mi Debian es la 7.6. ¿Y qué entorno de escritorio usas (KDE, GNOME, XFCE...)? Cuando pulso en Alsamixergui me da el siguiente error: Alxamixer: function snd_mixer_load failed: Invalid argument Cuando ejecuto alsactl init me da el siguiente error: Found hardware: HDA-Intel Realtek ALC887-VD HDA:10ec0887,1458a002,00100302 0x1458 0xa002 Hardware is initialized using a generic method /usr/share/alsa/init/default:26: control element not found /usr/share/alsa/init/default:26: control element not found /usr/share/alsa/init/default:48: control element not found Cuando ejecuto /etc/init.d/alsa-utils start me da el siguiente error: amixer: Mixer hw:0 load error: Invalid argument Kernel usado: 3.2.0-4-amd64 ¿Has pensando en probar un kernel superior? Por ejemplo, el que hay en los backports, para descartar que la tarjeta no esté soportada :-? Los módulos están cargados: (...) Alguien me puede arrojar algo de luz a ver por donde puedo seguir mirando? Todo parece correcto, al menos en cuando a la detección de la tarjeta de sonido por lo que sigo pensando que puede deberse a un problema de compatibilidad con la versión del kernel (o de ALSA) que lleva wheezy de serie. Googleando he encontrado un par de enlaces que te podrían servir: [solved] I can hear clearly now the pain is gone http://crunchbang.org/forums/viewtopic.php?id=30381 [SOLVED] Sound Problem - Realtek ALC887 http://www.debianuserforums.org/viewtopic.php?f=55t=2433 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.08.04.13.28...@gmail.com Solucionado. En este link, en la segunda respuesta tenéis la solución para aquellos que les ocurra. https://answers.launchpad.net/ubuntu/+source/alsa-driver/+question/159105 Gracias Camaleon. -- 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/cajs4opskisa9dkbmnjqd8qadac03nqysplfyszj6fcura3w...@mail.gmail.com
Re: [OT] Sistema de Archivos
Buenas, 2014-08-04 18:21 GMT+02:00 Emmanuel Brenes brenil...@hotmail.com: El 04/08/2014 08:12, Manolo Díaz escribió: El lunes, 4 ago 2014 a las 15:24 horas (UTC+2), Francisco SG escribió: El día 4 de agosto de 2014, 14:55, Manolo Díaz diaz.man...@gmail.com escribió: El lunes, 4 ago 2014 a las 14:40 horas (UTC+2), Francisco SG escribió: Yo entiendo que ese comportamiento es el deseable, en un caso así, pierdes los últimos cambios (esto es inevitable), luego se reconstruye el journal, se aplica si es posible y si no se descarta y a funcionar. Entiendo entonces que la restauración a partir del journal había que hacerla manualmente y que perdí ese fichero por ignorancia. ¿Es así? Me temo que no... por defecto, las escrituras se considera realizada cuando se escribe a disco, se escriben los metadatos y se elimina del log, esto era una operación de tal modo que la interrupción abrupta no deje una operación a la mitad lo que provoca una inconsistencia en el FS que es lo que hay que evitar a toda costa, así, sólo pierdes los últimos cambios, y te quedas con ficheros quizás con información antigua (unos segundos) pero operativos, lo cual es maravilloso comparado con tener que reconstruir el árbol y buscar bloques etc, etc. Aunque todo este funcionamiento se puede variar con parámetros, incluso puedes poner el journal ¿en un SSD? por ejemplo ;-) pero te tiene que gustar el riesgo o conocer bien lo que se hace, que no es mi caso :-D Por lo tanto, entiendo que lo normal es quedarte con la información del FS consistente y si tienes suerte recuperar el journal... cosa creo que bastante improbable. Pero tampoco me creas del todo que veo que las cosas han mejorado bastante. Un saludo Gracias por la aclaración. Saludos. Bastante enriquecedor salió el tema :-D eso es lo que quería ver :-P ¡Muchas gracias por contestar, Francisco! Ahora, según el entorno de pruebas que pretendo hacer (Máquinas virtuales, ni loco en mi máquina) tendré las opciones por defecto de cada FS, y les daré un archivo normal (10 GB) y lo moveré, borraré e incluso veré si puedo crearlo... el detalle sobre la carga, según he visto, JFS lo maneja mejor que los demás, un tipo de menos carga, pero un poco más lento, no obstante, las pruebas dirán que tanta verdad hay, así como la verdadera diferencia en entornos un poco más cargados. Claro, tampoco soy experto en temas de pruebas, así que será a la mano de Dios :-P Con gusto pondré mis resultados, trabajaré con XFS, JFS y Ext4, a ver qué es mejor. Al ser máquina virtual, supongo, es más sencillo aunque una prueba bare hardware (obvio, aplicado al contexto de directo sobre un computador, tipo Phoronix) sería ideal pero es lo que se tiene por ahora. ¡Saludos y gracias nuevamente! Me sorprende que nadie hable en este hilo de monitorizar las constantes del sistema mientras haces tu trabajo con esos ficheros de más de 10 GB y también me sorprende que nadie pregunte qué tipo de procesamiento haces con esos ficheros. Ejecuta vmstat 1, iostat 1 y iotop, mientras trabajas con el fichero, a ver si te canta algo. No creo que el sistema de ficheros te vaya a influir mucho. ¿Cómo lo tienes de lleno?, dicen que por encima del xx % empieza a empobrecerse el rendimiento. Por otro lado, si tienes espacio libre y tienes lvm, puedes probar el script adjunto (modificando las variables del principio y mirando que no te vaya a destrozar nada ), quizás sustituyendo el cat por el comando que tú uses para abrir el fichero y trabajar con él, para ver la diferencia entre sistemas de ficheros (eso sí, un sistema de ficheros con un único fichero no es lo mismo ... si tienes mucho espacio podrías incluso duplicar el sistema de ficheros origen). Un saludo test-fs Description: Binary data
Re: [OT] Sistema de Archivos
El 04/08/2014 15:16, Javier Barroso escribió: Buenas, 2014-08-04 18:21 GMT+02:00 Emmanuel Brenes brenil...@hotmail.com: El 04/08/2014 08:12, Manolo Díaz escribió: El lunes, 4 ago 2014 a las 15:24 horas (UTC+2), Francisco SG escribió: El día 4 de agosto de 2014, 14:55, Manolo Díaz diaz.man...@gmail.com escribió: El lunes, 4 ago 2014 a las 14:40 horas (UTC+2), Francisco SG escribió: Yo entiendo que ese comportamiento es el deseable, en un caso así, pierdes los últimos cambios (esto es inevitable), luego se reconstruye el journal, se aplica si es posible y si no se descarta y a funcionar. Entiendo entonces que la restauración a partir del journal había que hacerla manualmente y que perdí ese fichero por ignorancia. ¿Es así? Me temo que no... por defecto, las escrituras se considera realizada cuando se escribe a disco, se escriben los metadatos y se elimina del log, esto era una operación de tal modo que la interrupción abrupta no deje una operación a la mitad lo que provoca una inconsistencia en el FS que es lo que hay que evitar a toda costa, así, sólo pierdes los últimos cambios, y te quedas con ficheros quizás con información antigua (unos segundos) pero operativos, lo cual es maravilloso comparado con tener que reconstruir el árbol y buscar bloques etc, etc. Aunque todo este funcionamiento se puede variar con parámetros, incluso puedes poner el journal ¿en un SSD? por ejemplo ;-) pero te tiene que gustar el riesgo o conocer bien lo que se hace, que no es mi caso :-D Por lo tanto, entiendo que lo normal es quedarte con la información del FS consistente y si tienes suerte recuperar el journal... cosa creo que bastante improbable. Pero tampoco me creas del todo que veo que las cosas han mejorado bastante. Un saludo Gracias por la aclaración. Saludos. Bastante enriquecedor salió el tema :-D eso es lo que quería ver :-P ¡Muchas gracias por contestar, Francisco! Ahora, según el entorno de pruebas que pretendo hacer (Máquinas virtuales, ni loco en mi máquina) tendré las opciones por defecto de cada FS, y les daré un archivo normal (10 GB) y lo moveré, borraré e incluso veré si puedo crearlo... el detalle sobre la carga, según he visto, JFS lo maneja mejor que los demás, un tipo de menos carga, pero un poco más lento, no obstante, las pruebas dirán que tanta verdad hay, así como la verdadera diferencia en entornos un poco más cargados. Claro, tampoco soy experto en temas de pruebas, así que será a la mano de Dios :-P Con gusto pondré mis resultados, trabajaré con XFS, JFS y Ext4, a ver qué es mejor. Al ser máquina virtual, supongo, es más sencillo aunque una prueba bare hardware (obvio, aplicado al contexto de directo sobre un computador, tipo Phoronix) sería ideal pero es lo que se tiene por ahora. ¡Saludos y gracias nuevamente! Me sorprende que nadie hable en este hilo de monitorizar las constantes del sistema mientras haces tu trabajo con esos ficheros de más de 10 GB y también me sorprende que nadie pregunte qué tipo de procesamiento haces con esos ficheros. Ejecuta vmstat 1, iostat 1 y iotop, mientras trabajas con el fichero, a ver si te canta algo. No creo que el sistema de ficheros te vaya a influir mucho. ¿Cómo lo tienes de lleno?, dicen que por encima del xx % empieza a empobrecerse el rendimiento. Por otro lado, si tienes espacio libre y tienes lvm, puedes probar el script adjunto (modificando las variables del principio y mirando que no te vaya a destrozar nada ), quizás sustituyendo el cat por el comando que tú uses para abrir el fichero y trabajar con él, para ver la diferencia entre sistemas de ficheros (eso sí, un sistema de ficheros con un único fichero no es lo mismo ... si tienes mucho espacio podrías incluso duplicar el sistema de ficheros origen). Un saludo ¡Muchas gracias por responder, Javier! Bueno, no es de sorprenderse, creo yo que todos abarcan el tema desde una perspectiva distinta y según interpretación, conocimiento e incluso el ánimo, no obstante es precisamente lo que esperaba, ideas nuevas, distintas y que no estén en ningún lado, la experiencia y conocimiento de distintas personas. Tu aporte, como el de los demás, me parece de enorme importancia, una idea nueva y un enfoque distinto. :-D Por el lado técnico, actualmente la cantidad de archivos tiene secuestrado el 50 % del disco, sin contar que las particiones de root y swap, suman 32 GB. El disco no es muy grande, es de 500 GB. Lo del script, veré qué tal. Y actualmente no tengo mucho espacio, pues tengo pensado descargar algunos archivos de magnitudes similares a los mencionados ya. :-S ¡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/blu437-smtp3411674fe77591e52495e8a1...@phx.gbl
Re: Consulta sobre infraestructura en Debian, Brouter, etc
Si se puede tiene alguna logica al menos que labures en un lugar que tu info valga millones (muchos) por que violar la seguridad de una fibra no es facil (para nada) complicado , costoso y muy ovio yo optaria por violar la seguridad en otro lado en los switch (por ejemplo) Cristian, a que te refieres? Puedo suponer que intentas decir que poner los switchs detras de un equipo que lo proteja puede ser una buena idea? Muchas Gracias. Saludos. -- MrIX Linux user number 412793. http://counter.li.org/ las grandes obras, las sueñan los santos locos, las realizan los luchadores natos, las aprovechan los felices cuerdo, y las critican los inútiles crónicos, -- 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/53e0178e.1090...@gmail.com
Re: Consulta sobre infraestructura en Debian, Brouter, etc
On 04/08/14 14:25, Camaleón wrote: Sólo con conectar un llave USB a uno de los equipos ya te puede montar un cristo de mucho cuidado. Por eso le decía a nuestro amigo que la seguridad empieza por un cable y termina por el servidor web. Yo solo pregunté que podría poner en ambos extremos para securizar el vínculo... :( PD. No pedí que me hagan el trabajo ni siquiera que me pasen enlaces de google, solo una idea... -- 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/53e018e5.70...@gmail.com
