Si instalaste ubuntu 11.04 (natty) y no te gustó nada, como a mi, Unity, hoy te voy a explicar paso a paso como instalar y dejar funcionando Gnome 3 en Ubuntu. Antes de nada te recomiendo que mires el video de youtube que he colgado de mi escritorio en funcionamiento por si tienes alguna duda (Aclaro que los fallos que se ven de recuadros azules, blancos y zapatazos son efectos del capturador. El escritorio va fluido y sin fallos)

Antes de comenzar a instalar debo aclararte que no puedes echar atrás. Si instalas Gnome 3 te quedarás sin posibilidad de volver a utilizar la sesión con Unity. De modo que toda la responsabilidad corre por tu cuenta y no me hago responsable de la pérdida de ningún dato o configuración del equipo. Dicha esta pequeña aclaración vamos a ponernos manos a la obra. Voy a asumir que ya tienes instalado Ubuntu 11.04. Este tutorial no es válido para ubuntu 10 o inferiores.

Añadiendo el ppa e instalando

sudo add-apt-repository ppa:gnome3-team/gnome3
sudo apt-get update && sudo apt-get dist-upgrade
sudo apt-get install gnome-shell

Instalando la herramienta de Tweaks

sudo apt-get install gnome-tweak-tool

Una vez instalado todo esto vamos a reiniciar e iniciar la sesión por primera vez. Tenemos dos alternativas. Una es que funcione genial a la primera y otra es que vaya como el culo. En el segundo de los casos puede deberse a la configuración de pantalla (o si tienes un driver de ATI por ejemplo, he visto que va fatal. Con el de Nvidia va de lujo. En el caso que tengas estos problemas toca la config de pantalla o piensa en resignar el driver privativo de la tarjeta de video).

Ahora vamos a instalar el tema por defecto, tan bonito, de Gnome 3 “Adwaita”

sudo apt-get install gnome-themes-standard

Una vez instalado presionamos, vamos a actividades en la esquina superior izquierda y empezamos a escribir “tweak”. Veréis que rápidamente sale la herramienta que instalamos en el paso 2. La ejecutamos

Para poder volver a poner los botones de Maximizar, minimizar y cerrar, vamos a “Shell” y en la opción “Arrangement of buttons on the titlebar” seleccionamos el valor “All”

En “interface” activamos “menus have icons” y “buttons have icons” para que quede un poquito más bonito. En Gtk theme elegimos “adwaita” y en icon theme el que nos guste. Yo tengo humanity-dark

Para recuperar el gestor de archivos en el escritorio (ver los iconos en el escritorio de nuestro gnome 3), vamos a “File manager” y activamos ambas opciones. Uno renderea el nautilus en el desktop y el otro nos permite poner fondos de pantalla bonitos.

Una vez realizados todos los cambios, presionamos Alt + F2 y nos aparecerá la ventana para escribir un comando. Escribimos una “r” sin comillas, que lo que hace es recargar el shell de Gnome y actualiza los cambios. Ya podemos ir al escritorio y cambiar el fondo y ver nuestros archivos y directorios.

Apagar el sistema

Por defecto, la vista del menú no nos da la opción de “Apagar” como tal sino que tenemos por defecto cerrar sesión y suspender. Para poder ver la opción de apagar tenemos que situar el puntero sobre suspender y presionar la tecla “Alt” de la izquierda. Se cambiará el valor por “Apagar”

Personaliza los estilos

Una cosa que me ha parecido sorprendente es que se puede tocar el estilo de Gnome a través de CSS (si, css!). Todo lo podemos encontrar en el archivo /usr/share/gnome-shell/theme/gnome-shell.css

Si queremos editarlo, nuevamente presionamos Alt + F2 y dentro de la ventana de comandos introducimos

gksu gedit  /usr/share/gnome-shell/theme/gnome-shell.css

Nos pide la contraseña de root y nos abre Gedit para editar el fichero. Por ejemplo si queremos cambiar el exagerado tamaño de los iconos que nos aparecen en las “aplicaciones” dentro de actividades

Lo que vamos a hacer es abrir las CSS con el paso anterior y buscar /* Apps */ y veremos algo como

/* Apps */

.icon-grid {
spacing: 18px;
-shell-grid-item-size: 118px;
}

