De gracias recibisteis, dad de gracia.. Compartir es vivir dicen otros.. Es habitual en el mundo del desarrollo del software que se compartan los conocimientos. Los pinitos personales de cada uno en el día a día. Esas cosas que tanto nos han costado alcanzar, tras búsquedas y búsquedas leyendo a compañeros del desarrollo y al final reuniendo toda la información acabas construyendo la solución que necesitas.
No os comparto código del trabajo, ya que seguro que no es tan interesante como este ejemplo general de aquí abajo. Para que construyas el script que necesitas 😉
Creo que nunca dejaré de aprender los entresijo de Magento. Ahora estoy recorriendo los pedidos para obtener informes. Esto está probado sobre un Magento 1.9, no debería de haber muchas diferencias con otras versiones.
Ya tenemos entre nostros Ubuntu 16.04 LTS, la versión con soporte para mucho tiempo de Ubuntu más nueva hasta la fecha. Me instalé en los ordenadores de escritorio la actualización que me los pasó de la versión 14.04 LTS a la 16.04 LTS sin ningún problema.
Ahora disfruto de todas las novedades y mejoras que trae Ubuntu 16. El problema me ha llegado cuando he querido actualizar un servidor de Ubuntu 14 al 16. Resulta que en las versiones de escritorio de Ubuntu tenemos una sencilla interfaz para actualizar el sistema, mientras que en los servidores no. En las versiones de escritorio nos sale prácticamente todos los días las nuevas actualizaciones que tenemos disponibles, se pueden instalar automáticamente o seguir las instrucciones. Cuando ha salido la nueva versión de Ubuntuo 16.04 LTS nos salió junto con las actualizaciones la actualización a Ubuntu 16.04, simplemente seguimos las instrucciones y a correr.
Este estupendo CMS orientado a la venta online de productos hace las delicias de los vendedores, de igual modo de los maquetadores, y cómo no, también de los programadores.
Como analista programador llevaba ya un tiempo queriendo meterle mano a las entrañas de Magento. Así que poco a poco, he ido cogiendo los manuales para el usuario, luego el del diseñador, y ahora tengo entre manos el del programador. Ahora según van surgiendo las necesidades voy haciendo incursiones cada vez más a fondo en el código fuente de esta humongous web application.
La verdad es que lo estoy disfrutando porque Magento está desarrollado con una buena estructura y sobre un gran framework de desarrollo PHP, el Zend Framework. Incorporando técnicas de programación que le dan una gran flexibilidad sin añadir demasiada complejidad.
Este es otro pequeño how to para hacer una tarea rutinaria. Simplemente, como indica el título de la entrada, se hace lo que dice, en este caso mediante PHP. Esta tarea se puede programar en línea de comandos para ejecutarse todos los días. Es algo habitualmente necesario, y ya que PHP es un lenguaje de scripting muy sencillo y a la par potente, vamos a ver cómo hacer esto sin complejos sistemas intermedios.
Para este manual se usa Linux, y se ha probado sobre Ubuntu 14.
Traigo una pequeña receta de Chef 12 que he usado para crear un servidor virtual usando una pila de OpsWorks. He tenido que pegarle unas cuantas vueltas ya que el proyecto estaba con la versión 11, y era mi primera AMI completa creada 100% desde OpsWorks. Después de unas horas navegando, comprendiendo cómo funciona todo esto. He conseguido comprender, como dice un colega de trabajo, «uno de los pilares básicos sobre los que se basa Amazon Web Services».
La idea es tener una pila completa de OpsWorks, que cree completamente un servidor desde cero. Le vamos instalando todo lo que vayamos a necesitar, desde actualizaciones a todas las herramientas para el proyecto. En la última receta de creación de la instancia se limpia la instancia, se para, y podremos guardar nuestra propia AMI para lanzarla desde otra pila de OpsWorks, EC2, etc..
Ahí va el código en ruby para la receta de Chef que tanta guerra me ha dado. En la documentación oficial me faltaban algunos detalles que hacían que no funcionara con Chef 12 al arrancar de nuevo la instancia en otra pila de OpsWorks. Esto se puede poner en la última receta:
También se puede ejecutar esto desde línea de comandos conectando por SSH a la instancia.
Como cita la documentación oficial, si no hacemos esto, la nueva AMI quedará con las configuraciones de Chef y del agente de OpsWorks desde el que fue lanzada. Esto hará que no pueda hacer el setup si la arrancamos desde otra pila de OpsWorks creando servidores desde una «Custom AMI».
¡Buenos días a todos! Voy a tratar de no perder las buenas costumbres, como esta de compartir en el blog mi granito de arena en todo esto de la informática. Hasta estos últimos días, que no he tenido la necesidad de mantener al día tantos servidores como últimamente. Estaba haciéndolo manualmente, a pelo como se suele decir, entrando en los servidores y aplicando actualizaciones, modificaciones, etc.. Todo esto es mucho tiempo así que delegar en un proveedor de hosting todo éste trabajo es una buena elección. Pero no siempre te va a valer y puede que necesites hacer configuraciones que un proveedor de hosting no te va a permitir. Administrar tu propio servidor no tiene que ser complejo.
Todo esto me ha llevado a investigar sobre paneles de control de servidores. Tenemos el gran Cpanel, Plesk, Zpanel, y un largo etcétera. Por temas laborales ya he probado algunos en los propios proveedores. Muchos funcionan de maravilla y son sencillos de gestionar. Pero no me voy a dedicar a alquilar hosts, sino que simplemente necesito mantener unos pocos servidores y no es viable comprar una solución comercial. Así que navegando y navegando al final me topé con Webmin.
Qué tiene
A grandes rasgos es una web desarrollada sobre Perl, que se instala en el puerto 10000 del servidor y se integra con el sistema operativo. Nos permite ver el estado del servidor, hacer configuraciones de red, actualizarlo, programar actualizaciones automáticas recibiendo informes a tu email. Te permite configurar usuarios, permisos, instalar bases de datos, servidor web, configurarlos. También hay módulos para instalar un servidor de correo electrónico. Puedes administrar Apache2, Mysql, Postgres, Postfix, Dovecod, etc, etc, etc.
La verdad es que te quedas mucho más tranquilo teniendo una herramienta de estas instalada en un servidor. No tienes más que entrar y de un vistazo puedes saber qué tal anda el sistema. Puedes aplicar las principales configuraciones y a correr que el tiempo es muy valioso.
Hay algunas tareas como la configuración hosts virtuales que haciéndolas a mano me he aclarado mejor. Pero deduzco que será cuestión de acostumbrarme al panel. Leo que hay extensiones de Webmin para configurar fácilmente hosts con varios dominios, permitiendo la lectura de correos a los usuarios proporcionándoles un panel de entrada al sistema.
Un detalle que me ha gustado mucho es la autenticación en dos pasos (multi-factor authentication, MFA). Con el que podemos tener por ejemplo en nuestro móvil el Google Authenticator, y tener un código de seguridad extra que se genere a cada 30 segundos, para poder entrar como en la imagen siguiente:
El theme, piel, o plantilla que podéis ver en las imágenes no es el original. Es el ‘Authentic theme’ que me ha gustado también mucho. Es totalmente sensible al dispositivo (responsive), con lo que también podemos aplicar configuraciones sobre nuestro servidor desde el móvil o tablet, cosa que se agradece en gran manera.
Aquí podemos ver lo sencillo que se hace mantener actualizado el sistema:
Aquí en la imagen se puede ver cómo configurar que todos los días se apliquen todas las actualizaciones del sistema, no sólo las de seguridad. Esto dispara cada día la instalación de todos los paquetes para actualizar y me envía un informe del resultado de la instalación a mi email. Ya os podéis hacer a la idea de que tiene muchas cosas, y lo tranquilo que me quedo con cada correo que recibo diciéndome que todo se ha actualizado correctamente.
Como buen usuario de Ubuntu, todas las pruebas y las imágenes que se ven son sobre Ubuntu. Me lo voy a anotar como indispensable en las nuevas instalaciones. Navegando y navegando por el menú lateral ya veo que no me lo voy a acabar, así que tendré que ver la documentación oficial de cada herramienta para ir más al grano en las tareas que se necesiten.
Es un proyecto alojado en Github, que por lo que veo se ve bien activo. Ahora mismo hace 4 horas que han subido una actualización, lo que denota que vamos a seguir teniendo actualizaciones frecuentemente, como todo buen proyecto Open Source.
Para el que quiera seguir investigando en esta joya de la informática, son interesantes los módulos Usermin y Virtualmin. No creo que tarde mucho en probarlos. De estos tenemos una versión gratuita y otra comercial, con las que vamos añadiendo más y más funcionalidades al panel de control.
¿Alguna sugerencia de otro programa similar para administrar servidores?
De todos las soluciones de tienda online que he conocido hasta la fecha, Magento es de lo más robusto y potente que he visto de código abierto. Estoy conociendo poco a poco los entresijos de Magento 1 en el trabajo, y es buen momento de ver las mejoras que trae Magento 2 y así cotejar.
Es un sistema de información dedicado a la venta robusto, flexible y muy personalizable. Alrededor de Magento se mueve todo un ecosistema de soluciones empresariales de la más alta gama. Todo esto es posible gracias a las características de Magento.
Para explicar todo lo que tiene Magento necesitamos mucho tiempo, terminaríamos antes buscando qué no tiene. Pero también encontrar qué no tiene va a ser difícil porque Magento es todo un referente mundial de las soluciones eCommerce existentes.
Un poco de historia
Nació como proyecto de código abierto en el 2007. Ya en el 2008 fue premiado como mejor nuevo proyecto de código abierto del año. En el año 2009 la empresa Varien lanzó la versión Enterprise con el modelo de negocio de suscripción anual. Ahora mismo es propiedad de Ebay, la cual es propietaria del 100% de la empresa.
Lanzaron también una versión Profesional, pero no debe de haber tenido mucho éxito esta segmentación porque ahora mismo sólo disponemos de la Community Edition y la Enterprise Edition.
Requisitos para la instalación
Se necesita de una buena máquina para correr Magento, por lo menos se recomiendan 2 Gigas de RAM y échale CPUs que cuantos
más mejor. Yo le he puesto una máquina virtual con Vagrant de 4 Gigas de RAM y 2 CPUs. Se ha dejado instalar después de preparar un poco el servidor sin demasiadas configuraciones.
Instalando
Haciendo unas pruebas jugueteando con Vagrant, me ha quedado un script bien sencillo. Ejecutando lo siguiente tenemos automatizada la instalación de todo lo necesario en un servidor Linux para poder instalar Magento 2. Dejo aquí el script para Ubuntu Server con todo en el mismo servidor, Apache y MySQL:
sudo sed -i «s/bind-address\s*=\s*127.0.0.1/bind-address = 0.0.0.0/» ${mysql_config_file}
# Permitir acceso como root desde cualquier host echo «GRANT ALL PRIVILEGES ON *.* TO ‘root’@’%’ IDENTIFIED BY ‘root’ WITH GRANT OPTION» | mysql -u root –password=root echo «GRANT PROXY ON »@» TO ‘root’@’%’ WITH GRANT OPTION» | mysql -u root –password=root
sudo service mysql restart
echo «CREATE DATABASE magento2» | mysql -u root –password=root
Hay quien preferiría Nginx porque en sus inicios ejecutaba en multiples hilos de ejecución las peticiones HTTP, es ligero y sencillo. Ha llovido mucho desde que Nginx era el servidor más rápido del mercado con creces, viendo las últimas estadísticas comparativas entre Apache2 y Nginx más o menos van a la par en la fecha en que les escribo. No es objetivo hacer una comparativa Nginx-Apache en esta entrada así que lo dejaremos para otro momento si cabe.
A partir de aquí ya tenemos el servidor web Apache configurado con PHP, y una base de datos MySQL con la base de datos magento2 ya creada que usaremos para instalar nuestro nuevo Magento. También tenemos instalado globalmente en el sistema Composer, que cuando recién descomprimamos el nuevo magento y vayamos a instalar nos va a pedir que instalemos todas las librerías de PHP.
Tras esto podemos ver conectándonos a la base de datos que partimos de las no pocas 308 tablas, para empezar. Esto nos da una idea de la magnitud del programa que tenemos entre manos ¿cierto?
Las tareas cron, cachés..
El cron del sistema es el programador de tareas. Cuando recién hemos hecho la instalación, el panel de control nos notificará que instalemos las tareas automáticas para que funcione Magento o que las lancemos manualmente.
Esto hace necesario que tengamos acceso como root, como administradores del sistema, para que podamos configurar estas tareas en el servidor. No podemos instalar Magento en cualquier alojamiento web. O mejor dicho, sí que podemos, pero el funcionamiento va a ser una castaña si no hacemos los ajustes necesarios.
Otro tema que hace necesario un host con acceso como root son las cachés. En un sistema web tenemos caché de base de datos, compilación a bytecodes de PHP, generación de páginas HTML a partir de vistas. Y el gran Varnish, otro elemento a instalar y configurar para sacar el máximo partido a las prestaciones de nuestro servidor, aunque no es imprescindible tenerlo (al contrario de lo que dicen muchos administradores de sistemas). Evitar Varnish si no es necesario, como escuché a un experto en Magento en el último Meet Magento en España, nos puede aliviar las configuraciones ya que a veces este proxy inverso se mete en medio necesitando de más y más configuraciones a medida que instalamos extensiones o personalizamos nuestro Magento.
El sistema de cifrado SSL
En el script de instalación se crea un certificado autofirmado y se guarda en /etc/ssl/. A fecha de hoy ya queda poco para poder crear nuestros propios certificados 100% funcionales, para el entorno de producción o desarrollo, tantos como queramos, con Letsencrypt, pero mientras este sistema nos servirá.
Es de buena costumbre poner el cifrado en la zona de administración (back-end) y en el front-end. Para ello tenemos que configurar las URL base seguras y no seguras poniéndole el https delante. Por defecto se cifrará toda la navegación desde el momento en que haya datos personales de los usuarios. En el back-end se cifrará en todo momento.
Si vas a instalarlo en producción asegúrate de que esté todo funcionando antes de activar SSL en todo el sitio. Tener SSL mejorará el posicionamiento del sitio en los buscadores, pero me ha pasado que una extensión te fastidie todo porque no funcione correctamente, así que más vale probar y probar antes de dejarlo activado definitivamente. Aquí dejo la información para el que le sirva 😉
Características principales
Las bondades de Magento son una larga lista de características así que de entre las principales tenemos:
Multi-sitio web (varios dominios), multi-almacén y multi-vista de almacén, todo con un mismo panel de administración.
Multi-idioma, con packs de idiomas disponibles para instalar como extensiones.
Gestión total del catálogo; categorías y productos.
Gestión muy potente de atributos de productos.
Filtrado de productos para mejorar la navegación basado en atributos y características muy avanzado.
Integración con pasarelas de pago para poder instalar como extensiones.
Registro detallado que nos informa del estado actual con todo lujo de detalles: últimas ventas, ingresos, productos más vendidos..
Gestión de datos de clientes, registro, modificación.
Gestión de los usuarios que acceden al panel de administración.
Herramientas de marketing como emails transaccionales configurables, reglas de precios de catálogo o de carrito, herramientas SEO integradas.
Gestión de promociones basadas en características de productos o de carritos de la compra. Se pueden utilizar atributos personalizados para las reglas de promociones.
Temas para instalar; sistemas de páginas estáticas, bloques y widgets para personalizar.
También tenemos inteligencia de negocio con muchos informes detallados listos para ver en tiempo real.
Un sistema de gestión de índices y caché.
Muchas extensiones para personalizar nuestro Magento en su marketplace.
Por supuesto, acceso para interconectar con otros sistemas mediante punto de entrada a una API.
Magento es enorme, parece el SAP de las soluciones eCommerce Open Source. Soy sincero, no conozco SAP en sus entrañas, pero ya sólo ver que tenemos 300 tablas para guardar los datos necesarios para funcionar me hice una idea. Entrar a detallar las características de cada zona de su panel de administración es una tarea interminable así que será mejor ir directamente a su funcionamiento, empaparse de su documentación, o ir buscando lo que necesites. Recomiendo dar una lectura rápida a las guías de usuario disponibles en su página oficial.
Terminando
Lo que destaca de esta solución eCommerce es su robustez y fiabilidad. Estoy viendo muchas mejoras en la versión 2 con respecto a la 1: aumento de velocidad, sistema totalmente cacheado, compatible con HHVM.. Destaca la integración de la herramienta de consola de Symfony. Tenemos disponible la integración con Odoo mediante la instalación de una extensión en Magento, se abre el acceso al Webservice, e instalando los módulos correspondientes en Odoo podremos sincronizar catálogo, stocks, clientes, pedidos, carros abandonados, etc.. esto último está disponible hasta para la versión 1.9, espero que pronto esté también para Magento 2 😉
Al instalar los códigos me sorprendió que me pidiera ejecutar un ‘composer install’ para comenzar a correr la aplicación. Composer es una herramienta que organiza las librerías PHP, algo que venía haciendo falta. Es una herramienta PHP muy nueva, que están usando frameworks de desarrollo de la talla de Symfony o Laravel. Esto me hace preveer que el código fuente de Magento 2 puede incorporar pronto muchas nuevas mejoras del mundo PHP. Estaremos atentos.
Si has estado probando soluciones como Virtuemart, WooCommerce o Prestashop. Esta solución de código libre es más que interesante. Habrá que valorar qué es lo que necesitas para tu caso, pero lo que si puedo asegurar es que Magento es una gran solución.
El único inconveniente que le veo es que, por lo menos aquí en Spain donde resido, hay muy pocos desarrolladores especializados en Magento. Así que toma el dato, si quieres asegurarte el trabajo, aprende a desarrollar para Magento y no te faltará el trabajo.
¡Hola! Este es un pequeño HOWTO para configurar los permisos de directorio de un proyecto web que está en un servidor Apache. Nos puede pasar que estamos editando los ficheros del proyecto, pero puede ser que Apache no pueda acceder correctamente a los nuevos ficheros, crearlos, modificarlos o borrarlos. También nos puede pasar que Apache cree ficheros y nosotros no podamos tocarlos. Vamos a evitarlo con unos sencillos pasos. Esto sirve para configurarlo en Ubuntu. También se puede aplicar a cualquier otro sistema operativo Linux.
El usuario por defecto de un servidor Ubuntu es ‘ubuntu’. El usuario de Apache es ‘www-data’, así que comenzamos dando permiso a Apache para que pueda usar nuestro directorio de trabajo donde desarrollamos la web. Por defecto Apache trabaja sobre con la página principal en /var/www/html pero este post es para configurar a nuestro gusto el destino el directorio donde vamos a tener la web.
Supongamos que tenemos nuestra web en desarrollo en:
/home/jaime/miweb/
Ahora bien vamos al directorio donde está nuestra web y damos permisos a Apache así:
cd /home/jaime/ sudo chown www-data:www-data -R miweb/
Doy por sentado que ya tenemos instalado Apache y que tenemos configurado el host. Ahora bien, queremos trabajar como usuario editando y viendo los resultados en el navegador. Añadimos a nuestro usuario al grupo www-data:
sudo adduser jaime www-data
Con esto ya podremos editar el contenido del directorio de la web en /home/jaime/miweb/. Antes no podíamos porque hemos dado la propiedad a www-data que es el usuario de Apache con el comando chown.
Ahora para que los nuevos archivos creados dentro del directorio de la web sigan siendo propiedad del mismo grupo www-data para que tanto Apache como el usuario (tú) podáis seguir trabajando ejecutamos lo siguiente para poner el ‘sticky-bit’ de grupo a los directorios:
Esto pone el directorio del proyecto con el sticky-bit de grupo y luego busca dentro todos los subdirectorios y también le ponemos el sticky-bit de grupo. Ahora cualquier archivo que crees dentro del directorio seguirá tendrá tu usuario de propietario, y de grupo www-data. Así Apache podrá seguir sirviendo los archivos sin problemas y podremos trabajar sin preocuparnos de dar permiso o propiedad a los archivos que ya no sean de www-data.
En mi caso, en el Centro de Software de Ubuntu, simplemente con buscar cortafuegos me sale como disponible. Se llama ‘Configuración del cortafuegos’ y es una interfaz gráfica para que podamos manejar las configuraciones de iptables con las que configuramos las reglas de nuestro cortafuegos.
Si no lo pudiéramos instalar así desde un terminal lo podemos instalar escribiendo:
$ sudo apt-get install gufw
Una vez arrancado veremos una ventana como la de la imagen. Con sólo elegir un perfil y activarlo ya tendremos una protección extra ante posibles servicios de nuestro sistema que estén abiertos. Estos servicios que estén escuchando la red pueden ser vulnerables y siempre va a ser mejor configurar su acceso.
Fundamentos
Es interesante saber que gufw simplemente es una interfaz gráfica que nos ayudará a establecer unas reglas o configuraciones sobre nuestro acceso a la red. Gufw trabaja sobre iptables, que es una capa de sofware que establece directamente las reglas o configuraciones que vemos en la interfaz. A su vez, iptables trabaja sobre netfilter.
Netfilter es un framework que ofrece el núcleo de Linux para trabajar sobre la red. Permite filtrar, modificar, redireccionar, bloquear, registrar, etc.. paquetes de red a nivel de núcleo. Es decir, el núcleo de Linux proporciona unas herramientas para hacer todo tipo de tareas relacionadas con los cortafuegos de red.
Todas estas configuraciones que podemos hacer sobre iptables, gufw nos las sirve bien fácil para configurar. Y no sólo eso, sino que también nos proporciona una serie de plantillas para configurar los programas más habituales.
A parte de esto, también hay otras soluciones que no son iptables para configurar los cortafuegos de núcleos Linux. Y también trabajan sobre netfilter.
Probando
Para verificar que de verdad está funcionando podemos hacer una sencilla prueba. Vamos a la sección de reglas y podemos crear una regla que nos impida conectar con nuestro router. Habitualmente el router está en 192.168.0.1, depende del fabricante. En mi caso, creo una regla que bloquee la conexión saliente hacia el router al puerto 80 y no me deja conectarme a:
http://192.168.0.1/
Se me queda el navegador pensando y no sale nunca la página del router. Ya está comprobado de que funciona, borro la regla y vuelvo a la normalidad.
Si en una regla le activas que guarde registro luego puedes ir al directorio /var/log en donde tendrás los logs. Como se trata de una regla que se ejecuta al nivel de kernel se guarda en el fichero /var/log/kern.log. Esto también se puede configurar. Para ello hay que entrar a configurar ficheros de registro para iptables.
Es muy sencillo de configurar, a nada que vayamos probando haciendo click en todos los botones seguro que llegaremos a la configuración que queremos. Ya sea para casa, trabajo, o redes públicas. Como ya decía en el post sobre el antivirus ClamAV y la interfaz ClamTK, todavía más seguro puedes estar en Linux si activas el cortafuegos 😉
Hola de nuevo. Llevaba un tiempo dándole vueltas pero no encontraba el momento de llevarlo a cabo. Estaba pensando en unir entrebastidores.jnjsite.com y blog.jnjsite.com además de que tenía que mantener a la par jnjsite.com. Finalmente decidí por unirlo todo y llevarlo a un WordPress que es una excelente herramienta. Así me podré centrar en otras tareas como escribir entradas o atender lo demás que el tiempo corre.
Integración
Exporté las entradas de ambos blogs, las importé a un nuevo WordPress que se mantendrá actualizado automáticamente. A la vez las páginas informativas de mi página personal las he copiado y pegado en este nuevo sitio. Me decidí por un sencillo tema muy popular en el marketplace de WordPress, Customizr. Y la verdad que está quedando bastante bien ¿verdad?
Optimización
A esto le sumas la compresión de los códigos de estilo CSS, Javascripts y HTML. Junto con un acelerador mediante compilación de una caché de PHP a HTML de las zonas posibles. Todo junto me parece que está quedando bastante decente.
Espero que les guste y sigan visitándome los lectores del blog. Ahora tendré que ponerme con los temas de SEO jeje..
Ya estoy de nuevo por aquí frikeando un poco con el software. Estoy en estos días poniéndome al día con Magento. Es la gran solución de Código Libre para trabajar de forma económica montando una web. Entre las tres principales soluciones es la que de momento ostenta la primera posición, la segunda viene a ser Prestashop y la tercera WooCommerce.
Estoy hablando de las soluciones económicas, Open Source, PHP, robustas y estables. Ya si nos centramos sólo en España veremos que el despunte de tiendas online es para Prestashop. Espero no equivocarme con los datos, los puedes comprobar rápidamente haciendo un par de búsquedas y dejar un comentario abajo para corregir.
Situación
Resulta que tenemos entre manos ahora un Magento, pero no podemos entrar al panel de administración que lo tenemos en: https://nombredominio.com/index.php/admin
Pero sí que tenemos acceso a la base de datos. Es imprescindible tenerlo porque si no entonces tendremos que descartar éste mecanismo de recuperación. Necesitamos entonces acceso mediante phpMyAdmin, Mysql Workbench, línea de comandos..
Dónde tenemos que tocar
Ahora bien, los administradores están en la tabla admin_user y la contraseña de cada uno es la columna password. Si le hemos puesto un prefijo a las tablas entonces la tabla será de la forma prefijo_admin_user. Jeje, parece fácil pero ahora bien ¿qué cifrado se usa en Magento? Pues MD5, y se le añade una semilla al cifrado para hacerlo mejor.
Cómo cifra Magento las claves de administrador
Resumiendo, la estrategia es que pone una semilla delante de la contraseña. Si por ejemplo la semilla va a ser la palabra ‘semilla’ y la contraseña ‘thepass’ lo que hace es cifrar con MD5 la cadena ‘semillathepass’ y luego al resultado le añade después ‘:semilla’ y lo guarda.
Simplemente tenemos que ejecutar lo siguiente que hace esto que explico aquí arriba en el cliente de la base de datos Mysql y tendremos entonces la contraseña cambiada: UPDATE basededatos.prefijo_admin_user SET password=CONCAT(MD5(‘semillathepass’), ‘:semilla’) WHERE username=’administrador’;
Simplemente ejecutamos esto y se actualizará la clave del administrador ‘administrador’ poniéndole de clave ‘thepass’. Ya lo modificas a tu gusto y a correr 😉
¿Y las claves de usuarios clientes de la tienda?
Ahora bien, vamos a ir un paso más allá. Porque ¿dónde están las claves de los clientes? Éstas las tenemos en la tabla prefijo_customer_entity_varchar, y en prefijo_customer_entity tenemos los valores principales de los usuarios. Y en mi instalación estoy viendo que el atributo de identificador 12 corresponde a las claves de clientes. Que a su vez están cifradas de forma similar a las de administrador.
¿Pero qué tenemos aquí? ¿Porqué tenemos tantas tablas? ¿No sería mas sencillo una supertabla con una fila para cada usuario? Lo que ocurre es que Magento usa el modelo de datos EAV. Es un modelo de datos con el que los atributos que van a tener unos elementos se definen en una tabla, en otras se definen los principales valores de dichos elementos, y los valores disponibles se definen en otra tabla. Esto es engorroso para programar pero proporciona que se puedan definir en ejecución tantos valores como queramos de forma de que no se tengan que modificar ni códigos fuentes ni base de datos. Es muy potente, flexible, pero es engorroso y aumenta la complejidad.. a la hora de tocar base de datos o hacer consultas.
Es muy sencillo verlo de la siguiente forma. Tenemos la tabla de atributos prefijo_eav_attribute, si vemos un listado de algunos atributos podemos tener algo tal que así:
Fíjate que el atributo 12 es el password_hash. Ahora si vamos a los atributos de los customers que tenemos en la tabla prefijo_customer_entity_varchar y vemos los valores de las filas con attribute_id que sea 12 veremos que se parecen a contraseñas como las de los administradores ¿verdad?
Jeje, pues ya tenemos ahí las contraseñas. Parece que tenemos también la semilla después de los dos puntos concatenada con la clave. Será fácil entonces hacer otra consulta que actualice la contraseña de los usuarios de igual manera que la de los administradores.
UPDATE basededatos.prefijo_customer_entity_varchar SET password=CONCAT(MD5(‘semillathepass’), ‘:semilla’) WHERE value_id=1030;
Esta última consulta se supone que modificará la contraseña del cliente con identificador 175, es el valor 1030. A su vez el cliente que tendrá su email en la tabla prefijo_customer_entity y otros datos repartidos por sus tablas correspondientes.
Terminando
Ya lo dejo aquí, con el modelo de datos EAV, que es muy potente, tendremos disponibles todos los datos y podremos andar modificando no sólo las contraseñas de los clientes. Habrá que tener especial cuidado de no sobrecargar de consultas la base de datos, o hacerlo bien optimizándolas con JOINs en vez de concatenando tablas, no creando demasiados bucles que consultan datos y a su vez vuelven a consultar más datos con los resultados, etc.. porque fácilmente podemos relentizar en funcionamiento de nuestro Magento. Pero por otro lado tendremos un sistema muy potente para ir añadiendo lo que necesitemos si crear más y más tablas cada 2 por 3, con el consecuente peligro a la hora de actualizar cuando se añaden tablas o se modifica la base de datos.
Hola de nuevo. Aquí traigo otro pequeño HOWTO para automatizar la instalación de un servidor Postresql. Como ya indico en el post anterior, estoy jugueteando con Vagrant y necesito instalar la base de datos automáticamente para no tener que estar haciéndolo cada vez. Así que ya puestos a usar Vagrant o simplemente a usar la línea de comandos podemos ejecutar estos comandos para instalar y configurar Postgresql sin sufrir mucho y comenzar a trabajar lo antes posible.
Porqué Postgresql
Un compañero de trabajo me hizo una vez la pregunta, ¿porqué Postgresql?
Es un gigante de las bases de datos relacionales. Robusta como ella misma, soporta clustering, integridad referencial.. una cantidad ingente de características. En sus últimas versiones no tiene nada que envidiar al resto de bases de datos. Y mucho la catalogan como la mejor base de datos relacional Open Source. Además de que tenemos el pgAdmin que funciona a las mil maravillas.
https://es.wikipedia.org/wiki/PostgreSQL
Hay cantidad de información por Internet, ya que desde 1982 leo que está dando guerra, así que te puedes hacer una idea de si es o no una buena elección. Cada cual que mire cuáles son sus requisitos pues no es objetivo de este post hacer una comparativa.
Dónde está el script
Sin más preámbulos el script de instalación es el siguiente:
postgres_conf_file=»/etc/postgresql/9.3/main/postgresql.conf» postgres_pg_hba_file=»/etc/postgresql/9.3/main/pg_hba.conf» main() { apt-get -y install postgresql sudo -u postgres psql<<EOI password postgres postgres postgres q EOI sed -i «s/#listen_addresses = ‘localhost’/listen_addresses = ‘*’/g» ${postgres_conf_file} cat <<EOI > ${postgres_pg_hba_file} local all all md5 host all all 127.0.0.1/32 md5 host all all 10.0.2.2/32 md5 host all all ::1/128 md5 EOI service postgresql restart } main exit 0
A fecha en que escribo, este código se puede incluir en un Schell Script que por ejemplo podemos llamar instalarPostgresql.sh, darle permiso de ejecución y lanzarlo. Funciona con la versión que se instala actualmente en un servidor de producción con Ubuntu Server 14.04 que es la 9.3 de Postgresql si no me falla la memoria.
Simplemente instala el servidor, se conecta con el cliente psql para cambiar la contraseña del administrador postgres, escucha en todas las interfaces de red y permite conectar por red a 127.0.0.1 y a 10.0.2.2 que es la IP que se ve desde dentro de una máquina virtualizada con Vagrant.
