Desde que surgió node, estaba deseando que hubiera una herramienta como RVM para instalar nodejs. Resulta que la hay!!! Al igual que RVM, requiere cURL. Por cierto, se llama n

1
2
3

 curl -o /usr/local/bin/n https://raw.githubusercontent.com/visionmedia/n/master/bin/n
 chmod +x /usr/local/bin/n
 n lts

Instala hasta npm!

En debian, otra manera de hacer esto, es usando el repo oficial que provee node:

1
2
3

 curl -sL https://deb.nodesource.com/setup | bash -
 aptitude update
 aptitude install nodejs

Acuérdate que algunos paquetes (por no decir que los más usados) requieren compilar librerías. Así que no olvides instalar build-essential.

Es un gran mojón tener que generar un certificado para cada servicio. Y aquí, en el 5to infierno de infomed usar cualquier proveedor de CA gratis (como let’s encrypt) es por gusto.

En estos caso, no queda otro remiendo que usar un CA firmado localmente. La idea es.

Generamos un par de claves que harán la función de “autoridad certificadora”

• crear un Clave Privada (.key) y mantenerla bien escondida
• crear la Clave Pública del anterior (.pem) y la distribuimos

Una vez que tengamos nuestra autoridad certificadora. Empezamos a generar certificados y lo firmamos con esta.

• generamos una clave privada (el .key para este certificado)
• hacer una solicitud de certificado (.csr) al .key anterior
• generamos el dichoso certificado
• firmamos el certificado usando el .key de la CA

Usaremos al tan legalmente controversial OpenSSL para esta tarea.

La clave (.key) del CA, debe crearse en una máquina desconectada de la red y preferiblemente sepultada a 3 metros bajo tierra. Si esto le parece demasiado paranoico, entonces mantenga el “.key” en el servidor más aislado de la red. Preferiblemente, aquel que parezca menos importante y lejos de internet. En mi caso, yo uso mi laptop personal para tareas administrativas y es ahí donde tengo todas las claves privadas.

Supón que lo hagas en un servidor determinado. Creamos entonces en el home del root, un espacio adecuado para esto.

1
2
3

 mkdir -m700 CA
 cd CA
 unmask 077

Creamos la super-secretísima clave privada, que hará la función de CA:

openssl genrsa -out rootCA.key 2048

1
2
3
4
5

 [lazaro@artema CA]$ openssl genrsa -out rootCA.key 2048
 Generating RSA private key, 2048 bit long modulus
 ..............................+++
 .......................................................+++
 e is 65537 (0x010001)

Ya tenemos la piedra angular de nuestro CA; pero así no sirve. Esa es la clave primaria, o sea, la que tiene la facultad de descifrar y derivar nuevos certificados. No nos conviene que nuestros “usuarios finales”, o lo servidores, usen esta clave. Necesitamos crear una “clave pública”, esta clave pública se deriva de la privada, pero solo tiene la facultad de cifrar, así la puede tener cualquiera y mandarnos datos cifrados. Sin embargo, NO se puede usar la clave pública para DEScifrar. Al menos no; usando tecnología civil.

Nota para los imbéciles: El rootCA.key no se le puede dar a nadie.

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.pem

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

 [lazaro@artema CA]$  openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.pem
 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]:CU
 State or Province Name (full name) [Some-State]:Havana
 Locality Name (eg, city) []:Plaza
 Organization Name (eg, company) [Internet Widgits Pty Ltd]:Calixto Garcia
 Organizational Unit Name (eg, section) []:Calixto Garcia
 Common Name (e.g. server FQDN or YOUR name) []:Hospital Calixto Garcia
 Email Address []:ssl@hcg.sld.cu

Ya tenemos la clave pública (el “.pem”). Este fichero será distribuido a nuestros clientes para que puedan hacer dos cosas: Cosa 1, cifrar los datos, sin poder descifrarlos. Cosa 2, identificar a la autoridad certificadora.

1
2

 [lazaro@artema CA]$ ls
 rootCA.key  rootCA.pem

Nota para los imbéciles: El rootCA.pem se instalará en los clientes, navegadores, teléfonos, etc…

Note además, que hemos dado a nuestra clave pública, 10 años antes de su caducidad (-days 3650). Quizás quieras darle un solo.

