Jesus de Baldoma

Cómo instalar Oracle (Sun) Java JRE en Linux Mint

2014-02-18T17:29:00.000+01:00

Por regla general, las distribuciones de Linux Mint y Ubuntu incorporan OpenJDK (versión libre de Java) para poder dar soporte a LibreOffice.

OpenJDK y el plugin IcedTea son mantenidos por la comunidad y reciben actualizaciones periódicas. Funciona bien para la mayoría de los propósitos. Lo más probable es que no necesitemos Oracle Java en absoluto, pero podemos vernos en la necesidad de instalarlo y esto suele ser una fuente de problemas, ya que fue retirado de los repositorios "partner" por la revocación de la anterior licencia.

En este tutorial se muestran los pasos para instalar el Java de Oracle y, también, el correspondiente plugin para Firefox en la distribución Linux Mint..

Este paso previo se puede obviar, pero para evitar conflictos procederemos a eliminar OpenJDK y, también, todas sus dependencias.

$ sudo apt-get remove openjdk-6-jre
$ sudo apt-get autoremove
$ sudo apt-get clean

Instalación de Java

Desde la web oficial de Oracle descargamos el paquete .tar.gz correspondiente a la última versión de Java (en este momento, la 1.7.45). Descargamos desde los enlaces Linux (32-bit) o Linux x64 (64-bit). No descargar la versión RPM.

A continuación creamos els siguiente directorio en función de si nuestra arquitectura es de 32 o 64 bits.

- Versión 32-bit

$ sudo mkdir -p -v /opt/java/32

- Versión 64-bit

$ sudo mkdir -p -v /opt/java/64

Nos situamos en la carpeta donde hayamos realizado la descarga del archivo .tar.gz y lo descomprimimos. Una vez descomprimido, se habrá creado el directorio jre1.7.0_45. Lo movemos a la carpeta que hayamos creado en el paso anterior.

- Versión 32-bit

$ cd ~/Downloads
$ tar -zxvf jre-7u45-linux-i586.tar.gz
$ sudo mv -v jre1.7.0_45 /opt/java/32

- Versión 64-bit

$ cd ~/Downloads
$ tar -zxvf jre-7u45-linux-x64.tar.gz
$ sudo mv -v jre1.7.0_45 /opt/java/64

El último paso es definir el nuevo JRE por defecto y comprobar que se ha instalado correctamente.

- Versión 32-bit

$ sudo update-alternatives --install "/usr/bin/java" "java" "/opt/java/32/jre1.7.0_45/bin/java" 1
$ sudo update-alternatives --set java /opt/java/32/jre1.7.0_45/bin/java
$ java -version
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b13)
Java HotSpot(TM) Server VM (build 24.45-b03, mixed mode)

- Versión 64-bit

$ sudo update-alternatives --install "/usr/bin/java" "java" "/opt/java/64/jre1.7.0_45/bin/java" 1
$ sudo update-alternatives --set java /opt/java/64/jre1.7.0_45/bin/java
$ java -version
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b13)
Java HotSpot(TM) Server VM (build 24.45-b03, mixed mode)

Instalación del plugin para Firefox

Para cada usuario habrá que crear el siguiente directorio

$ mkdir -v ~/.mozilla/plugins

En ese mismo directorio, crearemos un link simbólico para que Firefox sepa dónde encontrar el plugin de Java.

- Versión 32-bit

ln -s /opt/java/32/jre1.7.0_45/lib/i386/libnpjp2.so ~/.mozilla/plugins/

- Versión 64-bit

ln -s /opt/java/64/jre1.7.0_45/lib/amd64/libnpjp2.so ~/.mozilla/plugins/

Ahora solo queda reiniciar Firefox y comprobar que la instalación ha sido efectuada. Basta con escribir about:plugins en el navegador.

Fuentes:

Deshabilitar Ctrl+Alt+Delete en Ubuntu

2014-01-15T18:30:00.000+01:00

Cuando se pulsan simultáneamente las teclas Control+Alt+Delete en un equipo con Ubuntu, el sistema se reinicia y muestra el siguiente mensaje por la consola de sistema.

Broadcast message from root@nombre_servidor
        (unknown) at 12:34 ...

The system is going down for reboot NOW!
Control-Alt-Delete pressed

Esta operación se controla mediante un fichero de configuración especial que se encuentra en /etc/init/control-alt-delete.conf. Para deshabilitar el reinicio del equipo (que es la operación por defecto), basta con editar ese fichero y comentar la línea que se indica.

$ sudo vim /etc/init/control-alt-delete.conf
#exec shutdown -r now "Control-Alt-Delete pressed"

Fuentes:

Ubuntu Linux Disable control-alt-delete [CTRL-ALT-DEL] Emergency Keypress Handling

Reinstalar drivers nVidia en Linux Mint 13

2013-12-31T19:28:00.000+01:00

Desde hace ya algún tiempo que tengo un Dell Vostro 1310 equipado con una tarjeta gráfica NVIDIA GeForce 8400M GS y al que le instalé Linux Mint 13 MATE 64-bit.

El caso es que, en las últimas fechas, el portátil se calentaba en exceso hasta el punto de llegar a quedarse "colgado" por sobrecalentamiento. El problema estaba en que, aparte de perder todo el trabajo no guardado, también se perdía la configuración de los drivers de la tarjeta gráfica y, en consecuencia, no arrancaba el servidor gráfico.

En este tutorial contaré la forma en que solucioné el problema.

1. Resolver el sobrecalentamiento de la CPU
Aunque, por importancia, este era el primer problema que había que solventar, no es el objeto de este tutorial. Lo que hice para solucionarlo fue restituir la capa de pasta térmica entre la CPU y el radiador.

2. Reinstalar (la última versión de) los drivers de la tarjeta gráfica
Hay que recordar que en el caso que nos ocupa no disponemos de servidor gráfico. Por lo tanto, todas las instrucciones se ejecutarán desde la consola del sistema.

Previamente, desde otro equipo, accederemos a la zona de descargas de la web de NVIDIA y descargaremos los drivers adecuados al sistema: en nuestro caso, GeForce 8400M GS para Linux de 64-bit.

Una vez realizada la descarga, copiamos el archivo (en nuestro caso, NVIDIA-Linux-x86_64-331.20.run) en el equipo donde haya que reinstalar los drivers.

Antes de proceder, actualizaremos del sistema

$ sudo apt-get update && sudo apt-get upgrade

A continuación, si no están instalados ya, instalamos los siguientes paquetes:

$ sudo apt-get install build-essential linux-headers-$(uname -r)

Nos situamos en el directorio donde hayamos copiado el archivo de los drivers y le asignamos permisos de ejecución

$ chmod +x NVIDIA-Linux-x86_64-331.20.run

Si ya habíamos instalado los drivers a mano anteriormente, los desinstalamos

$ sudo sh NVIDIA-Linux-x86_64-331.20.run --uninstall

Eliminamos los paquetes anteriores de nvidia y, también, el driver libre "nouveau"

$ sudo apt-get remove --purge nvidia*
$ sudo apt-get remove --purge xserver-xorg-video-nouveau

Editamos la lista negra que indica qué módulos no deben cargarse mediante modprobe y, al final del archivo, le añadimos los siguientes módulos:

$ sudo vim /etc/modprobe.d/blacklist.conf
blacklist vga16fb
blacklist nouveau
blacklist rivafb
blacklist nvidiafb
blacklist rivatv

Nos aseguramos de detener el servicio Mint Display Manager (mdm), ejecutamos el script que nos instalará los nuevos drivers (privativos) de NVIDIA y volvemos a arrancar el servicio mdm

$ sudo service mdm stop
$ sudo sh NVIDIA-Linux-x86_64-331.20.run
$ sudo service mdm stop

Si arranca la interfaz gráfica es señal de que ya tenemos instalado los drivers. En este punto sería recomendable reiniciar el sistema.

$ sudo reboot

Al arrancar de nuevo, para comprobar que ya están instalados vamos al menú y en el buscador escribimos "nvidia". Debería salir el "NVIDIA X Server Settings".

También se pueden buscar desde la consola:

$ glxinfo | grep direct 
direct rendering: Yes
    GL_EXT_Cg_shader, GL_EXT_depth_bounds_test, [...]

Si devuelve "Yes" quiere decir que están instalados.

A TENER EN CUENTA: La solución tomada en este tutorial es eliminar el driver libre nouveau para NVIDIA y proceder a la instalación de los respectivos drivers propietarios del fabricante.

Fuentes:

LinuxMint 13 y Ubuntu 12.04 driver privativo nVidia

Concatenar ficheros PDF en Ubuntu

2013-12-31T13:21:00.000+01:00

En Ubuntu existen varias formas de unir varios archivos PDF (file1.pdf, file2.pdf) en un único archivo de salida (mergedfile.pdf). En este tutorial veremos 3 formas de hacerlo:

1. GhostScript

Si es preciso, instalamos el paquete ghostscript.

$ sudo apt-get install ghostscript

Para concatenar los archivos, ejecutamos el siguiente comando:

$ gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite -sDEVICE=pdfwrite \
  -sOutputFile=mergedfile.pdf file1.pdf file2.pdf

Esta es una breve explicación del comando

gs         llamada al programa Ghostscript.
-dBATCH    una vez Ghostscript ha procesado los archivos PDF,
           finaliza la ejecución. Si no se incluye esta opción,
           Ghostscript se mantendrá en ejecución.
-dNOPAUSE  fuerza a Ghostscript a procesar cada página sin pausa para 
           interacción del usuario.
-q         evita que Ghostscript muestre mensajes mientras trabaja
-sDEVICE=pdfwrite 
           indica a Ghostscript que procese los archivos con su 
           escritor de PDF interno.
-sOutputFile=finished.pdf
           indica a Ghostscript que guarde el archivo PDF combinado 
           con el nombre especificado.

2. PDF Toolkit

Si es preciso, instalamos el paquete pdftk.

$ sudo apt-get install pdftk

Para concatenar los archivos, ejecutamos el siguiente comando:

$ pdftk file1.pdf file2.pdf cat output mergedfile.pdf

Para concatenar, en orden alfabético, todos los archivos PDF de un directorio se puede hacer lo siguiente:

$ pdftk *.pdf cat output mergedfile.pdf

Más información y ejemplos de uso de pdftk disponibles aquí.

3. PDF Shuffler

A diferencia de las dos soluciones anteriores que se basaban en aplicaciones que se ejecutaban desde la línea de comandos, PDF Shuffler es una aplicación con un GUI muy básico y sencillo de manejar. Basta con ir añadiendo los archivos que se quieren concatenar y salvar el PDF resultante.

El paquete se puede instalar desde la línea de comandos:

$ sudo apt-get install pdfshuffler

Fuentes:

Ask Ubuntu - How to merge several PDF files?

Ubuntu: Migrar una máquina virtual a una máquina física

