[magento] PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0

Estos últimas días hemos tenido que optimizar la carga de servidores con Magento. Una de las tareas es usar un sistema de caché que acelere los scripts php. Usamos apc por compatibilidad con Magento y por que ya viene paquetizado en los repositorios de Debian.

El problema, aparece en el pié de página: «PHP Fatal error:  Exception thrown without a stack frame in Unknown on line 0».
Este error aparece cuando se ha lanzado una excepcion en un lugar donde se no se puede lanzar una excepción por no tener ‘stack frame‘.

Los manejadores de excepciones ‘ exception handlers‘ y los destructores no tienen ‘stack frame‘.
Por lo que combinar por ejemplo un ‘execption handler‘ con un ‘error preporting‘  o lanzar un execption en un destructor puede provocar que aparezcan. Os podeis documentar más en este interesante enlace Solving “Fatal error: Exception thrown without a stack frame in Unknown on line 0″

En nuestro caso, tan solo hizo falta acutalizar la version del apc con un simple aptapt-get install php-apc

En la máquina estaba previamente instalado el apc vía pecl

La Rebelión de los spammers

La Rebelión de los spammers es un interesante artículo de David Barroso que leí hace años y ahora lo he vuelto a encontrar por casualidad. El documento habla de la metodología que usa para localizar e identificar procesos maliciosos, cómo identifica el fallo de seguridad, y análisis del enemigo. Se detalla el uso de herramientas de sistema lsof, strace, etc.. etc… Aunque para muchos este tipo de tareas es trivial por realizarlas a diario, no deja de ser un documento interesante para leer.

Dejo copia en el servidor del documento que he localizado en http://his.sourceforge.net/proy_his/papers/spammers/spammers.es.html del proyecto Honeynet In Spanish aparantemente muerto en 2006

El documento lo podeis encontrar en http://www.hostingaldescubierto.com/rebelion-spammers/spammers.es.html

[ALERTA] No actualizar servidores Plesk 9.3 a openssl 0.9.8e-12.el5_4.6 – ACTUALIZADO

La nueva versión de openssl ( 0.9.8e-12.el5_4.6 ) está ocasionando problemas con Plesk 9.3.0.

El síntoma es que el demonio sw-cp-server falla al arrancar:


/etc/init.d/sw-cp-server restart
Restarting SWsoft control panels server... stale pidfile. [FAILED]dfile.

En el log de swp-cp-server pemos observar estas lineas :


tail /var/log/sw-cp-server/error_log
2010-03-29 12:50:48: (log.c.75) server started
2010-03-29 12:50:48: (network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)
2010-03-29 12:50:51: (log.c.75) server started
2010-03-29 12:50:51: (network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)
2010-03-29 12:50:51: (log.c.75) server started
2010-03-29 12:50:51: (network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)
2010-03-29 12:59:46: (log.c.75) server started
2010-03-29 12:59:46: (network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)
2010-03-29 12:59:46: (log.c.75) server started
2010-03-29 12:59:46: (network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)

Por ahora se recomienda reinstalar la versión anterior ( openssl-0.9.8e-12.el5_4.1 disponible aqui )


yum downgrade openssl*

Actualización:
En caso de estar usando un vps puede realizar los siguientes pasos:rpm –erase –nodeps openssl-0.9.8e-12.el5_4.6

puede encontrarse con este error si usa arquitectura x86_65rpm –erase –nodeps openssl-0.9.8e-12.el5_4.6
error: «openssl-0.9.8e-12.el5_4.6» specifies multiple packages

En este caso proceder la manera siguiente:rpm –erase openssl-0.9.8e-12.el5_4.6.x86_64 –nodeps
rpm –erase openssl-0.9.8e-12.el5_4.6 –nodeps

y para instalar la versión válida:vzpkg install VEID -p openssl-0.9.8e-12.el5_4.1.x86_64

