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.
Buscar
CategorÃas
Nube de tags
champions sidenotes bsd linux frases hack blog ssh films update mac tip blogs deportes conciertos san_froilan apple freebsd lugo lucux bash seguridad bake futbol ibook rsidenotes ds 2007 felicidades ubuntu programación cms alemania_2006 openbsd barça soccer humor mundial juegos macosx rfilms nintendo iphone beers cakephp personal copa userlinux games blogsfera 2008 cake opinion meme debian web cumpleaños php mysql league
Ú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
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:
CVS: primeros pasos
Hay quien dice que el uso de un servidor de versiones cuando el número de desarrolladores tiende a uno es injustificado, es posible que tengan razón pero llevo algunos años con la doble tarea -programar y versionar- y creo adecuado delegar responsabilidades en algo más fiable que yo.
Asà que he tomado la decisión de probar CVS. Antes de ir corriendo a por unos algodones para los oidos intentaré explicar el motivo de usar estas siglas y no otras. Lo primero que se me ocurre es que OpenBSD lo trae de serie. ¡Correcto! la máquina que versionará mi código fuente es un pez globo. Entiendo que pueda parecer demasiado cómodo, pero para no haber usado nunca un sistema de control de versiones y poder evaluar la utilidad del mismo es más que suficiente.
Asà que he tomado la decisión de probar CVS. Antes de ir corriendo a por unos algodones para los oidos intentaré explicar el motivo de usar estas siglas y no otras. Lo primero que se me ocurre es que OpenBSD lo trae de serie. ¡Correcto! la máquina que versionará mi código fuente es un pez globo. Entiendo que pueda parecer demasiado cómodo, pero para no haber usado nunca un sistema de control de versiones y poder evaluar la utilidad del mismo es más que suficiente.
Dudando por un nuevo muro
Es posible que sea el momento adecuado de hacer reflexión y volver a levantar el muro. Me refiero a la máquina más importante de la red local, la que reparte conexión, filtra y se come los deshechos orgánicos del resto del mundo.
Reciclemos, en dicha máquina hay varios servicios que llevan 1 año -desde la visita del amigo Juanjo- en funcionamiento y no se han explotado demasiado, léase ftpd, proxy e incluso httpd. Otros -servicios/aplicaciones- como symon, symux, snort y cacti serán caso de estudio, porque o no se han acabado de configurar eficientemente o no se están usando como debieran.
Reciclemos, en dicha máquina hay varios servicios que llevan 1 año -desde la visita del amigo Juanjo- en funcionamiento y no se han explotado demasiado, léase ftpd, proxy e incluso httpd. Otros -servicios/aplicaciones- como symon, symux, snort y cacti serán caso de estudio, porque o no se han acabado de configurar eficientemente o no se están usando como debieran.
Secure by default
OpenBSD es un Sistema Operativo cuya filosofÃa (tanto de uso como de desarrollo) se centra en la seguridad. Theo de Raatd ha descubierto recientemente el segundo bug remoto en la instalación por defecto durante los últimos 10 años.
Se trata de un buffer overflow del kernel en alguna parte del código (mbuf) que toca IPv6, pudiendo deshabilitarse fácilmente en PF a través de una regla 'block in inet6' o aplicando el correspondiente parche en sys/mbuf.h.
Ahora el slogan: OpenBSD, toda una garantÃa de seguridad.
Se trata de un buffer overflow del kernel en alguna parte del código (mbuf) que toca IPv6, pudiendo deshabilitarse fácilmente en PF a través de una regla 'block in inet6' o aplicando el correspondiente parche en sys/mbuf.h.
Ahora el slogan: OpenBSD, toda una garantÃa de seguridad.
Muchos grupos, muchos permisos
Ayer durante el curso -si, docente de nuevo- me plantearon una duda que hizo tambalear mis (repito, mis) cimientos de Software Libre (los cuales no están tan arraigados como debieran). Un usuario con -supongo- conocimientos en otros sistemas operativos propietarios se quedó dubitativo mientras intentaban comprender propietarios y permisos en *nix.
Despues de ver que un archivo tiene los permisos clasificados en su usuario propietario (u), grupo propietario (g) y otros (o) surgió la temida pregunta: ¿Y si tengo 3 ó 4 grupos y quiero dar distintos permisos a cada uno?. Pensadlo, porque chown, chmod y chgrp no solucionan esa papeleta (que yo sepa).
Despues de ver que un archivo tiene los permisos clasificados en su usuario propietario (u), grupo propietario (g) y otros (o) surgió la temida pregunta: ¿Y si tengo 3 ó 4 grupos y quiero dar distintos permisos a cada uno?. Pensadlo, porque chown, chmod y chgrp no solucionan esa papeleta (que yo sepa).
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: