Apuntes de Software Libre

Receta para conectarnos a un servidor remoto con clave privada en pocos pasos …

Un poco de info previa siempre va bien

#> man ssh-keygen ssh-keygen -t rsa

// crear las claves

#> ssh-keygen ssh-keygen -t rsa

// Comprobamos que nos ha creado las claves

#> cd .ssh/
#> ls


más info:

man ssh-copy-id

// Copiamos la clave al servidor remoto con ssh-copy-id

#> ssh-copy-id -i id_rsa.pub root@192.168.183.10
root@192.168.183.10's password:
Now try logging into the machine, with "ssh 'root@192.168.183.10'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

// Comprobamos qué todo va:


#> ssh root@192.168.183.10 cat .ssh/authorized_keys
ssh-rsa AAAAB3NzwC1yc2EwAAABIwwAAQEA3pkJUOlAwpvw
DHUxZjNiI+Kfwrfesp8PhweAQ0csszQl5lwHFO97pqrdbSXNU+BG
OFUzTZ5u5y6LzHo6Fx+xDWObU1HFN+r4lTLaEMxfHheGWyhW
LyajS8uWqec9Ya84poFyZ8DhIlYZo91cyLOKZ696PY3TeNeyi6e4+
cUs5I60dCmR5NQHbCsfCesy44igpU17+yev3tHqxo5fAvbCBDnLj3T
Mdettkj65NqYvrIqHBq38zsDxPMLKeCRxIT5K1vq9ejGw0XrHpW/GD
McTBVr9h9NUV11aNVZ6sHEnnqKU/pvdIxGm0yPhFUL+cJlvRbtijnC
Mv7dLynQNPDkUrQ== user@host

//listo

También se puede editar a mano el fichero .ssh/authorized_keys y pegar ahi nuestra clave.

La idea es crear un sencillo sistema de backups de las tablas mysql en disco de manera que después podamos usar rsync para poder hacer las copias.
Los objetivos son:
que las copias las haga un usuario de sistema sin privilegios especiales.
que el usuario myql tenga los minimos privilegios necesarios posibles.
via mysqldump y cron
contraseñas fuera del script.
que nos avise si hay errores via mail.

UPDATE: Actualización del script para seleccionar todas las bases de datos y no hardcodearlas. 25.08.2010

1.- Creamos el usuario y le damos password.
El dir /home/backup/mysql nos servirá de repositorios para los backups. Como el usuario no necesita shell nos aseguramos de ponerle /bin/false como shell.

nahia:~# useradd -c "usuari backup mysql" --home-dir /home/backup --create-home --shell /bin/false backupusr
nahia:~# pass backupuser


Ahora crearemos el usuario de mysql con los privilegios justos y necesarios para poder hacer backup de todas las bases de datos. Estos son LOCK_TABLES y SELECT, nada más.


mysql> GRANT LOCK TABLES, SELECT ON *.* TO 'backupuser'@'localhost' IDENTIFIED BY 'pipipopo';
Query OK, 0 rows affected(0.03 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)


Para poder ejecutar mysqldump sin password en el script deberemos crear un fichero ~/.my.cnf con el siguiente contenido.


.my.cnf
[client]
user=backupuser
pass=pipipopo


Crearemos en /home/backup/bin/backup-mysql.sh :

Este script se ejecutará cada dia a las 01:00 am via cron:


# Backup de mysql cada dia a las 01:00 am.
0 1 * * * /home/backup/bin/backup-mysql.sh 2>&1 >/dev/null


Instalación de la wifi del ibook g4.
http://linuxwireless.org/en/users/Drivers/b43#fw-b43-new

Si la documentación ya lo explica paso a paso yo que más puedo decir.

Por fin me he decido a gestionar yo mismo el dns de los dominios que tengo. Los servicios de dns que usado, aunque normalmente no me han dado demasiados problemas, son un poco engorrosos y no te dan la libertad que tienes al hacerlo tú mismo.

