Mudanza

Bueno, estoy de mudanza.

De ahora en más el blog pasará a estar en www.asincronico.com usando wordpress para tener más posibilidades de customizar el mismo.

Saludos!.

Sincronización con RSync

RSync es una herramienta para Unix que permite sincronizar una carpeta con otra (remota o no) o como los autores especifican en la man page: "a fast, versatile, remote (and local) file-copying tool".


Los casos de uso son variados según la necesidad, por ejemplo, tenemos una copia local de archivos fuente de un proyecto web, deseamos publicar las modificaciones en el servidor de producción. Este sería el más común (por lo menos en mi caso) de los escenarios.

La carpeta src dentro del server A (o pc de trabajo) puede tener archivos que no se necesiten subir, o carpetas que no debe porque matchear contra la que está en el servidor B, todo esto lo resuelve el rsync según la configuración utilizada.


Como dije antes, es un comando de Unix, es por esto que tenemos la ventaja de usar "la bash" para generar un script completo complejo  que nos permita realizar muchas tareas.


Especificación del comando
rsync {opciones} {conexión} {origen} {destino}


Opciones

• -v, --verbose               Extender info
• -q, --quiet                 Suprimir información que no sean errores
• -c, --checksum              utilizar solo el checksum para evaluar la comparación de archivos
• -a, --archive               archive mode; equals -rlptgoD (no -H,-A,-X)
• -r, --recursive             recursivo dentro de directorios
• -b, --backup                realizar un backup (ver --suffix & --backup-dir)
•     --backup-dir=DIR        realizar backup dentro de DIR
•     --suffix=SUFFIX         backup suffix (default ~ w/o --backup-dir)
• -p, --perms                 preservar permissions
• -E, --executability         preservar executability
• -o, --owner                 preservar owner (super-user only)
• -g, --group                 preservar group
• -t, --times                 preservar modification times
• -n, --dry-run               Realizar una corrida en seco, excelente para poder probar si lo que hacemos es lo que necesitamos.
• -z, --compress              comprimir durante la transferencia
•     --compress-level=NUM    compression level
• -f, --filter=RULE           Necesario al momento de realizar exclusiones (por ejemplo, carpetas .svn, archivos .project, etc)
•     --exclude=PATTERN       matching PATTERN
•     --exclude-from=FILE     Desde un archivo "FILE"
•     --include=PATTERN       inverso al exclude
•     --include-from=FILE     inverso exclude-from
•     --files-from=FILE       inverso files-from
• -h, --human-readable        En formato legible por humanos
•     --progress              Mostrar el progreso (esto genera mucha suciedad al momento de ver el log)
• -4, --ipv4                  preferir uso de IPv4
• -6, --ipv6                  preferir uso de IPv6
•     --delete                borrar archivos del destino que no macheen

Yo particularmente utilizo la configuración: -avz con eso basta para transferir los archivos de una carpeta a otra.

Script para bash:

#!/bin/bash

HOME=/home/usuario/carpeta/src/

DEST=/var/www/sitio/src/

rsync -avz --delete --exclude=.svn --exclude=Thumbs.db  $HOME $DEST

echo "Done"

En los casos donde deba copiar por ssh al servidor de destino:

#!/bin/bash

HOME=/home/usuario/carpeta/src/

DEST=usuario@ip_destino_o_direccion:/var/www/sitio/src/

rsync -avz --delete --exclude=.svn --exclude=Thumbs.db  $HOME $DEST

echo "Done"

Luego podemos combinar opciones del ssh (como por ejemplo obtener el password para conectarse desde un archivo) para incrementar los usos de ambas herramientas según nuestra necesidad.

1 - Control de Versiones GIT

Este post no intenta explicar las ventajas y desventajas que tiene el sistema de versionado de GIT sino que intenta resumir los comandos más usados en la vida diaria de un programador.

Un breve resumen de comandos
Estos son los comandos utilizados en esta sección

• git config
• git clone
• git status
• git add
• git commit
• git rm
• git mv
• git log

Recordamos los tres estados de un archivo en GIT

• Committed: La información del archivo esta almacenada en forma segura en la database local.
• Modified: El archivo sufrió cambios locales pero no fue "comiteado" hasta el momento.
• Staged: Se ha marcado el archivo como modificado y pronto para el commit de la próxima snapshoot.

Configuraciones en GIT

Git trabaja en principio con 3 archivos que manejan gran parte de la configuración.

