Tag Archive: git


Ha pasado algo más de un año desde la última entrada, pero hemos vuelto con las pilas recargadas. A ver lo que me dura esta vez.
En el último post hablé sobre la seguridad en Symfony y lo desastroso que puede ser una mala configuración. Recordemos que si dejabamos expuesto la carpeta app de un proyecto en Symfony2, podiamos dejar accesible el fichero parameters.yml dejando expuesta las credenciales de la base de datos. Dejar  esto en un servidor con el proyecto accesible desde internet, es invitar a que los malvados nos hagan maldades.

A fecha de hoy, y buscando un poco en Google con el siguiente dork: inurl:app/config/parameters.yml te puedes encontrar varios proyectos con este fichero abierto para todos los públicos.
Y en algunos, no solo te encuentras las credenciales de la base de datos, sino también el usuario y contraseña de una cuenta de correo, (de gmail por ejemplo) si tienen configurado el mailer.

parameters.yml real

Ejemplo de un parameters.yml filtrado

Viendo esto, vamos a repasar las medidas de seguridad para evitar esta fuga de información:

  1. Lo más importante, intenta no dejar publicada la carpeta app. Es el fallo más grande.
  2. Si no queda otro remedio, asegurate que los ficheros .htaccess que vienen con la carpeta estén funcionando, puede que tengamos configurado apache para que no nos deje sobreescribir las directicas de seguridad necesarias.
  3. A lo mejor sería interesante incluir alguna directiva que denegara el acceso a través de web de los ficheros .yml.
  4. Si tenemos el proyecto en un repositorio git, es importantisimo poner en el .gitignore el parameters.yml. Mejor configurarlo 30 veces en producción que tener una sola fuga de información

Con todo esto en cuenta, se nos puede dar la situación de que no quede más remedio que publicar la carpeta app accidentalmente. Pero si hemos seguido los anterioes consejos,
no deberiamos de tener tantos problemas ya que hemos protegido los ficheros yml. Pero creernos que estamos a salvo sería un error. En Symfony2 tenemos la carpeta app/cache
en la que se almacenan los compilados de las plantillas y otros recursos del proyecto. Esta carpeta no suele estar protegida por ningún .htacces, de forma que sus documentos serían accesibles.
Dentro de ella encontramos el fichero appProdDebugProjectContainer.xml donde encontraremos lo mismo que hay en parameters.yml, pero no solo eso, también información jugosa como los bundles que se utilizan en el proyecto, que rutas están protegidas y mediante que roles,etc.

appDevDebugProjectContainer.xml

Fichero appDevDebugProjectContainer.xml publicado

De modo que hay que asegurarse de proteger también esta carpeta.

Conclusión, NO dejeis publicado el directorio app. Os ahorrareis muchos dolores de cabeza. Y tened cuidado con las carpetas que dejais accesible al público, sean del framework que sean.

