Acabo de "elegir la pastilla roja", y es que yo tambien acabo de hacer "mi elección", aunque se que realmente la tomé hace mucho.
Hoy he migrado mi último equipo con Windows a Linux. Erá un equipo doméstico destinado al ocio, pero he decidido que no tiene sentido ;)
Después de hacer todas las pruebas de compatibilidad oportunas en el portatil, me he dicho que había llegado el momento.... y para mi sorpresa algo debía salir mal (aunque poco ;))
Al instalar el SO he descubierto que la T.Red integrada en la placa Asus P5K-E que monto no estaba soportada, jejeje menuda cara de XXX se me debe haber quedado al ver el tema, después de estar probando a conciencia, y es que se me paso completamente por alto.
[root@localhost Desktop]# lspci|grep Eth
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12)
Bueno con esto y mirando un poco por ahi dí con el driver necesario:
--> sk98lin.X
Descarga RPM's:
http://centos.toracat.org/ajb/CentOS-5/sk98lin/
Detallado en:
http://www.centos.org/modules/newbb/viewtopic.php?topic_id=12895
lunes, 26 de enero de 2009
viernes, 23 de enero de 2009
Consumo memoria "Compiz"
He estado probando "Compiz" simplemente para ver cómo funcionan los efectos 3d, y claro también para ver el consumo que le supone al equipo.
La verdad es que con 4Gb de Ram no he notado nada en cuanto a rendimiento, pero al mirar un poco más a fondo el consumo de memoria si se ve afectado. Se ha pasado de:
a un consumo "un poco" mas elevado tras la instalación y activación:
Mem: 3367548k total, 740428k used, 2627120k free, 60520k buffers
La verdad es que con 4Gb de Ram no he notado nada en cuanto a rendimiento, pero al mirar un poco más a fondo el consumo de memoria si se ve afectado. Se ha pasado de:
Mem: 3367548k total, 525376k used, 2842172k free, 54900k buffers
a un consumo "un poco" mas elevado tras la instalación y activación:
Mem: 3367548k total, 740428k used, 2627120k free, 60520k buffers
Bueno ahí queda eso, vamos que si te puedes permitir el consumode 215Mb, los efectos hacen bastante mas ameno el entorno de trabajo ;)
SSL - Convivencia, Linux/Apache vs Oracle/Apache
Hace unos días conseguimos, por fin, hacer que funcionara la conexión https entre un servidor linux con Apache y un servidor de aplicaciones con Solaris/Oracle y su Apache.
Para solucionar el problema fue determinante realizar pruebas de conexión mediante openssl s_client
A continuación detallo las pruebas de conexión y las configuraciones de los VirtualHost's
Pruebas de conexión (Distintas versiones de SSL)
Esta fue la prueba más determinante para encontrar el problema que comento.
Y es que nos dimos cuenta de que desde la máquina linux, al intentar conectar con la otra (Solaris+Oracle), la conexión se establecía o no en función de la versión de certificado que usáramos.
Aquí hicimos pruebas con puertos distintos, simplemente lo pongo como ejemplo. Nuestros SSL escuchan en el puerto 443 ambos
Si no indicas la versión de SSL usa la que tiene establecida en Apache.
Estas son las configuraciones de los VirtualHost que hacen que funcione el montaje propuesto.
ServerName XXX.es
ErrorLog logs/XXX
TransferLog logs/XXX
LogLevel warn
Options None
AllowCONNECT 443
Allow from all
ProxyRequests Off
ProxyVia On
ProxyPreserveHost On
SSLVerifyDepth 10
ProxyPass /XXX/ https://XXX:443/XXX/
ProxyPassReverse /XXX/ https://XXX:443/XXX/
ProxyPass / https://XXX:443/XXX/
ProxyPassReverse / https://XXX:443/XXX/
SSLEngine on
SSLVerifyClient optional
SSLProxyEngine on
SSLCipherSuite ALL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLProtocol -ALL +SSLv3
RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}e"
SSLProxyCipherSuite ALL:!ADH:!EXPORT56:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
SSLCertificateFile /XXX.crt
SSLCertificateKeyFile /XXX/priv.key
SSLCertificateChainFile /XXX.crt
SSLProxyCACertificateFile /XXX.crt
SSLProxyCACertificatePath /XXX.crt/
SSLCACertificatePath /XXX.crt/
SSLOptions +StdEnvVars +ExportCertData
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
Para solucionar el problema fue determinante realizar pruebas de conexión mediante openssl s_client
A continuación detallo las pruebas de conexión y las configuraciones de los VirtualHost's
El esquema es el siguiente.
Pruebas de conexión (Distintas versiones de SSL)
Esta fue la prueba más determinante para encontrar el problema que comento.
Y es que nos dimos cuenta de que desde la máquina linux, al intentar conectar con la otra (Solaris+Oracle), la conexión se establecía o no en función de la versión de certificado que usáramos.
Aquí hicimos pruebas con puertos distintos, simplemente lo pongo como ejemplo. Nuestros SSL escuchan en el puerto 443 ambos
Si no indicas la versión de SSL usa la que tiene establecida en Apache.
------------------------------------------------
openssl s_client -connect maquina.es:7878
connect: Connection refused
connect:errno=29
------------------------------------------------
Aquí podemos ver el error usando SSL2
------------------------------------------------
[usuario@Maquina_Linux ~]$ openssl s_client -ssl2 -connect maquina.es:443
CONNECTED(00000003)
XXXX:error:XXXX:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:429:
------------------------------------------------
Aquí podemos ver el error usando TLS1
------------------------------------------------
[usuario@Maquina_Linux ~]$ openssl s_client -tls1 -connect maquina.es:443
CONNECTED(00000003)
XXXX:error:XXXX:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:286:
------------------------------------------------
Esta prueba es correcta, usando la versión SSL3 y el puerto correcto.
------------------------------------------------
[usuario@Maquina_Linux ~]$ openssl s_client -ssl3 -connect maquina.es:443
CONNECTED(00000003)
depth=2 /C=ES/O=XXX/OU=XXX/CN=XXX
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
XXXX
---
Server certificate
-----BEGIN CERTIFICATE-----
XXXX
-----END CERTIFICATE-----
XXXX
SSL-Session:
Protocol : SSLv3
Cipher : XXX
Session-ID: XXX
Session-ID-ctx:
Master-Key: XXX
Key-Arg : None
Krb5 Principal: None
Start Time: XXX
Timeout : XXX
Verify return code: 19 (self signed certificate in certificate chain)
---
------------------------------------------------
Parámetros implicados
Estas son las configuraciones de los VirtualHost que hacen que funcione el montaje propuesto.
Solaris/Oracle
..................
<VirtualHost _default_:443>
DocumentRoot "/.../htdocs"
ServerName xxx.es
ServerAdmin xxx@xxx.es
Port 443
ErrorLog "|/.../logs/error_log 43200"
TransferLog "|/.../logs/access_log 43200"
SSLEngine on
SSLWallet file:/.../ssl.wlt/...
SetEnvIf User-Agent "MSIE" nokeepalive ssl-unclean-shutdown
SSLOptions +ExportCertData +StdEnvVars
SSLCipherSuite ALL:!ADH:!EXPORT56:+HIGH:+MEDIUM:+LOW:-SSLV2:+EXP
SSLProtocol +SSLv3
<Files ~ "\.(cgi|shtml)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/.../cgi-bin">
SSLOptions +StdEnvVars
</Directory>
CustomLog "|/.../logs/ssl_request_log 43200" \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
Linux
ServerName XXX.es
ErrorLog logs/XXX
TransferLog logs/XXX
LogLevel warn
Options None
AllowCONNECT 443
Allow from all
ProxyRequests Off
ProxyVia On
ProxyPreserveHost On
SSLVerifyDepth 10
ProxyPass /XXX/ https://XXX:443/XXX/
ProxyPassReverse /XXX/ https://XXX:443/XXX/
ProxyPass / https://XXX:443/XXX/
ProxyPassReverse / https://XXX:443/XXX/
SSLEngine on
SSLVerifyClient optional
SSLProxyEngine on
SSLCipherSuite ALL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLProtocol -ALL +SSLv3
RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}e"
SSLProxyCipherSuite ALL:!ADH:!EXPORT56:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
SSLCertificateFile /XXX.crt
SSLCertificateKeyFile /XXX/priv.key
SSLCertificateChainFile /XXX.crt
SSLProxyCACertificateFile /XXX.crt
SSLProxyCACertificatePath /XXX.crt/
SSLCACertificatePath /XXX.crt/
SSLOptions +StdEnvVars +ExportCertData
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
miércoles, 21 de enero de 2009
Enfriando al "Chiquitín"
Bueno después de todas las fiestas y demás, el "chiquitín" Toshiba Satellite pro U-200 ha tenido también regalo de "Reyes" ;)
Y es que la temperatura que llegan a alcanzar cuando les aprietas un poco a estos bichitos, además de los problemas de rendimiento que puede suponer, es más que insoportable para el usuario.
Así que me "han" agenciado un soporte Targus de dos ventiladores para el portátil.
La verdad es que nunca había visto una funcionando y los beneficios de temperatura que obtienes, a costa de un ruido muy reducido son bastante bastante buenos.
Sobre todo que me hacía ilusion colgarle fotos ;).
lunes, 12 de enero de 2009
Pérdidas de rendimiento Mysql - SlowQueries
Hace unos días, tuvimos en el trabajo un problema con una aplicación que consulta a BBDD MySql, ya que esta dejaba de responder sin más.
En los momentos en los que esto sucedía, se podía observar el siguiente comportamiento:
-No había errores en los logs de Apache ni en los de MySql.
-El consumo de memoria de Apache no era desorbitado, aunque si alto.
-MySql seguia respondiendo correctamente, pero el servidor Apache de la aplicación parecía estar muerto...
-El número de conexiones a BBBDD era normal.
-El número de conexiones en el servidor web era normal.
Bueno para resumir todo el proceso, la cuestión empezó a clarificarse en el momento que se activaron los logs para SlowQueries de MySql ;)
En el fichero de configuracion de mysql /etc/my.cnf añadimos
[mysqld]
log-slow-queries=/mysql/var/log/mysql-slow.log
Tras un día de logs, se podía observar lo siguiente:
[root@xxxxxx~]# mysqladmin version -u root -p ........... Threads: XXX Questions: XXX Slow queries: 6 Opens: XXX Flush tables: X Open tables: XXX Queries per second avg: XXX
Revisando los logs generados
[root@xxxxxx~]# cat /mysql/var/log/mysqlslow.log
se puede ver a que tabla accede la query cuando genera la entrada de log.
Por último usando la aplicación "MySql Administrator 1.2.14", se vio que el tamaño de una tabla de índices, usada para cachear las búsquedas de la aplicación, era desorbitadamente grande.
Claro está el problema se solucionó vaciando esta tabla, para que fueran recacheados los resultados.
Este mismo problema está tratado con anterioridad aquí
En los momentos en los que esto sucedía, se podía observar el siguiente comportamiento:
-No había errores en los logs de Apache ni en los de MySql.
-El consumo de memoria de Apache no era desorbitado, aunque si alto.
-MySql seguia respondiendo correctamente, pero el servidor Apache de la aplicación parecía estar muerto...
-El número de conexiones a BBBDD era normal.
-El número de conexiones en el servidor web era normal.
Bueno para resumir todo el proceso, la cuestión empezó a clarificarse en el momento que se activaron los logs para SlowQueries de MySql ;)
En el fichero de configuracion de mysql /etc/my.cnf añadimos
[mysqld]
log-slow-queries=/mysql/var/log/mysql-slow.log
Tras un día de logs, se podía observar lo siguiente:
[root@xxxxxx~]# mysqladmin version -u root -p ........... Threads: XXX Questions: XXX Slow queries: 6 Opens: XXX Flush tables: X Open tables: XXX Queries per second avg: XXX
Revisando los logs generados
[root@xxxxxx~]# cat /mysql/var/log/mysqlslow.log
se puede ver a que tabla accede la query cuando genera la entrada de log.
Por último usando la aplicación "MySql Administrator 1.2.14", se vio que el tamaño de una tabla de índices, usada para cachear las búsquedas de la aplicación, era desorbitadamente grande.
Claro está el problema se solucionó vaciando esta tabla, para que fueran recacheados los resultados.
Este mismo problema está tratado con anterioridad aquí
Suscribirse a:
Entradas (Atom)