2013-11-12T02:00:00.000+01:00

Para esta aplicación en particular, Linux es mucho más versátil que Windows en el sentido de que, en general, una máquina virtual Linux se ejecutará sin demasiados problemas incluso en una máquina diferente con hardware diferente. Por el contrario, Windows es mucho más exigente con los cambios de hardware y las pantallas azules de la muerte son muy frecuentes.

Este tutorial se basa en la migración de una Máquina Virtual con Ubuntu 12.04 LTS.

Antes de empezar y para no tener problemas posteriores, lo primero que haremos será eliminar todos los snapshots de la máquina virtual sobre la que queremos realizar la migración.

A continuación, realizamos un listado de todos los discos de las máquinas virtuales y nos fijamos en la información de la máquina que nos interesa.

$ vboxmanage list hdds
[...]
UUID:        f128ad44-edfd-4cbf-962e-15703a3beb3a
Parent UUID: base
Format:      VDI
Location:    /home/user/VirtualBox VMs/ubuntu-12.04/ubuntu-12.04.vdi
State:       created
Type:        normal
Usage:       ubuntu-12.04 (UUID: 82845cce-762c-4bee-bfd9-90fbc2762e11)
[...]

Con esta información, ya estamos en disposición de realizar un clonado de la máquina virtual y forzar la salida sobre un fichero en formato RAW. (NOTA: A efectos del espacio necesario, hay que tener en cuenta que el fichero de salida acabará teniendo el mismo tamaño que el disco de la máquina virtual original).

$ vboxmanage clonehd f128ad44-edfd-4cbf-962e-15703a3beb3a disk.img \
  --format RAW
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Clone hard disk created in format 'RAW'. UUID: cdb8dc16-ba9f-462e-abb0-4b57d4f03dee

El archivo IMG obtenido en la operación anterior no es una imagen ISO, por lo que el sistema operativo instalado no se puede configurar para ejecutarse desde un CD / DVD. Lo que haremos será hacer un volcado del contenido del fichero obtenido directamente sobre el disco físico de destino (en nuestro caso, /dev/sdb).

$ sudo dd if=disk.img of=/dev/sdb bs=32M
256+0 registros leídos
256+0 registros escritos
8589934592 bytes (8.6 GB) copiados, 76.3879 s, 112 MB/s

Una vez realizada la migración, el número y el tamaño de las particiones en el disco de destino se mantendrá exactamente igual que en la máquina virtual original.

Lo más probable es que sea necesario redimensionar las particiones para aprovechar al máximo el espacio del disco duro físico.

Relacionado:

Eliminar las capturas de una imagen en VirtualBox

Fuentes:

Eliminar las capturas de una imagen en VirtualBox

2013-11-11T20:53:00.000+01:00

Antes de realizar algunas tareas más o menos habituales en el ámbito de las máquinas virtuales (como el clonado de discos virtuales o la redimensión de una partición en una máquina virtual), es necesario eliminar todas las capturas o snapshots.

Cuando se elimina una captura, en realidad, lo que se está haciendo es descartar la información de estado almacenada en ella. Los datos de disco repartidos en varios archivos creados con la captura se fusionan en un sólo archivo. Este proceso puede ser largo y, una vez terminado, la información de la captura no podrá ser recuperada.

La forma más sencilla de realizar esta operación es desde el propio GUI de VirtualBox.

1. Seleccionamos la Maquina Virtual y hacemos click sobre el icono de "Eliminar instantánea"

2. Confirmamos la operación haciendo click sobre el botón "Eliminar"

3. El resultado es una máquina virtual donde se ha fusionado el estado actual de la máquina virtual con todas las capturas existentes.

Cambiar la partición de swap por un fichero

2013-11-11T01:17:00.000+01:00

El espacio de intercambio es una zona del disco que se usa para guardar las imágenes de los procesos que no han de mantenerse en memoria física. A este espacio se le suele llamar swap y puede estar ubicado tanto en un fichero como en una partición exclusiva o partición de swap.

Dejando de lado el debate de si es necesario o no un espacio de intercambio, hay que tener en cuenta que ambos sistemas (fichero o disco) presentan ventajas e inconvenientes que no se van a discutir en este tutorial puesto que lo que nos planteamos es la forma de eliminar la partición de swap y utilizar en su lugar un fichero de intercambio.

1. Cálculo del tamaño de la partición de swap
En el caso que nos ocupa, partimos de una situación como la indicada en la imagen, con una partición de swap de 510MB situada dentro de una partición extendida.

Para conocer el tamaño de la partición de intercambio desde la línea de comandos se podría utilizar cualquiera de los dos comandos siguientes:

$ cat /proc/swaps
Filename                         Type          Size    Used   Priority
/dev/sda5                        partition     522236  0      -1

$ free
             total       used        free   shared   buffers    cached
Mem:        507772      86888      420884        0      9508     40804
-/+ buffers/cache:      36576      471196
Swap:       522236          0      522236

Si se divide la cifra de 522236 bytes entre 1024, se obtiene el tamaño conocido de 510MB.

2. Desactivación de la partición de swap
Antes de empezar, desactivaremos la partición de intercambio:

$ sudo swapoff -a

Se puede comprobar que, efectivamente, la partición de swap ya no está activa

$ cat /proc/swaps
Filename                         Type          Size    Used   Priority

$ free
             total       used        free   shared   buffers    cached
Mem:        507772      86888      420884        0      9508     40804
-/+ buffers/cache:      36576      471196
Swap:            0          0           0

3. Supresión de la partición de swap
A continuación ya se puede eliminar la partición de swap que, en nuestro caso, está situada en la partición /dev/sda5. También podemos eliminar la partición extendida que la contiene (/dev/sda2).

$ sudo parted /dev/sda rm 5
Información: Puede que sea necesario actualizar /etc/fstab

$ sudo parted /dev/sda rm 2
Información: Puede que sea necesario actualizar /etc/fstab

Una vez eliminada la partición de swap, la situación es la siguiente:

4. Creación del nuevo espacio de intercambio
En este punto, una vez ya ha sido eliminada la partición de swap, procederemos a crear el nuevo archivo de intercambio y a su posterior activación.

En primer lugar, generamos un archivo lleno de ceros con el mismo tamaño que tenía la partición de intercambio original (510MB).

$ sudo dd if=/dev/zero of=/swapfile bs=1M count=510
510+0 registros leídos
510+0 registros escritos
534773760 bytes (535MB) copiados, 2,77221 s, 193 MB/s

Lo siguiente será asignar el archivo recién creado como zona de intercambio y activar el swap.

$ sudo mkswap /swapfile
Configurando la versión swapspace 1, tamaño = 522236 KiB
sin etiqueta, UUID=503822fb-5cca-46c4-abf2-a366583d24c2

$ sudo swapon /swapfile

Después de lo anterior ya volvemos a tener zona de intercambio, pero ahora, en lugar de tenerla en una partición, la tenemos en un fichero. Lo podemos comprobar de nuevo.

$ cat /proc/swaps
Filename                         Type          Size    Used   Priority
/swapfile                        file          522236  0      -1

5. Consolidación de los cambios
Para que este cambio sea consistente y se mantenga activo la próxima vez que se reinicie el equipo, es preciso reflejar los cambios realizados en el archivo /etc/fstab. Para ello, basta con cambiar el antiguo UUID de la partición de swap por el nombre del nuevo fichero de intercambio y también el punto de montaje.

$ sudo vim /etc/fstab
<files system>   <mount point>   <type>   <options>  <dump>   <pass>
/swapfile            swap         swap        sw       0        0

La próxima vez que arranque el sistema, ya dispondrá del nuevo espacio de intercambio situado en el fichero /swapfile.

Fuentes:

Repositorios para versiones antiguas de Ubuntu

2013-11-07T00:10:00.000+01:00

El calendario de versiones de Ubuntu marca que cada seis meses se publique una nueva versión del sistema.

Las versiones estándar reciben soporte de Canonical durante nueve meses por medio de actualizaciones de seguridad, parches para bugs críticos y actualizaciones menores de programas.

Las versiones LTS (Long-Term Support), que se liberan cada dos años (la próxima será la 14.04, en abril de 2014), reciben soporte durante cinco años en los sistemas de servidor y 3 en los de escritorio.

La que sigue es una tabla con el ciclo de vida de las versiones Server de Ubuntu.

Fuente: ubuntu.com

Cuando termina el ciclo de soporte de una versión determinada, lo más indicado sería reinstalar el sistema con la última versión LTS disponible. No obstante, y dada la naturaleza de un equipo determinado, podría ser conveniente no realizar esa actualización.

Dado que, una vez finalizado el fin de ciclo de las versiones, los repositorios dejan de estar disponibles, cuando intentemos acceder a ellos para instalar cualquier paquete (tanto en APT como en Synaptic) se generará un error 404.

$ sudo apt-get update
Err http://archive.ubuntu.com hardy Release.gpg
No se pudo resolver 'archive.ubuntu.com'
Err http://archive.ubuntu.com hardy/main Translation-es
No se pudo resolver 'archive.ubuntu.com'
Err http://archive.ubuntu.com hardy/restricted Translation-es
No se pudo resolver 'archive.ubuntu.com'
Err http://archive.ubuntu.com hardy/universe Translation-es
No se pudo resolver 'archive.ubuntu.com'
Err http://archive.ubuntu.com hardy/multiverse Translation-es
No se pudo resolver 'archive.ubuntu.com'
Se está leyendo la lista de paquetes... Hecho
W: No se pudo obtener http://archive.ubuntu.com/ubuntu/dists/hardy/Release.gpg No se pudo resolver 'archive.ubuntu.com'
[…]

Dado el caso, existe una forma sencilla de solucionar este problema. Se trata de modificar las fuentes de los repositorios añadiendo los repositorios old-relesases para así poder seguir utilizando APT e instalar paquetes de esas versiones descatalogadas.

Modificaremos el fichero de configuración /etc/apt/sources.list y copiaremos en él el siguiente contenido:

$ sudo vim /etc/apt/sources.list
deb http://old-releases.ubuntu.com/ubuntu/ hardy main restricted
deb-src http://old-releases.ubuntu.com/ubuntu/ hardy main restricted
deb http://old-releases.ubuntu.com/ubuntu/ hardy-updates main restricted
deb-src http://old-releases.ubuntu.com/ubuntu/ hardy-updates main restricted
deb http://old-releases.ubuntu.com/ubuntu/ hardy universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ hardy universe multiverse
deb http://old-releases.ubuntu.com/ubuntu hardy-security main restricted
deb-src http://old-releases.ubuntu.com/ubuntu hardy-security main restricted

Este caso sería para la versión hardy (8.04 LTS). Si se utiliza otra versión, simplemente hay que sustituir "hardy" por el nombre de la misma.

Mapa de las versiones de Ubuntu