El primer problema que nos encontramos al gestionar un servicio que ofreceremos a internet es el de la seguridad y Bind y el DNS es un servicio con comunes problemas de seguridad con lo que hay que tener el máximo cuidado posible. La instalación de Bind en un chroot no es complicada una vez conoces los pasos adecuados y la gestión es idéntica a su instalación normal. Así que por el mismo precio lo instalamos en una jaula.

No voy a explorar el tema de bind y el firewall, quizás para otra ocasión.

El primer paso es instalar los paquetes de nuestra distribución Debian .

nahia:~# aptitude install bind9 bind9-doc dnsutils

Esto habrá instalado la última versión disponible en nuestro sistema, pararemos el servicio de dns para poder cer los cambios y crear el chroot.

nahia:~# /etc/init.d/bind9 stop

Crearemos la estructura de directorios del chroot y haremos al usuario bind dueño de estos directorios.

nahia:~#mkdir -p /var/chroot/bind9/{etc,dev,var/cache/bind,var/run/bind/run}
nahia:~# chown -R bind:bind /var/chroot/bind9/var/*

Con mknod crearemos los devices que necesitaremos y le daremos los permisos adecuados:

nahia:~# mknod /var/chroot/bind9/dev/null c 1 3
nahia:~# mknod /var/chroot/bind9/dev/random c 1 8
nahia:~# chmod 666 /var/chroot/bind9/dev/{null,random}

Ahora copiaremos la configuración previa (si la teníamos) a la estructura del chroot:

nahia:~# mv /etc/bind /var/chroot/bind9/etc
nahia:~# ln -s /var/chroot/bind9/etc/bind /etc/bind

De esta manera podremos seguir configurando bind como lo hacíamos hasta ahora.

Nos toca crear la parte de configuración de log. En mi caso, estoy usando Debian Lenny, la versión testing de Debian en el momento de escribir estas notas. Debian ha cambiado syslogd por rsyslog.
Nota: en el sistema donde hice la instalación, una debian testing “dist-upgradeada” desde la stable “etch” tuve que instalar rsyslog a mano.

Crearemos el siguiente fichero:

nahia:~# vi /etc/rsyslog.d/bind-chroot.conf

con el siguiente contenido:

$AddUnixListenSocket /var/chroot/bind9/dev/log

Ahora sólo nos queda indicarle al arranque de bind cómo arrancar:

Dejaremos el fichero /etc/default/bind9 así:

OPTIONS=”-u bind -t /var/chroot/bind9″
# Set RESOLVCONF=no to not run resolvconf
RESOLVCONF=yes

Con esto le estamos diciendo que arranque bind con el usuario (-u) bind con pocos privilegios y (-t) el directorio del chroot. Si el nombre del group al que pertenece bind es diferente del usuario -u bind tendremos que especificarlo también con (-g).

Ya podemos arrancar el servicio y veremos si todo ha ido bien:

nahia:~# /etc/init.d/bind9 start
Starting domain name service…: bind9.

nahia:~# ps -ef | grep named
bind 8577 1 0 19:15 ? 00:00:00 /usr/sbin/named -u bind -t /var/chroot/bind

Ya está, ya tenemos instalado bind9 en un entorno chroot. La configur
ación de las zonas y de los esclavos lo dejo para otros artículos.

La primera vez que tuve que montar un servidor con más de una tarjeta de red me volví loco para reconocer qué tarjeta era la eth0, cual la eth1, etc…

Los nombres de las tarjetas se asignan según se cargan por el kernel, y el resultado de la asignación puede cambiar en cada arranque…

Si tenemos dos tarjetas con diferente chip y los tenemos compilados como modulos en el kernel podemos forzar el orden poniéndolos en el /etc/modules o bien compilando uno de los drivers estaticamente en el kernel y el otro como módulo, así se cargará primero el que está como estático y se le asignará eth0 a su interfaz.

Si tenemos dos tarjetas con el mismo chip no podremos saber cual se carga primero a simple vista, para solucionarlo tenemos las reglas del udev en el fichero persistent-net.rules88 que podemos crear a mano o como ha sido mi caso lo puede hacer la instalación de la Debian.

dani@belyj-bes:~$ cat /etc/udev/rules.d/z25_persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x14e4:0x4320 (bcm43xx)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:11:XX:XX:XX:XX", NAME="eth1"