o descargar el rpm e instalar dentro del vpscd /usr/src
wget ftp://ftp.pbone.net/mirror/ftp.centos.org/5.4/updates/x86_64/RPMS/openssl-0.9.8e-12.el5_4.1.x86_64.rpm
rpm -ivh openssl-0.9.8e-12.el5_4.1.x86_64.rpm

y reiniciar el servicio/etc/init.d/sw-cp-server restart

Esperamos que en breve Parallels libere una actualización para corregir el problema.

ACTUALIZACION 2

Cuidado si eliminas los rpm de openssl antes de tener el nuevo rpm ya puedes encontrarte con cosas así:


wget ftp://ftp.pbone.net/mirror/ftp.centos.org/5.4/updates/x86_64/RPMS/openssl-0.9.8e-12.el5_4.1.x86_64.rpm
wget: error while loading shared libraries: libssl.so.6: cannot open shared object file: No such file or directory

empiezan los sudores….


# curl ftp://ftp.pbone.net/mirror/ftp.centos.org/5.4/updates/x86_64/RPMS/openssl-0.9.8e-12.el5_4.1.x86_64.rpm
curl: error while loading shared libraries: libssl.so.6: cannot open shared object file: No such file or directory

más sudor frío ….


$ scp openssl-0.9.8e-12.el5_4.1.x86_64.rpm root@10.0.1.1:/root
ssh_exchange_identification: Connection closed by remote host
lost connection

con esto ya te quedas blanco 😉


# /etc/init.d/sshd restart
Stopping sshd: [FAILED]
Starting sshd: /usr/sbin/sshd: error while loading shared libraries: libcrypto.so.6: cannot open shared object file: No such file or directory
[FAILED]

Por supuesto yum tampoco funciona, así que si tenemos aún una sesión abierta lo vamos a solucionar facilmente así :


GET ftp://ftp.pbone.net/mirror/ftp.centos.org/5.4/updates/x86_64/RPMS/openssl-0.9.8e-12.el5_4.1.x86_64.rpm > openssl-0.9.8e-12.el5_4.1.x86_64.rpm
rpm -ivh openssl-0.9.8e-12.el5_4.1.x86_64.rpm

PARCHES
Parallels ha publicado los parches correspondientes a este problema en
http://kb.parallels.com/en/8338

[ayuda magento] Errores al importar base de datos magento

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:

  • Mage::setIsDeveloperMode(true);
  • ini_set(‘display_errors’, 1);

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

[magento] cambiar usuario y contraseña de la base de datos

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>

[mysql] Reparar todas las tablas de todas las bases de datos

Para reparar todas las tablas de todas las bases de datos ( teniendo en cuenta que usamos Pleks ) en una sola linea tienes este churro:

for database in $(mysql --skip-column-names -uadmin -p`cat /etc/psa/.psa.shadow` -e "show databases" ); do echo "optmizing tables from $database"; for table in $(mysql --skip-column-names -uadmin -p`cat /etc/psa/.psa.shadow` -e "show tables" $database ); do echo "-> $table " ; mysql -uadmin -p`cat /etc/psa/.psa.shadow` -e "OPTIMIZE TABLE $table" $database ; done ; done ;

ayuda plesk : error al borrar un dominio

Un error que sigue apareciendo aunque pasen versiones y versiones de Plesk ( desde la 7.4 a la 9.2 ) es la perdida de integridad referencial en algunas tablas. Esto provoca que a la hora de ejectuar algunas herramientas y falten datos se generen errores. En ese caso al borrar el dominio ‘delete.me’ nos aparece este mensaje :

0: class.MailManager.php:242
        MailManager::execWithException(string 'smart_exec', string 'mailmng', array, array, string 'lst')
1: class.MailManager.php:274
        MailManager->callMailManager(string 'remove-mailname', array)
2: class.MailManager.php:354
        MailManager->removeMailname(string 'sharoj.com', string 'delete')
3: cmd_mail.php3:1357
        mn_del(string '490')