• /etc/gitconfig: Contiene los valores de todos los usuarios y todos los repositorios; para acceder a este recurso se hace git config --system (lectura y escritura)
• ~/.gitconfig file: Contiene la información del usuario local; se accede con git config --global. 
• .git/config: especifica la información particular de ese repositorio.

Cada nivel sobrescribe la configuración del anterior, por lo que el .git/config sobrescribe los que están en  /etc/gitconfig.

Configurar quien soy yo
Lo primero que debemos hacer una vez instalado GIT (sudo apt-get install git) es setear quien somos; esto lo hacemos con el comando git config --global para no tener que hacerlo nuevamente (notar el --global):

git config --global user.name "Juan Perez"
git config --global user.email "juan.perez@email.com"

Configuración de herramientas
Lo básico, el editor y el diff tool.

git config --global core.editor vim
git config --global merge.tool vimdiff
Una (extensa) lista de opciones se puede encontrar haciendo git config --help; un resumen del seteo de opciones se puede encontrar haciendo git config --list o en su defecto si solo se quiere cierta propiedad, se hace git config user.name


Hacer un checkout clone de un repo existente
Para eso tan solo necesitamos tener la url del repo y hacer un git clone
git clone git://github.com/schacon/grit.git

Nótese que el protocolo es git, también se puede hacer bajo un protocolo https o ssh si el repo lo permite:

git clone https://github.com/schacon/grit.git

user@server:/path/to/git/repository.git

Viendo el status de los archivos

Mediante el git status podemos acceder a la lista de estado de los archivos (o como aparece en la documentación, "show the working tree status"), recordamos que los archivos pueden estar versionados traked o no traked; a su vez, aquellos que estén bajo el versionado, pueden estar sin modificación, modificado o en staged.

Si ejecutamos un git status en el repo recién clonado deberíamos obtener:

$ git status

# On branch master

nothing to commit (working directory clean)

Nótese que al final nos dice bajo que branch estamos trabajando, en este caso como es un repo recientemente clonado, nos indica que estamos en el branch master.

Versionando los archivos

Esto se realiza mediante un simple git add {archivo, lista de archivos, expresión regular} esto nos marca al archivo como pronto para ser agregado, o mejor aún, nos indica que el archivo está en "stage" y que esta pronto para ser "comiteado"

Modificando archivos

Suponiendo un escenario donde tenemos un archivo no versionado y uno versionado pero modificado, podemos ver la siguiente salida después de ejecutar un git status.

$ git status

# On branch master

# Changes to be committed:

#   (use "git reset HEAD ..." to unstage)

#

# new file:   README

#

# Changed but not updated:

#   (use "git add ..." to update what will be committed)

#

# modified:   some_file.txt

#

Aquí se deben apreciar dos cosas; primero, vemos que el archivo nuevo no traked esta bajo el grupo "Changes to be committed" eso significa que el archivo no está traked pero si esta pronto para ser agregado en el caso que sea necesario. En segundo lugar vemos que bajo el grupo "Changed but not updated" está el archivo modificado localmente, esto implica que el archivo fue modificado localmente pero no fue puesto en "stage" por el momento. Para agregarlo en el stage debejos ejecutar git add {archivo, lista, exp. regular} .

$ git add some_file.txt

$ git status

# On branch master

# Changes to be committed:

#   (use "git reset HEAD ..." to unstage)

#

# new file:   README

# modified:   some_file.txt

#

Ahora ambos archivos están en "stage" prontos para hacer commit. Un punto importante aquí es que si nosotros modificamos nuevamente algún archivo, éste será vuelto a pertenecer al grupo de "Changed but not updated" pero a su vez estaría perteneciendo al grupo "Changes to be committed". Aquí hay un par de bifurcaciones, si hacemos git commit, se fijaran los cambios con el archivo tal cual estaba luego de hacer el primer git add omitiendo los últimos cambios realizados. Por el contrario, si deseamos agregar los últimos cambios debemos volver a ejecutar git add del archivo antes de hacer el git commit. 

Ciclo de estados de un archivo en GIT

Imagen extraída de: http://progit.org/book/ch2-2.html

Committing los cambios

Una vez agregado todos los archivos al stage, estamos prontos para hacer el commit, lo mejor es hacer git commit -m "comentario" si la opción -m no es incluída, el editor seteado se abrirá para ingresar el comentario, lo cual es un poco molesto.

Existe otra opción para el commit que permite "saltearse" el paso de stage, esto es mediante el comando:

git commit -a -m "Commit sin hacer add"

Esto agrega los archivos y les hace commit todo en un solo paso.