NOTA: Cada regla tiene que ir en una única línea!! Aquí por falta de espacio las líneas se cortan y las he marcado con una barra \ que no debe aparecer en el fichero de configuración

¿Qué es un servidor MX Backup?
Un servidor MX Backup es un servidor de correo que se encargará de recibir el correo de nuestro servidor MX primario cuando este no sea accesible, guardarlo en su cola y reenviarlo a nuestro servidor cuando este esté de nuevo disponible. Cuando un servidor smtp envía un correo a otro servidor mirará los registros DNS del dominio destino para saber quien es el responsable de la gestion del correo.

Vemos por ejemplo quienes son los servidores MX (Mail eXchanger) de gmail:


dani@belyj-bes:~$ dig -t MX gmail.com

; < <>> DiG 9.3.2 < <>> -t MX gmail.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 36740 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 8 ;; QUESTION SECTION: ;gmail.com. IN MX ;; ANSWER SECTION: gmail.com. 1745 IN MX 5 gmail-smtp-in.l.google.com. gmail.com. 1745 IN MX 10 alt1.gmail-smtp-in.l.google.com. gmail.com. 1745 IN MX 10 alt2.gmail-smtp-in.l.google.com. gmail.com. 1745 IN MX 50 gsmtp163.google.com. gmail.com. 1745 IN MX 50 gsmtp183.google.com.

... IN MX (número) fqdn
El número indica la prioridad del servidor, cuanto más bajo sea el número la prioridad será más alta.

¿Qué tenemos que hacer para configurar nuestro MX Backup?

1) Dar de alta el registro MX para nuestro servidor MX Backup.
2) Configurar Postfix en el servidor backup para que acepte los correos para nuestro dominio.

1) Dar de alta el registro MX para nuestro servidor MX Backup.
Deberos añadir los siguientes registros en nuestro DNS:


...
mydomain.com. IN MX 10 mail.mydomain.com.
mydomain.com. IN MX 20 mail.backupdomain.com.
...

(NOTA) Los puntos detras de los nombres de dominio son necesarios

2) Configurar Postfix en el servidor backup para que acepte los correos para nuestro dominio.

En /etc/postfix/main.cf:


...
relay_domains = $mydestination, mydomain.com#*dominio para el cual hacemos de MX Backup.
relay_recipients_maps = #**Buzones para los que aceptamos correo en el MX Backup.

(*)# Si hacemos de MX Backup para varios dominios nos interesara utilizar un fichero con los nombres.
relay_domain = $mydestination, hash:/etc/postfix/domains_backup
# Y en este fichero:

domain1.com
domain2.com
domain3.com


** Aquí nombraremos los buzones, cuentas, … del dominio al que hacemos de backup. ¿Para qué? Puesto que no podremos comprobar si la cuenta existe en el servidor primario tendremos que indicarles cuales son la cuentas válidas o aceptar todos los correos y ponerlos en cola, incluso direcciones del tipo: adaa232323saglrr@mydomain.com

O bien dejamos la línea como en la configuración anterior, con lo que aceptaremos todos los correos, o bien utilizaremos un fichero de texto como hash:

relay_recipients_maps = hash:/etc/postfix/relay_recipients
En este fichero:
user1@domain.com valor
user2@domain.com valor
@domain.com valor
...
El campo valor es necesario aunque postfix no lo utilza, podemos poner cualquier cosa: X, OK, YES, etc…

Esta configuración es suficiente. Un par de apuntes:

a) El tiempo máximo que nuestro backup va a mantener los correos en la cola intentando que enviarlos al servidor primario se ve reflejado en la directiva: “maximal_queue_lifetime” y por defecto es de 5d. Si sabemos que nuestro servidor va a estar inactivo por un período más largo deberíamos ponerle un valor más alto.
#postconf |grep maximal
maximal_backoff_time = 4000s
maximal_queue_lifetime = 5d


b) Si sabemos que el servidor primario ya está disponible y queremos enviar de golpe todos los emails en la cola:

#postqueue -s mydomain.com