4: class.DSMail.php:211
        DSMail->delete(boolean false)
5: class.PhDomain.php:358
        PhDomain->reset(integer '0', boolean true, boolean false)
6: class.BsDomain.php:330
        BsDomain->reset(integer '0')
7: class.BsDomain.php:302
      BsDomain->delete(integer '0')
8: class.BsDomain.php:536
        mdeleteDomains(array)
9: removeDomains.php3:42
        require(string '/opt/psa/admin/htdocs/domains/removeDomains.php3')
10: plesk.php:51

Tendremos que buscar manualmente donde está el problema y repararlo , directamente a la base de datos.

Comenzamos a buscar relaciones rotas entre objetos:

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa
Welcome to the MySQL monitor.  Commands end with ; or g.
Your MySQL connection id is 152938
Server version: 5.0.32-Debian_7etch10-log Debian etch distribution

Type 'help;' or 'h' for help. Type 'c' to clear the buffer.
  

mysql> select id, name from domains where name = "delete.me";
+------+------------+
| id   | name       |
+------+------------+
| 1241 | delete.me  | 
+------+------------+
1 row in set (0.00 sec)

Ya tenemos el ID del dominio, nos centramos en las cuentas de correo ya que el error se genera al borrar cuentas de correo. Vamos a ver que tablas hay en esta version de Plesk ( 9.2.3 )

mysql> show tables like '%mail%' ;
+------------------------+
| Tables_in_psa (%mail%) |
+------------------------+
| Webmails               | 
| badmailfrom            | 
| mail                   | 
| mail_aliases           | 
| mail_redir             | 
| mail_resp              | 
| mass_mail              | 
| mass_mail_clients      | 
| mass_mail_domains      | 
+------------------------+
9 rows in set (0.00 sec)

La tabla que nos interesa es mail vamos a ver que esctructura tiene y vamos sacando datos:

mysql> desc mail ;
+---------------+------------------------------------------+------+-----+---------+----------------+
| Field         | Type                                     | Null | Key | Default | Extra          |
+---------------+------------------------------------------+------+-----+---------+----------------+
| id            | int(10) unsigned                         | NO   | PRI | NULL    | auto_increment | 
| mail_name     | varchar(245)                             | NO   |     |         |                | 
| perm_id       | int(10) unsigned                         | NO   | MUL |         |                | 
| postbox       | enum('false','true')                     | NO   |     | false   |                | 
| account_id    | int(10) unsigned                         | NO   | MUL |         |                | 
| redirect      | enum('false','true')                     | NO   |     | false   |                | 
| redir_addr    | varchar(255)                             | YES  |     | NULL    |                | 
| mail_group    | enum('false','true')                     | NO   |     | false   |                | 
| autoresponder | enum('false','true')                     | NO   |     | false   |                | 
| spamfilter    | enum('false','true')                     | NO   |     | true    |                | 
| virusfilter   | enum('none','incoming','outgoing','any') | NO   |     | none    |                | 
| mbox_quota    | bigint(20)                               | NO   |     | -1      |                | 
| dom_id        | int(10) unsigned                         | NO   | MUL |         |                | 
+---------------+------------------------------------------+------+-----+---------+----------------+
13 rows in set (0.01 sec)

mysql> select * from mail where dom_id = 1241; 
+-----+-----------+---------+---------+------------+----------+------------+------------+---------------+------------+-------------+------------+--------+
| id  | mail_name | perm_id | postbox | account_id | redirect | redir_addr | mail_group | autoresponder | spamfilter | virusfilter | mbox_quota | dom_id |
+-----+-----------+---------+---------+------------+----------+------------+------------+---------------+------------+-------------+------------+--------+
| 490 | delete.me |    2202 | true    |       2204 | false    |            | false      | false         | false      | incoming    |         -1 |   1241 | 
+-----+-----------+---------+---------+------------+----------+------------+------------+---------------+------------+-------------+------------+--------+
1 row in set (0.00 sec)