Remover archivos

Mediante el comando git rm se pueden borrar archivos del versionado (en realidad lo saca del stage) y una vez que se haga commit ya no pertenecerá a la estructura del repo local. Si necesitáramos remover un archivo que está trakeado pero no queremos que lo borre del disco (algún archivo de configuración del ide por ejemplo) lo podemos hacer mediante el comando git rm --cached.

Nota: casi todos los comando permiten la identificación de un archivo, una lista de archivos o una expresión regular, esto por ejemplo nos permite git rm logs_folder/\*.log que sería eliminar todos los archivos .log dentro de la carpeta logs_folder.

Mover archivos

Para mover archivos es uno de los sistemas más sencillos que existen, tal cual en unix, basta ejecutar git mv old_file new_file una vez hecho esto, el nuevo archivo figurará como modificado y estará bajo el grupo de "Changes to be committed".

Historia de los commit

El comando git log provee una amplia gama para ver los logs de un repo, recordar que al clonar uno, éste baja todos los logs junto con los arhcivos por lo que no necesita ir al servidor a buscarlo para mostrarlo y esto redunda en una rapidez importante.

• git log --graph - muestra el log como un grafo
• git log --reverse - invierte la salida del log
• git log -4 - limita la salida a n logs
• git log --since={--since, --after, --until, --before} {2.weeks, "2008-10-10", etc}
• git log --author=User - Que el autor coincida con User.
• git log --committer=User - Que el committer coincida con User.
• git log --help
• git log -p - muestra el diff de cada commit
• git log --stat - muestra la lista de archivos modificados en cada commit
• git log --pretty=OPCION - muestra el output de según la forma predefinida
  
  Opciones
• oneline - muestra cada commit (comentario del) en una sola línea
• short - la salida pero resumida
• full
• fuller
• format: "%h - %an, %ar : %s"
  
  Etiquetas de formateo

• %H - Commit hash
• %h - Abbreviated commit hash
• %T - Tree hash
• %t - Abbreviated tree hash
• %P - Parent hashes
• %p - Abbreviated parent hashes
• %an - Author name
• %ae - Author e-mail
• %ad - Author date (format respects the –date= option)
• %ar  - Author date, relative
• %cn  - Committer name
• %ce  - Committer email
• %cd  - Committer date
• %cr - Committer date, relative
• %s - Subject

Para los amantes de log viewer gráficos existe la herramienta gitk que provee las funcionalidades de forma más amigable.

Fuentes: la mayor parte de la información es un resumen de ProGIT y de Git In The Trenches

Experiencias en Code Igniter - Parte 1

Bueno luego de una ausencia muuuy prolongada he decidido contribuir al conocimiento general como todo el mundo.

No tengo mejor manera de arrancar esto sino con lo que más he usado los últimos 3 años como herramienta de trabajo.

The Code Igniter Framework

0. Nota


Esto esta enfocado a personas que por lo menos han trabajado con algún framework, no esta escrito para personas que recién arrancan en el mundo de éstos. 
 

1. Instalación