Versión	Nombre en clave	Lanzamiento	Fin de soporte
4.10	Warty Warthog	20/octubre/2004⁴⁷	30/abril/2006
5.04	Hoary Hedgehog	8/abril/2005⁴⁸	31/octubre/2006
5.10	Breezy Badger	13/octubre/2005⁴⁹	13/abril/2006
6.06 LTS	Dapper Drake	1/junio/2006⁵⁰	14/julio/2009 (escritorio) 1/junio/2011 (servidor)
6.10	Edgy Eft	26/octubre/2006⁵¹	25/abril/2008
7.04	Feisty Fawn	19/abril/2007⁵²	19/octubre/2008
7.10	Gutsy Gibbon	18/octubre/2007⁵³	18/abril/2009
8.04 LTS	Hardy Heron	24/abril/2008⁵⁴	12/mayo/2011 (escritorio) 9/mayo/2013 (servidor)
8.10	Intrepid Ibex	30/octubre/2008⁵⁵	30/abril/2010
9.04	Jaunty Jackalope	23/abril/2009⁵⁶	23/octubre/2010
9.10	Karmic Koala	29/octubre/2009⁵⁷	30/abril/2011
10.04 LTS	Lucid Lynx	29/abril/2010⁵⁸	9/mayo/2013 (escritorio) 15/abril/2015 (servidor)
10.10	Maverick Meerkat	10/octubre/2010⁵⁹	10/abril/2012
11.04	Natty Narwhal	28/abril/2011⁶⁰	28/octubre/2012
11.10	Oneiric Ocelot	13/octubre/2011⁶¹	9/mayo/2013
12.04 LTS	Precise Pangolin	26/abril/2012⁶²	abril/2017
12.10	Quantal Quetzal	18/octubre/2012⁶³	abril/2014
13.04	Raring Ringtail	25/abril/2013⁶⁴	enero/2014
13.10	Saucy Salamander	17/octubre/2013⁶⁵	julio/2014
Color	Significado
Rojo	Versión ya sin soporte
Amarillo	Solo versión de servidor con soporte
Verde	Versión con soporte (escritorio y servidor)
Azul	Versión en futuro desarrollo
Fuente: wikipedia.org

Fuentes

Backup/Restore del MBR

2013-06-15T10:38:00.000+02:00

Un registro de arranque principal, conocido también como registro de arranque maestro o por su nombre en inglés Master Boot Record (abreviado MBR) es el primer sector ("sector cero") de un dispositivo de almacenamiento de datos, como un disco duro. A veces, se emplea para el arranque del sistema operativo con bootstrap, otras veces es usado para almacenar una tabla de particiones y, en ocasiones, se usa sólo para identificar un dispositivo de disco individual, aunque en algunas máquinas esto último no se usa y es ignorado.

Backup del MBR

En UNIX y GNU/Linux se puede usar el comando dd para hacer una copia de seguridad del MBR (en este caso, del disco sda):

$ sudo dd if=/dev/sda of=/path/to/file/mbr.512.img bs=512 count=1

Si se quiere hacer una copia de seguridad del MBR, sería recomendable copiar los primeros 63 sectores del disco (que equivaldrían al primer cilindro del disco) y no sólo el primero, ya que nuestro sistema podría tener implementado el sistema GUID, el cual utiliza más sectores para guardar la información sobre las particiones del disco duro. La instrucción sería parecida:

$ sudo dd if=/dev/sda of=/path/to/file/mbr_63.512.img bs=512 count=63

Borrado del MBR

Para borrar el MBR, si no tenemos una copia de seguridad pero necesitamos eliminar la información de este sector~~, tenemos que poner los 512 bytes a cero~~. Para ello bastará con borrar los primeros 446 bits porque el resto de MBR contiene la tabla de particiones :

$ sudo dd if=/dev/zero of=/dev/sda bs=446 count=1

Restauración del MBR

Desde la consola, igualmente, se puede restaurar el MBR

$ sudo dd of=/dev/sda if=/path/to/file/mbr.512.img bs=512 count=1

Advertencia: Restaurar el MBR con una tabla de particiones diferente hará que sus datos sean ilegibles y casi imposible de recuperar.

En los sistemas operativos de Microsoft no hay acceso directo al MBR. En DOS o Windows 9x, el programa de DOS fdisk junto con fdisk /mbr (del que no hay documentación) reescribirá el código del MBR. En Windows 2000 y posteriores, la consola de recuperación puede usarse para escribir el nuevo código del MBR al disco duro. Existen otras utilidades para editar la tabla de particiones del MBR directamente.

Si se está haciendo un backup del disco duro (lo que en inglés se conoce como ghosting) y da avisos de que no se encuentra el fichero de paginación, seguramente se pueda solucionar con fdisk /fixmbr (ejecutado desde un disquete, ya que no se podrá entrar en Windows).

Fuente

Cambiar el UUID de una partición

2013-06-13T17:13:00.000+02:00

Después de haber realizado un volcado de una partición sobre otra con el comando dd, es habitual que los UUID de ambas particiones queden iguales. En el caso del ejemplo, hemos hecho un volcado de la partición /dev/sda5 sobre la partición /dev/sda3. De ahí que ambas particiones tengan el mismo UUID.

$ sudo blkid
/dev/loop0: TYPE="squashfs"
/dev/sda1: LABEL="DELLUTILITY" UUID="805E-EA66" TYPE="vfat"
/dev/sda2: LABEL="OS" UUID="50A5-D2A7" TYPE="vfat"
/dev/sda3: UUID="294a6668-e7ac-46d6-9394-f5c19061fed4" TYPE="ext4"
/dev/sda5: UUID="294a6668-e7ac-46d6-9394-f5c19061fed4" TYPE="ext4"
/dev/sda6: UUID="3e2e04c1-f76a-43a3-865e-2cb3e415e140" TYPE="swap"

Lógicamente, el hecho de que dos particiones distintas tengan el mismo UUID va a generar un problema puesto que el sistema no va a poder distinguir entre ambas particiones. Para solucionarlo, vamos a cambiar el UUID de la partición /dev/sda3.

En nuestro caso, hemos consultado el archivo /boot/grub/grub.cfg y hemos podido recuperar el UUID original de la partición /dev/sda3 (147589f2-5680-4727-b1d6-acbc43d335c1). Si no fuera posible recuperar el UUID, siempre se puede generar uno nuevo con el comando uuidgen.

$ uuidgen
fdd9b2c0-ae0e-4c2b-a833-084462e97bd9

Finalmente, una vez conocemos el nuevo UUID para la partición podemos proceder al cambio y a la posterior comprobación.

$ sudo tune2fs /dev/sda3 -U 147589f2-5680-4727-b1d6-acbc43d335c1
$ sudo blkid
/dev/loop0: TYPE="squashfs"
/dev/sda1: LABEL="DELLUTILITY" UUID="805E-EA66" TYPE="vfat"
/dev/sda2: LABEL="OS" UUID="50A5-D2A7" TYPE="vfat"
/dev/sda3: UUID="147589f2-5680-4727-b1d6-acbc43d335c1" TYPE="ext4"
/dev/sda5: UUID="294a6668-e7ac-46d6-9394-f5c19061fed4" TYPE="ext4"
/dev/sda6: UUID="3e2e04c1-f76a-43a3-865e-2cb3e415e140" TYPE="swap"

Fuentes

Sudo Juice - How to Change the UUID of a Linux Partition

Eliminar el sufijo de país en Blogger

2013-05-29T13:15:00.000+02:00

Desde hace ya un tiempo, Blogger añade a todos sus blogs el sufijo correspondiente al dominio TLD del país desde el que se realiza la consulta (.es si se visita desde España, .mx desde Mexico, .fr desde Francia, etc.). De este modo, si se visita este blog (ubicado en barralog.blogspot.com) desde Alemania, Blogger nos intentará redirigir automáticamente hacia barralog.blogspot.com.de.

Hay diversas razones por las que esto puede llegar a ser una molestia, por eso os indico una forma de solventarlo. Basta con insertar el siguiente código dentro del <head> de la plantilla.

<script type="text/javascript"> 
   //<![CDATA[
   // Eliminar el sufijo del TLD de cada país en blogger
   var host = document.location.hostname;
   var ruta = document.location.pathname;
   var positive = host.substr(host.lastIndexOf("."));
   if (positive != ".com") {
      var output = "http://" + host.substr(0, host.indexOf("."));
      output += ".blogspot.com/ncr" + ruta;
      window.location.replace(output);
   }
   //]]>
</script>

Nota: Esta acción no está penalizada en absoluto por Blogger y tampoco afecta a AdSense.

Información relacionada

Blogger - ¿Por qué mi blog se redirecciona a una URL específica de un país?

Fuentes

AJRM DESIGN - Ocultar el sufijo en blogger

Desconectar sesión remota

2013-05-13T14:52:00.000+02:00

En algunas ocasiones se puede dar el caso de establezcamos una conexión por ssh a un servidor remoto y que, por la razón que sea, al cerrar esa conexión, la sesión haya quedado abierta. En este artículo veremos una forma de eliminar esa sesión remota "fantasma".

A través del comando who se pueden consultar las sesiones que están abiertas en este momento. En el caso del ejemplo nos damos cuenta de que existe una sesión remota en pts/0, abierta desde hace días, que no debería estar activa.

$ who
root  tty1         2013-05-03 14:41
root  pts/0        2013-04-30 19:26 (remote-host.local)

Consultamos todos los procesos asociados a esa sesión remota (con identificador pts/0).

$ ps ax | grep pts/0
(standard input):76: 1504 ?        S      0:02 sshd: root@pts/0 
(standard input):77: 1505 pts/0    Ss+    0:01 -bash
(standard input):104: 5172 tty1    S+     0:00 grep pts/0

En primer lugar, eliminaremos el proceso "padre" (pid=1504) que es el que mantiene la sesión abierta. Posteriormente podemos comprobar que la sesión remota ya ha quedado cerrada.

$ sudo kill -9 1504
$ ps ax | grep pts/0
$ who
root  tty1         2013-05-03 14:41

Fuentes

Glosario X - Desconectar un usuario remoto en Linux

Habilitar HTTPS en apache

2013-05-13T13:02:00.000+02:00

En algunas ocasiones (envío de formularios, páginas de autenticación, etc.) es necesario que nuestro servidor web pueda entregar páginas cifradas bajo el protocolo seguro HTTPS. En este artículo se muestran cuales son los pasos a seguir para i) generar un certificado SSL autofirmado y ii) configurar convenientemente el servidor apache2 para que pueda entregar la página https://www.midominio.com.

1. Creación de un certificado SSL autofirmado

En primer lugar crearemos el directorio /etc/apache2/ssl que es el lugar donde dejaremos las claves pública y privada del certificado SSL. Posteriormente, crearemos un certificado SSL para el dominio "midominio.com" con una validez de 365 días.