Bibliografia MUY recomendada
Documentación de Postifx.
Postfix: The definitive Guide.

Objetivo: Montar un servidor de dhcp en nuestro router:
hardware: En este ejemplo tenemos un ordenador con GNU/Linux instalado y dos tarjetas de red, eth0 y eth1, las cuales conectaremos a las redes 192.168.1.0/24 y 192.168.254.0/24 respectivamente, esta última la gestionaremos nostros mediante dhcp.

Software a instalar: Instalaremos el servidor dhcp3-server que viene en nuestra distribución Debian:

#> aptitude install dhcp3-server
Y respondemos a las preguntas.

El dhcp3 tiene 3 ficheros importantes:

1) /etc/default/dhcp3-server
Aquí indicamos en que interfaces escuchará nuestro servidor dhcpd. En nuestro ejemplo:

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
# Separate multiple interfaces with spaces, e.g. “eth0 eth1”.
INTERFACES=”eth1″

2)/etc/dhcp3/dhcpd.conf

El fichero más importante, donde pondremos toda la información del servidor que vamos a servir:

—dhcpd.conf—

#Opciones globales _antes_ de definir las redes. Estas opciones se aplicarán a #todas las redes que definamos si en ellas no se especifican estos valores.

ddns-update-style none; #Si tenemos un DNS podemos actualizarlo dinámicamente: DDNS, en este ejemplo no se trata esta configuración.
option domain-name "darlinx.lan"; #El dominio que enviaremos
option domain-name-servers 80.58.0.33, 80.58.32.97; # Los DNS para el cliente
default-lease-time 600;
max-lease-time 7200;
authoritative; #Authoritative si nuestro servidor dhcp es el primario para la red.

#Tenemos que definir TODAS las redes a las que nuestro servidor está conectado, independientemente de si serviremos ip en ellas o no. En el ejemplo la red 1.0/24 es la conectada a la eth0.

subnet 192.168.1.0 netmask 255.255.255.0 {
}

#Ahora definimos la red de eth1 donde Sí que serviremos ips.

subnet 192.168.254.0 netmask 255.255.255.0 {
range 192.168.254.10 192.168.254.20; # el rango de ips a servir.
option routers 192.168.254.1; # el gateway para los clientes
}
# Hay más opciones, pero las más interesante están _ya_ definidas en sección global con lo que no hace falta definirlas aquí si no van a cambiar.

#Por último, si queremos asignar alguna ip estática a algún ordenador de la red:

host diablica {
hardware ethernet 00:00:00:00:00:00;
fixed-address 192.168.254.2;
}


3)/var/lib/dhcp3/dhcpd.leases

contiene información sobre las ips que ha concedido, a qué máquina, cuando, mac address, etc. Este fichero no debemos editarlo a mano. Dejo un extracto como ejemplo…

—extracto de dhcpd.leases—

lease 192.168.254.19 {
starts 1 2006/07/31 10:18:29;
ends 1 2006/07/31 10:28:29;
binding state active;
next binding state free;
hardware ethernet 00:90:96:25:f1:XX;
client-hostname “diablica”;
}

Escenario: Queremos usar nuestro ordenador con dos tarjetas de red para que sirva de pasarela a otros ordenadores de nuestra red local:

Los podemos hacer en dos sencillos pasos:

1.- Activamos el ip_forwarding del Kernel:

#> echo 1 > /proc/sys/net/ipv4/ip_forward

Aplicamos una regla en iptables para hacer masquerading:

#> iptables -t nat -A POSTROUTING --src $nuestra_red -o $iface_inet -j MASQUERADE

cambiamos $nuestra_red por el rango de ip’s a los que queramos hacer nat e $iface_inet por la interface de red conectada a internet: p.ej eth0.

Con esto es suficiente. Si queremos que los cambios sean permanentes podemos escribir un script en Bash para iptables que cargue estas y o otras reglas en cada inicio.

script_fw.sh
——————
#!/bin/bash
#script para compartir una conexión a internet.

#Definimos las variables
EXIF=”eth0″
INIF=”eth1″
LOCAL_NET=”192.168.254.0/24″

