Re: Okular no imprime PDF, hoja en blanco.
El Sat, 31 Jan 2015 10:22:26 -0300, Walter O. Dari escribió: El 30/01/15 a las 11:55, Camaleón escribió: (...) Como baipás se me ocurre que pruebes: - Otra aplicación (obvio :-P) - Pasar el archivo PDF a PS (PostScript) Me ha pasado que con una aplicación no se imprimían los códigos de barras y con otra no había problemas, nunca entendí el por qué. No recuerdo con cual fue la que tuve inconvenientes, pero siempre he usado evince y okular, creo que fue con ésta última. A mí me pasa igual... tengo instalado epdfviewer pero es una patata (no es capaz de renderizar el 70% de los archivos PDF) por lo que he tenido que instalar GV que no sé de qué año será pero seguro que no es de este siglo :-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.2015.01.31.15.39...@gmail.com
Re: [OT] Raid por hardware
El Sat, 31 Jan 2015 11:29:04 +0100, José Miguel (sio2) escribió: El Sun, 25 de Jan de 2015, a las 07:12:30PM +, Camaleón dijo: Recuerda que no sólo tienes que asegurarte de la configuración que tienes en la BIOS para la controladora del disco duro sino también del módulo del kernel que usas en todo momento. Es decir, la teoría establece los siguientes parámetros óptimos: BIOS → módulo del kernel IDE → libata / mptctl SATA/AHCI → ahci RAID/INTEL → dm RAID/LSI → mptsas Todo esto parecía ir bien: cuando usaba la controladora RAID se cargaba el módulo mptsas, cuando no la usaba no lo hacía. En un correo anterior mencionaste que con el modo IDE activado en la BIOS se cargaba un driver que no era el habitual libata sino mptctl lo cual no deja de ser una ventaja porque te permite ir combinando opciones de configuración en la BIOS con distintos módulos del kernel para ver qué combinación se desempeña mejor. Al final resultó que sin la controladora RAID, acabaron por producirse las demoras. Definitivamente tuve que quitar el servidor y poner el ordenador normalillo para ir tirando. Ahora vuelvo a estar en precario. Sigue siendo raro. De todas formas, has hecho muchas cosas en ese equipo, yo hubiera empezado desde cero (instalando en limpio y reiniciando el array) para monitorizarlo. Después de cerciorarme de que la cosa seguía mal, decidí deshacer el RAID otra vez, pinchar los discos directamente a la placa base; y, como novedad, quitar físicamente la controladora del servidor. Hecho esto, probé... y funciona. Ahora va como un tiro. Pero te sigues olvidando del módulo del kernel y de la configuración de la BIOS. Eso no lo cité, pero lo hice también: quité la controladora y puse la BIOS la controladora en modo IDE (o AHCI no recuerdo bien). Sin tener la controladora pinchada, entiendo que se podrían haber dado dos situaciones: - IDE con driver libata - AHCI con driver ahci La secuencia para comprobar el correcto (o no) funcionamiento de la controladora raid sería la siguiente (conlleva pérdida de datos): 1/ Configurar los discos en la BIOS como RAID/LSI 2/ Acceder a la BIOS de la controladora y definir el raid 1 reinicializando los discos (se borra todo) 3/ Instalar de nuevo el sistema operativo desde cero o asegurarte de que el kernel carga el módulo adecuado (mptsas). No instalé de nuevo el sistema, pero sí comprobé que se cargaba mptsas. No valía, de hecho cuando lo puse en RAID/LSI fue cuando peor fue. Peor que con RAID/IDE o RAID/AHCI. Pero ya habías hecho muchas cosas, lo suyo -como te decía más arriba- era empezar desde cero para poder establecer una posible causa del origen del problema. De otra forma es posible que los metadatos de los discos con la información del raid esté molestando por lo que idealmente habría que empezar desde cero. No sé si molestan o no. De hecho, no tengo muy claro que el problema sea de acceso a disco. Quizás que no se sincronicen los discos es una consecuencia y no la raíz del problema. Tenías pocos datos del estado del array. En ocasiones la utilidad del raid te dice una cosa y en la BIOS de la controladora aparece otra, es decir, no hay que fiarse al 100%, es mejor comparar lo que te dice la utilidad con lo que ves desde otros sitios (la BIOS u otra aplicación). De todas formas, también te digo que en ese equipo no creo que vayas a notar una merma en el rendimiento por usar md (software raid) en lugar del raid por harwdare. Si optas por esta opción (md) recuerda poner el modo AHCI en la BIOS. En realidad usé el raid por hardware por el hecho de tener la controladora. No es un servidor que soporte mucho tráfico, ni mucho menos. Va más que sobrado. Cuando funciona bien, claro. Y no parece una controladora problemática, o la menos no he visto muchas quejas por Google sobre ese modelo. Y si no va a llevar gran carga de trabajo mejor. La actualización de la BIOS te cambió los parámetros de acceso a los discos, no sé ni cómo fue capaz de iniciar el sistema . Quizás la actualización hizo algo, pero lo cierto es que yo he probado a cambiar los parámetros de acceso a disco. Usando la controladora RAID: IDE, AHCI y LSI; y sin usar la controladora IDE y AHCI; y con todos tenía los problemas de demora. Puede ser que el problema esté en otro sitio. Puede ser, pero siempre que se hacen cambios hay que analizar los resultados no a ojo ni con percepciones sino con pruebas y datos fehacientes (registros del sistema, mensajes de error, consulta del estado del array desde varias aplicaciones, etc...) Ya contarás :-) Pues eso, que no se arregló. El problema es que ahora no tengo mucho tiempo para cambalaches. Me temo que voy a tener que dejar el ordenador de repuesto y esperar mejores tiempos. Bueno, al menos ha servido para saber algo más de esa controladora :-) Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject
Re: Okular no imprime PDF, hoja en blanco.
Hola gente: El 30/01/15 a las 11:55, Camaleón escribió: El Thu, 29 Jan 2015 22:25:12 -0300, Ricardo escribió: Mi impresora HP LaserJet Pro 1606dn imprime bien en mi Debian 8 Jessie con KDE, el problema se encuentra en que al querer imprimir un documento en PDF desde la aplicación Okular, la impresora me larga la hoja en blanco. Si sólo te pasa con esa en concreto tiene pinta de bug y una búsqueda en Google parece corroborarlo: https://www.google.es/webhp?complete=0hl=engws_rd=cr,sslei=PprLVOSPAcv9UL-tg8gP#complete=0hl=enq=okular+print+blank+page Como baipás se me ocurre que pruebes: - Otra aplicación (obvio :-P) - Pasar el archivo PDF a PS (PostScript) Me ha pasado que con una aplicación no se imprimían los códigos de barras y con otra no había problemas, nunca entendí el por qué. No recuerdo con cual fue la que tuve inconvenientes, pero siempre he usado evince y okular, creo que fue con ésta última. Saludos, Saludos, -- Walter O. Dari http://swcomputacion.com/ https://facebook.com/swcomputacion/ skype: waomda -- 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/54ccd712.2070...@gmail.com
Apache + 2 versiones de PHP
Saludos: Tengo un servidor web el cual debe ser actualizado desde hace tiempo, pero tengo la certeza que en el momento que suba la version de PHP de 5.3 a otra superior algunas webs alojadas dejarán de funcionar. Así pues que llevo dias probando de hacer correr un servidor Apache con dos versiones diferentes de PHP, e intentar que se puede indicar que version debe usar a nivel de virtualhost. En teoria esto es posible a nivel con la combinación de PHPFarm + FastCGI, pero de momento no he conseguido hacerlo funcionar y tampoco veo donde estoy fallando ya que el log no dice nada a considerar, incluso todo parece funcionar corrrectamente: [Sat Jan 31 19:08:40 2015] [notice] caught SIGTERM, shutting down [Sat Jan 31 19:08:41 2015] [notice] FastCGI: process manager initialized (pid 9410) [Sat Jan 31 19:08:41 2015] [warn] FastCGI: server /var/www/cgi-bin/php-cgi-5.3.29 started (pid 9412) [Sat Jan 31 19:08:41 2015] [notice] Apache/2.2.22 (Debian) mod_fastcgi/mod_fastcgi-SNAP-0910052141 configured -- resuming normal operations Estoy siguiendo el siguiente manual: https://dbforch.wordpress.com/2010/05/21/apache2-fastcgi-multiple-php-versions-ubuntulucid-10-04/ En cualquier caso tengo otras dudas de concepto: Si uso FastCGI para invocar PHP, supongo que todas las páginas que requieran PHP (de la versión que sea) deberán ser llamadas por FastCGI? O puedo usar PHP como modulo para algunos virtualhost y por FastCGI para otros? Al no usar PHP como módulo no puedo alterar el funcionamiento de PHP para un Virtualhost con los tags php_value? Existe alguna manera alternativa de hacerlo? Si alguien ha tenido experiencia con esta forma de llamar a PHP agradecerias sus comentarios. Muchas gracias. -- Alfonso alfo...@gnuino.net signature.asc Description: OpenPGP digital signature
Re: Apache + 2 versiones de PHP
El Sat, 31 Jan 2015 19:15:58 +0100, Alfonso escribió: Saludos: Tengo un servidor web el cual debe ser actualizado desde hace tiempo, pero tengo la certeza que en el momento que suba la version de PHP de 5.3 a otra superior algunas webs alojadas dejarán de funcionar. Una VM siempre viene bien para probar esas cosas. Así pues que llevo dias probando de hacer correr un servidor Apache con dos versiones diferentes de PHP, e intentar que se puede indicar que version debe usar a nivel de virtualhost. En teoria esto es posible a nivel con la combinación de PHPFarm + FastCGI, pero de momento no he conseguido hacerlo funcionar y tampoco veo donde estoy fallando ya que el log no dice nada a considerar, incluso todo parece funcionar corrrectamente: [Sat Jan 31 19:08:40 2015] [notice] caught SIGTERM, shutting down [Sat Jan 31 19:08:41 2015] [notice] FastCGI: process manager initialized (pid 9410) [Sat Jan 31 19:08:41 2015] [warn] FastCGI: server /var/www/cgi-bin/php-cgi-5.3.29 started (pid 9412) [Sat Jan 31 19:08:41 2015] [notice] Apache/2.2.22 (Debian) mod_fastcgi/mod_fastcgi-SNAP-0910052141 configured -- resuming normal operations Bueno, ahí te dice que está usando la versión 5.3.x ¿no? Para saber qué no funciona y/o por qué tendrías que mandar a la lista la configuración del apache para los virtualhosts y decirnos qué tipo de prueba estás haciendo exactamente para saber si funciona o no. Estoy siguiendo el siguiente manual: https://dbforch.wordpress.com/2010/05/21/apache2-fastcgi-multiple-php- versions-ubuntulucid-10-04/ En cualquier caso tengo otras dudas de concepto: Si uso FastCGI para invocar PHP, supongo que todas las páginas que requieran PHP (de la versión que sea) deberán ser llamadas por FastCGI? O puedo usar PHP como modulo para algunos virtualhost y por FastCGI para otros? (...) En teoría podrías usar para cada virtualhost un sistema distinto (mod_php y mod_fastcgi). 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.2015.01.31.20.57...@gmail.com
Re: [OT] Raid por hardware
El Sun, 25 de Jan de 2015, a las 07:12:30PM +, Camaleón dijo: Recuerda que no sólo tienes que asegurarte de la configuración que tienes en la BIOS para la controladora del disco duro sino también del módulo del kernel que usas en todo momento. Es decir, la teoría establece los siguientes parámetros óptimos: BIOS → módulo del kernel IDE → libata / mptctl SATA/AHCI → ahci RAID/INTEL → dm RAID/LSI → mptsas Todo esto parecía ir bien: cuando usaba la controladora RAID se cargaba el módulo mptsas, cuando no la usaba no lo hacía. Al final resultó que sin la controladora RAID, acabaron por producirse las demoras. Definitivamente tuve que quitar el servidor y poner el ordenador normalillo para ir tirando. Ahora vuelvo a estar en precario. Después de cerciorarme de que la cosa seguía mal, decidí deshacer el RAID otra vez, pinchar los discos directamente a la placa base; y, como novedad, quitar físicamente la controladora del servidor. Hecho esto, probé... y funciona. Ahora va como un tiro. Pero te sigues olvidando del módulo del kernel y de la configuración de la BIOS. Eso no lo cité, pero lo hice también: quité la controladora y puse la BIOS la controladora en modo IDE (o AHCI no recuerdo bien). La secuencia para comprobar el correcto (o no) funcionamiento de la controladora raid sería la siguiente (conlleva pérdida de datos): 1/ Configurar los discos en la BIOS como RAID/LSI 2/ Acceder a la BIOS de la controladora y definir el raid 1 reinicializando los discos (se borra todo) 3/ Instalar de nuevo el sistema operativo desde cero o asegurarte de que el kernel carga el módulo adecuado (mptsas). No instalé de nuevo el sistema, pero sí comprobé que se cargaba mptsas. No valía, de hecho cuando lo puse en RAID/LSI fue cuando peor fue. Peor que con RAID/IDE o RAID/AHCI. De otra forma es posible que los metadatos de los discos con la información del raid esté molestando por lo que idealmente habría que empezar desde cero. No sé si molestan o no. De hecho, no tengo muy claro que el problema sea de acceso a disco. Quizás que no se sincronicen los discos es una consecuencia y no la raíz del problema. De todas formas, también te digo que en ese equipo no creo que vayas a notar una merma en el rendimiento por usar md (software raid) en lugar del raid por harwdare. Si optas por esta opción (md) recuerda poner el modo AHCI en la BIOS. En realidad usé el raid por hardware por el hecho de tener la controladora. No es un servidor que soporte mucho tráfico, ni mucho menos. Va más que sobrado. Cuando funciona bien, claro. La actualización de la BIOS te cambió los parámetros de acceso a los discos, no sé ni cómo fue capaz de iniciar el sistema . Quizás la actualización hizo algo, pero lo cierto es que yo he probado a cambiar los parámetros de acceso a disco. Usando la controladora RAID: IDE, AHCI y LSI; y sin usar la controladora IDE y AHCI; y con todos tenía los problemas de demora. Puede ser que el problema esté en otro sitio. Ya contarás :-) Pues eso, que no se arregló. El problema es que ahora no tengo mucho tiempo para cambalaches. Me temo que voy a tener que dejar el ordenador de repuesto y esperar mejores tiempos. Saludos, Saludos. -- Flérida para mí dulce y sabrosa, más que la fruta de cercado ajeno. --- Garcilaso de la Vega --- -- 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/20150131102904.ga5...@cubo.casa