$ sudo mkdir /etc/apache2/ssl
$ sudo openssl req -new -x509 -days 365 -nodes \
  -out /etc/apache2/ssl/midominio.com.pem \
  -keyout /etc/apache2/ssl/midominio.com.key
Generating a 1024 bit RSA private key
................................................................+++
........................................................+++
writing new private key to '/etc/apache2/ssl/midominio.com.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:Provincia
Locality Name (eg, city) []:Ciudad
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Mi organización
Organizational Unit Name (eg, section) []:Departamento
Common Name (e.g. server FQDN or YOUR name) []:www.midominio.com
Email Address []:contacto@midomino.com

Por defecto, cuando se crean los archivos para las claves pública y privada del certificado SSL, se le asignan unos permisos que permiten el acceso de cualquier usuario. Dado que la clave privada debe de ser privada (únicamente debe de ser accesible por su propietario), procederemos a cambiar los permisos del fichero.

$ sudo chmod 400 /etc/apache2/ssl/midomino.com.key
$ ls -l /etc/apache2/ssl
total 8
-r-------- 1 root root 1505 mai 10 13:12 midominio.com.key
-r--r--r-- 1 root root 1708 mai 10 13:12 midominio.com.pem

2. Configuración del servidor apache2

Ahora que ya tenemos ubicadas las claves pública y privada para nuestro domino, ya podemos proceder a la configuración de apache2.

El primer paso será el de habilitar el módulo SSL de apache.

$ sudo a2enmod ssl
Enabling module ssl.
See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
service apache2 restart

A continuación, modificaremos la configuración de Apache para que también escuche peticiones por el puerto 443 (que es el puerto por defecto para el protocolo HTTPS).

$ sudo vim /etc/apache2/ports.conf
Listen 80
Listen 443

Comprobamos, para nuestro servidor, los sites que están disponibles y los que están habilitados

$ ls -l /etc/apache2/sites-available/
total 12
-rw-r--r-- 1 root root 1779 mai  3 13:14 default
-rw-r--r-- 1 root root 7469 feb  7  2012 default-ssl

$ ls -l /etc/apache2/sites-enabled/
total 0
lrwxrwxrwx 1 root root 26 mar 11 13:50 000-default -> ../sites-available/default

De los listados anteriores se comprueba que, aunque se habilite el módulo SSL, esta acción no habilita el sitio (default-ssl) automáticamente. Hay que activarlo de forma manual. Una vez habilitado el sitio, podemos comprobar que, efectivamente, el sitio default-ssl está activado.

$ sudo a2ensite default-ssl
Enabling site default-ssl.
To activate the new configuration, you need to run:
service apache2 reload

$ ls -l /etc/apache2/sites-enabled/
total 0
lrwxrwxrwx 1 root root 26 mar 11 13:50 000-default -> ../sites-available/default
lrwxrwxrwx 1 root root 30 mai 10 11:50 default-ssl -> ../sites-available/default-ssl

Ya solo queda editar el fichero de configuración del nuevo site para añadir la configuración del VirtualHost para el dominio www.midominio.com permitiendo así el acceso a la página cifrada https://www.midominio.com

$ sudo vim /etc/apache2/sites-available/default-ssl
<VirtualHost *:443>
   ServerAdmin contacto@midominio.com
   ServerName www.midominio.com
   DocumentRoot /var/www/vhosts/midominio.com/
   ErrorLog /var/log/apache2/midominio.com-error-ssl.log
   CustomLog /var/log/apache2/midominio.com-access-ssl.log combined
   SSLEngine On
   SSLCertificateFile /etc/apache2/ssl/midominio.com.pem
   SSLCertificateKeyFile /etc/apache2/ssl/midominio.com.key
</VirtualHost>

Finalmente, para que todos los cambios efectuados sean operativos, hay que reiniciar el servicio apache.

$ sudo service apache2 restart
 * Restarting web server apache2... 
waiting                                                           [ OK ]

Error de confianza

Dado que el certificado que hemos generado más arriba no está generado por una CA (Autoridad Certificadora) de confianza, cuando intentemos acceder a la página en cuestión, el navegador mostrará un error en el certificado.

Relacionado

Redirigir a una conexión segura https en Apache

Fuentes

Activar SSL en Apache2 (Ubuntu 10.04)

Extraer lineas de un archivo

2013-05-02T15:56:00.000+02:00

Actualmente estoy manipulando un fichero LDIF que tiene alrededor de 6.800.000 líneas.

El caso es que si utilizo un editor gráfico como por ejemplo gedit, al tener que manejar un archivo de ese tamaño, el sistema se cuelga. Por otro lado, según qué tipo de operación se deba realizar, el uso de editores en modo consola como nano o vim puede llegar a ser incómodo.

Para esos casos, puede servir de ayuda un pequeño script que nos permita la extracción de algunas líneas de código del archivo original. Basta con pasarle la línea de inicio, la línea final y el nombre del archivo sobre el que realizar la extracción.