.icon-grid .overview-icon {
icon-size: 96px;
}

Si no tenemos conocimientos de CSS os dejo como lo puse yo

/* Apps */
.icon-grid {    spacing: 30px;    -shell-grid-item-size: 84px;}
.icon-grid .overview-icon {    icon-size: 64px;}

Simplemente es reemplazar lo existente por lo que os dejo yo. Uno reemplaza al otro íntegramente. Nuevamente Alt + F2 y escribimos “r” para recargar (sin las comillas, solo una r).

Quitando algo de basura

Como podréis observar cuando entramos a Aplicaciones dentro de actividades, nos topamos con absolutamente todos los iconos. Esto es así porque podemos comenzar a escribir cualquier cosa y nos encuentra directorios, aplicaciones y archivos. A mi personalmente me atormenta ver tantas cosas, de modo que he quitado algo de basura del listado. Os comento que si dais click derecho sobre cualquiera de ellos y seleccionas “Añadir a favoritos” nos lo va a ubicar en la barra lateral izquierda de actividades para un acceso rápido junto a las aplicaciones que están en ejecución.

Volvamos a limpiar. Para poder quitar aplicaciones del listado necesitaremos el antiguo editor de menús que usábamos en gnome 2. Para esto abrimos un terminal y escribimos el comando “alacarte” sin las comillas. Se nos abre la siguiente ventana

Allí simplemente es añadir o quitar. Incluso podemos crear accesos directos a otras aplicaciones no listadas desde “Elemento nuevo”

El tray de aplicaciones

Antiguamente el tray de aplicaciones tipo pidgin y manejador de Wifi se encontraba en la esquina superior derecha. Ahora está en la esquina inferior derecha. Para verla tenemos que acercar el puntero hacia dicha esquina y nos aparece en un efecto de transparencias muy elegante.

Cuando terminemos todos nuestros cambios podemos cerrar la sesión y volver a iniciarla seleccionando “Gnome Shell” o algo así (no lo tengo en la mente exactamente como es. Todas las demás menos la consola de recuperación no van a funcionar).

AUXILIO, mi escritorio no arranca y se queda todo bloqueado al siguiente inicio de sesión

He podido comprobar que a veces si tocamos alguna cosa rara o nos ponemos a experimentar demasiado, puede que al siguiente inicio de sesión Gnome no arranque. Recuerda que aún están en desarrollo y no es lo estable que Debian quisiera De modo que no vamos a perder los nervios, aunque si nuestros cambios. Si se queda bloqueado, reiniciamos el equipo manualmente y en la pantalla de login elegimos como sesión de inicio la consola de recuperación (recovery console). Una vez en ella hacemos sudo su y luego nos situamos en nuestro home. Algo asi

$ sudo su

# cd /home/munix

Una vez en nuestro home vamos a tener que borrar las configuraciones de Gnome para que vuelva a arrancar. Alto! esto es sólo si algo sale mal y no arranca, no vayas a hacerlo si todo ha salido bien. Para esto y sobre nuestro directorio home hacemos

rm -r .gnome .gnome2 .gconf .gconfd

Damos a exit en la consola dos veces (una para salir del su y otra para cerrar la sesión) y volvemos a iniciar la sesión normal de Gnome.. y tendremos que volver a configurar todo, incluso la wifi, pero ojo, esta vez te recomiendo no llegar hasta el punto que provocara el fallo

Un saludo a todos, espero que os sirva!

Publicaciones relacionadas que recibes por Yet Another Related Posts Plugin.

Hace un largo tiempo que google lanzó AppEngine. Yo la verdad que esperaba ese lanzamiento muy impaciente, hasta que me enteré que únicamente aceptaba JAVA y Phyton (o primero uno y luego el otro, da igual). El caso es que nunca llegué a más que darme de alta y generar un nuevo perfil de aplicación.

Hoy por fin me he puesto las pilas y me he dispuesto a probar ejecutar PHP sobre AppEngine utilizando el proyecto Quercus. El resultado? http://munixapp.appspot.com/

Está bien para ejecutar algunas sentencias básicas de PHP pero se ve muy limitado,no por Quercus, sino por las políticas de seguridad del propio AppEngine.

