Artículos de la fecha Enero 2008 ↓
Escrito por The Evangelist el 11 de Enero de 2008 y etiquetado como: Dynamips, MacPorts, Networking, OSX
En este artículo voy a mostrar como compilar Dynamip para Mac (tanto intel como PowerPC, ambas requieren MacPorts instalado) y para Linux Debian, pero es bastante sencillo compilar para cualquier otra plataforma y hay mucha documentación en internet.
Compilar para Mac OSX (Vía MacPorts):
Es lo más sencillo y cómodo ya que todo lo han hecho ya los chicos de MacPorts (gracias):
sudo port install dynamips
Compilar para Mac OSX (Power PC):
Primero creamos un directorio temporal:
mkdir dynamips
cd dynamips
Instalamos las librerías necesarias:
sudo port install libpcap
sudo port install libelf
y descargamos el source de dynamips (en este ejemplo la versión 0.2.8-RC2) y lo descomprimimos:
wget http://www.ipflow.utc.fr/dynamips/dynamips-0.2.8-RC2.tar.gz
tar xvfz dynamips-0.2.8-RC2.tar.gz
cd dynamips-0.2.8-RC2
Para poder compilar en PowerPC hay que realizar algunos cambios en el Makefile, aquí tenéis el patch:
--- dynamips-0.2.8-RC2/Makefile 2007-10-14 10:43:07.000000000 +0200
+++ Makefile 2008-01-11 01:03:01.000000000 +0100
@@ -3,7 +3,8 @@
# Replace x86 by amd64 for a build on x86_64.
# Use "nojit" for architectures that are not x86 or x86_64.
-DYNAMIPS_ARCH?=x86
+# DYNAMIPS_ARCH?=x86
+DYNAMIPS_ARCH?=nojit
# Change this to 0 if your system doesn't support RFC 2553 extensions
HAS_RFC2553?=1
@@ -62,8 +63,10 @@
DESTDIR=/usr
else
ifeq ($(shell uname -s), Darwin)
- CFLAGS+=-I/usr/local/include -mdynamic-no-pic -D_FILE_OFFSET_BITS=64
- LIBS=-L/usr/local/lib -L. -ldl -lelf -lpthread
+ LOCALBASE?=/opt/local
+ CFLAGS+=-I$(LOCALBASE)/include -I$(LOCALBASE)/include/libelf \
+ -I/usr/local/include -mdynamic-no-pic -D_FILE_OFFSET_BITS=64
+ LIBS=-L$(LOCALBASE)/lib -L/usr/local/lib -L. -ldl -lelf -lpthread
else
ifeq ($(shell uname -s), SunOS)
CFLAGS+=-I/usr/local/include -DINADDR_NONE=0xFFFFFFFF \
Una vez aplicado el patch al Makefile (o si lo prefieres descargalo Makefile ) podemos proceder a compilar:
make
Saldrán muchos warnings que realmente no sé que significan ni si es correcto ignorarlos, pero a pesar de todo el programa funciona de forma correcta.
Ya solo queda pasarle el comando strip para reducir el tamaño del ejecutable y ponerle permisos de ejecución.
strip dynamips
chmod +x dynamips
Compilar para Linux (Debian):
Primero creamos un directorio temporal:
mkdir dynamips
cd dynamips
Instalamos las librerías necesarias:
apt-get install libpcap0.8 libpcap0.8-dev
apt-get install libelf1 libelf-dev
apt-get install debhelper
y descargamos el source de dynamips (en este ejemplo la versión 0.2.8-RC2) y lo descomprimimos:
wget http://www.ipflow.utc.fr/dynamips/dynamips-0.2.8-RC2.tar.gz
tar xvfz dynamips-0.2.8-RC2.tar.gz
cd dynamips-0.2.8-RC2
Como dynamips viene preparado para construir un paquete .DEB, procedemos a realizar dicho paquete (a mi me hizo falta hace el chmod aunque no está de más hacerlo):
chmod +x debian/rules
dpkg-buildpackage
La versión que nos genera es la 0.2.8-RC2 pero como los fichero Debian no han sido modificados el fichero resultante tendrá como versión 0.2.6-RC2, es solo el nombre del fichero .DEB. También posiblemente nos dé algún warning, especialmente del fichero .DSC que podemos ignorar.
Para que el fichero nos indique la versión correcta debemos editar antes de compilar los 2 sigueintes fichero y poner la versión correcta:
vim debian/files
vim debian/changelog
Ya solo queda instalar (o actualizar) el paquete como otro cualquiera
cd ..
dpkg -i dynamips_0.2.8-RC2-1_i386.deb
Escrito por The Evangelist el 9 de Enero de 2008 y etiquetado como: Aplicaciones, OSX, TimeMachine
En Mac OS X 10.5 Leopard, Apple ha introducido Time Machine, una manera muy conveniente de hacer backups. Desafortunadamente el intervalo entre backups está prefijado de manera constante en una hora. Apple usa un “launchd daemon” para controlar este lapso, pero cambiando el valor de dicho intervalo en el fichero “launchd.plist” no surge efecto alguno.
TimeMachineScheduler desactiva la función automática de backup de Time Machine e instala su propio “launchd daemon”. Dado que dicho “daemon” se halla localizado en la librería principal, se requiere una contraseña de administrador para todas las operaciones (que conllevan escritura). Exceptuando la desactivación de Time Machine, ningún otro fichero o preferencia del sistema se ve afectado por TimeMachineScheduler.
Todavía existen algunos problemas concerniendo los privilegios de acceso en OS X 10.5 Leopard en aquellos casos en que el sistema operativo ha sido actualizado, migrado o instalado mediante la opción archivar e instalar. TimeMachineScheduler se encarga de todos los ficheros y fija el propietario, grupo y los privilegios a sus correctos valores por defecto.
Es posible instalar y desinstalar el “daemon” así como tan sólo cargarlo y descargarlo a fin de ejecutar backups puntuales. El intervalo puede ser prefijado entre 1 y 12 horas, y el “daemon” puede ser programado para ejecutarse adicionalmente al cargarlo, lo cual significa también al arrancar y ejecutar el “login”. Asimismo es posible presionar un botón para ejecutar un backup inmediato. El estado del temporizador se muestra en todo momento.
Durante la la ejecución de los backup, los elementos de control se hallan desactivados y toda acción es escrita en un dichero de log (/Library/Logs/TimeMachineScheduler.log).
TimeMachineScheduler no requiere ser ejecutado permanentemente, el temporizador funciona de forma autónoma en segundo plano. Si se quiere volver a la configuración original de Time Machine, tan sólo hay que desinstalar el temporizador y reactivar Time Machine en su Panel de Preferencias.
Para el peor de los casos (el cual no sucederá nunca) se incluye un desinstalador de “emergencia”.
Características:
- Intervalo definible entre 1 y 12 horas.
- Es posible ejecutar el backup manualmente o automáticamente, incluso a arrancar, entrar en la cuenta de usuario o cuando el “daemon” es cargado.
- Muestra el estado del “daemon”, del volumen de backup y si dicho backup está actualmente en progreso.
- Auto-montaje, una opción para montar y desmontar el volumen de backup automáticamente (ver problemas conocidos).
- Opción para ocultar el volumen de backup (requiere relanzar el Finder para que surja efecto).
Problemas conocidos:
Dado que TimeMachineScheduler funciona independientemente de las Preferencias de Time Machine, alguna información puede ser mostrada de forma errónea en el Panel de Preferencias de Time Machine.
Podría darse el caso que el volumen utilizado para el backup no pudiese ser desmontado (usando la función de auto-montaje). Ello sucede en caso que la aplicación TimeMachineScheduler esté en funcionamiento. Pese a ello, el “daemon” no se ve afectado en su funcionamiento.
Página principal: www.klieme.com/TimeMachineScheduler.html
Capturas:

