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.
Buscar
Categorías
Nube de tags
beers mac php iphone tip userlinux champions frases lucux bash blog league cumpleaños conciertos rsidenotes mysql 2008 mundial ssh 2007 personal lugo linux futbol nintendo blogsfera cake web films update juegos cakephp opinion san_froilan seguridad freebsd programación blogs deportes copa humor bake hack ibook bsd ubuntu ds macosx meme debian games alemania_2006 felicidades macbook rfilms sidenotes openbsd apple barça cms
Últimos comentarios
Webs amigas
Archivo
Year 2010
Year 2009
Year 2008
Year 2007
Year 2006
Year 2005
Year 2004
Year 2003
Year 2002
Promo
Links de interés
Uptime: New world record
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!.
Jugando con mailq
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.
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.
FreeBSD: Arrancando Postfix
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:
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:
Courier Authlib (de nuevo)
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.
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.bakNada 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 ;).
Arreglando pkgdb
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 -aFOQVaya, era previsible tener algo roto después de tanto tiempo. A ver si obtenemos más información de lo que ocurre realmente:
Cambios de portupgrade
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:
Bloqueando ssh bruteforce con PF
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:
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:
Packet Filter en FreeBSD
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.