A estas alturas del partido, podemos encontrar por la red numerosos artículos y opiniones contándonos las bondades de utilizar control de versiones, especialmente Git. Así que he decidido aportar mi granito de arena dando mi opinión de porqué hay que utilizar este fabuloso sistema de control de versiones. Voy a resumirlo en 10 puntos, que creo que cubre  la mayoría de ventajas, por supuesto no son todas, pero en mi opinión creo que sí las más importantes.

  1. Nos proporciona organización: esto es común a cualquier sistema de control de versiones, eso de tener 30 carpetas para diferenciar las versiones sólo nos suele traer dolores de cabeza, pérdida de tiempo y problemas a la hora de entregar un trabajo o ponerlo en producción.
  2. Podemos probar nuestro código de forma más ordenada sin necesidad de crear copias de los ficheros o el proyecto. Codeamos, probamos, que funciona, bien, que no funciona, hacemos un revert y no ha pasado nada.
  3. Nuestro código estará más limpio, ya que con Git no es necesario ir comentando código “por si luego lo uso”. Esto, aparte de ser una mala práctica, luego nos costará más mantener el código, mientras con git siempre podremos ver las versiones antiguas de nuestros archivos y rescatar código eliminado.
  4. Más sencillo controlar los cambios, proyectos y ver el historia. Si instalamos un visor web en nuestro servidor de repositorios, cómo GitLab, o utilizamos GitHub, podremos ver todos nuestros proyectos y navegar de forma sencilla por todas las versiones, ramas, etc.
  5. Las puestas en producción son más sencillas y rápidas, sobre todo hablando de entornos web. Hay gente que todavía utiliza el FTP cómo medio de subir los proyectos, y muchas veces sin comprimir, tardando bastante en subir un proyecto. Aparte de que si has cambiados varios ficheros y se te olvida subir alguno, puedes ocasionar errores en el funcionamiento de la aplicación. Con Git, basta con hacer un pull del proyecto para que suba los cambios casi de forma instantánea y sin dolores de cabeza.
  6. Sirve cómo sistema de copia de seguridad, siempre que lo tengamos en un servidor. Git trabaja de forma no destructiva, así que salvo que utilicemos uno o dos comandos especiales. Nuestra información siempre estará ahí. También donde tengamos un repositorio (servidor y diferentes máquinas), tendremos la historia completa del repositorio. Hay quien piensa que guardandolo en Dropbox o similares tenemos una copia de seguridad. Pero cómo accidentalmente borremos el proyecto de la carpeta, se borarrá entodos los equipos sincronizados. Esto me ha pasado y no fué agradable.
  7. Nos permite fiscalizar mejor nuestro trabajo. Hay veces que necesitamos un historial de los cambios de una aplicación para facturarlos o por otras necesidades. Esto, normalmente conlleva un tiempo buscando correos y papeles con las especificaciones o a veces ni eso ya que las peticiones se hicieron telefónicamente. Si usamos Git podremos ver de un vistazo todos los cambios y cuando se hicieron. Si a esto le añadimos una buena metodología en los mensajes de los commits, aparte del cuándo, podremos saber el qué se cambió.
  8. Compartir nuestro código, Git es ideal para hacer trabajo colaborativo, permitiendo desarrollos en paralelos y si utilizamos GitHub, podemos publicar nuestro código para que la comunidad lo aproveche y nos ayude a mejorarlo.
  9. Trabaja desde cualquier sitio, teniendo un servidor de Git (propio o GitHub) es tremendamente sencillo poder descargarte una versión de tu proyecto en cualquier sitio y trabajar fuera de tu ámbito normal. Esto viene genial para arreglar errores críticos que te pillen fuera de la oficina o por si pierdes o rompes tu equipo.
  10. Estaréis mejor visto laboralmente, actualmente en la gran mayoría de las ofertas de trabajo de programador, están pidiendo que se sepa utilizar un sistema de control de versiones, especialmente Git. Así que dedicándole un par de mañanas, podréis añadir a vuestro curriculum una nueva habilidad que os facilitará encontrar un empleo.

Espero haberos convencido, a aquellos que aún no lo utilicen, para probar este sistema y ver cómo vuestra calidad de vida de programadores.

Después de mucho sin actualizar, ya iba tocando.

Llevo algo más de un mes dandole duro a Symfony 2 otra vez. Esta vez con la versión 2.1, y estoy descubriendo un nuevo mundo utilizando composer para gestionar las dependencias.

Todo aquél que haya comenzado a utilizarlo, sabrá que el repositorio oficial de composer es https://packagist.org/, y aunque tiene un buscador muy bueno, no proporciona suficiente información acerca de los bundles que puedes encontrar. Aparte, de que no es un repositorio exclusivo de bundles de Symfony 2, aunque es lo que más hay.

Así que buscando esta mañana un Bundle para retocar imágenes, he dado con la página http://knpbundles.com/ , que contiene una gran cantidad de bundles (2003 actualmente). Nos da bastante información acerca de cada uno, así como el nombre y enlace para pacakgist (e incluirlo directamente en el composer.json) y la dirección en github. Desde luego , es lo suficientemente interesante cómo para dedicarle unos minutos de nuestro tiempo.