if [ $# -eq 3 ]; then 
   first=$1 
   last=$2 
   file=$3
   head -n $last $file | tail -n `expr $last - $first + 1` 
else 
   echo "Usage: `basename $0` [firstLine] [lastLine] [file]" 
fi

Fuente

[Blog de Manel Pérez] Extraer lineas de un archivo

perl: warning: Setting locale failed.

2013-04-05T11:09:00.001+02:00

Al instalar cualquier paquete mediante el uso de apt-get en Ububtu Server 12.04 LTS, el sistema genera un error como este:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
 LANGUAGE = "en_US:en",
 LC_ALL = (unset),
 LC_TIME = "es_ES.UTF-8",
 LC_MONETARY = "es_ES.UTF-8",
 LC_ADDRESS = "es_ES.UTF-8",
 LC_TELEPHONE = "es_ES.UTF-8",
 LC_NAME = "es_ES.UTF-8",
 LC_MEASUREMENT = "es_ES.UTF-8",
 LC_IDENTIFICATION = "es_ES.UTF-8",
 LC_NUMERIC = "es_ES.UTF-8",
 LC_PAPER = "es_ES.UTF-8",
 LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_ALL to default locale: No such file or directory

La forma de solucionarlo (fijando los locales en inglés y español) es la siguiente

$ sudo locale-gen en_US en_US.UTF-8 es_ES es_ES.UTF-8
Generating locales...
en_US.ISO-8859-1... done
en_US.UTF-8... up-to-date
es_ES.ISO-8859-1... done
es_ES.UTF-8... done
Generation complete.

$ sudo dpkg-reconfigure locales
Generating locales...
en_AG.UTF-8... done
en_AU.UTF-8... done
en_BW.UTF-8... done
en_CA.UTF-8... done
en_DK.UTF-8... done
en_GB.UTF-8... up-to-date
en_HK.UTF-8... done
en_IE.UTF-8... done
en_IN.UTF-8... done
en_NG.UTF-8... done
en_NZ.UTF-8... done
en_PH.UTF-8... done
en_SG.UTF-8... done
en_US.ISO-8859-1... up-to-date
en_US.UTF-8... up-to-date
en_ZA.UTF-8... done
en_ZM.UTF-8... done
en_ZW.UTF-8... done
es_ES.ISO-8859-1... up-to-date
es_ES.UTF-8... up-to-date
Generation complete.

Fuentes

[Ubuntu forums] perl: warning: Setting locale failed

Mi página web no se visualiza bien en IE

2012-12-15T22:23:00.000+01:00

Uno de los principales retos a la hora de realizar un diseño web profesional es que la página se visualice correctamente en cualquier navegador. ¿Os imagináis que Facebook o Twitter sólo se vieran bien en Internet Explorer?

Para ello, la primera premisa es realizar una programación basada en estándares web. A pesar de eso, Internet Explorer suele dar algunos problemas ya que se trata de un navegador con una interpretación de los estándares un tanto "peculiar".

Es frecuente que un diseño web se vea bien en la mayoría de navegadores pero que Internet Explorer presente problemas de visualización. Para solventarlo, hay una solución muy simple y que suele funcionar: basta con añadir el siguiente meta tag justo al inicio del <head> de la página.

<head> 
<meta http-equiv="X-UA-Compatible" content="IE=8" />
[...]
</head>

Para saber más

Maestros del web: Estándares web

Relacionado

Ajustar el huso horario en PHP

2012-12-14T10:30:00.000+01:00

Cuando invocamos la función string date( string $format [, int $timestamp = time() ] ) en PHP, ésta nos devuelve una cadena con formato del tiempo indicado por el parámetro $timestamp o, en el caso de no indicar ningún timestamp, del momento actual.

Un problema típico con el que nos podemos encontrar al leer la fecha y la hora actual es que el servidor se encuentre en un huso horario distinto al de la prestación del servicio. Por ejemplo, cuando el hosting está en algún punto de EEUU y el servicio se está prestando en alguna parte de Europa.

Este problema se puede solucionar fácilmente de forma sencilla con la función bool date_default_timezone_set ( string $timezone_identifier ) tal y como se muestra en este ejemplo:

<?php
   $now = time();
   date_default_timezone_set( 'Europe/Madrid' );
   $fecha = date( "d/m/Y", $now );
   $hora  = date( "H:i:s", $now );
?>

Sigue un listado con todos los husos horarios clasificados por área

Para saber más

Sincronizar el reloj con NTP en servidores Debian

2012-12-11T13:53:00.000+01:00

Para los administradores de sistemas con multitud de equipos y servidores a su cargo es muy conveniente mantener los relojes de todos los equipos sincronizados. De ese modo, en el caso de producirse algún incidente de seguridad (pero no solo en ese caso), como todos los ficheros de log estarán sincronizados, el rastreo y secuenciación de los hechos es mucho más fácil.

Lo primero que necesitamos es instalar el paquete ntpdate.

# apt-get install ntpdate

El paso siguiente es el de sincronizar el reloj de cada sistema con un servidor de NTP. Para hacer eso basta con ejecutar el comando ntpdate nombre.del.servidor. Si nuestro equipo está detrás de un firewall es conveniente usar el parámetro -u del ntpdate para que use un puerto no privilegiado en la comunicación con el servidor NTP (ntpdate -u nombre.del.servidor).

Un servidor que funciona suficientemente bien para estos menesteres es swisstime.ethz.ch.

Sincronización automática

Vamos a asegurarnos que la sincronización se realice de forma periódica. Para ello, editaremos el fichero /etc/cron.hourly/ntp con el siguiente contenido para que se ejecute cada hora:

# vim /etc/cron.hourly/ntp
#!/bin/bash 
/usr/sbin/ntpdate -u swisstime.ethz.ch

Para asegurarnos que se ejecutará sin problemas debemos de asignar permisos de ejecución al fichero /etc/cron.hourly/ntp

# chmod a+x /etc/cron.hourly/ntp

$ ls -lF /etc/cron.hourly/ntp 
-rwxr-xr-x 1 root root 46 dec 11 13:39 /etc/cron.hourly/ntp*

Esto es todo. A partir de ahora, todos los equipos tendrán la misma (buena) hora.

Fuentes

BULMA: Sincroniza tu reloj con NTP

Para saber más

Cómo volver a crear el icono Mostrar escritorio en la barra de herramientas Inicio rápido en Windows XP

2012-10-16T00:38:00.000+02:00

Para volver a crear el icono Mostrar escritorio usted mismo, siga estos pasos

Haga clic en Inicio y, en Ejecutar, escriba notepad en el cuadro Abrir y haga clic en Aceptar.

Copie y pegue el texto siguiente en la ventana del Bloc de notas.

[Shell]
Command=2
IconFile=explorer.exe,3
[Taskbar]
Command=ToggleDesktop

En el menú Archivo, haga clic en Guardar como y, a continuación, guarde el archivo en el escritorio como "Show Desktop.scf". El icono Mostrar escritorio se crea en el escritorio.

Haga clic y arrastre el icono Mostrar escritorio a la barra de herramientas Inicio rápido.

Fuentes

Cómo volver a crear el icono Mostrar escritorio en la barra de herramientas Inicio rápido en Windows XP

Instalando symfony 1.4 en Mac OS X

2012-08-04T13:33:00.001+02:00

Symfony es un completo framework diseñado para optimizar, gracias a sus características, el desarrollo de las aplicaciones web. Para empezar, separa la lógica de negocio, la lógica de servidor y la presentación de la aplicación web.

Proporciona varias herramientas y clases encaminadas a reducir el tiempo de desarrollo de una aplicación web compleja. Además, automatiza las tareas más comunes, permitiendo al desarrollador dedicarse por completo a los aspectos específicos de cada aplicación. El resultado de todas estas ventajas es que no se debe reinventar la rueda cada vez que se crea una nueva aplicación web.

En su momento vimos como realizar la instalación de symfony para Ubuntu. Hoy vamos a ver como realizar la instalación para Mac OS X

Requisitos previos

Antes de iniciar todo el proceso, debemos asegurarnos de tener en marcha una arquitectura MAMP (Mac-Apache-Mysql-PHP) en nuestro equipo.

Nota: Si el sistema MAMP ya está instalado, se puede saltar directamente al proceso de instalación de symfony.

Existen herramientas como apachefriends ó MAMP que instalan todo lo necesario de una forma cómoda y sin complicaciones. En este tutorial, en cambio, vamos a aprovechar, las versiones de Apache y PHP que ya vienen instaladas en Mac OS X Lion e instalaremos manualmente mySQL.

Apache

A diferencia de lo que pasa en Windows, Mac OS ya trae instalado el servidor Apache. Simplemente hay que activarlo. Para ello iremos a las «Preferencias del sistema», seleccionaremos el icono «Compartir» y marcaremos la opción «Compartir Web». Una vez activado el servicio, podemos comprobar el funcionamiento del servidor Apache escribiendo http://localhost en la barra de direcciones del navegador. Se mostrará una página básica que nos indicará que funciona correctamente.

Por defecto, la raíz de los documentos de la página web (ficheros HTML, PHP, imágenes, etc.) se encuentra en el directorio /Library/Webserver/Documents.

PHP

Una vez activado Apache, para que éste pueda cargar el módulo PHP, bastará con editar el fichero de configuración del servicio /etc/apache2/httpd.conf y descomentar la línea donde se carga el múdulo de PHP (descomentar LoadModule php5_module)

$ sudo vim /etc/apache2/httpd.conf
## Descomentamos (eliminamos el # inicial) la siguiente línea:
LoadModule php5_module libexec/apache2/libphp5.so

A continuación, hacemos una copia del fichero de configuración por defecto del PHP y lo editamos:

$ sudo cp /etc/php.ini.default /etc/php.ini
$ sudo vim /etc/php.ini
## Cambiamos el tamaño máximo de subida de ficheros hasta 30M:
; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
upload_max_filesize = 30M

## Fijamos la zona horaria correspondiente:
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
date.timezone = "Europe/Madrid"

Para que todos estos cambios tengan efecto, hay que reiniciar el servicio de Apache

$ sudo apachectl restart

Para comprobar el correcto funcionamiento del PHP dentro de Apache, crearemos una página en PHP con una llamada a phpinfo() en la raíz de la web y la visualizaremos en el navegador:

$ sudo vim /Library/WebServer/Documents/info.php
<?php phpinfo(); ?>

Cargando esta página en el navegador podremos comprobar el correcto funcionamiento de PHP:

mySQL

A diferencia de Apache y PHP que, como ya hemos visto, sí vienen con el sistema y solo hay que activarlos, mySQL no viene viene incorporado (Mac OS X Lion incluye el soporte a postgreSQL).

Para poder instalarlo, deberemos descargarlo desde Download MySQL Community Server. En nuestro caso, elegimos «Mac OS X ver. 10.6 (x86, 64-bit), DMG Archive». Para realizar la descarga, no es preciso registrarse, basta con hacer click en «No thanks, just start my download!».

Una vez abierto el paquete DMG que nos acabamos de descargar, tenemos un ventana como esta:

El orden de instalación:

Mysql-5.5.15-osx10.6-x86_64.pkg
MySQL.prefPane
MySQLStartupItem.pkg

Tal y como ha quedado instalado el sistema, la contraseña de root para mySQL está en blanco, lo cual es un potencial agujero de seguridad. Para ello, habrá que proceder a cambiar la contraseña siguiendo las indicaciones de "Cambiar la contraseña root de mySQL".

Para trabajar desde la cónsola de una forma más eficaz, nos puede interesar añadir el directorio donde se encuentran los ejecutables de mySQL dentro de la variable PATH del sistema. Para ello, editaremos el archivo .bash_profile dentro de nuestra carpeta personal y añadiremos la siguiente línea:

$ vim ~/.bash_profile
export PATH="/usr/local/mysql/bin:$PATH"

Para terminar con la configuración de mySQL, vamos a crear el fichero my.conf. Copiaremos el fichero de ejemplo que viene con la instalación y luego lo editaremos:

$ sudo cp /usr/local/mysql/support-files/my-medium.cnf /etc/my.cnf
$ sudo vim /etc/my.cnf

Dentro del apartado [client], añadiremos al usuario root, descomentaremos la línea de password (eliminando el primer carácter #) y le indicaremos la contraseña de root de mySQL. Más abajo, en la sección [mysqld] nos aseguraremos de que la localización del socket sea la misma que la indicada por la variable pdo_mysql.default_socket del archivo de configuración /etc/php.ini (en el caso de los Mac, suele ser /tmp/mysql.sock):

[client]
user = root
password        = nuestra_contraseña

[mysqld]
port            = 3306
socket          = /tmp/mysql.sock

[...]

INSTALACIÓN DE SYMFONY

Antes de instalar symfony, es necesario crear el directorio que contendrá todos los ficheros relacionados con el proyecto. Para el ejemplo que nos ocupa, dispondremos de un contenedor global de proyectos en /Users/sfprojects/ y, en su interior, colocaremos una carpeta diferente para cada proyecto que vayamos a crear (en este tutorial, nuestro proyecto se llamará proyecto):

$ sudo mkdir -p /Users/sfprojects/proyecto
$ sudo chown -R username /Users/sfproject/proyecto
$ cd /Users/sfproject/proyecto

Elección de la versión de Symfony

En el momento de escribir este artículo, symfony tiene dos ramas estables del framework: la 1.4.18 y la 2.0.0. En este tutorial asumimos que se desea instalar symfony 1.4.

Se puede instalar symfony a nivel global en el servidor o incrustarlo en cada uno de los proyectos. Esta segunda opción es la preferida porque nos permitirá que los proyectos sean totalmente independientes unos de otros.

La actualización del framework instalado localmente en un proyecto no romperá ninguno de los otros proyectos de forma inesperada. Esto significa que se pueden tener proyectos en diferentes versiones de Symfony, y actualizarlos cada uno a la vez que mejor convenga.

Siguiendo la práctica recomendada, instalaremos los archivos de symfony en el directorio lib/vendor. Así pues, en primer lugar, vamos a crear ese directorio dentro de la estructura del proyecto:

$ mkdir -p lib/vendor

Instalando Symfony

La forma más fácil de instalar symfony es descargándose el archivo desde la página web oficial del proyecto. Tenemos disponibles para la descarga las versiones en formatos .tgz y .zip.

Descargamos el archivo (en nuestro caso, la versión .tgz) y lo colocamos en el directorio recién creado proyecto/lib/vendor, lo descomprimimos, y le cambiamos el nombre a symphony:

$ cd lib/vendor
$ curl http://www.symfony-project.org/get/symfony-1.4.18.tgz -o symfony-1.4.18.tgz
$ tar zxpf symfony-1.4.18.tgz
$ mv symfony-1.4.18.tgz symfony
$ rm symfony-1.4.18.tgz

Creación del proyecto

Nos situamos en el directorio proyecto/ y, para crear el proyecto symfony, ejecutaremos la tarea generate:project :

$ cd ../..
$ php lib/vendor/symfony/data/bin/symfony generate:project proyecto

La tarea generate:project genera la estructura predeterminada de directorios y archivos necesarios para un proyecto symfony:

Directorio	Descripción
`apps/`	Contiene todas las aplicaciones del proyecto
`cache/`	Los archivos almacenados en caché por el framework
`config/`	Los archivos de configuración del proyecto
`data/`	Los archivos de datos como los accesorios iniciales
`lib/`	Las bibliotecas y clases del proyecto
`log/`	Los archivos de registro del framework
`plugins/`	Los plugins instalados
`test/`	La unidad y los archivos de prueba funcional
`web/`	El directorio raíz web (véase más adelante)

¿Por qué Symfony genera tantos archivos?

Uno de los principales beneficios de usar un framework completo es la normalización de los desarrollos. Gracias a la estructura de archivos y directorios por defecto de Symfony, cualquier desarrollador con algunos conocimientos de Symfony puede asumir el mantenimiento de un proyecto. En cuestión de minutos, será capaz de bucear en el código, corregir errores y añadir nuevas funcionalidades.

La tarea generate:project también crea, en el directorio raíz del proyecto, un acceso directo hacia symfony para acortar el número de caracteres a escribir cuando se ejecuta una tarea. Por lo tanto, a partir de ahora, en lugar de utilizar la ruta completa al programa de Symfony (proyecto/lib/vendor/symfony/data/bin/symfony), podemos utilizar el acceso directo de symfony.

Verificación de la instalación

Ahora que Symfony está instalado, desde el directorio proyecto/, comprobaremos que todo funciona correctamente. Para ello, utilizaremos la línea de comandos de symfony para que nos muestre la versión instalada (notar el uso de la V mayúscula):

$ php symfony -V
symfony version 1.4.18 (/Users/sfprojects/proyecto/lib/vendor/symfony/lib)

La opción -V (en mayúscula) también muestra la ruta al directorio de instalación de Symfony, que se almacena en config/ProjectConfiguration.class.php. Si en el fichero de configuración muestra una ruta absoluta hacia Symfony (siguiendo las instrucciones al pie de la letra, no debería serlo), con el fin de obtener una mejor portabilidad, la cambiaremos por lo que se sigue:

// config/ProjectConfiguration.class.php
require_once  dirname(__FILE__).'/../lib/vendor/symfony/lib/autoload/sfCoreAutoload.class.php';

De este modo, podremos mover el directorio del proyecto a cualquier otra parte del servidor y seguirá funcionando igual.

Configurando la base de datos

Al crear un nuevo proyecto, se activa por defecto Doctrine. Configurar la base de datos utilizada por Doctrine es tan sencillo como llamar la tarea configure:database:

$ php symfony configure:database "mysql:host=localhost;dbname=dbname" dbuser dbpassword

Creación de la aplicación

Ahora vamos a crear el frontend de la aplicación ejecutando la tarea generate:app.

$ php symfony generate:app frontend

Debido a que el acceso directo a symfony es ejecutable, de ahora en adelante, se pueden reemplazar todas las apariciones de «php symfony» por «./symfony».

Basado en el nombre de la aplicación dada como argumento, la tarea generate:app crea la estructura de directorios predeterminada necesaria para la aplicación dentro del directorio apps/frontend/:

Directorio	Descripción
`config/`	Los archivos de configuración de la aplicación
`i18n/`	Los archivos para la internacionalización y localización
`lib/`	Las bibliotecas de aplicaciones y clases
`modules/`	El código de la aplicación (MVC)
`templates/`	Los archivos de plantillas globales

Seguridad

De forma predeterminada, la tarea generate:aplication fortifica nuestra aplicación para prevenirla de las dos vulnerabilidades más extendidas en la web: XSS y CSRF.

Para evitar ataques XSS, se ha activado el mecanismo de escape de caracteres, y para prevenir los ataques CSRF, se habilita la generación de tokens.

Por supuesto, se puede ajustar la configuración de estos parametros, mediante las opciones:

--escaping-strategy: Activa o desactiva el mecanismo de escape de caracteres
--csrf-secret: Permite tokens de sesión en los formularios

En caso de no saber nada acerca de XSS y CSRF, es recomendable que se tome un tiempo para aprender más de estas vulnerabilidades de seguridad.

Permisos de la estructura de directorios

Antes de intentar acceder a un proyecto de nueva creación, es necesario asegurarse de que se han establecido de forma correcta los permisos de escritura para los directorios cache/ y log/, de modo que el servidor web pueda escribir en ellos:

$ chmod 777 cache/ log/

Configuración del servidor web

Una buena práctica es poner bajo el directorio raíz web únicamente los archivos que necesiten tener acceso desde el exterior mediante un navegador web, como las hojas de estilo, el código JavaScript y las imágenes. Por defecto, se recomienda almacenar estos archivos en el subdirectorio web/ del proyecto symfony.

Si echamos un vistazo a este directorio, nos encontraremos algunos subdirectorios (css/, images/, js/ y uploads/) y los archivos de los controladores del frontend (index.php y frontend_dev.php). Estos son los únicos archivos PHP que necesitan estar bajo el directorio raíz de la web. Todos los demás archivos se pueden ocultar al navegador, lo cual es una buena idea en cuanto a seguridad se refiere.

Configuración del apache

Ahora es el momento de cambiar la configuración de Apache para que el nuevo proyecto sea accesible a través de la web. Editaremos el fichero de configuración /etc/apache2/httpd.conf para habilitar la carga de los VirtualHost.

## Descomentamos la línea que incluye la configuración de los Virtual hosts
Include /private/etc/apache2/extra/httpd-vhosts.conf

A continuación, editamos el fichero de definición de los Virtual Host:

$ sudo vim /etc/apache2/extra/httpd-vhosts.conf
# Debemos asegurarnos de que esta línea exista una sola vez en nuestra configuración
NameVirtualHost 127.0.0.1:8080

# Esta es la configuración de nuestro proyecto
Listen 127.0.0.1:8080

<VirtualHost 127.0.0.1:8080>
   DocumentRoot "/Users/sfprojects/proyecto/web"
   DirectoryIndex index.php
   <Directory "/Users/sfprojects/proyecto/web">
      AllowOverride All
      Allow from All
   </Directory>
   Alias /sf /Users/sfprojects/proyecto/lib/vendor/symfony/data/web/sf
   <Directory "/Users/sfprojects/proyecto/lib/vendor/symfony/data/web/sf">
      AllowOverride All
      Allow from All
   </Directory>
   ErrorLog "/private/var/log/apache2/proyecto-error_log"
   CustomLog "/private/var/log/apache2/proyecto-access_log" common
</VirtualHost>

El Alias /sf permite el acceso a las imágenes y los archivos JavaScript necesarios para mostrar adecuadamente las páginas symfony por defecto y, también, la barra de herramientas de depuración web.

Para que todos estos cambios sean efectivos, hay que reiniciar el servidor apache.

$ sudo apachectl restart

La configuración indicada hace que Apache escuche peticiones web por el puerto 8080 del servidor. De este modo, el sitio será accesible a través de la siguiente URL:

http://localhost:8080/

Se puede cambiar 8080 por cualquier otro número. En favor de los números de puerto superiores a 1024 como éste, hay que decir que no requieren de derechos de administrador.

Configuración con un nombre de dominio dedicado

Si somos administradores del equipo, lo mejor será configurar un VirtualHost en lugar de añadir un nuevo puerto cada vez que se inicia un proyecto.

Así pues, en vez de elegir un puerto y agregarle la correspondiente declaración Listen, elegiremos un nombre que identifique el proyecto (con el sufijo .localhost para distinguirlo de un dominio de Internet real) y añadimos una declaración ServerName:

# Esta es la configuración de nuestro proyecto
<VirtualHost *:80>
   ServerName proyecto.localhost
   DocumentRoot "/Users/sfprojects/proyecto/web"
   DirectoryIndex index.php
   <Directory "/Users/sfprojects/proyecto/web">
      AllowOverride All
      Allow from All
   </Directory>
   Alias /sf /home/sfprojects/proyecto/lib/vendor/symfony/data/web/sf
   <Directory "/home/sfprojects/proyecto/lib/vendor/symfony/data/web/sf">
      AllowOverride All
      Allow from All
   </Directory>
   ErrorLog "/private/var/log/apache2/proyecto-error_log"
   CustomLog "/private/var/log/apache2/proyecto-access_log" common
</VirtualHost>

Para poder utilizar este nombre de dominio (proyecto.localhost) tendremos que declararlo localmente en el fichero /etc/hosts añadiéndole la siguiente línea:

127.0.0.1    proyecto.localhost

Comprobando la nueva configuración

Reiniciamos Apache, y verificamos que tenemos acceso a la aplicación escribiendo en el navegador http://localhost:8080/index.php o http://proyecto.localhost/index.php (dependiendo de la configuración elegida en el apartado anterior). Si todo ha ido correctamente, visualizaremos una página como esta:

Si Apache tiene instalado el módulo mod_rewrite no será necesario escribir index.php en la URL. Esto es posible gracias a las reglas de reescritura configuradas en el fichero web/.htaccess.

Se puede acceder al entorno de desarrollo (en otro documento hablaremos de los entornos) de la aplicación escribiendo la siguiente URL en el navegador:

http://proyecto.localhost/frontend_dev.php

Debería de mostrarse la barra de debug web en la esquina superior derecha, incluidos los iconos.

En este punto, Symfony 1.4.18 ya está instalado y es completamente operativo.

Relacionado

Instalando symfony 1.4 en Ubuntu

Para saber más

Fuentes

Cambiar la contraseña root de MySQL

2012-06-01T13:56:00.000+02:00

Es posible que tengamos que administrar una base de datos MySQL y, por la razón que sea, no tengamos la contraseña de root. Esta situación, que es más habitual de lo que nos imaginamos, presenta un grave problema porque nos impide crear nuevas base de datos, nuevos usuarios, etc.

En este tutorial vamos a ver cómo se puede cambiar la contraseña de root de MySQL desde la cónsola del sistema y de una forma muy sencilla.

En primer lugar debemos detener el servicio MySQL.

# /etc/init.d/mysql stop
Stopping MySQL database server: mysqld.

A continuación iniciamos de nuevo el servicio, pero en "modo abierto" y en background.

# mysqld_safe --skip-grant-tables --skip-networking &
[1] 18305
120601 12:56:45 mysqld_safe Logging to syslog.
120601 12:56:45 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

En el comando anterior, la opción --skip-grant-tables hace que el servidor no utilice el sistema de permisos, con lo que podremos obtener acceso sin restricciones a todos los usuarios y a todas las bases de datos.

NOTA: Si MySQL fue configurado y compilado con la opción '--disable-grant-options' entonces lo anterior no funcionará y no hay mucho que hacer para poder cambiar la contraseña. En la práctica, por suerte, esta opción no se suele usar.

La opción --skip-networking indicada más arriba hace que MySQL deje de escuchar (LISTEN) conexiones TCP/IP provenientes de la red y opere únicamente en el ámbito local.

Una vez reiniciado el servicio en modo "abierto" y "local", ya podemos acceder al monitor y proceder. Para trabajar con ella, capturaremos la base de datos mysql.

# mysql -u root
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
[...]

mysql> use mysql;

Procedemos a la actualización del campo 'password' del usuario 'root' y, como ya hemos terminado, abandonamos del monitor.

mysql> UPDATE user SET password=PASSWORD('NUEVA_CONTRASEÑA') WHERE user='root';
Query OK, 2 rows affected (0.00 sec)
Rows matched: 2  Changed: 2  Warnings: 0

mysql> exit

Solo queda reiniciar el servicio mysql.

# /etc/init.d/mysql restart
Stopping MySQL database server: mysqld
120601 12:58:35 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended.
Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..
[1]+  Hecho          mysqld_safe --skip-grant-tables --skip-networking

Lo que ha ocurrido es que se detenido el servicio (que operaba en background y modo "abierto" y "local") y se ha vuelto a iniciar en modo "normal". Desde este momento ya se puede acceder al sistema con la nueva contraseña.

Fuentes

LinuxTotal - Cambiar la contraseña root de MySQL

Redirigir a una conexión segura https en Apache

2012-05-15T13:23:00.001+02:00

Puede que, como administradores de un sistema, nos interese que todos los accesos a una determinada página web, se realicen siempre bajo protocolo seguro HTTPS.

Veremos dos posibilidades: Redirección permanente o Reescritura

Método de redirección permanente

El procedimiento será definir un Virtualhost para HTTPS y otro para HTTP. Desde el Virtualhost HTTP fijaremos una redirección permanente hacia HTTPS.

# /etc/apache2/sites-enabled/000-default
<VirtualHost *:80>
   ServerName  www.ejemplo.com
   ServerAdmin webmaster@ejemplo.com
   Redirect permanent / https://www.ejemplo.com
</VirtualHost>

Método de reescritura

Para que este método funcione, deberemos asegurarnos de tener instalado el módulo mod_rewrite. En caso de estar presente, el módulo se puede instalar mediante el siguiente comando (para que sea operativo, después habrá que reiniciar apache).

# a2enmod rewrite
Enabling module rewrite.
Run '/etc/init.d/apache2 restart' to activate new configuration!

Una vez instalado el módulo mod_rewrite ya estamos en disposición de preparar la reescritura de todo el sitio web añadiendo el siguiente código dentro del correspondiente VirtualHost de HTTP o, alternativamente, en un fichero .htaccess en la raíz del sitio web.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

O, alternativamente

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.dominio.com/$1 [R,L]

Si se quiere redireccionar el contenido de una carpeta específica

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} folder
RewriteRule ^(.*)$ https://www.dominio.com/folder/$1 [R,L]

Finalmente, si lo que se quiere redireccionar es únicamente una página concreta (por ejemplo, un formulario) podemos utilizar el siguiente código.

RewriteEngine On
RewriteRule ^formulario\.html$ https://www.ejemplo.com/formulario.html [R=301,L]

Para saber más

Apache Module mod_rewrite

Fuentes

Autenticación mediante clave pública en SSH

2012-05-11T15:25:00.000+02:00

El uso de claves públicas para acceder a servicios como SSH, SCP o SFTP, resulta una técnica más segura para autenticar dichos servicios que el esquema clásico de usuario y contraseña, al que estamos tan acostumbrados. Además, nos permite realizar una identificación automática y transparente, sin necesidad de tener que interaccionar, lo cual será de gran utilidad en la automatización de ciertas tareas rutinarias que, preferiblemente, deban realizarse de forma desatendida como por ejemplo la realización de copias de seguridad.

Algoritmos de cifrado

SSH permite crear claves usando los algoritmos RSA y DSA, pero… ¿cuál de ellos nos conviene más?

RSA: (de las siglas de sus autores, Rivest, Shamir y Adleman) Es un algoritmo asimétrico cifrador de bloques, que utiliza una clave pública, la cual se distribuye y otra privada, guardada en secreto por su propietario. Su funcionamiento reside en el uso de expresiones exponenciales dentro de la aritmética modular. Obteniendo una completa seguridad, debido a que aún no se conocen formas óptimas de factorizar un número grande en sus factores primos utilizando ordenadores personales. El RSA se basa en dos problemas matemáticos: el problema de factorizar números grandes y el problema RSA. El descifrado completo de un texto cifrado con RSA es computacionalmente intratable.
Por otro lado la factorización de números grandes proponen métodos para longitudes de 600-700 bits de longitud. Y generalmente, las claves RSA usan entre 1024-2048 bits.
DSA: (Digital Signature Algorithm) es el algoritmo de firmado digital incluido en el DSS (Digital Signature Standard) del NIST Norteamericano. Está basado en el problema de los logaritmos discretos y únicamente puede emplearse para las firmas digitales (a diferencia del RSA, que puede emplearse también para encriptar). La elección de este algoritmo como estándar de firmado generó multitud de críticas puesto que perdía bastante flexibilidad respecto al RSA.

En general, se comprueba que el algoritmo DSA es más rápido para generar la firma que para verificarla, al contrario de lo que sucede con RSA. Por lo que, para realizar la autentificación en nuestro servidor SSH, usaremos este último. Además, si comparamos el tamaño de las llaves generadas por ambos algoritmos, comprobaremos que las utilizadas por RSA son superiores a las de DSA. Razones por las que nos decantaremos por usar el algoritmo RSA.

Configuración en el servidor

Vamos a comprobar que el equipo remoto tiene activada la versión 2 del protocolo SSH y, además, que tenga habilitada la opción para utilizar claves RSA. Para ello buscamos las siguientes directivas en el fichero de configuración del servidor SSH /etc/ssh/sshd_config:

Protocol 2
RSAAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Para cada usuario que vaya a conectarse remotamente, debe de existir el directorio /home/nombre_usuario/.ssh/ y en él el archivo authorized_keys. En caso de no existir, deberemos crearlo de forma manual, asignarle los permisos correspondientes y, posteriormente, (re)iniciar el servidor.

$ cd ~
$ mkdir .ssh
$ chmod 600 .ssh/
$ touch .ssh/authorized_keys
$ sudo /etc/init.d/sshd start

Generación de los pares de claves RSA

Como antes comentamos, SSH nos permite generar indistintamente claves RSA o DSA (en nuestro caso usaremos claves RSA), creándose una clave pública y una clave privada.

Dichas claves, pueden generarse en el servidor, en la estación cliente, o en cualquier otra máquina.

Al final sólo la clave pública debe de aparecer en el fichero ~/.ssh/authorized_keys del servidor remoto.

Para generar el par de claves utilizaremos el comando ssh-keygen. Durante el proceso, se nos pedirá la introducción de una passphrase, lo que viene a ser una contraseña para poder generar unas claves más fuertes y seguras.

En nuestro caso, vamos a dejar la passphrase en blanco para que no nos la pida y, de ese modo, poder acceder al servidor remoto de forma desatendida.

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/nombre_usuario/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/nombre_usuario/.ssh/id_rsa.
Your public key has been saved in /home/nombre_usuario/.ssh/id_rsa.pub.
The key fingerprint is:
8d:34:58:47:33:4a:ff:98:bd:a8:a9:cc:65:ba:6c:02 nombre_usuario@mi_ordenador_portatil
The key's randomart image is:
+--[ RSA 2048]----+
|        o.=      |
|       + + o     |
|      . + .      |
|       . + =     |
|        S + o    |
|  E       . .    |
|   .    o . .    |
|    .+.+ o       |
|     oBoo        |
+-----------------+

Instalación de clave pública y protección de la clave privada

Una vez generado el par de claves, el siguiente paso es copiar la clave pública en el servidor (o los servidores) donde tengamos pensado autentificarnos a través de clave pública y guardar en un lugar seguro la clave privada.

Particularidades de las claves pública/privada

La misma clave pública nos puede servir para acceder a cualquier servidor. No hay que generar una nueva clave cada vez.

La clave privada debe de ser PRIVADA y debe custodiarse en un lugar seguro (típicamente, en ~/.ssh con los permisos adecuados para que solo pueda acceder el propietario de la clave).

Procedemos a copiar la clave pública al servidor remoto. Una vez realizada la copia, accedemos al servidor y comprobamos que los permisos de los ficheros authorized_keys y known_hosts sea la correcta:

$ ssh-copy-id usuario@host_remoto
usuario@host_remoto's password: 
Now try logging into the machine, with "ssh 'usuario@host_remoto'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

$ ssh usuario@host_remoto
Last login: Fri May 11 13:46:05 2012 from 192.168.0.15
Linux host_remoto 2.6.32-5 #1 SMP Mon Jan 16 20:48:30 UTC 2012 x86_64 GNU/Linux

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

$ ls -l .ssh/
total 8
-rw------- 1 usuario usuario 1226 May 11 14:39 authorized_keys
-rw-r--r-- 1 usuario usuario 2017 Nov 26  2011 known_hosts

Ahora nos encargamos de la clave privada que debe de estar en nuestro equipo. Forzamos que las claves sólo sean accesibles por su propietario.

$ chmod 600 ~/.ssh/{id_dsa,id_dsa.pub}
$ ls -l ~/.ssh/
total 48
-rw------- 1 usuario usuario   668 2012-05-11 14:38 id_dsa
-rw------- 1 usuario usuario   613 2012-05-11 14:38 id_dsa.pub
-rw-r--r-- 1 usuario usuario 37372 2012-05-07 11:31 known_hosts

Pasos finales

Una vez copiada la clave pública en el servidor y asegurado que podemos establecer una conexión remota, vamos a aumentar la seguridad del servidor remoto introduciendo algunos cambios en el fichero de configuración del servicio ssh (/etc/ssh/sshd_config). Impediremos la conexión con el usuario root y la autenticación mediante password.

PermitRootLogin no
PasswordAuthentication no

Para incrementar la seguridad del equipo remoto, es recomendable activar siempre la primera directiva. Con ella evitamos el acceso remoto como root. En este sentido, lo más seguro es acceder como usuario sin privilegios y, una vez ganado el acceso al sistema, cambiar a usuario root con los comandos su o sudo.

En cuanto a la segunda directiva, hay que tener en cuenta que impedirá que NINGÚN usuario pueda conectarse remotamente mediante usuario/contraseña. TODOS los usuarios remotos deberán validarse mediante su clave pública. A efectos prácticos, en algunos entornos, puede que esto no sea lo más recomendable.

Para saber más

Wikipedia - Infraestructura de clave pública

Fuentes

Instalando symfony 1.4 en Ubuntu

2012-05-11T02:35:00.001+02:00

$ sudo mkdir -p /home/sfprojects/proyecto
$ sudo chown -R username.username /home/sfproject/proyecto
$ cd /home/sfproject/proyecto

Elección de la versión de Symfony

En el momento de escribir este artículo, symfony tiene dos ramas estables del framework: la 1.4.17 y la 2.0.0. En este tutorial asumimos que se desea instalar symfony 1.4.

Se puede instalar symfony a nivel global en el servidor o incrustarlo en cada uno de los proyectos. Esta segunda opción es la preferida porque nos permitirá que los proyectos sean totalmente independientes unos de otros.

La actualización del framework instalado localmente en un proyecto no romperá ninguno de los otros proyectos de forma inesperada. Esto significa que se pueden tener proyectos en diferentes versiones de Symfony, y actualizarlos cada uno a la vez que mejor convenga.

Siguiendo la práctica recomendada, instalaremos los archivos de symfony en el directorio lib/vendor. Así pues, en primer lugar, vamos a crear ese directorio dentro de la estructura del proyecto:

$ mkdir -p lib/vendor

$ cd lib/vendor
$ wget http://www.symfony-project.org/get/symfony-1.4.17.tgz
$ tar zxpf symfony-1.4.17.tgz
$ mv symfony-1.4.17.tgz symfony
$ rm symfony-1.4.17.tgz

Creación del proyecto

Nos situamos en el directorio proyecto/ y, para crear el proyecto symfony, ejecutaremos la tarea generate:project:

$ cd ../..
$ php lib/vendor/symfony/data/bin/symfony generate:project proyecto

La tarea generate:project genera la estructura predeterminada de directorios y archivos necesarios para un proyecto symfony:

Directorio	Descripción
`apps/`	Contiene todas las aplicaciones del proyecto
`cache/`	Los archivos almacenados en caché por el framework
`config/`	Los archivos de configuración del proyecto
`data/`	Los archivos de datos como los accesorios iniciales
`lib/`	Las bibliotecas y clases del proyecto
`log/`	Los archivos de registro del framework
`plugins/`	Los plugins instalados
`test/`	La unidad y los archivos de prueba funcional
`web/`	El directorio raíz web (véase más adelante)

$ php symfony -V
symfony version 1.4.17 (/home/sfprojects/proyecto/lib/vendor/symfony/lib)

La opción -V también muestra la ruta al directorio de instalación de Symfony, que se almacena en config/ProjectConfiguration.class.php. Si en el fichero de configuración muestra una ruta absoluta hacia Symfony (siguiendo las instrucciones al pie de la letra, no debería serlo), con el fin de obtener una mejor portabilidad, la cambiaremos por lo que se sigue:

// config/ProjectConfiguration.class.php
require_once dirname(__FILE__).'/../lib/vendor/symfony/lib/autoload/sfCoreAutoload.class.php';

$ php symfony configure:database "mysql:host=localhost;dbname=dbname" dbuser dbpassword

Creación de la aplicación

Ahora vamos a crear el frontend de la aplicación ejecutando la tarea generate:app.

$ php symfony generate:app frontend

Debido a que el acceso directo a symfony es ejecutable, de ahora en adelante, se pueden reemplazar todas las apariciones de «php symfony» por «./symfony».

Directorio	Descripción
`config/`	Los archivos de configuración de la aplicación
`lib/`	Las bibliotecas de aplicaciones y clases
`modules/`	El código de la aplicación (MVC)
`templates/`	Los archivos de plantillas globales

Seguridad

De forma predeterminada, la tarea generate:aplication fortifica nuestra aplicación para prevenirla de las dos vulnerabilidades más extendidas en la web: XSS y CSRF.

Para evitar ataques XSS, se ha activado el mecanismo de escape de caracteres, y para prevenir los ataques CSRF, se habilita la generación de tokens.

Por supuesto, se puede ajustar la configuración de estos parametros, mediante las opciones:

--escaping-strategy: Activa o desactiva el mecanismo de escape de caracteres
--csrf-secret: Permite tokens de sesión en los formularios

En caso de no saber nada acerca de XSS y CSRF, es recomendable que se tome un tiempo para aprender más de estas vulnerabilidades de seguridad.

Permisos de la estructura de directorios

Antes de intentar acceder a un proyecto de nueva creación, es necesario establecer los permisos de escritura en los directorios cache/ y log/ a los niveles apropiados, de modo que el servidor web pueda escribir en ellos:

$ chmod 777 cache/ log/

Configuración del servidor web

Una buena práctica es poner bajo el directorio raíz web únicamente los archivos que necesiten tener acceso desde el exterior mediante un navegador web, como las hojas de estilo, el código JavaScript y las imágenes. Por defecto, se recomienda almacenar estos archivos en el subdirectorio web/ del proyecto symfony.

Si echamos un vistazo a este directorio, nos encontraremos algunos subdirectorios (css/, images/, js/ y uploads/) y los archivos de los controladores del frontend (index.php y frontend_dev.php). Estos son los únicos archivos PHP que necesitan estar bajo el directorio raíz de la web. Todos los demás archivos se pueden ocultar al navegador, lo cual es una buena idea en cuanto a seguridad se refiere.

Configuración del apache

Ahora es el momento de cambiar la configuración de Apache para que el nuevo proyecto sea accesible a través de la web. Editaremos el fichero de configuración httpd.conf para añadirle la siguiente configuración:

# Debemos asegurarnos de que esta línea exista una sola vez en nuestra configuración
NameVirtualHost 127.0.0.1:8080

# Esta es la configuración de nuestro proyecto
Listen 127.0.0.1:8080

<VirtualHost 127.0.0.1:8080>
   DocumentRoot "/home/sfprojects/proyecto/web"
   DirectoryIndex index.php
   <Directory "/home/sfprojects/proyecto/web">
      AllowOverride All
      Allow from All
   </Directory>
   Alias /sf /home/sfprojects/proyecto/lib/vendor/symfony/data/web/sf
   <Directory "/home/sfprojects/proyecto/lib/vendor/symfony/data/web/sf">
      AllowOverride All
      Allow from All
   </Directory>
   ErrorLog "/var/log/apache2/proyecto-error_log"
   CustomLog "/var/log/apache2/proyecto-access_log" common
</VirtualHost>

La configuración indicada hace que Apache escuche peticiones web por el puerto 8080 del servidor. De este modo, el sitio será accesible a través de la siguiente URL:

http://localhost:8080/

Se puede cambiar 8080 por cualquier otro número. En favor de los números de puerto superiores a 1024 como éste, hay que decir que no requieren de derechos de administrador.

Configuración de un nombre de dominio dedicado

Si somos administradores del equipo, lo mejor será configurar un VirtualHost en lugar de añadir un nuevo puerto cada vez que se inicia un proyecto.

Así pues, en vez de elegir un puerto y agregarle la correspondiente declaración Listen, elegiremos un nombre que identifique el proyecto (con el sufijo .localhost para distinguirlo de un dominio de Internet real) y añadimos una declaración ServerName:

# Esta es la configuración de nuestro proyecto
<VirtualHost *:80>
   ServerName proyecto.localhost
   DocumentRoot "/home/sfprojects/proyecto/web"
   DirectoryIndex index.php
   <Directory "/home/sfprojects/proyecto/web">
      AllowOverride All
      Allow from All
   </Directory>
   Alias /sf /home/sfprojects/proyecto/lib/vendor/symfony/data/web/sf
   <Directory "/home/sfprojects/proyecto/lib/vendor/symfony/data/web/sf">
      AllowOverride All
      Allow from All
   </Directory>
   ErrorLog "/var/log/apache2/proyecto-error_log"
   CustomLog "/var/log/apache2/proyecto-access_log" common
</VirtualHost>

Para poder utilizar este nombre de dominio (proyecto.localhost) tendremos que declararlo localmente en el fichero /etc/hosts añadiéndole la siguiente línea:

127.0.0.1    proyecto.localhost

Si Apache tiene instalado el módulo mod_rewrite no es necesario escribir index.php en la URL. Esto es posible gracias a las reglas de reescritura configuradas en el fichero web/.htaccess.

Podemos acceder al entorno de desarrollo (en otro documento hablaremos de los entornos) de la aplicación escribiendo la siguiente URL en el navegador:

http://proyecto.localhost/frontend_dev.php

La barra de debug web debería mostrarse en la esquina superior derecha, incluidos los iconos. La prueba de que la configuración del alias sf/ es correcta.

En este punto, Symfony 1.4.17 ya está instalado y es completamente operativo.

Relacionado

Instalando Symfony 1.4 en Mac OS X

Para saber más

Fuentes

[PDF] Symfony: Getting started

3 formas de ejecutar comandos en segundo plano en linux

2012-05-04T00:57:00.000+02:00

En algunas ocasiones puede ser necesario ejecutar un script en segundo plano; ya sea porque tarde mucho en finalizar o porque el programa tiene que ejecutarse de forma indefinida y al mismo tiempo se quieren analizar sus salidas/salidas en tiempo real, o cuando, en el caso de conexiones remotas, por el motivo que sea, se pueda producir una desconexión.

Analizaremos 3 posibilidades:

& y bg

Si añadimos un ampersand (&) al final del comando o del script que queremos ejecutar, éste se ejecutará en segundo plano.

$ ./my-shell-script.sh &
[1] 10233

Si ejecutamos un comando de la forma habitual (en primer plano o foreground) y, después de pasado un cierto tiempo, nos damos cuenta que hubiera sido mejor ejecutarlo en segundo plano o background, lo podemos hacer sin necesidad de tener que matar el proceso y volver a ejecutarlo de nuevo con el ampersand. Esto se hace presioando "CTRL+Z" para suspender la ejecución del comando actual, y después invocando el comando bg.

$ ./my-shell-script.sh
^Z
[2]+  Detenido                my-shell-script.sh

$ bg
[2]+ my-shell-script.sh &

Este proceso que se acaba de pasar al segundo plano, también se puede volver al primer plano con el comando fg.

$ fg 2
my-shell-script.sh

nohup y &

Al finalizar una sesion en un terminal se envía un signal (SIGHUP) a todos los procesos que esté ejecutando nuestro usuario. Como resultado, dichos procesos se mueren (aunque les hayamos puesto & al final)

Para evitar esto utilizamos el comando nohup. Este comando hace que un proceso ignore la señal SIGHUP, y redirige la salida de nuestro script a un archivo nohup.out que es creado en el directorio actual.

$ nohup ./my-shell-script.sh &

Una buena practica sería redireccionar stdin, stdout y stderr. Básicamente, por dos razones: i) rastrear la salida de nuestro script en caso de producirse algún error, y ii) evitar problemas al terminar nuestra sesión ssh, si es que la ejecutamos en un servidor remoto.