Ya puedes hacer público el “.pem” para que todo el que sepa que hacer con este, se lo instale. Por ejemplo, si tienes una intranet local, podrías dejarla con http plano y brindar información (así como la descarga) sobre el dicha clave. Puedes crear una página de HTML plano explicando porque SSL y como instalarlo en los navegadores. Ahí dices además, que se debe iniciar la conexión usando el prefijo “https”. Podrías poner esa página como el destino de redirección para todos los virtualhsot que usen “http” y así hacer conciencia a los usuarios. Por ejemplo, en servidores con información sensible (como los webmails), solo debe ser alcanzado usando ssl.

Pero sin extremismos. Una intranet que brinda información pública, no tiene que ser obligado por SSL (a menos que sea un wordpress con login).

Por cierto, Firefox tiene su propio almacén de certificados. Dirígete a Configuraciones, Avanzada, Certificados.

Una vez ahí, ve a donde dice Autoridades (no a tus certificados) y procede a importar el certificado.

En android también es tremenda balasera instalar el “.pem” y no dejará de meterme miedo diciendo que “un tercero podría estar manipulando tu información”. Lo cual no deja de ser cierto, poner un SSLbumper a squid bataría para hacer horrores.

Llégate a la configuración de seguridad y verás una opción que dice “instalar certificados desde la tarjetaSD” o “desde el almacenamiento”.

En algunos android 4, si te pide una clave y no sabes cual es, debes configurar el acceso al teléfono mediante clave. O sea, quita el patrón, pon una clave y prueba importar el “.pem”. Al pedir la clave pones la que estableciste para entrar. Una vez importado el certificado, vuelves a poner el mecanismo de seguridad que deses (patrón, ninguno, etc…)

de vuelta al servidor secreto

Pasemos ahora a crear uno (o varios) certificados para nuestros servidores. Para empezar, crearemos el certificado del servidor de correo, pero no del smtp, si no del webmail.

MUY IMPORTANTE en los certificados, el CN (Common Name) no puede ser el que te de la gana a tí. Si por ejemplo tu servidor de correo está en webmail.dominio.cu, ese ha de ser su CN

Nota para los imbéciles: Creas un certificado para cada servicio y su CN será el mismo nombre del virtualhost.

Creamos una clave privada para este servidor (para que pueda cifrar, te requiero que es bilateral y simétrico).

openssl genrsa -out webmail.key 2048

1
2
3
4
5

 [lazaro@artema CA]$ openssl genrsa -out webmail.key 2048
 Generating RSA private key, 2048 bit long modulus
 .+++
 ......................................................................................+++
 e is 65537 (0x010001)

Le pedimos a esta clave que genera un certificado (certificate request).

openssl req -new -key webmail.key -out webmail.csr

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

 [lazaro@artema CA]$ openssl req -new -key webmail.key -out webmail.csr
 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]:CU
 State or Province Name (full name) [Some-State]:Havana
 Locality Name (eg, city) []:Plaza
 Organization Name (eg, company) [Internet Widgits Pty Ltd]:Calixto Garcia
 Organizational Unit Name (eg, section) []:Calixto Garcia
 Common Name (e.g. server FQDN or YOUR name) []:webmail.hcg.sld.cu
 Email Address []:ssl@hcg.sld.cu
 
 Please enter the following 'extra' attributes
 to be sent with your certificate request
 A challenge password []:
 An optional company name []:

Ya tenemos las dos máquinas enigmas listas, pero no están sincronizadas y por ende, los cifrados producidos producidos por estos dos ficheros, serán simétricos pero no bilaterales. Alguien debe decirle que son padre e hijo.

Eso lo haremos, firmando con nuestro CA, el certificado generado.

openssl x509 -req -in webmail.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out webmail.crt -days 3650 -sha256

1
2
3
4

[lazaro@artema CA]$ openssl x509 -req -in webmail.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out webmail.crt -days 3650 -sha256
Signature ok
subject=C = CU, ST = Havana, L = Plaza, O = Calixto Garcia, OU = Calixto Garcia, CN = webmail.hcg.sld.cu, emailAddress = ssl@hcg.sld.cu
Getting CA Private Key

Note como hacemos uso de las claves pública y privada del CA. Por tanto, si un atacante adquiere los certificados del webmail y los colocase en otro sitio, este no machea el CN webmail.hcg.sld.cu y desata una advertencia en el navegador de nuestros usuarios. Además, no podrá firmar el certificado para modificarlo e incluir su CN.

1
2