Vemos que tiene al menos una cuenta de correo para el usuario 2204, vamos a buscar este usuario en la tabla accounts, ya que el id es accounts_id

mysql> show tables like '%acco%'
    -> ;
+------------------------+
| Tables_in_psa (%acco%) |
+------------------------+
| accounts               | 
+------------------------+
1 row in set (0.00 sec)

mysql> select * from accounts where id = 2204 ;
Empty set (0.01 sec)

Pues no está, aquí tenemos el problema, no existe la información del usuario pero sí el buzón.
lo más comodo es borar la entrada en la base de datos de la cuenta de correo. Dado que vamos a borrar el dominio nos es indiferente conservarlo.

mysql> delete from mail where id =490 limit 1 ;
Query OK, 1 row affected (0.03 sec)

De otra forma , habíamos dado de alta una fila en accounts con el id 2204 .

He migrado mi web y ahora no me salen los acentos !!!

Suele ocurrir cuando migramos de un sistema a otro que el juego de caracteres del sistema no es el mismo. Esto unido a que la mayoría de los no profesionales ni saben ni les interesa codificar sus webs correctamente genera horror y caos tras una migración.

Frases célebres :

  • me han hackeado la web, las eñes (ñ) no salen
  • no salen los acentos, arreglamelo
  • algo pasa con el office que me salen símbolos en vez de tildes , eñes y exclamaciones.
  • y la mítica de no me funciona internet…

Para evitar que esta tortura se dilate en el tiempo tengo un copy paste bastante elegante que ahorra tiempo:

cd /var/www/vhosts/tudominio.ext/httpdocs
alias cp='cp'

for file in $( find -name "*.htm*" ); do echo "convirtiendo $file.."; cat $file |iconv -flatin1 -t utf8> ../tmp.htm; cp ../tmp.htm $file ; done ;

rm -f ../tmp.htm

Basicamente convertimos todos los ficheros de latin1 a utf8 usando un fichero temporal fuera del httpdocs para que no nos convierta el propio fichero temporal.

RECOMENDACIÓN:
Elegir un fichero, hacer el iconv a mano y ver que aparece correctamente en el explorador ya que apache también puede estar configurado para usar por defecto un juego de caracteres u otro. O que el cambio no sea de latin1 a utf8 sino al revés. Eso ya es cosa vuestra.

[PHP] Fatal error: Cannot access empty property

Un error a simple vista dificil de encontrar… funcionaba la web en otras versiones de php5.x pero en esta última no… algo extraño, muy extraño…

Si hubiera sido una migración de la versión php4 a php5 … sería lógico pero esto no :/

[Thu Aug 13 18:09:44 2009] [error] [client 93.174.6.8] PHP Fatal error:  Cannot access empty property in /var/www/vhosts/hostingaldescubierto.com/httpdocs/test.php on line 4, referer: http://www.hostingaldescubierto.com/test.php

y la linea del error, la 4, aquí …

$this->$con = mysql_connect("localhost","user","password");

Aparentemente normal… pero, el error indicaba algo acerca de la propiedad. Efectivamente en un objeto de php sólo lleva el signo de $ el nombre del objeto o clase pero no sus propiedades. Con lo que quitando el $ a $con , funcionó perfectamente:

$this->con = mysql_connect("localhost","user","password");

Spamassassin: FORGED_MUA_OUTLOOK, la regla problemática

Desde hace tiempo y en ocasiones puntuales se puede ver que spamassassin ha marcado un correo como spam y el detonante ha sido la puntuacion (3.4) de la FORGED_MUA_OUTLOOK. Lo peor es que es un falso positivo y nos mete el correo en spam.

Aunque hay bugs reportados y supuestamente está corregido, personalmente prefiero desactivarla por si acaso :>

Para desactivarla ( en Debian ) editaremos el fichero /etc/mail/spamassassin/local.cf y agregamos

score FORGED_MUA_OUTLOOK 0.0 0.0 0.0 0.0