Vamos al sitio oficial de CodeIgniter (http://codeigniter.com/) y descargamos la última versión (al día de hoy 1.7.2) .
Descomprimimos el archivo y vemos que la estructura es:

/
. /system
. /index.php


Primero que nada, el index.php es el archivo de CodeIgniter (de aquí en más CI) que maneja todas las peticiones al framework. Dentro de la carpeta system tenemos un monton de carpetas, la única que debemos tener en cuenta es la carpeta "application".
Dentro de esta carpeta estarán todos los archivos específicos de nuestro proyecto. Por lo que actualizar el framework se torna sumamente sencillo.

Hemos de suponer que se tiene de un lugar donde alojar estos archivos, por ejemplo, un servidor con un dominio. En otro momento mostraré como se pueden crear un entorno de trabajo cómodo para trabajar varias personas sobre el mismo proyecto. Entonces, decía, supongamos que tenemos un dominio http://misitio.com/ y que el document root de nuestro hosting se llama "httpdocs".
Debemos tirar dentro de la carpeta pública (httpdocs) los archivos ta cual están en el .zip que nos bajamos del sitio de CI.

Para una instalación básica, solo debemos modificar el archivo:
/system/application/config/config.php
 
Donde dice: 

$config['base_url'] = "http://www.mysite.com/";

debemos especificar la dirección del sitio, ahora bien, muy a menudo sucede que el sitio puede cambiar de dirección (múltiples nombres o diferentes ámbitos), lo que yo aconsejo es dejar parametrizado este parámetro (redundancia :D ) 

$config['base_url'] = "http://".$_SERVER['HTTP_HOST']."/";

Así nos aseguramos de que no importa el dominio en el que se encuentre, siempre va a funcionar. 

Probemos la instalación haciendo http://misitio.com/ en el browser, deberíamos ver una página que diga "Welcome to Code Igniter!. Eso significa que que logramos instalar correctamente el framework Hasta aquí nada complicado ni nuevo. Ahora bien, comenzamos la parte donde "tuenamos" el CI para potenciarlo.


1. División MVC


La división MVC clásica nos dice que tenemos una capa Modelo, una capa Vista y una capa Controladora (en realidad sería Model View Controller). Esto es ya lo disponemos en nuestro CI.

• /controller: carpeta de los controladores.
• /model: carpeta de los modelos.
• /views: carpeta de los archivos de vistas.

Bien, según esto, dentro de los archivos de "views" vamos a tener solamente HTML, CSS, JS, y muy poco de php (por lo general, los objetos de transporte de datos y búcles de iteración). En "controller" tenemos los controladores que son los métodos por los cuales accederemos a nuestras páginas, pero también son aquellos que leen datos del usuario y leen datos desde la DB.

¿Que tiene de bueno y de malo ésto?

• Lo bueno: Hay una separación entre la vista y el modelo mediando por el controlador, este se encargará de trabajar los datos entre ambos extremos para poder presentarlos en cada uno de ellos de la manera correcta.
• Lo malo: se torna complicado reutilizar código o modularizar componentes ya que depende mucho de como fue confeccionado el controlador. Es decir, puedo reutilizar un controlador que permita registrar o loguear a un usuario, pero ya es más difícil si mi controlador hiciera cosas más complejas o que dependan un poco más del proyecto en el que esté.

Ahora, ¿que pasa si a este modelo le agregáramos una capa más al MVC? llamémosla capa "business". Podríamos colocar aquí todo lo relativo al manejo grueso del negocio en la aplicación, haciendo que una clase sea la encargada exclusiva de solicitar datos al modelo y presentarlos como colección de objetos al controlador, para que éste opere con éstos como lo desee. También se encargaría de las acciones que impacten en el modelo, tomando los datos en "crudo" desde el controlador para que luego trabaje con ellos (validación, conversión, etc) y eventualmente realize la operación solicitada o notifique un error. También puede encargarse de tareas sobre archivos, enviar e-mails, etc. Todo aquello que pueda ser modularizado y realice tareas complejas (más allá de tareas de presentación de datos).


Resumiendo: Creamos una nueva capa llamada business donde concentra todo el negocio grueso de nuestra aplicación, impacto de datos en el modelo, validación de los datos, obtención de datos desde el modelo, envío de e-mails, etc, etc.


2. Transferencia de datos y Objetos


Como habrán visto, la transferencia de datos, sobre todo de parámetros en php puede llegar a ser compleja si no se tiene cuidado. Es por eso que el concepto que debemos asimilar es la de usar Data Transfer Objects (DTOs). Estos son objetos sencillos donde representarían la entidad que deseamos modelar. Estos objetos no son nada mas que clases vacías de implementación solo con los atributos.

Por ejemplo: Si tuviéramos que crear un DTO para la entidad "usuario" éste sería:

/**
 * 
 * User Data Transfer Object
 * @author isanchez
 * @version 1.0
 *
 */
class UserDTO {
 /**
  * 
  * User Identification
  * @var Int
  */
 public $userId = null;
 
 /**
  * 
  * User name
  * @var VARCHAR
  */
 public $name = null;
 
 /**
  * 
  * User E-mail
  * @var VARCHAR
  */
 public $email = null;
}

En este caso definimos la clase UserDTO con los atributos userId, name e email. si tuviéramos este objeto cargado en una variable el mismo se vería así:

$userDTO = new UserDTO();
$userDTO->userId = 123;
$userDTO->name = "Bill Gates";
$userDTO->email = "none@none.com";

Entonces cuando queremos pasarle los datos de creación de un usuario al business de usuario, solo deberíamos cargar los datos como lo hicimos anteriormente (sin el userId obviamente) y pasárselos a la función encargada, como por ejemplo:

$userDTO->userId = $userBusiness->create($userDTO);
if( $userDTO->userId > 0 ){
    echo "Usuario creado";
}else{
    echo "No se pudo crear el usuario";
}

Resumiendo: Usamos clases vacías como objetos para trasportar datos, tanto sea para pasarlo como parámetro entre los métodos de una clase como para usarlos a nivel de vista (podemos paras arrays de UserDTOs cuando queramos listar los usuarios de nuestra aplicación por ejemplo).


Bien hasta aquí mas o menos se logra tener instalada una copia de CI con la división MVC + la capa business. Más adelante escribiré en detalle sobre esta última capa y sobre las clases "base" que debemos tener para una mejor utilización de éste framework.

Acerca del mundo blogger

Buenas para el que este en este blog!!!
Antes que nada esto es simplemente una reflexión que carece de toda funcionalidad práctica.
Resulta que siguiendo recomendaciones de amigos sobre los beneficios de escribir blogs había comenzado este ya hace no se cuanto tiempo.
Uno de estos amigos me dijo que el lo veía mas bien como un instrumento para escribir "conocimiento adquirido" y que de esa manera, ejercitaba un poco más su dominio en el tema y que de última, le servía para mantener una especie de "manual" online de lo que ya sabía.

Es por eso, que hay algunos post míos sobre algoritmos y cosas del svn y bla bla bla....
Pero el mundo del trabajo es voraz y me ha alejado de este pequeño espacio.

Ahora bien, ¿a que viene este post? resulta que, como le había agregado analytics, estaba viendo que sin hacer prácticamente nada, sin agregar un post ni de casualidad durante años, este bendito sitio viene a tener más entradas que algunos otros que tengo jajajja es increíble como con 4 post "Bobos" se puede llegar a tantas entadas. :D

Bueno era eso solo, una simple micro reflexión, comentario, catarsis que quería hacer.
Muchas gracias a los 4 individuos que dejaron comentarios en los posts anteriores :D

Festival Latinoamericano de Instalación de Software Libre Flisol 2009 Montevideo - Uruguay

Bueno este próximo 25 de Abril es el Festival Latinoamericano de Instalación de Software Libre tanto en Montevideo como en otros departamentos de nuestro país (y por supuesto, del mundo).

Desde la web del sitio, ¿que es el Flisol?

Es el Festival Latinoamericano de Instalación de Software Libre (FLISoL) es el evento de difusión de Software Libre más grande en Latinoamérica. Se realiza desde el año 2005 y su principal objetivo es promover el uso del software libre, dando a conocer al público en general su filosofía, alcances, avances y desarrollo.

Para tal fin, las diversas comunidades locales de software libre (en cada país, en cada ciudad/localidad), organizan simultáneamente eventos en los que se instala, de manera gratuita y totalmente legal, software libre en las computadoras que llevan los asistentes. Además, en forma paralela, se ofrecen charlas, ponencias y talleres, sobre temáticas locales, nacionales y latinoamericanas en torno al Software Libre, en toda su gama de expresiones: artística, académica, empresarial y social.

---

Itinerario:

Anfiteatro Antel

9:00	Apertura	Agradimientos, mención de sponsor etc.
9:30-10:15	Enrique Verdes	Software Libre: guía de supervivencia.
10:30-11:15	Andrea Mangiatordi	Tecnologías de accesibilidad.
11:30-12:15	Mauricio Campiglia	Filtrado de contenidos para padres.
12:30-13:15	Macello Farias	Amenazas en Internet.
13:15-14:00	Receso: Comida,música, etc.
14:00-14:45	Nicolás Levy	Taller Básico de Ubuntu
15:00-15:45	Nicolás Levy	Taller Básico de Ubuntu
16:00-16:45	Marcelo Ramos	El lenguaje de programación Python
17:00-17:45	Nestor Flaquer y Graciela	Uso básico de la Xo.
18:00-18:30	Nestor Flaquer y Graciela	Uso básico de la Xo.
18:30	Fernando Da Rosa	Software Libre y apropiación tecnológica.

Sala Interactiva

9:30-10:15
10:30-11:15	Alejandro Segovia	Ceibal Chess
11:30-12:15	Ceibal Jam	Programación
12:30-13:15	Ceibal Jam	Programación
13:15-14:00	Receso: Comida,música, etc.
14:00-14:45	Virginia Demarco	Taller de Gimp
15:00-15:45	Nicolás Pence	*BSD Sistemas Operativos Libres Alternativos.
16:00-16:45	Carlos Moreira, Mitchel Quilici y Carlos Pirez	Promoviendo la independencia tecnológica
17:00-17:45	Ismael Castagnet Gabriela Rodríguez	Taller: "Democratización del conocimiento en la era de la información (oportunidades, amenazas y desafíos)"
18:00-18:30	Ismael Castagnet Gabriela Rodríguez	Taller: "Democratización del conocimiento en la era de la información (oportunidades, amenazas y desafíos)"
19:00	Cierre del Festival	Sorteos y mas ...

Instalación y Configuración de Apache 2.2 con PHP y MySQl

El otro día me vi en la situación de instalar Apache con PHP y MySQL en mi ubuntu 8.10 (próximamente a convertirse en el 9.1) y googleando encontré mucho material, y arme un instructivo paso a paso de como instalar Apache en Ubuntu.

Ejecutamos para instalar apache.

sudo apt-get install apache2

Ejecutamos para instalar php5:

sudo apt-get install php5 libapache2-mod-php5

Para comprobar que este bien instalado hacemos:

sudo a2enmod php5

Reiniciamos apache:

sudo apache2ctl restart

Instalamos MySQL:

sudo apt-get install mysql-server

Instalamos manejador de php mysql:

sudo apt-get install php5-mysql

Y como complemento si queremos SVN:

sudo apt-get install subversion

Ahora bien, vamos a necesitar identificar y hacer algunos ajustes al apache para que funcione con algunos elementos extras como por ejemplo, los Virtual Host (VHost en adelante).

La idea es crear sitios con virtual host distintos para que cada uno tenga una configuración aparte.

Para esta tarea primero identificaremos la estructura de directorios de apache.

En /etc/apache2 disponemos de varios subdirectorios dos de ellos importantes para nosotros.

•conf.d

•mods-available

•mods-enabled

•sites-available

•sites-enabled

Los ficheros de configuración de los VHost se configuran en sites-available.

En sites-enabled sólo contiene enlaces a aquellos VHost que queremos activar.

Supongamos que queremos crear (por ejemplo) un VHost de nombre "misitio.site" para que, cuando ponga en mi navegador http://misitio.site me lleve a la página principal de ese host.

Observar!! Si pongo http://localhost me llevará al VHost por defecto (distinto del de misitio.site).

Pero antes que nada, para que mi browser "sepa" a que ip conectarse cuando haga el request de misitio.site debo añadir unas líneas al archivo situado en: /etc/hosts

Entonces ejecuto

sudo vim /etc/hosts

Creo una nueva entrada manteniendo lo que había y añado lo siguiente:

127.0.0.1 misitio.site

127.0.0.1 www.misitio.site

En general será {IP} {serverName} à IP y nombre del servidor

Observar que esto solo es necesario para que desde mi propia máquina pueda acceder al sitio por medio del browser, en caso de montar un servidor, este trabajo lo haría el propio dominio que estaría apuntando a la ip de mi servidor.

Ahora comienzo con la creación del espacio en disco para mi sitio, creo una carpeta para el contenido dentro de la carpeta /var/www/ para este caso usaremos: /var/www/misitio.site

Notar que no interesa que como se llame la carpeta, pero es una buena práctica identificarla con el dominio que tendrá.

Pasamos a la configuración del VHost, ejecutamos

cd /etc/apache2/sites-available

Hacemos:

sudo vim default

default es un archivo donde se definen los virtual host y le agrego la línea (esto solo por una única vez) NameVirtualHost *:80

Hago una copia del archivo default ejecutando

cp default misitio.site

Edito el misitio.site y lo dejo, como por ejemplo:

<VirtualHost 127.0.0.1:80>

ServerAdmin admin@misitio.site

DocumentRoot "/var/www/misitio.site/src"

ServerName misitio.site

ServerAlias www.misitio.site

</VirtualHost>

En fin, agrego todo lo que necesite para mi VHost, como por ejemplo reglas de rescritura, etc.

Cierro el archivo y ejecuto

cd /etc/apache2

y luego

a2ensite misitio.site

El comando a2ensite (available 2 enablesite) crea un enlace en sites-enable al site que le indiquemos (es decir, activa el VHost que acabamos de crear)

Comprobamos que todo este OK ls -al sites-enabled/

Recargamos apache /etc/init.d/apache2 reload

En caso de que el VHost configurado lleve reglas de rescritura, se debe cargar el módulo mod_rewrite esto lo podemos hacer con el comando a2enmod ejecutado:

cd /etc/apache2/

y luego

a2enmod rewrite

y por último restart del apache

/etc/init.d/apache2 restart

Y con esto tendríamos pronto un sitio en apache, mediante un virtual host, podremos chequearlo con solo acceder a http://misitio.site