Para llegar hasta donde he llegado, los pasos son los siguientes:

1- Regístrate en AppEngine

2- Descarga este archivo a tu ordenador y procede a descomprimirlo en un sitio que te venga cómodo

3- Dentro del directorio que descomprimiste vas a encontrar la ruta war/WEB-INF/. Allí edita el archivo appengine-web.xml y pon el nombre del proyecto que diste de alta en el paso 1

4- Descarga el sdk de java, por ejemplo, y utiliza el comando de consola

/dir_al_sdk_java/bin/appcfg.sh update /home/tu_dir/phpwithjava/war

para subir los archivos al servidor. Verás que /home/tu_dir/ es donde has descomprimido el archivo descargado en el paso 2. Dentro del directorio war van a estar todos los archivos php

Ten en cuenta que por defecto trae que el archivo principal al abrir el dominio sea index.html. Para editar esto vamos a war/WEB-INF/web.xml y buscamos la etiqueta <welcome-file>index.html</welcome-file> y le cambiamos el valor a index.php

Y listo! ya tienes funcionando php en AppEngine.

Nuevamente para realizar cambios sobre el proyecto (si borras o cambias o añades archivos) debes usar el comando appcfg.sh (para linux) o appcfg.cmd (win)

Espero que os haya servido

Publicaciones relacionadas que recibes por Yet Another Related Posts Plugin.

Muchas veces nos encontramos con la necesidad de trabajar entre dos estaciones linux en modo no interactivo (algún script que se tenga que conectar vía SSH desde una máquina a otra, realice algo y se desconecte). Como dije, si lo hacemos de manera interactiva no tendremos problemas ninguno de escribir la clave. De cualquier manera también nos puede ayudar a agilizar trabajo si, a pesar de que nos conectamos de manera interactiva, lo hacemos muy a menudo y con varias máquinas.

Entones la idea es generar una llave pública en nuestra estación y añadirla al listado de llaves conocidas del equipo destino. Vamos a ponernos manos a la obra. Los pasos son sencillos y voy a suponer que ssh está funcionando perfectamente en ambas máquinas.

Generar las llaves en el equipo local

Vamos a entender por “equipo local” al pc desde el cual nos conectaremos hacia el otro. Para generar las llaves vamos a entrar al sistema del equipo local con el usuario que tendrá los permisos de conexión con el equipo remoto. En mi caso mi equipo local es “Pantera” y mi usuario es “munix”, entonces:

munix@Pantera:~$ ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/home/munix/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/munix/.ssh/id_rsa.

Your public key has been saved in /home/munix/.ssh/id_rsa.pub.

munix@Pantera:~$ scp /home/munix/.ssh/id_rsa.pub munix@Extreme:/home/munix/

munix@Pantera:~$ ssh munix@Extreme

munix@Extreme:~$ cat /home/munix/id_rsa.pub >> /home/munix/.ssh/authorized_keys

Publicaciones relacionadas que recibes por Yet Another Related Posts Plugin.

Ya que estoy por la labor de documentar un poco y hacer mini how-to, paso a comentar los pasos para “instalar” con éxito CakePHP en un sistema Debian/Ubuntu/Similar GNU/Linux asumiendo que tenemos permisos de sudo

Descargando y descomprimiendo

Primero que nada descargamos y descomprimimos el paquete:

munix@pantera:~# wget http://cakeforge.org/frs/download.php/735/cake_1.2.5.zip/donation=complete

Esto nos descarga el archivo en formato zip pero con el nombre “donation=complete”. Vamos a renombrarlo para hacer las cosas bonitas

munix@pantera:~# mv donation\=complete cake.zip

Ahora vamos a descomprimir con el comando unzip. Si no lo tenemos instalado podemos hacer un apt-get install unzip antes.

munix@pantera:~# unzip cake.zip

Tendremos la salida algo como “cake_1.2.5″ (dependiendo de la versión que descarguemos). Borramos el zip.

munix@pantera:~# rm cake.zip -rf

Y ahora copiamos los archivos al DocumentRoot de nuestro dominio, supongamos /var/www/sites/miapp

munix@pantera:~# cp ./cake_1.2.5/* /var/www/sites/miapp/ -rf

