Tag freebsd - Userlinux.net

Cuaderno de bitácora, 22:46. Esto es una locura, el único equipo sobremesa que tengo por casa lleva desde las 14:30 -aproximadamente- compilando Gnome2 (en FreeBSD-7.0) y todavía no ha acabado.

Ni idea de lo que le queda pero teniendo en cuenta sus 256 Mb. de RAM y el gigahertzio con el que trabaja, es posible que se le haga la noche muuuy larga.

Luego si me encuentro con ánimo explicaré el motivo, pero dejo de administrar este pedazo de uptime y me apetecía fardar de ello:

# uname
FreeBSD
# uptime
 7:52PM  up 442 days,  8:29, 4 users, load averages: 0.04, 0.06, 0.02

¡Qué todo vaya bien en sus nuevas manos!.

Cuando falla la entrega en un servidor de correo lo lógico es que la cola se vaya llenando hasta reparar el problema. En ese momento las peticiones irán saliendo con cierto orden de prioridad. Hay varios comandos con los que podemos jugar para ayudar al servidor en el proceso de peticiones.

Con un poco de paciencia, conocimientos mínimos de bash y usando tanto mailq como postsuper (Postfix) podremos facilitar el flujo de correos encolados. Vamos a ello.

Hay circunstancias en las que un problema no se resuelve de la forma más eficiente. Suele ser bajo presión, cuando las cosas no se ven del todo claras y -sin motivo lógico- acaba funcionando con la condición no escrita de no tocarle más.

Algo así pasó hace tiempo en una FreeBSD, intentando reiniciar el servicio de correo (Postfix) no atendía a razones:

# /usr/local/etc/rc.d/postfix start
#

Rabia e impotencia se unían a la presión de tener colgado un servicio de varios cientos de clientes, indagando -deprisa y corriendo- por la sintaxis de postfix al final se solucionó con un inadecuado:

Increible, o como diría Andrés Montes: "dos de dos!... jugón!". Segunda actualización fuerte en la misma máquina y de nuevo falla el mismo paquete: courier-authlib.

Aunque esta vez he leido y repasado el /usr/ports/UPDATING creo que a alguien se le ha ido la mano con el principal fichero de configuración. Ahora la actualización machaca tus configuraciones y coloca unas por defecto. Cierto es que antes genera una copia de seguridad pero solo faltaría que se quedara tan ancho.

# ls -flash /usr/local/etc/authlib/authmy*
10 -rw-------   1 courier  courier   8.3K Oct  3 16:45 authmysqlrc
 2 -rw-------   1 courier  courier   521B Nov 17  2006 authmysqlrc.bak

Nada que cp/mv no arreglen pero aún así resulta molesto perder el control de esta forma. Tirón de orejas para oliver@freebsd.org ;).

Hay veces que FreeBSD también juega malas pasadas. Este ha sido el caso de una máquina dejada en el olvido. Estoy intentando recuperar su uso y ponerla al día. Me gusta utilizar portupgrade para estas tareas de mantenimiento, con lo que, -después de un make update- al hacer un listado de los paquetes que necesitaban actualizarse procedo con uno de ellos:

# portupgrade ruby-1.8.5_4,1
[Updating the pkgdb (format:bdb_btree) in /var/db/pkg ... /var/db/pkg/pkgdb.db: unexpected
file type or format -- Invalid argument; rebuild needed] [Rebuilding the pkgdb
(format:bdb_btree) in /var/db/pkg ... [Updating the pkgdb (format:bdb_btree) in /var/db/pkg ... /var/db/pkg/pkgdb.db:
unexpected file type or format -- Invalid argument; rebuild needed]
[Rebuilding the pkgdb (format:bdb_btree) in /var/db/pkg ... /var/db/pkg/pkgdb.db: unexpected file type or format -- Invalid 
argument: Cannot update the pkgdb!]: Cannot update the pkgdb!]
Command failed [exit code 1]: /usr/local/sbin/pkgdb -aFOQ

Vaya, era previsible tener algo roto después de tanto tiempo. A ver si obtenemos más información de lo que ocurre realmente:

En FreeBSD a veces pasa, después de un make update intentamos instalar un paquete del que creemos saber ubicación en el árbol de ports:

# cd /usr/ports/sysutils/portupgrade
/usr/ports/sysutils/portupgrade: No such file or directory.
#

¡¡Qué nooooo!! diría el bueno de Borat, ¡qué ya no está ahí!. Aunque si me fío del make search sigo en las mismas:

# cd /usr/ports/ ; make search name=portupgrade | grep Path
Path:   /usr/ports/sysutils/portupgrade
#

¿Habrán cambiado su ubicación?... malas costumbres las de no actualizar el índice de la base de datos local, pero como de todo se aprende:

Buena referencia de ayuda a la anterior entrada sobre Cacti.

Al hilo de la anterior entrada y buscando alternativas para bloquear todos esos ataques por fuerza bruta (bruteforce) al servicio de administración remota SSH he encontrado la solución ideal -o lo que más se le aproxima-, sin descartar las anteriores.

La regla mágica hace uso de una nueva característica de Packet Filter (desde OpenBSD-3.7) llamada max-src-conn-rate. Lo que venimos a decirle a nuestro firewall es que permita todas las conexiones ssh con la salvedad de que no se sobrepasen 3 intentos en menos de 30 segundos, en dicho caso se agregará la IP del atacante a una lista llamada ssh-bruteforce, en pf.conf:

Desde hace algún tiempo (Julio del 2003) el software de filtrado de paquetes más eficiente de todos los que conozco (olé la imparcialidad) ha sido portado a FreeBSD. Activarlo, dependiendo de la versión instalada, puede resultar no tan obvio como se desea.