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.
Este es un pequeño HOWTO para instalar la base de datos. He estado jugueteando con Vagrant estos días probando como instalar automáticamente máquinas virtuales de forma automática, y me topé con el problema de cómo hacer un script que me instalara la BD en el sistema y que además dejara configurada la contraseña de administrador.
Este script funciona para Ubuntu 15.04, el cual te instala MariaDB 10.0 por defecto, que viene a ser la última versión estable de la aplicación.
MariaDB
Esta base de datos es un replace del archi-conocido MySQL pero al cual le han mejorado en varios aspectos. Es decir, tras la compra por parte de Oracle de MySQL, el equipo de desarrollo de la base de datos se separó continuando su desarrollo en lo que ahora se conoce como MariaDB.
Hay quien dice que Oracle pretendía estancar el desarrollo porque ya tiene sus propios productos de base de datos. Pueden haber sido diferencias de opiniones entre los desarrolladores. A saber cuál ha sido el porqué, el hecho es que MariaDB ha cogido fuerza. Por lo que la he probado funciona muy bien y tengo un servidor en producción que va muy bien hasta la fecha de hoy.
Al grano, el script
Esto a continuación se puede poner en un fichero, por ejemplo, llamado instalarMariaDB.sh y ejecutarlo: echo «######################################################################################» echo «# This script will install MariaDB and will set the root password.» echo «# It only works for first time execution. If it fails, check one command each time.» echo «######################################################################################»
sudo mysql -u root<<EOI use mysql; update user set plugin=» where User=’root’; update user set password=PASSWORD(«root») where User=’root’; flush privileges; quit EOI
sudo service mysql restart
Con esto ya dejo el ordenador y al sobre. Un saludo.
Imaginemos que somos mecánicos y tenemos un coche. Le estamos arreglando un faro, un faro que se ha roto o que alumbra poco o tiene un golpe. Ya tenemos la pieza de recambio, quitamos el faro antiguo y le ponemos el nuevo. Acto seguido ¿qué debemos hacer? ¿llamamos al dueño a que lo recoja directamente?
Tenemos mucha prisa porque estamos reparando una cosa tras otra. Nos han hecho una llamada de última hora y no nos hemos dado cuenta de que no hemos hecho las conexiones correctamente. Llega el dueño, va a arrancar y revienta un fusible porque no hemos hecho las conexiones bien. Ahora es cuando se nos cae la cara de vergüenza porque ni siquiera hemos arrancado el coche a ver si funcionaba el nuevo faro..
En el desarrollo de software es de vital importancia hacer los programas rápidamente, entregarlos en el tiempo y forma, además de que deben funcionar bien. Estas prisas nos pueden jugar malas pasadas pero hay soluciones profesionales, formas de trabajo para controlar o evitar estos problemas.
Pruebas unitarias y funcionales
Esto que le ha pasado al mecánico con prisas es lo mismo que nos puede pasar si entregamos un programa sin haber hecho las pruebas pertinentes. En el mundo del software existen, además de las pruebas manuales, formas de trabajo en las que se pueden tener una batería de pruebas automatizadas que prueben el buen funcionamiento de una aplicación.
Por ejemplo, estoy empezando el desarrollo de un proyecto Open Source y tenemos ya el inicio de unas pruebas automatizadas. Los resultados de cobertura del código se pueden ver aquí:
http://obmscoverage.jnjsite.com/
Esto es el resultado de un navegador que simula un usuario que va probando las diferentes secciones de una aplicación web (programa web). El resultado mostrado es el Code Coverage, que significa cobertura del código. Es decir, es el porcentaje del programa que se ha probado navegando automáticamente por él sin que se funda ningún fusible 😉
Para el que quiera curiosear más en el programa que cito, el repositorio público está aquí:
https://github.com/obms/obms
Garantía de buen funcionamiento
Un nivel adecuado de cobertura oscila desde el 70% al 100%. Es muy tedioso alcanzar el 100%, y dependiendo de la naturaleza del software con un 70% – 80% será bastante. Pero si de ello dependen sistemas de vital importancia es aconsejable aumentar la cobertura al 100% o casi.
Esto a su vez evita que a medida que se va ampliando un programa, pasen desapercibidos errores nuevos al introducir nuevas mejoras en las aplicaciones web. Por esto es siempre bueno pedir los resultados de las pruebas automatizadas.
Integración Contínua (CI, Continuous Integration)
La integración continua es el sistema por el que todas estas pruebas automáticas se lanzan continuamente dando reportes de estado y alarmas para su supervisión.
Es un buen trabajo montar este sistema, pero una vez montado, la persona o el equipo de desarrollo se centrarán en desarrollar las nuevas funcionalidades, o en mantener el software.
Todo estará centralizado, organizado desde un punto desde el que, cada cierto tiempo se lanzarán automáticamente toda esta serie de pruebas automatizadas. También se suelen hacer a ciertas horas del día, o por la noche. Se podrán ver los resultados, con todo tipo de estadísticas. Se pueden automatizar análisis para buscar posibles problemas futuros, códigos fuentes duplicados. Se puede estudiar la mantenibilidad de un programa, entre otras cosas..
Para el proyecto anterior que cito, junto con las pruebas también se generan reportes de peligros o chequeos de estilo del código fuente:
http://obmscode.jnjsite.com/
También la documentación de la aplicación:
http://obmsdoc.jnjsite.com/
Aquí, el equipo o persona encargada de desarrollar, se podrá centrar en el análisis y programación puramente. Siempre que el sistema de Integración Contínua no de señales de alarma simplemente se puede continuar el trabajo, pudiendo dormir tranquilo.
Entregando
Aquí no termina todo, ahora tenemos un programa. Un programa que no da fallos, ha pasado las pruebas, tenemos alto porcentaje de cobertura, etc.. pero quedan otras tareas.
Una cosa es que el programa no de errores, y otra que haga lo que realmente tiene que hacer. Aquí es donde empezarán las pruebas de usuario, mantenimientos varios. Las llamadas pruebas de estrés, donde se mide la capacidad que tiene un programa. Es como si llevamos al circuito de carreras al coche con el que estamos trabajando para probarlo, damos unas cuantas vueltas viendo cómo va todo, su velocidad, frenada, etc.. Ahora sí que estaremos seguros al entregar el coche de que todo va a ir bien, o casi seguros.
Se quedan en el aire muchos conceptos pero no quiero extenderme demasiado y así tengo tema para otros posts 😉
Este es un pequeño HOWTO para tener de referencia.
Si tienes una relación entre dos entidades de la forma ManyToMany, una de ellas tendrá inversedBy y la otra mappedBy. Con un ejemplo se ve más claro.
Suponiendo que has generado las acciones CRUD con el comando siguiente:
$ php app/console doctrine:generate:crud
Supongamos que tenemos usuarios y negocios relacionados así, en una relación muchos a muchos. En la entidad Business tenemos: /** * @ORMManyToMany(targetEntity=»User», * inversedBy=»users», cascade={«persist»}) */ private $users;
Y en la entidad User tenemos:
/** * @ORMManyToMany(targetEntity=»Business», * mappedBy=»users», cascade={«persist»}) * @ORMJoinColumn(onDelete=»SET NULL») */ private $businesses; Ahora el editar los usuarios tenemos en el formulariode edición de un usuario lo siguiente:
->add(‘businesses’, ‘entity’, array( ‘by_reference’ => false, //.. )) La entidad inversedBy, que en este caso es Business, guardará correctamente los Users referenciados al editarlos. Pero al contrario con la entidad Users, tiene los Business mapeados, lo que hará que no guarde automáticamente las referencias.
Hay que añadir lo que he puesto en negrita en los códigos anteriores y en la entidad User lo siguiente para permitir que añada y borre los Business correctamente.
/** * Add businesses. * * @param AppBundleEntityBusiness $businesses * * @return User */ public function addBusiness(AppBundleEntityBusiness $business) { $this->businesses[] = $business; $business->addUser($this);
return $this; }
/** * Remove businesses. * * @param AppBundleEntityBusiness $businesses */ public function removeBusiness(AppBundleEntityBusiness $business) { $this->businesses->removeElement($business); $business->removeUser($this); }
Con ésto ya debe de funcionar. Si estamos editando un Business y añadimos o borramos Users lo hará correctamente, y de la forma inversa, si estamos editando un User, también añadirá o borrará Business.
Brutal el proyecto que están desarrollando en Sylius. Navegando y navegando por proyectos para hacer tiendas online. Viendo las principales opciones del mercado: Magento, Prestashop y WordPress con WooCommerce. Me planteaba la opción de cómo sería desarrollar una tienda completa en Symfony. Integrar pasarelas de pago, métodos de envío, ordenando todo los productos por categorías, valores, atributos de los productos.. es un trabajazo. Pero por otro lado no quería prescindir de la flexibilidad y agilidad que nos da un buen framework PHP, en este caso el gran Symfony.
Aterrizaje
Todas estas búsquedas me llevaron a encontrar Sylius. Lo que hasta ahora es el proyecto de tienda online basado en Symfony que me ha parecido más interesante. A fecha en que escribo está en fase de desarrollo aunque hay quien ya lo está utilizando.
Se trata de un proyecto Open Source, licenciado bajo la MIT license. Esto nos permite usar Sylius para cualquier proyecto, libremente sin coste de compra ninguno. Lo único que no se pude hacer es decir que Sylius lo hemos hecho nosotros, como es lógico. Se puede adaptar, modificar, ampliar, etc.. Cualquier cosa se puede hacer porque lo que tenemos entre manos es un proyecto Symfony.
Diferenciación
La principal diferenciación es que para modificarlo no tienes que leerte una ingente cantidad de documentación. Cuando estás desarrollando algo para algún CMS como WordPress, Magento, Joomla.. debes tener siempre a mano su documentación. Acabas especializándote y luego no te puedes salir de dicha plataforma. Por otro lado, el que mucho abarca poco aprieta, no te puedes espcializar mucho en un CMS en concreto. Si lo haces, que luego no te saquen de ahí porque cuando te llevan a otro CMS es otro mundo.
Al ser una plataforma 100% en Symfony, todo sigue el esquema general. Las plantillas están donde deben de estar, igual los controladores, las entidades de las bases de datos. La estructura de directorios es la misma que la de cualquier proyecto Symfony. Las nuevas librerías se añaden igual que cualquier proyecto Symfony. Todo está en su sitio. Esto agiliza mucho la adaptación y ampliación de funcionalidades. No necesitas sumergirte en un mar de documentación específica del CMS en cuestión.
Características
Por su propia naturaleza, se trata de un programa muy potente, rápido, flexible, adaptable y escalable a más no poder. Es como si se tratara de un desarrollo de una tienda 100% artesanal, pero donde estará casi todo listo para usar.
Esta siendo traducido a varios idiomas, con zona frontal, zona de administración. Tendremos productos, el clásico carro de la compra, productos organizados por categorías y atributos, formas de pago, métodos de envío, gestión de mensajes de clientes, páginas estáticas, además de muchas otras configuraciones. Incluso se prevee la inclusión de una API para interconectar el sistema Sylius con otros sistemas.
Resumiendo
¡Toda una joya de la informática! A mi me parece un gran proyecto. Que está siendo organizado empresarialmente desde Lakion.com. Una empresa que preveo que ofrecerá todo tipo de servicios alrededor del proyecto. De igual forma que hacen la mayoría de proyectos Open Source.
Resumiendo, tenemos un gran proyecto. Pretende revolucionar el mundo de los CMS de tiendas online. Está siendo una revolución en el mundo de la programación a medida. Y seguro que lo va a ser también en el mundo de los CMSs cuando alcance su madurez para que cualquier no-programador lo use.