## Borramos las reglas que pudieran haber cargadas anteriormente.
iptables -F
iptables -X
iptables -Z
iptables -t nat -F

## Definimos las políticas por defecto
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT

#Activamos el ip_forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

#Hacemos NAT
iptables -t nat -A POSTROUTING -s $LOCAL_NET -o $EXIF -j MASQUERADE

#Permitimos que los paquetes en la tabla FORWARD salgan de la red
iptables -A FORWARD -i $INIF -o $EXIF -j ACCEPT

#Permitimos las conexiones a la red interna si han sido establecidas previamente desde nuestra red.
iptables -A FORWARD -i $EXIF -o $INIF -m state –state RELATED,ESTABLISHED -j ACCEPT

——– end of script———-

Objetivo:
Queremos instalar en nuestra Debian el servidor Web Apache para servir varios dominios desde una sola ip.

Instalamos el servidor Apache2 y sus dependencias:

#aptitude install apache2 apache2-common

La configuración de Apache2 en Debian está, cómo no, en el directorie /etc/apache2:

#/etc/apache2$ ls

apache2.conf conf.d envvars httpd.conf magic mods-available mods-enabled ports.conf README sites-available sites-enabled ssl

La función de cada fichero está explicada brevemente en el fichero README que podemos ver.

Debian incluye sus propias herramientas para activar y desactivar tanto sitios web como módulos. Si miramos, por ejemplo, en sites-enabled, veremos que son enlaces a sites-available.

a2ensite-> Activa un sitio web.
a2dissite-> Desactiva un sitio web
a2enmod-> Activa un módulo de apache disponible en mods-available.
a2dismod->Desactiva un módulo.

Apache viene con la típica página “Placeholder” por defecto para que podamos ver que se ha instalado correctamente el servidor. Vamos a desactivarla:

#a2dissite default

y recargamos apache:

#/etc.initi.d/apache2 reload

Ahora iremos a /etc/apache2/sites-available y haremos dos copias del fichero default que nos servirán como base para nuestros sitios.


#cp default sitio1.org
#cp default sitio2.org

y crearemos en /var/www las carpetas para guardar nuestras páginas:

#mkdir -p /var/www/sitio1.org /var/www/sitio2.org

Editaremos cada unos de los ficheros de configuración de sites-available de la siguiente manera:

#sitio1.org#

NameVirtualHost 192.168.1.3 –>ip del ordenador, igual en todos
los virtualhosts

<VirtualHost 192.168.1.3>
ServerName sitio1.org -> Nombre del servidor
ServerAdmin webmaster@sitio1.org

DocumentRoot /var/www/sitio1.org
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/sitio1.org>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
< /Directory>

…

#sitio2.org#
NameVirtualHost 192.168.1.3
<VirtualHost 192.168.1.3>
ServerName sitio2.org
ServerAdmin webmaster@sitio2.org

DocumentRoot /var/www/sitio2.org
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
&lt,Directory /var/www/sitio2.org>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

Ahora activamos los dos sitios:

#a2ensite sitio1.org
#a2ensite sitio2.org

Tendremos que recargar la configuración para que apache coja los cambios.

# /etc/init.d/apache2 reload

y miramos si la configuración de los virtualhosts está bien:

#apache2 -S

VirtualHost configuration:
192.168.1.3:* is a NameVirtualHost
default server sitio1.org (/etc/apache2/sites-enabled/sitio1.org:2)
port * namevhost sitio1.org (/etc/apache2/sites-enabled/sitio1.org:2)
port * namevhost sitio2.org (/etc/apache2/sites-enabled/sitio2.org:2)
Syntax OK

Todo correcto, ya podemos comprobar si realmente funciona. Si no hemos dado de alta sitio1.org y sitio2.org en un servidor de DNS para hacer pruebas podemos editar el /etc/hosts para que las peticiones a esos dominios vayan a nuestros servidor:

192.168.1.3 sitio1.org sitio2.org

Aquí el enlace para configurar Amarok contra la base de datos MySQL, muy importante si nuestra colección de música tiene ya unas medidas importantes.
Enlace al wiki oficial de Amarok.