Por último borramos el directorio cake_1.2.5

munix@pantera:~# rm cake_1.2.5 -rf

Configurando Apache

Voy a asumir que tenemos instalado Apache 2, perfectamente configurado. Es muy importante para Cake el uso de mod_rewrite, de modo que si no lo tenemos cargado lo podemos hacer de la siguiente manera (ubuntu):

munix@pantera:~# a2enmod rewrite

Si no tenemos el comando a2enmod podemos cargarlo a mano creando el enlace simbólico

munix@pantera:~# ln -s /etc/apache2/mods-available/rewrite.load /etc/apache2/mods-enabled/rewrite.load

Ahora debemos comprobar que en el bloque <Directory> correspondiente a nuestro VirtualHost tengamos el AllowOverride en All. Sino luego cuando intentemos usar el mod_rewrite no tendremos éxito alguno. Además en este mismo archivo tendremos que redefinir el DocumentRoot

Para ello podemos hacer

munix@pantera:~# nano /etc/apache2/sites-enabled/tudominio.conf

Lucirá como esto

<VirtualHost *:80>

ServerName www.miapp.com

DocumentRoot /var/www/sites/miapp

<Directory /var/www/sites/miapp>

Options Indexes Includes FollowSymLinks MultiViews

AllowOverride None

Order allow,deny

Allow from all

</Directory>

</VirtualHost>

Buscas el AllowOverride y lo cambias a All. Además en el DocumentRoot deberemos cambiar la ruta por /var/www/sites/miapp/app/webroot que es donde Cake tiene el .htaccess

Como detalle, si trabajamos en local, podemos cambiar el ServerName por un dominio que quieras, por ejemplo local.miapp.com, luego lo apuntaremos a nuestra IP de loopback

Luego grabas los cambios con Ctrl+X seguido de un y para confirmar.

Si cambiaste el ServerName, te tocará editar el archivo /etc/hosts

munix@pantera:~# nano /etc/hosts

Y añadimos una línea que sea como la siguiente:

127.0.0.1   local.miapp.com

Salimos guardando cambios. Esto nos hará que cuando pongamos en el navegador el dominio local.miapp.com nos apunte a nuestra máquina en vez de intentar resolver el nombre por los DNS de nuestro proveedor de internet.

Ahora recargamos la configuración del Apache del siguiente modo:

munix@pantera:~# /etc/init.d/apache2 force-reload

Otorgando permisos

Por defecto cuando instalamos (por ejemplo en ubuntu) el apache desde el Synaptic lo hacemos con el usuario www-data y el grupo www-data. Ahora nos importa el grupo, puesto que el usuario que uses para editar los archivos de cake lo meteremos al grupo www-data. Supongamos que nuestro usuario es “munix”, entonces hacemos:

munix@pantera:~# usermod -g munix www-data

Ahora sólo nos resta cambiarle el dueño al directorio “miapp” y darle algunos permisos necesarios para las Cache de Cake:

munix@pantera:~# chown munix:www-data /var/www/sites/miapp -R

munix@pantera:~# chmod 777 /var/www/sites/miapp/app/tmp -R

Probando en el navegador

Está claro que no hemos configurado nuestra base de datos, no hemos creado ni un modelo, controlador, vista… nada, pero si vamos al navegador y ponemos la url deberíamos tener algo como esto:

Si todo ha salido bien deberíamos ver la página por default de Cake, con todos sus estilos, colores, etc. Si la vemos sin colores es que estamos teniendo problemas con el rewrite.

Espero que os haya servido

Publicaciones relacionadas que recibes por Yet Another Related Posts Plugin.

Con este “how to for dummies” hoy vamos a crear un repositorio con subversion en un sistema debian (o ubuntu) GNU/Linux.

La necesidad

La idea en la que voy a basar este tutorial es la siguiente:

Tenemos un servidor web con apache. Dentro de un directorio de los que usa apache para sus virtual hosts vamos a tener nuestra versión de producción de la aplicación y dentro de otro vamos a tener una versión de pruebas. Por otro lado, en este mismo servidor vamos a instalar el demonio svnserve, crearemos nuestro repositorio y, finalmente desde nuestro ordenador de casa tendremos nuestro entorno de desarrollo.

