Entradas etiquetadas con configuracion
Integración continua: Automatizando la creación de proyectos WordPress, Drupal, Symfony, etc. (II)
0En el post anterior hemos actualizado el script que crea los repositorios, para poder añadirle unas cuantas acciones para automatizar la creación del proyecto (creación de directorios, directorios ignorados, etc.). Ahora vamos a desarrollar la segunda parte, que consistirá en la automatización de la instalación del cms o framework elegido.
Integración continua: Instalando y configurando Redmine
0¿Qué es Redmine?
Redmine es una herramienta de gestión de proyectos, nos permite mantener un control de las tareas y errores a solucionar en ellos. Esta herramienta nos permite organizar los proyectos por versiones, o por springs si utilizas alguna metodología ágil. Dispone de gráficos Grantt, wiki, acceso al repositorio del proyecto, etc.; muchísimas características que nos facilitan el día a día en el desarrollo de proyectos.
Instalando Redmine
La instalación de Redmine es bastante sencilla, utiliza el siguiente comando:
apt−get install redmine redmine−mysql libapache2−mod−passenger
Una vez instalado y configurado creamos una carpeta en /var/www llamada redmine:
mkdir /var/www/redmine
A continuación, creamos un enlace simbólico con el contenido que se mostrará en el navegador:
ln −s /usr/share/redmine/public /var/www/redmine
Accediendo a Redmine desde un subdominio
Ahora configuraremos un subdominio para poder acceder a Redmine.
Comprueba que tienes activado el módulo passenger en apache2:
a2enmod passenger
Instala «bundle», una gema de Ruby:
gem install bundle
Da permisos al usuario www-data:
usermod −aG root www−data chmod 775 −R /usr/share/redmine
Modifica el archivo /etc/apache2/mods-available/passenger.conf añadiendo la siguiente línea:
PassengerDefaultUser www−data
Crea el VirtualHost en /etc/apache2/sites-available, con el siguiente contenido:
*:80> ServerName redmine.ic.net DocumentRoot /var/www/redmine /var/www/redmine> AllowOverride all Options −MultiViews PassengerResolveSymlinksInDocumentRoot on
Reinicia apache:
/etc/init.d/apache2 restart
Al igual que hicimos con Jenkins, será necesario que modifiques tu archivos hosts y añadas la siguiente línea:
192.168.1.40 redmine.ic.net
Sustituye la IP por la tuya.
Ahora, si escribes la dirección de Redmine en tu navegador podrás acceder a tu gestor de proyectos. El usuario para el administrador es «admin» y su contraseña «admin».
A partir de aquí, es cosa tuya. Crea algunos proyectos, añade algunas versiones, tareas, errores, etc.
Integración continua: primeros pasos
0Ya expliqué la semana pasada qué era eso de la integración continua, pues bien, ahora toca dar los primeros pasos. Obviamente necesitamos un ordenador que haga de servidor, una máquina virtual, o bien un servidor de verdad si lo que pretendes es utilizar de forma profesional.
Como sistema operativo para esta guía utilizaré Ubuntu 14.04. Tú puedes usar el que quieras pero tal vez te resulte más complicado encontrar algún software, con lo que tendrás que investigar más.
El hardware a usar dependerá de las necesidades que tengas, o para lo que quieras un servidor de integración continua. En mi caso utilizo un pc de gama baja con micro AMD, 8 GB de RAM, sin teclado, ratón, ni monitor (y por tanto sin escritorio gráfico), y con una tarjeta WiFi para conectar a internet. Y esto, para mí, es suficiente. Si lo fueses a usar en un grupo de desarrollo, lo mejor es usar un VPS o un servidor dedicado, ya que mejorará en gran medida el rendimiento.
Ya tenemos el hardware listo y nuestro sistema operativo está instalado, por tanto vamos a iniciar los primeros pasos para crear nuestro servidor de integración continua.
Integración continua: Introducción
0Supongo que os preguntaréis qué es eso de la integración continua, pues bien, os explico: se considera Integración Continua al conjunto de metodologías y procesos que se ejecutan durante el desarrollo de un proyecto de programación, con la diferencia de que estos procesos están centralizados y automatizados, lo que permite ejecutarlos cada pocas horas.
Dentro de los procesos automatizados se encuentran la descarga de los repositorios, la comprobación de los estándares de codificación, la ejecución de los test unitarios, la actualización de la base de datos, el despliegue al servidor de producción, etc. Cualquier proceso que se ejecute durante el desarrollo de un proyecto se puede integrar en este sistema.
Esta forma de trabajar nos permite a los desarrolladores detectar, antes de poner en producción el proyecto, posibles errores o ineficiencias, pudiendo solucionarlos y mejorando con ello la calidad del software que generamos.
Sirva este pequeño artículo como introducción a esta nueva sección del blog, ya que durante las próximas semanas iré publicando nuevos artículos para que podáis montar vuestro propio servidor de integración continua, me centraré en la automatización de procesos en proyectos PHP, ya sean basados en Frameworks (Symfony, Zend, etc.), CMS (WordPress, PrestaShop, etc.) o creados desde cero, aunque es muy posible que muchas cosas de las que os explique podáis utilizarlas para otros lenguajes de programación. Os explicaré tanto la instalación del software necesario como su configuración, además de como unir todo el software para que se ejecute de forma automática.
De momento os dejo con varios links para que le vayáis echando un ojo a eso de la Integración Continua:
Optimizar el servidor web Apache
1Tenía intención de crear un post explicando la optimización de Apache, pero la verdad es que en la red ya existe bastante información al respecto por tanto os dejo dos links, uno explicando cada uno de los parámetros que se pueden modificar en el archivo httpd.conf de Apache y el otro con algunos ejemplos de optimización: – Definición de parámetros: http://www.codenb.com/optimizar-apache-16/ – Ejemplos: http://www.forosdelweb.com/f58/recetas-para-configuracion-apache-404961/
#symfony, I18N, UTF-8 y Dreamweaver
0Supongo que ya sabrás de lo que voy a hablar, sí, codificación de caracteres y el jodío de Dreamweaver. Te cuento:
Estoy haciendo algunas pruebas con Symfony y su sistema de internacionalización ( I18N ), y para ello he hecho que el charset que muestre la plantilla sea utf-8 (además de las tablas de la BD y las conexiones desde y hacía la BD), lo curioso es que cuando he ido a verlo en el navegador el resultado me aparecía con chinos (unos cuadrados (aunque pueden ser otros símbolos) que sustituyen a las letras con tilde), total que me he tirado todo el día dándole vueltas al tema, y el problema lo tenía en Dreamweaver que, por defecto, guarda los archivos en «Europeo occidental» y no en utf-8.
Te explico todo lo que he modificado en el proyecto de Symfony, por si te pasa algo parecido puedas comparar. Con esta configuración que te voy a mostrar el sistema de internacionalización de Symfony funciona al 100%:
Antes de nada te informo que esto está pensado para Symfony 1.4, versiones superiores o inferiores pueden necesitar una configuración distinta. Cuando hablo de Dreamweaver me refiero a la versión CS3, aunque muy probablemente algo parecido haya en versiones superiores.
settings.yml
Doy por hecho que ya has creado el proyecto, al menos una aplicación y un módulo con el que hacer pruebas. Nos vamos al archivo settings.yml de la app y añadimos:
- all:
- .settings:
-
- # Indicamos la cultura por defecto
- # Aquí poned la que os interese
- default_culture: es_ES
-
- # Indicamos la codificación de caracteres
- charset: utf-8
-
- # Esto lo dejo a tu elección
- # Puedes escribir esta línea para que el helper I18N esté
- # en todas las plantillas de forma global
- # Lo bueno de usar esta opción es que puedes añadir
- # más helpers:
- # standard_helpers: [I18N,text, etc]
- standard_helpers: [I18N]
-
- # O puedes escribir esta otra línea, pero
- # en cada una de las plantillas tendrás que incluir
- # al prinicipio <?php use_helper('I18N') ?>
- # la decisión es tuya
- i18n: true
routing.yml
Modificamos este archivo para indicar el módulo que se mostrará como página de inicio (homepage):
- # Esto es lo que está por defecto
- homepage:
- url: /
- param: { module: default, action: index }
-
- # Lo único que cambio es el nombre del módulo, que en mi caso es 'login'
- homepage:
- url: /
- param: { module: login, action: index }
view.yml
Este archivo creo que no hacia falta modificarlo para la internacionalización, pero por si acaso:
- metas:
- language: es
indexSuccess.php del módulo
Añadimos el texto que vamos a probar:
- // No voy a poner todo el código que tengo en mi plantilla
- // así que pongo solo un ejemplo
-
- <?php echo __('Hola Mundo!') ?>
-
- // Esto te mostrará el texto en español
Bien, como le hemos dado el valor «es_ES» a «default_culture«, Symfony no mostrará ninguna traducción sino el valor que le hemos indicado en la plantilla. Para hacer una prueba en condiciones vamos a modificar la cultura de un usuario a «en_EN«, esto mantendrá la cultura de todo el proyecto como «es_ES«.
actions.class.php del módulo
En la acción Index escribimos lo siguiente:
- class loginActions extends sfActions
- {
- /**
- * Executes index action
- *
- * @param sfRequest $request A request object
- */
- public function executeIndex(sfWebRequest $request)
- {
-
- // Esta línea cambiará la cultura SÓLO para el usuario
- $this -> getUser() -> setCulture('en_EN');
-
- return sfView::SUCCESS;
- }
- }
Obviamente nos falta crear el archivo que le indicará a Symfony el texto que debe utilizar para su sustitución. A ello voy:
english.en.xml
Este archivo se guarda en la carpeta «i18n» de la app, aunque también puedes crear la carpeta dentro del módulo y guardar el archivo allí. Este archivo tiene un formato especial que se debe mantener:
- <?xml version="1.0" encoding="utf-8"?>
- <xliff version="1.0">
- <file orginal="global" source-language="en_EN" datatype="plaintext">
- <body>
- <trans-unit id="1">
- <source>Hola Mundo!</source>
- <target>Hello World!</target>
- </trans-unit>
- <trans-unit id="2">
- <source>soy un texto</source>
- <target>I'm a text</target>
- </trans-unit>
- <trans-unit id="3">
- <source>Adiós</source>
- <target>Bye</target>
- </trans-unit>
- </body>
- </file>
- </xliff>
Cosas importantes respecto de este archivo:
- Le puedes poner cualquier nombre pero debe acabar en *.culture.xml, por ejemplo: login.en.xml, registro.en.xml, administracion.fr.xml, comentario.it.xml.
- También se puede poner la cultura completa, es decir, en vez de solo *.en.xml puedes nombrarlo como *.en_EN.xml.
- El parámetro «source-language» siempre debe indicar la cultura que se va a traducir, en este caso es el ingles (en_EN).
- Cada texto a traducir está dentro de la etiqueta <trans-unit>, que tiene el atributo id, pues bien, cada frase a traducir debe aumentar el id ( 1,2,3,4,5….500 etc)
- No es necesario que todas las frases estén en un solo archivo, puede haber varios archivos con textos diferentes, por ejemplo, para el menú, la cabecera, el pie de página, etc.,. Importante: aunque sean archivos para idiomas diferentes el nombre del archivo siempre debe ser el mismo, variando, eso sí, la cultura.
Una vez guardado el archivo volvemos al indexSuccess.php y lo modificamos para que quede tal que así;
- // No voy a poner todo el código que tengo en mi plantilla
- // así que pongo solo un ejemplo
-
- <?php echo __('Hola Mundo!', null, 'login') ?>
-
- // Ahora mostrará el texto que corresponda con la cultura del usuario
- // Además lo buscará en un archivo concreto en este caso login.en.xml
Y así se internacionaliza un proyecto Symfony. Ahora el problemita de Dreamweaver:
El bicho, (por llamarlo de alguna manera) tiene una opción para abrir archivos que no indiquen su codificación. Normalmente está en «Europeo occidental» y debería estar en «Unicode (utf-8)«. Para cambiarlo accedemos al menú «Edición -> Preferencias…» y en «Nuevo documento» busca un desplegable que ponga «Codificación pred.«; ahí elige «Unicode (utf-8)«, activa la casilla que dice «Utilizar al abarir archivos existentes que no indiquen su codificación» y en el desplegable de abajo (Formulario de normas Unicode) selecciona «C (descomposición de compatibilidad seguida de composición canónica)«. Pulsa aceptar y prueba el en navegador.
Tal vez tengas que limpiar la cache de Symfony para ello solo tienes que escribir en la consola (que debe apuntar a la carpeta donde tienes el proyecto) symfony cc o php symfony cc.
Si sigue fallando, abre el archivo indexSuccess.php del módulo con el bloc de notas, y sin modificar nada, vete a Archivo -> Guardar como… , ahí podrás elegir la codificación, en nuestro caso, utf-8, y para evitar que se guarde como un archivo .txt elige «Todos los archivos» y así se guardará en php. Vuelve a limpiar la caché y vuelve a probar, ahora sí te debería funcionar bien.
Symfony: El controlador (III)
0SEGURIDAD DE LA ACCIÓN
Con Symfony podemos controlar quién puede acceder a una acción concreta, utilizando para ello las herramientas de identificación de usuarios que el framework nos provee.
Una acción segura sólo podrá ser ejecutada por un usuario registrado y que tenga la acreditación para ello.
- Las acciones seguras requieren que los usuarios estén autenticados.
- Las credenciales son privilegios de seguridad agrupados bajo un nombre y que permiten organizar la seguridad en grupos.
- ver:
- is_secure: off # Todos los usuarios pueden ejecutar la acción "ver"
-
- modificar:
- is_secure: on # La acción "modificar" es sólo para usuarios autenticados
-
- borrar:
- is_secure: on # Sólo para usuarios autenticados
- credentials: admin # Con credencial "admin"
-
- all:
- is_secure: off # off es el valor por defecto
Lo que sucede cuando un usuario trata de acceder una acción restringida depende de sus credenciales:
- Si el usuario está autenticado y tiene las credenciales apropiadas, entonces la acción se ejecuta.
- Si el usuario no está autenticado, es redireccionado a la acción de login.
- Si el usuario está autenticado, pero no posee las credenciales apropiadas, será redirigido a la acción segura por defecto.
Las páginas login y secure son bastante simples, por lo que seguramente será necesario personalizarlas. Se puede configurar que acciones se ejecutan en caso de no disponer de suficientes privilegios en el archivo settings.yml de la aplicación cambiando el valor de las propiedades:
- all:
- .actions:
- login_module: default
- login_action: login
-
- secure_module: default
- secure_action: secure
OTORGANDO ACCESO
Los métodos utilizados para permitir acceso a una acción segura se encuentran en el objeto sfUser. El estado identificado se establece con setAuthenticated() y se puede comprobar con isAuthenticated():
- <?php
-
- class miCuentaActions extends sfActions
- {
- public function executeLogin($peticion)
- {
- if ($peticion->getParameter('login') == 'valor')
- {
- $this->getUser()->setAuthenticated(true);
- }
- }
-
- public function executeLogout()
- {
- $this->getUser()->setAuthenticated(false);
- }
- }
Las credenciales son un poco más complejas de tratar, ya que se pueden verificar, agregar, quitar y borrar:
- <?php
-
- class miCuentaActions extends sfActions
- {
- public function executeEjemploDeCredenciales()
- {
- $usuario = $this->getUser();
-
- // Agrega una o más credenciales
- $usuario->addCredential('parametro');
- $usuario->addCredentials('parametro', 'valor');
-
- // Verifica si el usuario tiene una credencial
- echo $usuario->hasCredential('parametro'); => true
-
- // Verifica si un usuario tiene una de las credenciales
-
- // Verifica si el usuario tiene ambas credenciales
-
- // Quitar una credencial
- $usuario->removeCredential('parametro');
- echo $usuario->hasCredential('parametro'); => false
-
- // Elimina todas las credenciales (útil en el proceso de logout)
- $usuario->clearCredentials();
- echo $usuario->hasCredential('valor'); => false
- }
- }
Las credenciales se pueden utilizar también para mostrar contenido autenticado en una plantilla:
- <?php
-
- <ul>
- <li><?php echo link_to('seccion1', 'content/seccion1') ?></li>
- <li><?php echo link_to('seccion2', 'content/seccion2') ?></li>
- <?php if ($sf_user->hasCredential('seccion3')): ?>
- <li><?php echo link_to('seccion3', 'content/seccion3') ?></li>
- <?php endif; ?>
- </ul>
CREDENCIALES COMPLEJAS
a sintaxis YAML utilizada en el archivo security.yml permite restringir el acceso a usuarios que tienen una combinación de credenciales, usando asociaciones de tipo AND y OR. Con estas combinaciones, se pueden definir flujos de trabajo y sistemas de manejo de privilegios muy complejos — como por ejemplo, un sistema de gestión de contenidos (CMS) cuya parte de gestión sea accesible solo a usuarios con credencial admin, donde los artículos pueden ser editados solo por usuarios con credenciales de editor y publicados solo por aquellos que tienen credencial de publisher:
- editarArticulo:
- credentials: [ admin, editor ] # admin AND editor
-
- publicarArticulo:
- credentials: [ admin, publisher ] # admin AND publisher
-
- gestionUsuarios:
- credentials: [[ admin, superuser ]] # admin OR superuser
Cada vez que se añade un nuevo nivel de corchetes, la lógica cambia entre AND y OR. Así que se pueden crear combinaciones muy complejas de credenciales, como la siguiente:
- credentials: [[root, [supplier, [owner, quasiowner]], accounts]]
- # root OR (supplier AND (owner OR quasiowner)) OR accounts
CONFIGURACIÓN DEL MÓDULO
Algunas características de los módulos dependen de la configuración. Para modificarlas, se debe crear un archivo module.yml en el directorio config/ y se deben definir parámetros para cada entorno (o en la sección all: para todos los entornos).
- all: # Para todos los entornos
- enabled: true
- is_internal: false
- view_class: sfPHP
- partial_view_class: sf
El parámetro enabled permite desactivar todas las acciones en un módulo. En ese caso, todas las acciones se redireccionan a la acción module_disabled_module/module_disabled_action (tal y como se define en el archivo settings.yml).
El parámetro is_internal permite restringir la ejecución de todas las acciones de un módulo a llamadas internas. Esto es útil por ejemplo para acciones de envío de correos electrónicos que se deben llamar desde otras acciones para enviar mensajes de e-mail, pero que no se deben llamar desde el exterior.
El parámetro view_class define la clase de la vista. Debe heredar de sfView. Sobreescribir este valor permite utilizar otros sistemas de generación de vistas con otros motores de plantillas, como por ejemplo Smarty.
El parámetro partial_view_class define la clase de la vista que se emplea para los elementos parciales de este módulo. La clase indicada debe heredar de sfPartialView.
Pasar un proyecto symfony de un servidor a otro (a capón xD)
6Sí, soy un poco bestia para algunas cosas jejeje; en este caso tuve que pasar el proyecto con el que estaba trabajando en el portatil al ordenador de sobremesa. En el portatil tengo instalada una versión de WAMP y en el sobremesa AppServ así que cuando pasé la carpeta del proyecto con un copy&paste y fui a ejecutarlo al navegador, obviamente no funcionaba, exactamente daba este error:
Warning: sfAutoload::require(C:/wamp/www/sf_sandbox/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/database/sfDoctrineDatabase.class.php) [sfautoload.require]: failed to open stream: No such file or directory in F:\AppServ\www\sf_sandbox\lib\vendor\symfony\lib\autoload\sfAutoload.class.php on line 188
Fatal error: sfAutoload::require() [function.require]: Failed opening required ‘C:/wamp/www/sf_sandbox/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/database/sfDoctrineDatabase.class.php’ (include_path=’.;F:\AppServ\php5\pear’) in F:\AppServ\www\sf_sandbox\lib\vendor\symfony\lib\autoload\sfAutoload.class.php on line 188
Continue reading “Pasar un proyecto symfony de un servidor a otro (a capón xD)” »