[lazaro@artema CA]$ ls
rootCA.key  rootCA.pem  rootCA.srl  webmail.crt  webmail.csr  webmail.key

Bueno, todo listo, hagamos un paquete con todo lo necesario para que nuestro servidor de correo se lo configure en el webmail. Para postfix y para dovecot, debemos hacer otro que machee smtp.hcg.sld.cu y pop3.hcg.sld.cu sucesivamete.

REPITO! el rootCA.key NO puede hacerse público. Así que le daremos una copia del rootCA.pem

1
2
3
4
5
6
7
8
9
10

 [lazaro@artema CA]$ mkdir webmail
 [lazaro@artema CA]$ mv webmail.* webmail/
 [lazaro@artema CA]$ cp rootCA.pem webmail/
 [lazaro@artema CA]$ tar cvfz webmail.tar.gz webmail/
 webmail/
 webmail/webmail.crt
 webmail/webmail.csr
 webmail/webmail.key
 webmail/rootCA.pem
 [lazaro@artema CA]$ scp webmail.tar.gz root@webmail.hcg.sld.cu:/root/

Instálale esos certificado a tu apache/nginx y todo el que tenga el rootCA.pem instalado en su dispositivo; verá a “Calixto Garcia” como una legítima autoridad certificadora al abrir el webmail.

Lo que si no me queda claro es como se le instala el “.pem” a Windows. ¿Sugerencias?

Aquí les dejo el script que uso para hacer esto de forma automatizada. Para correrlo cree un directorio. Por ejemplo:

1
2
3

 mkdir miCA
 cd miCA
 mkcert.sh

Al correrlo la primera vez te creara el rootCA.pem, luego al correrlo con argumentos, se generan certificados para dichos dominios.

1
2
3

 mkcert.sh fulanito.dominio.cu
 ...
 echo fulanito.dominio.cu.tar.gz está listo para despachar

Te devolverá un .tar.gz con todo dentro.

La miseria, es lo único que; aun repartida a muchos, toca en abundancia. Esta historia se desarrolla en un policlínico remoto y olvidado; donde tuve que facturar con un 50% de descuento para que dejaran de decir “por favor ayuda”.

La superioridad tecnológica de XenServer es indiscutible: seguro (esquema de pacheo de XOA), versátil (la XAPI), robusto (CentOS) y sencillo (Xen Orchestra Appliance) y enterprise (next, next, next, install, boot, ready!) PERO:

Cuando los megas de RAM se cuentan con los dedos de una mano, el peso de la XAPI y la necesidad de tener otra máquina corriendo para el XenOrchestra, DUELEN. Tomemos por ejemplo, una máquina con 2 gigas de RAM. En mi caso tengo Xen Orchestra en la laptop, pero desplegar node+servidor en una máquina virtual más; no es una opción en este escenario. Que se jodan XOA, XenServer y los capitalistas de la Citrix ¡Hora de ser completamente libre!

Yo hubiera matado la jugada con LXC pero el cliente insiste en usar los 3 sistemas; tal como está en mi esquema del calixto. Lo cierto es que 3 contenedores no inspiran mucha confianza. Tampoco KVM es una buena opción, sobre todo cuado no hay un super microprocesador.

Rercordemos que: Xen, mejor con CPU, pero peor IO. Mientras que: KVM, mejor IO, pero CPU más penalizado.

El menú:

Dos interfaces de red, un disco de 500G, 2G de ram, y un CPU que por suerte soporta virtualización. Un switch de 24 puertos a 100 megas, otro a gigabit. Un friki que oye reguetton, una enfermera de post-guardia (la mujer del friki) y 5 pesos de café en un vaso plástico.

Las VM y su RAM:

• debian como servidor de correo (postfix y dovecot, sin webmail) - 512M
• alpine como ruter (dns, dhcp y firewall) - 512M
• FreeBSD como proxy (squid) - 1G

La brujería:

Con suerte No se matarán por los 2 Gigas de RAM. El squid con usuarios PAM como autenticación y casi nada en las ACL, además en BSD no come mucha ram. Alpine es un chiste en lo que a RAM se refiere y el de correo no tendrá un webmail así que plin.

Los 3 servidores tendrán unos cortafuegos super estrictos. Descartarán todo tipo de ICMP para evitar cuellos de botella. La LAN funciona a 100 megas y el servidor está conectado al ÚNICO switch a gigabit. Osea, el server, un switch y un cable al netgear viejo que está a 100 megas. Con eso, la difusión “uno a varios” será mayor y no habrá congestiones, mientras que la peticiones entrantes (individual) no excederán el 10% el ancho de vianda del servidor. La ley del embudo.

