Prestashop 1.4.2.5

Ayer se liberó la version 1.4.2.5 de Prestashop build 6780.
Incluye pocos cambios con respecto a las versiones anteriores, que desde que se liberó la 1.4.0 ha mejorado bastante.

####################################
# v1.4.2.5 – 6780 (2011-05-30) #
####################################

Improved/changed features:

[*] Installer : add PS_VERSION_DB configuration data filled after install / upgrade

[*] FO : smarty_v2 improvement : moved currentTemplate init in fetch method instead of display method

[*] Core : module carrier has been disabled on One page checkout when customer isn’t logged
[*] Core : module carrier has been disabled on One page checkout when customer isn’t logged Part 2

Fixed bugs:

[-] Project : fix an issue on Tools::jsonDecode

[-] Installer : fixed bug where categories have incorrect level_depth

[-] FO : Bug Fixed #PSCFI-2077 – Tax rules + customization
[-] FO : Fixed #PSCFI-2051 – weekdays translations are now correct in store_infos google maps
[-] FO : Fixed #PSCFI-2066 – Control terms if terms are activated
[-] FO : On updating address with a bad field, firstname and alias are fill with the post + the registered data.

[-] BO : Fixed bug #PSCFI-2035 – The other messages in this category have been answered
[-] BO : Fixed bug #PSCFI-2073 – avoid crashing the product listing page when you have not enough memory to resize the thumbnails

[-] Classes : fixed bug with cookie name generated from http host causing cookie duplication

[-] MO : Bug fixed #PSCFI-2055 – number_format replaced by round in PayPal Module (Thanks Angora 🙂
[-] MO : Bug fixed on eBay Module (when products does not exist)
[-] MO : Fixed bug #PSCFI-1782 – Dibs could not do the callback
[-] MO : adding a message in So Colissimo module, in order to indicate: this module isn’t compliant with OPC feature

Para ver los cambios completos, puedes consultar el CHANGELOG de prestashop

«RuntimeError: could not open display»

Con una nueva instalación de CentOS, aparece este error al intentar ejecutar aplicaciones en remoto que quieren
entorno gráfico.
[shell]
«RuntimeError: could not open display»
[/shell]

Recordad seguir estos pasos:

  1. Activar X11Forwarding en /etc/ssh/sshd_config ( X11Forwarding yes)
  2. Acceder usando ssh -X user@host
  3. Probar a ejecutar forzando la variable DISPLAY ( DISPLAY=:0 system-config-users )
  4. Verificar que esté instalado el paquete xorg-x11-xauth. En caso contrario instalarlo, salir de la sesión y volver a entrar.

Plesk 9.5 : lista para instalar – CORREGIDO

Aunque hace varias semanas hacíamos referencia a que estaba disponible Plessk 9.5, al día siguiente fue retirada de los repositorios. Según comentarios del equipo de Parallels era una beta para algunos clientes, aunque lo habitual es que lo liberen para que un pequeño grupo de usuarios actualice creyendo que es estable y probarles como cobayas 😀

Desde antes de ayer ( más o menos) vuelve a estar disponible, aunque no ha sido oficialmente publicado. Seguramente sea la release final ya que en el KA ( panel de gestión de las licencias ) de Parallels aparecen disponibles ya las licencias de 9.5. Este hecho hace pensar que Plesk 9.5 marcará un cambio en la linea de Parallels ( marketing, funcional… habrá que verlo )

Desde la versión Plesk 8.6, que a mi gusto ha sido la mas estable y con mejor rendimiento desde las 6.x, la gente de Parallels no ha estado muy acertada con los cambios y han estado plagadas de bugs , sobretodo relacionados con postfix, qmail, spamasassin, drweb y domain keys y la basura del nuevo sistema de backup ( or decir algo elegante ) . Por todo ello no recomendaría instalar esta nueva versión en producción al menos hasta que salga Plesk 9.5.1 o 9.5.2 que seguro no tardarán mas de un mes desde que la liberen oficialmente.

No obstante para los intrépidos y los testers que quieran estar a la última , aqui teneis los repositorios para probarlas:

  • Centos

  • cat > /etc/yum.repos.d/CentOS-Plesk9.repo << EOF

    [plesk9-base]
    name=CentOS-Plesk9 – Base
    baseurl=http://autoinstall.plesk.com/PSA_9.5.0/dist-rpm-CentOS-$releasever-$basearch/
    gpgcheck=0
    enabled=1

    [plesk9-thirdparty]
    name=CentOS-Plesk9 – thirparty
    baseurl=http://autoinstall.plesk.com/PSA_9.5.0/thirdparty-rpm-CentOS-$releasever-$basearch/
    gpgcheck=0
    enabled=1

    [plesk9-updates]
    name=CentOS-Plesk9 – Updates
    baseurl=http://autoinstall.plesk.com/PSA_9.5.0/update-rpm-CentOS-$releasever-$basearch/
    gpgcheck=0
    enabled=1
    EOF

  • Debian

  • Etchcat > /etc/apt/sources.list.d/Plesk950.list << EOF
    deb http://autoinstall.plesk.com/debian/PSA_9.5.0 etch all
    EOF

  • Lenny:
    cat > /etc/apt/sources.list.d/Plesk950.list << EOF
    deb http://autoinstall.plesk.com/debian/PSA_9.5.0 lenny all
    EOF

FEDERATED: cómo activar storage engine en GNU/Linux

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:

  •  Yes : El soporte para ese motor es posible y está activo
  • Default : Como yes, pero el motor es que hay por defecto
  • No : El motor no está soportado
  • Disabled : El motor está soportado pero no activo.

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

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.

