Esto ya es la segunda vez que me ocurre así que documentado aquí me será mas facil de encontrar para la tercera ;), y es que es el mismo proceso que con Fedora11.
En la web de Adobe, la versión de flash player que está disponible es para 32bits, así que para poder tenerlo en 64 bits, hay que realizar lo siguiente:
(Existen varios procesos expuestos por la web, aunque este es el mas sencillo)
1.- Descargar
#wget http://download.macromedia.com/pub/labs/flashplayer10/libflashplayer-10.0.32.18.linux-x86_64.so.tar.gz
2.-Descomprimir
#cd /usr/lib64/mozilla/plugins/
#tar -zxvf libflashplayer-10.0.32.18.linux-x86_64.so.tar.gz
#rm -f libflashplayer-10.0.32.18.linux-x86_64.so.tar.gz
NOTA:
Al arrancar nuestro Firefox, será capaz de cargar los Flash, pero......
El funcionamiento es cuanto menos "experimental", así que debéis estar preparados para cuelgues inesperados, en la reproducción de los flash que siempre vienen a producirse con más de un flash en marcha.
Aún no tengo idea de porque ocurre, así que soy todo oídos.
Actualización 15/02/2010
La url actual es:
http://download.macromedia.com/pub/labs/flashplayer10/flashplayer10_1_p2_linux_121709.tar.gz
viernes, 20 de noviembre de 2009
lunes, 16 de noviembre de 2009
Notas sobre LVM - Recordando.
La verdad es que me ha pasado varias veces que he querido consultar sobre este tema, sobre todo por trabajo ;) y no he encontrado mis notas, así que lo mejor será tenerlas aquí que así seguro que las encontraré la próxima vez.
Esquema:
-Los discos o particiones seran asignados como Volumenes Fisicos (PV)
-Uno o varios (PV) seran asignados a un Grupo de Volumenes (VG), el (VG) podrá
crecer en la medida que tenga espacio libre en los (PV) que tiene asignados.
-Un (VG), tendrá uno o varios Volumenes Lógicos (LVM) los cuales son nuestras tradicionales particiones.(/home, /etc....). Los (LV), podran crecer en la medida que quede espacio en su (VG)
Monitorizacion:
PV-Physical Volume
(Vemos a que VG estan asignados nuestros discos (PV) y cuanto espacio tenemos sin asignar en (PV))
pvs Display information about physical volumes
lvm> pvs
PV VG Fmt Attr PSize PFree
/dev/sdb1 vg_disco1 lvm2 a- 465,76G 0
/dev/sdc1 vg_disco2 lvm2 a- 465,76G 0
pvscan List all physical volumes
lvm> pvscan
PV /dev/sdc1 VG vg_disco2 lvm2 [465,76 GB / 0 free]
PV /dev/sdb1 VG vg_disco1 lvm2 [465,76 GB / 0 free]
Total: 2 [931,52 GB] / in use: 2 [931,52 GB] / in no VG: 0 [0 ]
VG-Volume Group
(Vemos cuantos VG tenemos asi como cuantos PV los formar y cuantos LV tiene cada uno. Ademas vemos el espacio libre en el VG)
vgs Display information about volume groups
lvm> vgs
VG #PV #LV #SN Attr VSize VFree
vg_disco1 1 2 0 wz--n- 465,76G 0
vg_disco2 1 2 0 wz--n- 465,76G 0
vgscan Search for all volume groups
lvm> vgscan
Reading all physical volumes. This may take a while...
Found volume group "vg_disco2" using metadata type lvm2
Found volume group "vg_disco1" using metadata type lvm2
LV-Logical Volume
(Vemos los LV que tenemos en cada VG y su tamaño)
lvscan List all logical volumes in all volume groups
lvm> lvscan
ACTIVE '/dev/vg_disco2/LVdatos' [270,45 GB] inherit
ACTIVE '/dev/vg_disco2/LVtrabajo' [195,31 GB] inherit
ACTIVE '/dev/vg_disco1/LVdescargas' [195,31 GB] inherit
ACTIVE '/dev/vg_disco1/LVmultimedia' [270,45 GB] inherit
lvs Display information about logical volumes
lvm> lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
LVdescargas vg_disco1 -wi-ao 195,31G
LVmultimedia vg_disco1 -wi-ao 270,45G
LVdatos vg_disco2 -wi-ao 270,45G
LVtrabajo vg_disco2 -wi-ao 195,31G
Para una informacion mas detallada de nuestros LV:
lvm> lvdisplay
--- Logical volume ---
LV Name /dev/vg_disco2/LVdatos
VG Name vg_disco2
LV UUID nXbOdP-CIBc-XibZ-Wvzm-MbOf-HB3V-tzrPml
LV Write Access read/write
LV Status available
# open 1
LV Size 270,45 GB
Current LE 69234
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:4
...
También es útil conocer cuales de nuestros disco están siendo usados:
lvm> lvmdiskscan
...
/dev/sdb1 [ 465,76 GB] LVM physical volume
/dev/sdc1 [ 465,76 GB] LVM physical volume
0 disks
24 partitions
0 LVM physical volume whole disks
2 LVM physical volumes
Evidentemente el comando mas interesante lo dejo para el final ;)
#lvm
lvm>help
Este comando sin comentarios.
Con esto espero no olvidarlo más, que ya tendría delito.
Esquema:
-Los discos o particiones seran asignados como Volumenes Fisicos (PV)-Uno o varios (PV) seran asignados a un Grupo de Volumenes (VG), el (VG) podrá
crecer en la medida que tenga espacio libre en los (PV) que tiene asignados.
-Un (VG), tendrá uno o varios Volumenes Lógicos (LVM) los cuales son nuestras tradicionales particiones.(/home, /etc....). Los (LV), podran crecer en la medida que quede espacio en su (VG)
Monitorizacion:
PV-Physical Volume
(Vemos a que VG estan asignados nuestros discos (PV) y cuanto espacio tenemos sin asignar en (PV))
pvs Display information about physical volumes
lvm> pvs
PV VG Fmt Attr PSize PFree
/dev/sdb1 vg_disco1 lvm2 a- 465,76G 0
/dev/sdc1 vg_disco2 lvm2 a- 465,76G 0
pvscan List all physical volumes
lvm> pvscan
PV /dev/sdc1 VG vg_disco2 lvm2 [465,76 GB / 0 free]
PV /dev/sdb1 VG vg_disco1 lvm2 [465,76 GB / 0 free]
Total: 2 [931,52 GB] / in use: 2 [931,52 GB] / in no VG: 0 [0 ]
VG-Volume Group
(Vemos cuantos VG tenemos asi como cuantos PV los formar y cuantos LV tiene cada uno. Ademas vemos el espacio libre en el VG)
vgs Display information about volume groups
lvm> vgs
VG #PV #LV #SN Attr VSize VFree
vg_disco1 1 2 0 wz--n- 465,76G 0
vg_disco2 1 2 0 wz--n- 465,76G 0
vgscan Search for all volume groups
lvm> vgscan
Reading all physical volumes. This may take a while...
Found volume group "vg_disco2" using metadata type lvm2
Found volume group "vg_disco1" using metadata type lvm2
LV-Logical Volume
(Vemos los LV que tenemos en cada VG y su tamaño)
lvscan List all logical volumes in all volume groups
lvm> lvscan
ACTIVE '/dev/vg_disco2/LVdatos' [270,45 GB] inherit
ACTIVE '/dev/vg_disco2/LVtrabajo' [195,31 GB] inherit
ACTIVE '/dev/vg_disco1/LVdescargas' [195,31 GB] inherit
ACTIVE '/dev/vg_disco1/LVmultimedia' [270,45 GB] inherit
lvs Display information about logical volumes
lvm> lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
LVdescargas vg_disco1 -wi-ao 195,31G
LVmultimedia vg_disco1 -wi-ao 270,45G
LVdatos vg_disco2 -wi-ao 270,45G
LVtrabajo vg_disco2 -wi-ao 195,31G
Para una informacion mas detallada de nuestros LV:
lvm> lvdisplay
--- Logical volume ---
LV Name /dev/vg_disco2/LVdatos
VG Name vg_disco2
LV UUID nXbOdP-CIBc-XibZ-Wvzm-MbOf-HB3V-tzrPml
LV Write Access read/write
LV Status available
# open 1
LV Size 270,45 GB
Current LE 69234
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:4
...
También es útil conocer cuales de nuestros disco están siendo usados:
lvm> lvmdiskscan
...
/dev/sdb1 [ 465,76 GB] LVM physical volume
/dev/sdc1 [ 465,76 GB] LVM physical volume
0 disks
24 partitions
0 LVM physical volume whole disks
2 LVM physical volumes
Evidentemente el comando mas interesante lo dejo para el final ;)
#lvm
lvm>help
Este comando sin comentarios.
Con esto espero no olvidarlo más, que ya tendría delito.
sábado, 7 de noviembre de 2009
Fedora 12 Release Party - Valencia
La verdad es que hace ya bastante tiempo que no escribía por aquí. No se si por falta de tiempo, ganas, ideas, ilusión, o... por una mezcla de todas ;)
Se que no es muy original retomar esto de escribir citando a otro pero me parece importante e interesante el tema, así que aquí va....
Juan J, Martinez ha organizado una "Fedora 12 Release Party" en Valencia, para reunir a usuarios de Fedora.
Los datos los tenéis en los enlaces, igual que el cartel del anuncio.
Si no sale ningún imprevisto nos vemos en la "Release Party" ;)
Suerte con el evento Juanjo.
Se que no es muy original retomar esto de escribir citando a otro pero me parece importante e interesante el tema, así que aquí va....
Juan J, Martinez ha organizado una "Fedora 12 Release Party" en Valencia, para reunir a usuarios de Fedora.
Los datos los tenéis en los enlaces, igual que el cartel del anuncio.
Si no sale ningún imprevisto nos vemos en la "Release Party" ;)
Suerte con el evento Juanjo.
domingo, 20 de septiembre de 2009
Certificados exportados desde Windows.
Hace unos días por necesidades del trabajo, necesite instalarme unos certificados, que habian sido generados y exportados desde una maquina Windows.
La verdad es nunca me habia puesto a trastear con certificados, así que al ver que no podía usarlos, empezaron mis problemillas.
Los formatos no coincidian con los que se suponía.
Para poder exportar el certificado de usuario junto con su clave, el cual esta en formato "pfx"
Lanzamos lo siguiente:
[root@gollum satec]# openssl pkcs12 -in manuel.pfx -out EXPORTADO.TXT -chain -nodes
Tras esto, copiamos el fichero exportado como:
manuel.crt y manuel.key
En cada uno de estos ficheros, editandolos con "vi", dejaremos solo la parte del certificado en el fichero crt y la parte de la firma en el fichero key
CRT
-----BEGIN CERTIFICATE-----
.....
-----END CERTIFICATE-----
KEY
-----BEGIN RSA PRIVATE KEY-----
.....
-----END RSA PRIVATE KEY-----
Con esto tenemos el certificado de cliente, listo para usar.
Ahora vamos a adecuar los certificados raices que estan en formato "pb7"
[root@gollum satec]# openssl pkcs7 -inform DER -outform PEM -in Certificados\ Raices.p7b -out certname.pem -print_certs
Esto nos deja el fichero con los certificados raices listo.
Estos ficheros ya los podemos usar en una máquina Linux.
La verdad es nunca me habia puesto a trastear con certificados, así que al ver que no podía usarlos, empezaron mis problemillas.
Los formatos no coincidian con los que se suponía.
Para poder exportar el certificado de usuario junto con su clave, el cual esta en formato "pfx"
Lanzamos lo siguiente:
[root@gollum satec]# openssl pkcs12 -in manuel.pfx -out EXPORTADO.TXT -chain -nodes
Tras esto, copiamos el fichero exportado como:
manuel.crt y manuel.key
En cada uno de estos ficheros, editandolos con "vi", dejaremos solo la parte del certificado en el fichero crt y la parte de la firma en el fichero key
CRT
-----BEGIN CERTIFICATE-----
.....
-----END CERTIFICATE-----
KEY
-----BEGIN RSA PRIVATE KEY-----
.....
-----END RSA PRIVATE KEY-----
Con esto tenemos el certificado de cliente, listo para usar.
Ahora vamos a adecuar los certificados raices que estan en formato "pb7"
[root@gollum satec]# openssl pkcs7 -inform DER -outform PEM -in Certificados\ Raices.p7b -out certname.pem -print_certs
Esto nos deja el fichero con los certificados raices listo.
Estos ficheros ya los podemos usar en una máquina Linux.
miércoles, 9 de septiembre de 2009
Optimización MySql
Hace ya bastante tiempo comente acerca de un problema de rendimiento con MySql y las SlowQuerys
Bueno pues como la historia siempre se repite (o eso dicen), ha vuelto a ocurrir, pero esta vez hasta que se ha descubierto, que el problema era el mismo, se han probado y profundizado en aspectos que mejoran el rendimiento de MySql
Esto es lo que voy a comentar brevemente.
1.- Lo primero ha sido garantizar que este error no se produce otra vez y para eso he creado un mini script que me vacíe la tabla en cuestión, citada en el post anterior.
NUM_ROWS=`mysql -u root -pXXXXX NOMBRE_BBDD -e"SELECT COUNT(*) FROM NOMBRE_TABLA;"`
#Quitamos 9 caracteres "COUNT(*) " que aparecen en la salida de mysql
NUM_ROWS=`echo${NUM_ROWS:8}`
if [ $NUM_ROWS -gt 2500000 ]; then
echo `date`
echo "El tamano es excesivo, $NUM_ROWS de entradas, hay que vaciar la tabla
NOMBRE_TABLA"
RESULT=`mysql -u root -pXXXXX NOMBRE_BBDD -e"TRUNCATE TABLE NOMBRE_TABLA;"`
echo $RESULT
fi
2.- Thread_cache_size y Thread_cache_concurrency
Esta es la primera parte de la "optimización" que se ha realizado.
Parece que Linux no gestiona bien la creacion de threads, por lo que crear nuevos supone un coste muy elevado.
Cuando tenemos muchas conexiones nuevas a BBDD, es necesario crear estos threads, mientras que si almacenamos los que van quedando libres al desconectarse un usuario, la reasignación de estos es mucho menos costosa, con lo que mejoramos el rendimiento.
Para decidir el valor optimo, podemos empezar por el recomendado "8", he ir ajustándolo de la siguiente manera.
mysql> show status like '%Thread%'; .... | Threads_created | 214 | ....
mysql> show status like '%Conn%'; ... | Connections | 14250 | ...
Threads_created/connections
Si este valor se aproxima a "1", significa que creamos tantos threads como conexiones tenemos, por lo que habria que aumentar el tamaño de la cache de threads.
Si este valor se aprixima a "0" significa que apenas creamos threads nuevos con lo que el tamaño de cache es correcto.
3.-Key_buffer_size
Esta variable indica el tamaño del buffer donde se almacenaran los indices de las tablas MyIsam.
A mas indices cacheados mas accesos en las consultas se servirán desde RAM y menos desde disco, con al aumento de rendimiento que esto supone.
Aquí ya que aún no lo hemos ajustado no voy a profundizar mucho más simplemente comentar que.
key_read_request (indices servidos desde RAM)
key_reads (indices servidos desde disco)
Con estas dos variables podemos ver lo siguiente.
key_read_request 10000
key_reads = 100
key_read_request/key_reads=100
Por lo que estamos obteniendo una proporción de 100 a 1, es decir por cada 100 indices servidos desde RAM 1 es servido desde disco.
Esta es la relación mínima que se cita en la documentación que he encontrado aunque también hablan de valores de 1000 a 1, por lo que cuanto más alto mejor.
Bueno con los ajustes necesarios de estas variables deberíamos notar una mejora de rendimiento en nuestros servidores.
Bueno pues como la historia siempre se repite (o eso dicen), ha vuelto a ocurrir, pero esta vez hasta que se ha descubierto, que el problema era el mismo, se han probado y profundizado en aspectos que mejoran el rendimiento de MySql
Esto es lo que voy a comentar brevemente.
1.- Lo primero ha sido garantizar que este error no se produce otra vez y para eso he creado un mini script que me vacíe la tabla en cuestión, citada en el post anterior.
NUM_ROWS=`mysql -u root -pXXXXX NOMBRE_BBDD -e"SELECT COUNT(*) FROM NOMBRE_TABLA;"`
#Quitamos 9 caracteres "COUNT(*) " que aparecen en la salida de mysql
NUM_ROWS=`echo${NUM_ROWS:8}`
if [ $NUM_ROWS -gt 2500000 ]; then
echo `date`
echo "El tamano es excesivo, $NUM_ROWS de entradas, hay que vaciar la tabla
NOMBRE_TABLA"
RESULT=`mysql -u root -pXXXXX NOMBRE_BBDD -e"TRUNCATE TABLE NOMBRE_TABLA;"`
echo $RESULT
fi
2.- Thread_cache_size y Thread_cache_concurrency
Esta es la primera parte de la "optimización" que se ha realizado.
Parece que Linux no gestiona bien la creacion de threads, por lo que crear nuevos supone un coste muy elevado.
Cuando tenemos muchas conexiones nuevas a BBDD, es necesario crear estos threads, mientras que si almacenamos los que van quedando libres al desconectarse un usuario, la reasignación de estos es mucho menos costosa, con lo que mejoramos el rendimiento.
Para decidir el valor optimo, podemos empezar por el recomendado "8", he ir ajustándolo de la siguiente manera.
mysql> show status like '%Thread%'; .... | Threads_created | 214 | ....
mysql> show status like '%Conn%'; ... | Connections | 14250 | ...
Threads_created/connections
Si este valor se aproxima a "1", significa que creamos tantos threads como conexiones tenemos, por lo que habria que aumentar el tamaño de la cache de threads.
Si este valor se aprixima a "0" significa que apenas creamos threads nuevos con lo que el tamaño de cache es correcto.
3.-Key_buffer_size
Esta variable indica el tamaño del buffer donde se almacenaran los indices de las tablas MyIsam.
A mas indices cacheados mas accesos en las consultas se servirán desde RAM y menos desde disco, con al aumento de rendimiento que esto supone.
Aquí ya que aún no lo hemos ajustado no voy a profundizar mucho más simplemente comentar que.
key_read_request (indices servidos desde RAM)
key_reads (indices servidos desde disco)
Con estas dos variables podemos ver lo siguiente.
key_read_request 10000
key_reads = 100
key_read_request/key_reads=100
Por lo que estamos obteniendo una proporción de 100 a 1, es decir por cada 100 indices servidos desde RAM 1 es servido desde disco.
Esta es la relación mínima que se cita en la documentación que he encontrado aunque también hablan de valores de 1000 a 1, por lo que cuanto más alto mejor.
Bueno con los ajustes necesarios de estas variables deberíamos notar una mejora de rendimiento en nuestros servidores.
Suscribirse a:
Entradas (Atom)