Entrando en materia:

Volvemos a la génesis de xen pero usaremos virt-manager para manejar el hypervisor.

Primero que todo, llevamos a cabo una instalación típica de Xen en un debian 8. Nada que contar; el clásico Dom0.

1
2
3

 aptitude update
 aptitude install xen-linux-system
 dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen

Esta PC tiene dos interfaz de red. Una de cara al router, con una ip/29 “públicas” y otra interfaz, de cara a la LAN. Por tanto crearemos 3 puentes:

• br0 de eth0 hacia el router
• br1 de eth1 hacia la LAN
• br2 para comunicación interna (costumbre, nunca está de más)

Así me quedó el /etc/network/interfaces

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

 # arriba todo el mundo
 auto lo eth0 eth1 br0 br1 br2

 # el lo
 iface lo inet loopback

 # levanta las dos interfacess
 # pa cuando el bridge se levante
 iface eth0 inet manual
 iface eth1 inet manual

 # puente de la interfaz onboard (WAN)
 iface br0 inet static
    bridge_ports eth0
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0

 # puente de la interfaz PCI (LAN)
 # y la ip del hypervisor para hacer SSH
 iface br1 inet manual
    address 192.168.99.10
    netmask 255.255.255.0
    bridge_ports eth1
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0

 # una interfaz de red local de las VM
 # note que el puente apunta a la interfaz none
 iface br2 inet static
    bridge_ports eth0
    address 169.254.0.1
    netmask 255.255.255.0
    bridge_ports none
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0

Ahora vienen los toques mágicos. Libvirt!

1

 apt-get install libvirt-bin

De más está que te diga, que este debian fue instalado sobre LVM. Crea el directorio /etc/libvirt/storage/ y dentro, le pondremos un fichero llamado xenvg.xml o comotedelagana.xml. Al instalar con el particionado guiado; el grupo llama hostname-vg, en este caso xen-vg. Note como la cláusula path, apunta hacia el mapper del grupo de volumen group y que tanto nombre del fichero como del pool; no deben contener espacios ni “-”.

1
2
3
4
5
6

<pool type='logical'>
  <name>xenvg</name>
  <target>
    <path>/dev/xen-vg</path>
  </target>
</pool>

Ahora inicializaremos el pool de libvirt:

1
2
3

 virsh pool-define /etc/libvirt/storage/xenvg.xml
 virsh pool-start xenvg
 virsh pool-autostart xenvg

Corre virsh pool-info xenvg para ver si todo pinchó. Llegado a este punto te recomiendo reiniciar…

De regreso a la máquina del informático…

Arrancamos el virt-manager:

De más está que te diga, que las operaciones de libvirt se hacen por ssh, así que debes tener ssh en la máquina remota; preferiblemente con autenticación por llaves y no por password.

1
2

 ssh-keygen
 ssh-copy-id root@192.168.99.10

Vamos a File y Add connection, agregaremos una conexión del tipo Xen.

De aquí en adelante, es la misma mecánica básica de virt-manager. Solo quiero hacer un apartado para crear un pool más y me refrito a un pool donde pondremos los ficheros “.iso”.

Creamos el directorio donde meteremos los ISO y copiamos el iso que querramos para allá. Como ya me conocen, soy el enemigo de las plantillas. Confío más en lo que yo mismo hago que en lo que hacen otros.