$ nohup ./my-shell-script.sh > foo.out 2> foo.err < /dev/null &

Esta opcion es muy útil cuando necesitamos ejecutar un proceso largo y no nos interesa saber nada de él hasta que finalice. Podemos desconectarnos irnos, regresar al día siguiente y analizar el resultado del proceso.

screen

Si invocamos un comando en segundo plano (usando nohup y &), éste se ejecutará incluso después de que cerremos nuestra sesión. Pero, en ninguno de los casos anteriores, podemos conectarnos a la misma sesión otra vez y ver exactamente qué es lo que está pasando en la pantalla, como si no nos hubieramos desconectado. Para lograr esto, usaremos el comando screen.

El primer paso es ejecutar el script que necesitamos como parametro del comando screen.

$ screen ./my-shell-script.sh

Si después de ejecutar la linea anterior tecleamos “CTRL+A d”, el sistema nos separara de la sesión actual (en la que estamos ejecutando my-shell-script.sh) y nos retornará a la terminal a la espera de teclear un nuevo comando.

Llegados a este punto, podemos cerrar la sesión, irnos, regresar, iniciar una nueva sesión y recuperar la pantalla (screen) que esta corriendo nuestro script. Para ello, invocaremos el comando screen con el parámetro -ls para obtener un listado de las sesiones actuales:

$ screen -ls
[detached from 1788.ttys000.milleniumfalcon]

A continuación, mediante el parámetro -r y el identificador de la sesión recuperamos la pantalla que necesitemos:

$ screen -r 1788.ttys000.milleniumfalcon

¿Qué opcion usar?

Bueno, pues eso dependerá de cada caso, habrá veces que con el ampersand será suficiente y otras en las que tenemos que optar por una opción diferente. Para saber más acerca de nohup y screen recomiendo leer las páginas del manual.

Fuentes

3 maneras de ejecutar comandos en segundo plano en linux