Escrito por The Evangelist el 8 de Enero de 2008 y etiquetado como: Juniper, JunOS, Networking
Tener una copia de seguridad de la configuración del Junos es muy importante pero es aún más importante tenerla en un servidor remoto. El JunOS hace varias copia de seguridad en el propio sistema, para ser exactos 50 copias, la actual y las tres siguientes (1 a 3) en la Compact Flash (para tenerlas a mano rápidamente) y el resto (de la 4 a la 49) en el disco duro (para ahorrar espacio en la Compact Flash.
La actual y las tres siguientes las podemos ver:
user@router> file list /config [detail]
/config:
juniper.conf.1.gz
juniper.conf.2.gz
juniper.conf.3.gz
juniper.conf.gz
rescue.conf.gz
el resto:
user@rrouter> file list /var/db/config/ [detail]
/var/db/config/:
juniper.conf.10.gz
juniper.conf.11.gz
...
juniper.conf.48.gz
juniper.conf.49.gz
juniper.conf.5.gz
juniper.conf.6.gz
juniper.conf.7.gz
juniper.conf.8.gz
juniper.conf.9.gz
En ambos casos podemos usar el parámetro “detail”para ver en más detalle los atributos de los fichero, al más puro estilo unix.
Otra forma de obtener una copia de la configuración, esta vez fuera del router en un servidor remoto, es usando la siguiente instrucción desde el modo operacional:
file copy <fichero> <destination URL>
file copy /config/juniper.conf.gz server:nombre_fichero_configuración
file copy /config/juniper.conf.gz ftp://user:pass@server:nombre_fichero_configuración
El primero copia vía ssh y el segundo vía ftp.
Desde el modo configuración podemos guardar la configuración completa o una parte, según estemos en la raíz [edit] o en alguna sección concreta con lo cual SOLO guardará dicha sección completa.
Para guardar la configuración completa en modo configuración:
[edit]
user@router# save server:nombre_fichero_configuración
user@router# save ftp://user:pas@server:nombre_fichero_configuración
o Si solo queremos guardar por ejemplo la configuración de BGP:
[edit protocols bgp]
user@router# save server:nombre_fichero_configuración
user@router# save ftp://user:pas@server:nombre_fichero_configuración
Todos estos métodos son manuales , pero si queremos hacerlo de forma automáticamente tenemos 2 posibilidades. La primera es hacer una copia de la configuración cada vez que hagamos un “commit” (del tipo que sea) con lo cual siempre tendremos una copia en un servidor remoto con cada cambio realizado:
[edit]
user@router# set system archival configuration transfer-on-commit
user@router# set system archival configurationarchive-site ftp://user:pass@server:/directorio_donde_dejar_las_copias
El otro método es similar pero hace la copia cada un intervalo de tiempo especificado, ya se hayan hecho modificaciones o no, con lo cual podemos tener varias copias idénticas de la configuración por lo que se recomienda poner algún tipo de cron que rote las configuraciones o borre antiguas a menos que tengamos bastante espacio (aunque los ficheros no ocupan demasiado):
[edit]
user@router# set system archival configuration transfer-interva intervalo
user@router# set system archival configurationarchive-site ftp://user:pass@server:/directorio_donde_dejar_las_copias
intervalo puede ser desde 15 minutos hasta 2.880 minutos (48 horas) y se debe especificar en minutos.
NOTA: una gran desventaja de estos dos últimos métodos es que se debe usar el método de transferencia de FTP y por lo tanto la clave queda en la configuración sin cifrar por lo que es visible a simple vista.
Como método alternativo y ajeno a la configuración del JunOS es utilizar la heramienta libre de código abierto llamada RANCID muy utilizada para copias de seguridad de dispositivos de red de diersas marcas.
Escrito por The Evangelist el 9 de Enero de 2008 y etiquetado como: Debian, Linux
En algunas ocasiones he necesitado compilar un paquete Debian para modificar algo o para tener una versión concreta que no está de momento en la distribución estable pero si en la inestable.
Para compilar un paquete de la distribución estable (o en la que estemos) para modificar algo o simplemente para compilarlo nosotros (no recomendado), primero nos vamos a un directorio temporal, por ejemplo:
cd /usr/src/nombre_del_paquete
Luego nos bajamos el fuente y los ficheros necesarios, como el .diff y el .dsc:
apt-get source nombe_del_paquete
Para asegurarnos de que tenemos los paquetes necesarios para compilar:
apt-get build-dep netatalk
Ahora podemos ir al directorio donde están las fuentes y demás ficheros y directorios y modificar lo que necesitemos. Un fichero importante donde casi siempre añadiremos variables y opciones que por defecto no vienen es:
debian/rules
Una vez modificado lo que necesitemos, compilamos y generamos el o los paquetes tal cual lo haría un desarrollador:
dpkg-buildpackage
Una vez que termine (si no ha dado ningún eror) un nivel por encima de donde estamos habrá generado el/los .deb que podremos instarlar o actualizar y tendremos el paquete modificado casi como si fuera el oficial.
Escrito por The Evangelist el 9 de Enero de 2008 y etiquetado como: Debian, Linux, Networking
Por defecto el paquete de netatalk de Debian (al menso en Etch) no viene con soporte de encriptación debido a las políticas de Debian, por lo que si usamos por ejemplo Leopard nos daremos cuanta que nuestro server de APF no funciona ya que Leopard obliga a las contraseñas vayan cifradas no en textos plano como en Tiger. Así que vamos a compilar nuestro propio paquete DEB de Netatlak con soporte de encriptación.
Primero nos vamos a un directorio temporal donde vamos a trabajar (luego se puede borrar a que solo es necesario para compilar):
mkdir /usr/src/netatalk
cd /usr/src/netatalk
Y procedemos a bajar los ficheros necesarios para compilar, primero comprobamos que tenemos las librerías y paquetes necesarios (puede que ya tengamos estos paquetes instalados, si es así seguimos):
apt-get install openssl cracklib2 libpam-cracklib cracklib2-dev wspanish
Nos bajamos el source de Netatalk (y sus ficheros complementarios .diff y .dsc):
apt-get source netatalk
Comprobamos que tenemos los paquetes requeridos para compilar el paquete Netatalk:
apt-get build-dep netatalk
Ya tenemos todo lo necesario para compilar, por lo que procedemos a modificar la configuración para indicarle que queremos soporte de encriptación:
cd netatalk-2.0.3/
vi debian/rules
Y añadimos la línea siguiente justo antes del comentario que dice ## FIXME:
DEB_BUILD_OPTIONS=ssl debuild
y solo nos queda compilar y que todo vaya bien:
dpkg-buildpackage
Si todo ha ido bien (seguro que si) en el directorio superior a donde estamos se habrá creado el paquete Debian del Netatalk con soporte de encriptación, así que lo instalamos:
dpkg -i netatalk_2.0.3-4_i386.deb