Instalando gitolite

Una vez que tenemos nuestro servidor de git funcionando de forma básica. Pero si queremos darle un uso serio y va a ser utilizado por más de una persona, lo mejor es añadirle un control de seguridad por usuarios. Para eso, podemos utilizar gitolite.
Los requisitos que hay que tener en el servidor:

  •  git 1.6.6+
  • perl 5.8.8+
  • openssh 5.0+
  • Un usuario dedicado para almacenar los repositorios. Como usuario ,vamos a utilizar el que usuario git creado anteriormente.

Cumpliendo estos requisitos, la instalación de gitolite es muy sencilla siguiendo los siguientes pasos:

  1. Nos logueamos con el usuario git.
    $ sudo su - git
    
  2. Hay que asegurarse que el archivo ~/.ssh/authorized_key no existe o está vacio.
    $ rm .ssh -rf
    
  3. Descargamos y configuramos gitolite:
    $ cd /home/git
    $ git clone git://github.com/sitaramc/gitolite
    $ mkdir bin -p
    $ gitolite/install -to ./bin
    $ bin/gitolite setup -pk git.pub
    

    Lo que estamos haciendo es lo siguiente, nos descargamos el proyecto de github, creamos una carpeta bin, donde se van a guardar los ejecutables de gitolite. Yo prefiero hacerlo dentro del home de git, para no guarrear mucho el servidor. Con el comando gitolite/install -to ./bin le indicamos que la instalación la haga en la carpeta que acabamos de crear. Por último, al hacer setup, configura automáticamente gitolite, con -pk git.pub le estamos diciendo que utilice el archivo git.pub, que contiene una clave pública, para hacer el logueo de usuario administrador. Este archivo con la clave pública, deberemos crearlo y pasarselo nosotros. Con esto ya tenemos gitolite configurado para empezar a trabajar.

Creación de la llave pública y privada

Para crear el par llave pública/privada, es tan sencillo como ejecutar:

$ ssh-keygen -t rsa

Nos preguntará donde queremos guardar la clave privada. En nuestro le ponemos el nombre git, para que lo haga en el directorio actual. Nos pedirá una passphrase para proteger la clave privada, en mi caso prefiero dejarla vacia. Nos creará dos archivos nuevo, uno llamado git a secas, que es la clave privada y otro llamado git.pub que es la clave pública. Esta clave pública es la que utilizamos en el apartado anterior. La clave privada, la tendremos que poner en el cliente para poder acceder a la configuración administrativa de gitolite.

Configuración de usuarios y repositorios

Ahora en el cliente, con nuestra clave privada, normalmente en ~/.ssh/id_rsa, hacemos un clone del panel administrativo de gitolite:

$ git clone git@host:gitolite-admin

Si todo está correctamente, hará el pull del proyecto directamente, sin pedir ninguna contraseña. En caso de que nos pida una contraseña, algo estamos haciendo mal con las claves privada/publica.

Dentro del proyecto gitolite-admin hay dos carpetas, config y keydir. En config tenemos el fichero de configuración de gitolite y en keydir, tendremos que poner las claves públicas de los usuarios.

Para configurar gitolite, os dejo el enlace de  la documentación oficial y de un libro de git que a mi me ha servido de mucha ayuda.
Una vez hecho todos los cambios necesarios, haremos un push al servidor y gitolite se encargará automaticamente de actualizar la configuración y el acceso a través de las claves.
Ahora desde nuestro cliente,  podremos ver los repositorios a los que tenemos acceso, así como los permisos:

ssh git@host info

Si pide contraseña, esque hay algún problema con las claves. Si muestra la informaci´no, todo ha ido perfecto y ya podremos trabajar tranquilamente, teniendo el control de seguridad extra, en nuestros repositorios.

Toca volver a reescribir el post, ya que por problemas de hosting, se me perdieron varios posts. Vuelvo a retomar el tema del control de versiones.  Últimamente se habla mucho de GIT,  y la verdad que con razón. Este sistema de control de versiones, es ligero y sencillo de utilizar, sobre todo desde un IDE con soporte para este sistema.