install: cannot stat `nls/af.gmo’: No such file or directory

Estoy generando un rpm para sysstats desde el codigo fuente en http://pagesperso-orange.fr/sebastien.godard/sysstat-9.0.6.tar.gz . El caso es que CentOS no dispone de ‘pidstat'( muy útil para analizar post-morten o in-morten que proceso nos está molestando).

El caso es que he seguido estos pasos:
[shell]
yum install gcc make rpm-build
cd /usr/src
wget http://pagesperso-orange.fr/sebastien.godard/sysstat-9.0.6.tar.gz
tar zxvf sysstat-9.0.6.tar.gz sysstat-9.0.6/sysstat-9.0.6.spec
cp sysstat-9.0.6.tar.gz /usr/src/redhat/SOURCES/sysstat-9.0.6.tar.gz
rpmbuild -bb sysstat-9.0.6/sysstat-9.0.6.spec
[/shell]

y la compilación fallaba con estas últimas lineas:
[shell]
install -m 644 nls/af.gmo /var/tmp/sysstat-9.0.6-root-root/usr/share/locale/af/LC_MESSAGES/sysstat.mo
install: cannot stat `nls/af.gmo’: No such file or directory
make: *** [install_nls] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.94933 (%install)
[/shell]

Algo fallaba, y algo me faltaba por instalar… asi echando un vistazo al log del configure encontré esto:

[shell]
WARNING: msgfmt command not found!
WARNING: xgettext command not found!
WARNING: msgmerge command not found!
[/shell]

Pues ahí lo llevas primo, eso va a ser, vamos a ver en que paquete está:
[shell]
# yum provides */msgfmt
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* addons: ftp.cica.es
* base: ftp.cica.es
* updates: ftp.cica.es
Excluding Packages from CentOS-Plesk – Base
Finished
gettext-0.14.6-4.el5.i386 : GNU libraries and utilities for producing multi-lingual messages.
Repo : base
Matched from:
Filename : /usr/bin/msgfmt

gettext-0.14.6-4.el5.x86_64 : GNU libraries and utilities for producing multi-lingual messages.
Repo : base
Matched from:
Filename : /usr/bin/msgfmt

gettext-0.14.6-4.el5.x86_64 : GNU libraries and utilities for producing multi-lingual messages.
Repo : installed
Matched from:
Filename : /usr/bin/msgfmt

gettext-0.14.6-4.el5.i386 : GNU libraries and utilities for producing multi-lingual messages.
Repo : installed
Matched from:
Filename : /usr/bin/msgfmt
[/shell]

Pues nada, vamos a instalarlo
[shell]
yum install gettext
[/shell]

Le damos otra vez a generar el rpm
[shell]
rpmbuild -bb sysstat-9.0.6/sysstat-9.0.6.spec
[/shell]

y ahora si tenemos ya nuestro rpm listo para instalar
[shell]
rpm -ivh /usr/src/redhat/RPMS/x86_64/sysstat-9.0.6-1.x86_64.rpm
[/shell]

Alerta de seguridad : apache vulnerable en RedHat/CentOS

Ayer día 14 de Julio de 2009 se publica una actualización de seguridad para apache ( httpd ) en RedHat / CentOs debido a un fallo de seguridad que provoca Denial Of Service aprovechando un fallo en el modulo mod_proxy. Esta denegación de servicio parece ser explotable únicamente cuando se usa este modulo mod_proxy como un proxy inverso, cargando la cpu y generando así la denegación del servicio.
Se ha encontrado también una posible denegación de servicio usando el modulo mod_defalte intantando comprimir ficheros grandes que genera una alta carga de cpu provocando la denegación de servicio aún cuando se haya cortado la conexión.

Más información en https://rhn.redhat.com/errata/RHSA-2009-1148.html

mas errores con yum

Ultimamente me estoy encontrando con este error al hacer un yum update:

Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in ?
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 229, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 145, in main
    (result, resultmsgs) = base.buildTransaction()
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 647, in buildTransaction
    (rescode, restring) = self.resolveDeps()
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 704, in resolveDeps
    for po, dep in self._checkFileRequires():
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 939, in _checkFileRequires
    if not self.tsInfo.getOldProvides(filename) and not self.tsInfo.getNewProvides(filename):
  File "/usr/lib/python2.4/site-packages/yum/transactioninfo.py", line 414, in getNewProvides
    for pkg, hits in self.pkgSack.getProvides(name, flag, version).iteritems():
  File "/usr/lib/python2.4/site-packages/yum/packageSack.py", line 300, in getProvides
    return self._computeAggregateDictResult("getProvides", name, flags, version)
  File "/usr/lib/python2.4/site-packages/yum/packageSack.py", line 470, in _computeAggregateDictResult
    sackResult = apply(method, args)
  File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 861, in getProvides
    return self._search("provides", name, flags, version)
  File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 43, in newFunc
    return func(*args, **kwargs)
  File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 837, in _search
    for pkg in self.searchFiles(name, strict=True):
  File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 43, in newFunc
    return func(*args, **kwargs)
  File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 586, in searchFiles
    self._sql_pkgKey2po(rep, cur, pkgs)
  File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 470, in _sql_pkgKey2po
    pkg = self._packageByKey(repo, ob['pkgKey'])
  File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 413, in _packageByKey
    po = self.pc(repo, cur.fetchone())
  File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 68, in __init__
    self._read_db_obj(db_obj)
  File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 94, in _read_db_obj
    setattr(self, item, _share_data(db_obj[item]))
TypeError: unsubscriptable object

Parece tener que ver con algún paquete y la versión de librpm.

Lo más cómod es hacer

yum clean all

Borrará todas las cachés, pero funciona.