Mucho más cómodo que cambiar la password en la base de datos, es lanzar este comando en la ruta de la instalación de tu mediawiki :
php ./maintenance/changePassword.php –user=WikiSysop –password=nuevapasssword
No tiene mucho que explicar
Mucho más cómodo que cambiar la password en la base de datos, es lanzar este comando en la ruta de la instalación de tu mediawiki :
php ./maintenance/changePassword.php –user=WikiSysop –password=nuevapasssword
No tiene mucho que explicar
Si estamos usando un script en php y necesitamos subir ficheros de gran tamaño, puede que tengamos que ampliar algunos parámetros.
Normalente aparece un error como :
File Upload Warning: Max File Size Exceeded
Para ello, hay que revisar los siguientes parámetros:
Siguiendo con la linea anterior de otras releases , Parallels ha liberado temporalmente su version 9.5 y aún no está disponible para los demás clientes.
Según este comentario en el foro de Parallels, sólo está disponible para ‘testear’
http://forum.parallels.com/showthread.php?t=99362
Pero lo cierto es que Parallels libera durante unas horas las nuevas releases para que algunos usuarios incautos las instalen y así probar qué tal funciona.
Dado que la release aún no ha sido liberada todo apunta a que Plesk 9.5 viene cargado de fallos. Mucho cuidadado con la nueva versión. Esperamos estar equivocados.
Si tuvieramos que valorar la nota de Plesk no sería ni mucho menos un 9,5 ( sobresaliente ) si no más bien un 5,9 ( bien bajo jejeje ). Tras la tremenda oleada de cagadas que están teniendo ( sobretodo con qmail y postfix ) tenemos ya la release 9.5
Básicamente corrigen mogollón de fallos realtivos al webmail, qmail y posftix. Agregan soporte para Explorer 8, soporte para CloudLInux, pasarelas de pago, virtualizacion con Xen, HyperV, Wmware,etc.. y quizás dos o tres cosas que nos interesa a los administradores :
[-] SpamAssassin spam filter incorrectly classified most of the messages delivered in the year 2010 as spam – issue resolved.
[-] If a message cannot be sent, sender receives a message with invalid field from=#@[] bug is fixed.
[-] Web statistics were not calculated properly when the piped logs feature was switched on – issue resolved.
Como podeis comprobar, cuatro cositas de nada más los ‘known bugs’
En algún momento se puede requerir activar el motor FEDERATED para mysql en nuestro servidor.
Una tabla de la base de datos ‘FEDERATED‘ no se almacena localmente. Viene a ser algo asi como crear la esctructura de los datos en local pero el almacenamiento de los datos se realiza en otro servidor remoto y se usa el api del cliente de mysql para las operaciones de lectura escritura. actualización e inserción.
En ejemplo de tabla FEDERATED:
CREATE TABLE federated_table (
id INT(20) NOT NULL AUTO_INCREMENT,
name VARCHAR(32) NOT NULL DEFAULT '',
other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id),
INDEX name (name),
INDEX other_key (other)
)
ENGINE=FEDERATED
DEFAULT CHARSET=latin1
CONNECTION='mysql://fed_user@remote_host:9306/federated/test_table';
Para activar esta opción en nuestro servicio de mysql es necesario ver si tenemos compilado el soporte. Para ello ejecutaremos
SHOW ENGINES;
Un ejemplo en una distro Debian :
mysql> show engines ; +------------+---------+----------------------------------------------------------------+--------------+------+------------+ | Engine | Support | Comment | Transactions | XA | Savepoints | +------------+---------+----------------------------------------------------------------+--------------+------+------------+ | InnoDB | YES | Supports transactions, row-level locking, and foreign keys | YES | YES | YES | | MRG_MYISAM | YES | Collection of identical MyISAM tables | NO | NO | NO | | BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO | | CSV | YES | CSV storage engine | NO | NO | NO | | MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO | | FEDERATED | NO | Federated MySQL storage engine | NULL | NULL | NULL | | ARCHIVE | YES | Archive storage engine | NO | NO | NO | | MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance | NO | NO | NO | +------------+---------+----------------------------------------------------------------+--------------+------+------------+ 8 rows in set (0.00 sec)
En la documentación del comando show engines vemos que hay cuatro valores posibles:
En caso de las máquinas con Centos 5.x está como “NO” así que es necesario recompilar para activar el soporte. Para ello realizamos los siguientes pasos:
Descargamos las fuentes de mysql :
wget http://mirror.centos.org/centos/5/updates/SRPMS/mysql-5.0.77-4.el5_4.1.src.rpm
rpm -ivh mysql-5.0.77-4.el5_4.1.src.rpm
Si en nuestro sistema tenemos rpmbuild4.x:
Editar el fichero /usr/src/redhat/SPECS/mysql.spec y agregar a la seccion %configure –with-federated-storage-engine
Con rpmbuild 5 :
rpmbuild -bb --with federated-storage-engine /usr/src/redhat/SPECS/mysql.spec
Una vez generado los paquetes los ACTULIZAMOS en vez de instalar para evitar problemas.
rpm -Uvh /usr/src/redhat/RPMS/x86_64/mysql-5.0.77-4.1.x86_64.rpm /usr/src/redhat/RPMS/x86_64/mysql-server-5.0.77-4.1.x86_64.rpm
Para ello necesitaremos añadir federated en nuestro fichero my.conf
Esos días he revisado un par de artículos para mejorar el rendimiento de una tienda magento. Básicamente en toda la documentación se remite a los mismo puntos :
Además detalles de como optimizar magento , y en este artículo tambien se comenta el uso de memcached
Mucho tiempo ha tenido que pasar para que podamos actualizar nuestra Debian a Lenny no cargarnos la instalación de Plesk.
Podeis confirmar en las novedades de la versión 9.2.3 para sistemas basadas en paquetes .deb que Debian 5.0 está soportado.
Esperamos no encontrarnos con errores gordos con postfix como antaño.
La lista de sistemas soportados por Plesk actualmente es la siguiente:
Magento es un software en auge entre los interesados en montar tiendas virtuales. Parece que Oscommerce ya tiene un sustituto fuerte, bien diseñado, estructurado, mvc, modulable y con pasarelas de pago maduras.
Uno de los problemas es que requiere php 5.2. Como muchos sabrán php 4 dejó de ser soportada hace años, pero aún existen distribuciones que oficialmente distribuyen la php 5.0 o 5.1 en su rama estable. Este es el caso de Centos 5 / RHEL 5 que necesita de repositorios no oficiales para subir a version php 5.2.
Bien, puestos en situación, el caso se nos ha presentado un caso extraño de consumo de memoria desorbitado y totalmente desconcertante. Después de realizar todo tipo de pruebas para localizar este agujero negro de ram, hemos decidido cambiar a otro servidor basado en Debian que sí distribuyen php 5.2 en su rama ‘stable‘.
La migración ha sido un poco más problemática de lo habitual ya que Magento está muy preparado para el control de errores y no suelta los errores como habitualmente en error_log o en consola. Por ello hay que activar las siguientes lineas en index.php:
De esta forma, sí nos vuelca los errores pon pantalla pero usando un manejador del propio Magento.
Otra piedra en el camino para el cambio del servidor ha sido este error con los índices de mysql
ERROR 1064 (42000) at line 25: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8' at line 10
Al parecer hay algún pequeño cambio de como definir el indice basado en BTREE ( acelera las búsquedas ) y no son totalmente compatibles la versión de Centos ( mysql 5.1 ) y la Debian ( mysql 5.0) . Si existe algún bug abierto en Debian, lo desconozco, aunque lo buscaré
La linea original del volcado es PRIMARY KEY (`actualidad_id`) USING BTREE y debe ser sustituida por PRIMARY KEY USING BTREE (`actualidad_id`) para los más cómodos :
sed -i 's/PRIMARY KEY (`actualidad_id`) USING BTREE/PRIMARY KEY USING BTREE (`actualidad_id`)/' volcado.sql
Igualmente para este otro error:
ERROR 1064 (42000) at line 390: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'USING BTREE, KEY `FK_ATTRIBUTE_VARCHAR_ENTITY` (`entity_id`), KEY `FK_CATALO' at line 9
el cambio sería :
mysql 5.1 UNIQUE KEY `IDX_BASE` (`entity_type_id`,`entity_id`,`attribute_id`,`store_id`) USING BTREE, mysql 5.0 UNIQUE KEY `IDX_BASE` USING BTREE (`entity_type_id`,`entity_id`,`attribute_id`,`store_id`), sed -i 's/UNIQUE KEY `IDX_BASE` (`entity_type_id`,`entity_id`,`attribute_id`,`store_id`) USING BTREE,/UNIQUE KEY `IDX_BASE` USING BTREE (`entity_type_id`,`entity_id`,`attribute_id`,`store_id`),/' volcado
Más información acerca de la sintaxis de mysql en http://dev.mysql.com/doc/refman/5.0/en/create-table.html
Para cambiar los datos de acceso a la base de datos que usa la instalación de Magento hay que editar el fichero :
/app/etc/local.xml
La estructura del fichero es la siguiente :
<config> <global> <install> <date><![CDATA[Tue, 14 Jul 2009 16:19:11 +0000]]></date> </install> <crypt> <key><![CDATA[g41f732d5dc4abfb174c73bb76cc0670]]></key> </crypt> <disable_local_modules>false</disable_local_modules> <resources> <db> <table_prefix><![CDATA[]]></table_prefix> </db> <default_setup> <connection> <host><![CDATA[localhost]]></host> <username><![CDATA[user_name]]></username> <password><![CDATA[user_password]]></password> <dbname><![CDATA[data_base_name]]></dbname> <active>1</active> </connection> </default_setup> </resources> <session_save><![CDATA[files]]></session_save> </global> <admin> <routers> <adminhtml> <args> <frontName><![CDATA[admin]]></frontName> </args> </adminhtml> </routers> </admin> </config>
Me he encontrado con este problema al chequear una lista de correo en mi máquina con Plesk:
check_perms : chequea los permisos de ficheros y directorios de la estructura de mailman
# ./check_perms -f -v
comprobando el modo para /var/lib/mailman
comprobando gid y modo de /var/lib/mailman/logs/post
comprobando gid y modo de /var/lib/mailman/logs/error
comprobando gid y modo de /var/lib/mailman/logs/qrunner
comprobando gid y modo de /var/lib/mailman/logs/smtp
comprobando gid y modo de /var/lib/mailman/logs/subscribe
comprobando gid y modo de /var/lib/mailman/logs/smtp-failure
comprobando gid y modo de /var/lib/mailman/logs/vette
comprobando gid y modo de /var/lib/mailman/logs/bounce
comprobando gid y modo de /var/lib/mailman/logs/locks
comprobando gid y modo de /var/lib/mailman/mail
Traceback (most recent call last):
File "./check_perms", line 380, in ?
checkall()
File "./check_perms", line 196, in checkall
os.path.walk(d, checkwalk, STATE)
File "/usr/lib/python2.4/posixpath.py", line 290, in walk
func(arg, top, names)
File "./check_perms", line 120, in checkwalk
print _('%(path)s bad group (has: %(groupname)s, '
File "/usr/lib/mailman/Mailman/i18n.py", line 90, in _
return tns % dict
ValueError: unsupported format character 't' (0x74) at index 8
Según he visto comentado en varias fuentes es un bug debido a un problema con el juego de caracteres de la consola, por lo que utf8 está generando problemas. Hay que forzar a ejecutarlo con LANG=C
export LC_ALL=C; export LANG=C ./check_perms -f -v