Lo ideal, aparte de utilizarlo en local, es tenerlo en un servidor remoto para poder tenerlo como copia de seguridad, colaborar con otros desarrolladores, etc. La comunidad de github es perfecta para esto. Aunque tiene la desventaja de que los repositorios han de ser públicos, a noser que quieras pasar por caja. Así que vamos a pasar a implementar nosotros en un servidor.

En este post, vamos a hacerlo de la forma más básica.  Como requisitos, nuestro servidor deberá tener ssh activo, ya que es el mejor sistema de los que utiliza git, para poder hacer clone y push de nuestros proyectos. Así que vamos a ponernos manos a la obra.

Primero, instalar git:


$ sudo aptitude install git

Con esto, nos instala todo lo necesario. En mi caso lo he hecho desde una Ubuntu 12.04, en versiones anteriores, el paquete era git-core, pero ahora lo marca como deprecated.

Ahora, con git instalado,  vamos a crear un usuario, que será el encargado de manejar el repositorio. De esta forma lo tenemos todo más ordenado.

$ sudo adduser git

Ya con esto, podemos empezar a trabajar sin problemas. Crearemos nuestro repositorio desde el servidor, antes de empezar a trabajar.

$ cd /home/git
$ sudo git init --bare miProyecto
$ sudo chown git.git miProyecto -R

Lo que hemos hecho aquí, es crear el repositorio vacio. Es importante la opción –bare, ya que necesitamos que cree solo el repositorio, si no lo ponemos, entenderá que estamos en un directorio de trabajo y nos creara el repositorio para el directorio actual. Esto después nos creará conflictos a la hora de trabajar y hacer push desde el cliente. Lo siguiente es cambiarle el propietario del proyecto, para no tener conflictos de permisos.

Con todo los pasos anteriores listos, ya podemos empezar a trabajar. Así que nos vamos a nuestro cliente y hacemos clone del repositorio:

$ git clone ssh://git@host/~/miProyecto
$ echo "Hola mundo" > index.php
$ git add index.php
$ git commit -m "first commit"
$ git push origin master

Al hacer clone del repositorio remoto, seguramente nos de un warning de que el es un directorio de trabajo vacio. Es normal, ya que aún no hemos creado contenido. Así que creamos un fichero y hacemos commit. Por último, hacemos un push para subir los cambios al repositorio remoto. Ya que el clone está hecho desde el remoto, la conexión está establecida y no hace falta realizar ninguna configuración extra.

Para nosotros los programadores, hay una cosa que puede resultar algo complejo: Crearse un portfolio. Para los artistas y diseñadores, es suficiente con crearse una página simple y unas cuantas capturas de sus trabajos. Pero para un programador, es más complejo, si has hecho una aplicación web accesible al público, puedes poner el enlace. Pero, ¿Y si solo has creado un módulo de una aplicación? ¿ Y sí has colaborado en un proyecto con una pequeña parte? ¿Y si quieres enseñar una aplicación de la universidad?. Incluso a veces, a  un posible contratador, le puede interesar más ver la calidad de nuestro código. Para este tipo de casos, tenemos una opción, que además nos permite recibir feedback de otros usuarios. Para que nos entendamos, una red social de desarrolladores.

Estoy hablando de Github, que aparte de todo esto, nos proporciona un control de versiones, que debería de ser algo obligado para todos nuestros proyectos.
A pesar de sus bondades, tiene una cosa muy buena y una cosa muy mala. La cosa muy buena esque te puedes crear una cuenta gratis, la mala cosa, esque los proyectos que subamos han de ser públicos, salvo que nos hagamos una cuenta de pago. En este último caso, el número de proyectos privados dependerá de la cantidad que paguemos. Aún así, sigue siendo una opción bastante interesante, sobre todo si tenemos algún proyecto interesante en mente, ya que nos abrimos a colaborar con más desarrolladores y eso siempre es bueno.

Os dejo una lista con los enlaces para configurar git de forma sencilla :