La idea es que nosotros desarrollemos en nuestro ordenador y lo subamos al repo. Posteriormente vamos a descargar dichos archivos del repo a nuestro directorio de pruebas sobre el que vamos a realizar todos los test antes de hacer el checkout al directorio de producción.

Instalar subversion

Para instalar svnserve en nuestro servidor nos logueamos en él y vamos a crear un directorio donde estará nuestro repo y luego instalaremos:

munix@pantera:~# mkdir /home/repos

munix@pantera:~# apt-get install subversion

Una vez que termine de instalar lanzaremos el demonio

munix@pantera:~# svnserve -d -r /home/repos

Ahora vamos a crear nuestro repositorio con el comando “svnadmin”. A nuestra app le llamaremos “app_ejemplo”:

munix@pantera:~# svnadmin create /home/repos/app_ejemplo

Y listo! ya tenemos creado nuestro repositorio para nuestra “app_ejemplo”.

Checkout en nuestro equipo

Ahora desde nuestro ordenador elegimos el cliente SVN que más nos guste (a mi me gusta Smart SVN o RapidSVN. Éste último es verdaderamente “rapid” ) y realizaremos nuestro primer checkout. Para ello nos solicitará la URI del repo y un directorio en local donde almacenar los archivos.

La URI será algo como lo siguiente: svn+ssh://user@server:/home/repos/app_ejemplo

Donde reemplazaremos “user” por un usuario con privilegios en el servidor y “server” por el nombre del host. Nos solicitará la contraseña de “user” y hará el primer checkout. Como no hemos subido archivos al repo no descargará nada.

Subiendo los primeros archivos al repo

Cuando hicimos el primer checkout con nuestro cliente, nos solicitó un directorio donde almacenar los archivos. Como no tenemos nada en el repo, vamos a subir nuestro primer archivo llamado “index.php”, asumiento que desarrollaremos nuestra app en PHP. Se puede subir cualquier tipo de archivos. Entonces en el directorio donde descargamos el repo creamos nuestro index.php. Ahora vamos al cliente y le damos a “Add” para que incluya el archivo a la cola para subir. Finalmente a ese archivo le damos un “Commit” y se quedará al repo

Descargando nuestro repo en el directorio de pruebas

Supongamos que nuestra url de pruebas es http://test.dominio.com y que el subdominio “test” en nuestro server corresponde a /var/www/sites/test/

La idea es, como dije inicialmente, que desarrollemos en local, subamos al repo y luego descarguemos el repo en el directorio de pruebas antes de subir a nuestro entorno de producción.

Para descargar por primera vez el repo en el directorio de test tendremos que hacer un checkout (recordemos que a pesar de que apache y subversion están en el mismo equipo, es necesario descargar el repo al directorio de apache). Para esto hacemos algo como lo siguiente:

munix@pantera:~# cd /var/www/sites/test/

munix@pantera:/var/www/sites/test# svn checkout file:///home/repos/app_ejemplo/

Con esto ya tendremos descargado el repo y todo lo que hayamos subido desde nuestro equipo en el directorio de test. Para el de producción es igual pero cambiando el directorio.

Como dije antes, el paso anterior sólo se hace la primera vez. Ahora cada vez que queramos descargar los archivos o cambios que hicimos previamente en nuestro equipo, deberemos hacer un “Update”. Para esto, subimos o cambiamos nuestros archivos desde nuestro equipo local, los subimos al repo y desde el servidor hacemos:

munix@pantera:~# svn up /var/www/sites/test

Simplificando el Update

Si la ruta a nuestro directorio web es muy larga y queremos ahorrar un poco de tiempo en los updates, crearemos un enlace desde nuestro directorio home al directorio web de la siguiente manera:

munix@pantera:~# ln -s /var/www/sites/test test

Entonces ahora simplemente cada vez que hagamos un update, tendremos que escribir únicamente:

munix@pantera:~# svn up test

Al ser test un enlace a nuestro directorio web, el resultado será el mismo

Y con esto hemos terminado este mini how-to. Si quieres aprender un poco más acerca de todo el abanico de posibilidades que te ofrece subversion, puedes visitar este enlace.

Publicaciones relacionadas que recibes por Yet Another Related Posts Plugin.