lunes, 26 de enero de 2009

Pastilla Roja - Tarjeta de Red Marvel en Centos.

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

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:

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


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



DocumentRoot /XXX
ServerName XXX.es
ErrorLog logs/XXX
TransferLog logs/XXX
LogLevel warn
Options None
AllowCONNECT 443

Order deny,allow
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 ;).





Añadir imagen

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í