1
2

 ssh root@192.168.99.10 mkdir /opt/isos/
 scp ~/Downloads/ISO/*.iso root@192.168.99.10:/opt/isos/

Selecciona la conexión al Xen, y haz click en el botón de crear nueva máquina.

El asistente nos llevará al gestor de almacenamiento. Seleccionamos “Local install media” y click en siguiente. Luego “Use ISO image”.

Aquí haces click en Browse y te conduce al lugar donde crearemos los ISO. Inmediatamente te verás en la pantalla donde te pedirá que selecciones los storage volume. En la imagen se puede apreciar que ya existe uno llamado “iso”, pero de igual, para el ejemplo mostraremos como se creará.

Odio las interfaz visual, como hacen pasar trabajo! Pero virsh no es cosa jamón para mi cliente que no es del todo un hacha en linux.

Bueno… has click en el signo de más color azul y te mostrará un dialogo que muestra “Create Storage Pool”. Lo nombramos “iso” y le decimos que será del tipo “dir”. O sea un directorio común en el sistema de archivos.

Como segundo argumento, nos pedirá la ruta. Le daremos la que creamos en el servidor, en este caso /opt/isos.

Sí todo salió bien, verás los .iso que tiene el directorio.

Al hacer click en el iso seleccionado, vuelve el asistente y muestra que se usará dicho iso.

Lo demás es pa mongo, la RAM el disco que creamos en el SR “default”, etc…

Marcamos el check que dice “Customize configuration before install” y caeremos en la pantalla que muestra todos los detalles de la máquina.

Esta pantalla es importante; no permite configurar de manera más exquisita el hardware. Por ejemplo, las interfaces de redes, yo quiero que tenga como primera interfaz, la que apunta a br0 y como segunda, la que apunta a br2. Además, algunas veces la máquinas traen una wacom tablet como interfaz (mariconerías del virt-manager).

En fin, así me quedó la mía.

Un otorrino me ha dejado sorprendido cuando me pidió que le instalara ArchLinux en su laptop (las todos tenemos de los médicos). La primera vez le instalé fedora, pero lo quitó y volvió pidiéndome que le instalara arch. El doctor Bershard, me cuenta las epopeyas de los usuarios de linux en la red de la habana.

Durante el proceso de “que te instalo” me mencionó “el tiwol” como un juego muy importante. No me imaginé que sería tan fascinante. Similar al minimilitia de android. Me di cuenta que crear un server, es lanzar un comando y dejarlo funcionando. La gente se conecta y desconecta del servidor cuando quiera. Se pueden jugar partidas de equipo, pero la más caliente es el “death match”. Entra mata un rato y sale cuando te aburras.

En el calixto el jueguito causó furor (está para windows y se conecta perfectamente). A cada rato entro y me encuentro 3 o 4 con nombres cada vez más creativos matándose a tiros y dando brincos.

Según la documentación, al correr teeworlds_srv -f fichero.cfg cargará ese fichero. Muy útil para crear múltiples modos de juego. Al lanzar el comando teeworlds_srv noté que dice:

1
2
3
4
5

[58db3577][storage]: using standard paths
[58db3577][storage]: added path '$USERDIR' ('/home/lazaro/.teeworlds')
[58db3577][storage]: added path '$DATADIR' ('/usr/share/teeworlds/data')
[58db3577][storage]: added path '$CURRENTDIR' ('/home/lazaro/.teeworlds')
[58db3577][console]: failed to open 'autoexec.cfg'

Así que al crear el fichero /home/lazaro/.teeworlds/autoexec.cfg resultó que se cargaba solo. Pero… ¿qué metemos ahí?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#
# teeworld_srv -f este_fichero.cfg
#

# Los mapas y la secuencia de mapas
#
# ls /usr/share/teeworlds/data/maps/
sv_map dm7
sv_maprotation dm7 dm6 dm2 dm9 md8 dm1

# como se ve el servidor
sv_name Masacre en el Calixto
sv_motd "las teclas son «a», «d» y Espacio"

# que tipo de juego jugamos
sv_gametype dm
sv_scorelimit 30
sv_timelimit 0

# configuración del servidor
bindaddr 0.0.0.0
sv_register to 0

# permite usar la consola remota
sv_rcon_password secretisimo

Dice: Jugaremos una ronda de 30 puntos, sin límite de tiempo, que empieza por el mapa “dm7”.

El comando sv_maprotation recibe como argumento la lista de mapas. Cada vez que termine una ronda, se cambiará el mapa.

Más información en el sitio de teeworlds www.teeworlds.com

Cuando usamos XenOrchestra, aveces sucede que teniendo un XenServer con “muchas” máquinas virtuales, al crear una nueva; se crea como Paravirtualizada (PV) y no como Virutalización por Hardware (HVM). Nos damos cuenta porque arrancar la máquina buteando de una unidad óptica es casi imposible.

Algunos creen que es porque XenServer impone un límite. Esto no es cierto, ya que XenServer es completamente gratuito hoy en día. Simplemente, asume que el servidor está muy cargado y que una PV es más ligera. En mi experiencia creo que XenOrchestra es el que hace eso; no xenserver como tal. También influye la plantilla que utilices para crear una nueva VM.

Cuando esto pase, simplemente tomas la máquina y le dices que se pase a HVM. Lo haremos seteando un parámetros que involucre HVM.

1

 xe vm-param-set uuid=uuid-de-la-maquina HVM-boot-policy="BIOS order"

Al setearle que el orden de buteo será el que diga el bios y listo. La máquina pasa a ser HVM.

Aún recuerdo que algunos clientes me preguntaban con mucho asombro: “-y porque no roundcube”; cuando hablábamos de webmail. Pero finalmente rainloop se ha puesto de moda en cuba.

Un método bastante perezoso de instalar una LAMP en Debian, es instalar el paquete phpmyadmin. Esto instala y configura el servidor SQL; además de hacer jugar a apache2 con php y mysql, todo de un solo teclazo. Pero aveces, por ejemplo, al instalar RainLoop, no queremos que phpmyadmin quede instalado. Una buena variante es desinstalarlo después; pero nos quedan algunos paquetes innecesarios instalados.

Para lograr la armonía que buscamos, instalaremos la LAMP por partes. Primero apache SOLO.

1

 aptitude install apache2

Ahora instalamos mysql, a través de los metapaquetes, para que se instale el adecuado de manera automática.

1

 aptitude install mysql-server mysql-client

Llegado a este punto, debian y su magia te ayudarán a configurar el mysql, pidiéndote la contraseña del root. Ahora instalamos la piedra angular. El soporte de php+mysql de apache.

1

 aptitude install php5 libmysqlclient-dev php5-mysql

Instalamos el resto de la paquetería necesaria para rainloop.

1

 aptitude install curl libcurl3 libcurl3-dev php5-curl php5-json

Ahora reinicia tanto apache como mysql.

1
2

 systemctl restart mysql
 systemctl restart apache2

Crearemos un par de bases de datos necesarias para rainloop. Puedes o no crear un usuario para rainloop, pero si vamos a tener un servidor sql con dos bases de datos para una aplicación; la cual además, será la única cosa sql en el servidor; no vale la pena crear otro usuario. Lo dejo a tu elección.

1
2
3
4

create database rainloop;
create database contactos;
commit;
exit;

Si de todas maneras quieres crear el usuario.

1
2
3
4

create user rainloop@localhost identified by "rainloop";
grant all privileges on rainloop.* to rainloop@localhost;
flush privileges;
exit;

Y vamos a instalar rainloop! La manera clásica de hacerlo es usando el paquete “.zip” del sitio. Si quieres llégate allá y bájatelo. Descomprimes en un directorio y sigue las instrucciones; sin embargo hay otra manera.

1
2
3

mkdir -p /var/www/rainloop
cd /var/www/rainloop
curl -s http://repository.rainloop.net/installer.php | php

Si tienes acceso a internet de verdad. Pinchará. Si estás detrás de un proxy, te jodiste, hazlo a la manera ortodoxa.

Rainloop es fulísima con los permisos. Si no los tienes claros, dará unos palos horribles que no tienen nada que ver con permisos aparentemente. Por ejemplo, si el fichero que dice la versión, no pertenece al usuario que corre el servidor web, te dirá que no puede encontrar el directorio “data”. Espectacular! Para evitar eso, solo los directorios tendrán el ejecutable. Además, todo pertenecerá al usuario www-data; que en debian es el usuario que usa el apache para correr.

1
2
3

chown -R www-data:www-data .
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

No te pondré como hacer el virtualhost porque eso no tengo que explicártelo (no te hace falta verdad?). Te recomiendo que uses SSL.

No olvides entrar al admin panel (o al fichero de configuración) de rainloop y pasarle la mano. Para abrir el admin panel, usa la url /?admin. Ahí configura las bases de datos. Muy importante habilitar el soporte de contactos y especificarle la base de datos, que creo, no debe ser la misma que rainloop; aunque una gente me dijo que tiene ambas cosas en la misma base de datos; yo no le he probado.

El usuario por defecto es admin y la contraseña es 12345. De más está que te diga: CÁMBIALO!

Si estás de cara a internet, recuerda que rainloop viene con yahoo y gmail configurado como servidores por defecto. No sé si está habilitados pero chequéalo. Juraría que hay versiones en que venía habilitado. De todas formas, te interesará que tus usuarios tengan gmail/yahoo más cerca, especialmente si un usuario tiene múltiples identidades. Recuérdales que deben habilitar el acceso pop en su cuenta de gmail.