Actualizando ISC DHCP server desde Debian Lenny hacia Squeeze

Recientemente actualicé el servidor dhcp 3.1.1-6+lenny4 desde Lenny hacia Squeeze, el cual provee la versión 4.1.1-P1-15 . Después de hacer unas pruebas aparentemente todo funcionó con normalidad, por lo cual me desentendí del caso.

Pero no fue hasta que tuve que agregar una hoja estática cuando me di cuenta que algo estaba mal. Los cambios simplemente no tenían efecto, pero la configuración “antigua” si.

Después de revisar configuraciones, me di cuenta que aparte del usual directorio /etc/dhcp3 se había creado el directorio /etc/dhcp , el cual contenía el archivo de configuración dhcpd.conf . Al hacer un diff entre ambas configuraciones, eran efectivamente los cambios que hice recientemente.

Así que en términos sencillos isc dhcp server utiliza el directorio /etc/dhcp e ignora /etc/dhcp3, y al momento de hacer hacer la actualización, hizo la copia de la configuracion “automágicamente”. Esto suena muy lógico debido a que la versión ha cambiado de 3 hacia 4, pero sin estar advertido anteriormente de dicho cambio no fue algo tan divertido.

Así que listo, aquellos que actualicen isc dhcp server desde debian Lenny hacia Squeeze, deben de utilizar el directorio /etc/dhcp y /var/lib/dhcp

Activando soporte Oracle Instant Client + PHP5 en Debian Linux

Para conectarse a una base de datos Oracle con PHP 5, se puede hacer a través del “Oracle Instant Client” y el modulo oci8 de pear.

Primero se debe descargar los paquetes “Basic” y “SDK” desde http://www.oracle.com/technology/tech/oci/instantclient/instantclient.html. En mi caso, los archivos fueron

  • instantclient-basic-linux32-10.2.0.3-20061115.zip
  • instantclient-sdk-linux32-10.2.0.3-20061115.zip

Creamos directorios y descomprimimos

# mkdir -p /opt/oracle/instantclient
# cd /opt/oracle/instantclient
# unzip instantclient-basic-linux32-10.2.0.3-20061115.zip
# unzip instantclient-sdk-linux32-10.2.0.3-20061115.zip

Agregamos las librerías de oracle a las librerías del sistema

# echo /opt/oracle/instantclient >> /etc/ld.so.conf
# ldconfig

Creamos los vínculos simbólicos en caso de que el comando anterior no lo haya hecho:

# cd instantclient_10_2
# ln -s libclntsh.so.10.1 libclntsh.so
# ln -s libocci.so.10.1 libocci.so

Instalamos paquetes necesarios para la configuración del módulo oci8, entre ellos Pear

# apt-get install php-pear php5-dev build-essential

En teoría el comando pecl install oci8 debería de funcionar, pero aparentemente no puede trabajar con las librerías de Oracle Instanclient, así que procedemos a ejecutar los pasos manualmente

# mkdir -p /usr/local/src
# cd /usr/local/src
# pecl download oci8
# tar xfz oci8-1.3.5.tgz
# cd oci8-1.3.5
# phpize
# ./configure –with-oci8=shared,instantclient,/opt/oracle/instantclient/instantclient_10_2
# make
# make install

El nombre del archivo oci8-1.3.5.tgz cambiará dependiendo de nuevas versiones

Luego activamos el módulo oci8 en el archivo php.ini (/etc/php5/apache2/php.ini and /etc/php5/cli/php.ini), con la siguiente línea:

extension=oci8.so

Este paso tarde o temprano tendrá que ejecutarse, asi que mejor de una vez configuramos el archivo  tnsnames.ora

#  mkdir -p /opt/oracle/instantclient/instantclient_10_2/network/admin

Editamos el tnsnames.ora de acuerdo a nuestras necesidades.

# vi /opt/oracle/instantclient/instantclient_10_2/network/admin/tnsnames.ora

Ahora se procede a reiniciar Apache y listo :), podemos auxiliarnos de phpinfo() para comprobar que el módulo oci8 está cargado.

Detalle de la instalación de snmpd en Debian

La instalación y configuración del servicio de snmp es de lo más sencillo, pero en mi caso personal se complicó más de la cuenta en un servidor Debian.

El caso era que no funcionaba snmpwalk desde ningún otro host que no fuera el propio servidor, para lo cual revisé y modifiqué numerosas veces /etc/snmp/snmpd.conf , además de hacer múltiples pruebas para ver si había problemas con el tráfico UDP.

La solución vino del lugar más inesperado, en específico del archivo /etc/default/snmpd el cual contiene la siguiente línea:

SNMPDOPTS=’-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1′

Ese 127.0.0.1 hace que el servicio solamente funcione en localhost , ignorando cualquier directiva agentaddress que pudiera estar en /etc/snmp/snmpd.conf .

Como se puede sospechar, la solución es un

# sed -i -e ‘s/127.0.0.1//g’ /etc/default/snmpd

Lo que me llama la atención es la posible intención de la persona que mantiene este paquete,  al hacer un cambio de este tipo sin ninguna notificación al momento de instalar snmpd.

Será que no estoy acostumbrado al modo Debian de hacer las cosas?

apt : Recommends

En Debian GNU/Linux, cuando se desea instalar un paquete, por ejemplo Gnome,  agrega a la lista de paquetes a instalar un sinfin de programas que no tienen ni la mas mínima relación o que se desconoce porque razón lo desea instalar.

En el caso de hacer un apt-get install gnome , software como rhythmbox,  rpm, wodim, wpasupplicant, sane-utils, p7zip, liferea entre muchos muchos otros que NO SON NECESARIOS para utilizar Gnome  se ven instalados.

La verdad que tener que instalar todo ese software, porque alguien pensó que era una buena idea™ incluirlo es realmente muy molesto.

La instalación del sinfin de software se debe a los Recommends , que según la documentación de Debian son paquetes que deberían de ser instalados siempre a menos que sea una instalación excepcional.

Pero existe una “solución” a este inconveniente, tal como la mencionó un tal rmayorga.

# apt-config dump |  grep Reco |  sed ‘s/1/0/’ > /etc/apt/apt.conf.d/02user

lo que deja una línea similar a APT::Install-Recommends “0”; en el archivo /etc/apt/apt.conf.d/02user .

La diferencia es notoria, con el apt-get install gnome :

Antes:

0 upgraded, 842 newly installed, 0 to remove and 0 not upgraded.
Need to get 592MB of archives.
After this operation, 1588MB of additional disk space will be used.

Después:

0 upgraded, 494 newly installed, 0 to remove and 0 not upgraded.
Need to get 366MB of archives.
After this operation, 952MB of additional disk space will be used.

Tip en la línea de comandos de Debian

En la mayoría de las distribuciones GNU/Linux lo siguiente nos funcionará en una línea de comandos:

$ ls [PgUp] me muestra $ ls bleh/

Si lo sigo presionando me saldrán los comandos que hayan comenzado con “ls”, en conjunto con PgDn se podrá “avanzar” o “retroceder”. Esto funciona para cualquier comando que hayamos digitado en la consola y es algo muy útil por ejemplo en comandos extensos que hayamos digitado alguna vez.

En Debian no viene activado por defecto, desconozco el porqué, pero es fácil de corregir.

En el archivo /etc/inputrc modificamos la siguientes líneas:

# alternate mappings for “page up” and “page down” to search the history
# “e[5~”: history-search-backward
# “e[6~”: history-search-forward

por

# alternate mappings for “page up” and “page down” to search the history
“e[5~”: history-search-backward
“e[6~”: history-search-forward

Fácil cierto?

Error en init scripts en Debian

Modifico una línea de una zona de un servidor BIND en un Debian etch, e intento “recargar” la configuración.

Lo siguiente sucede:

proxy:~# /etc/init.d/bind9 reload
rndc: connect failed: connection refused
proxy:~# /etc/init.d/bind9 stop
Stopping domain name service: namedReloading Squid configuration files.
done.
rndc: connect failed: connection refused
.
proxy:~# ps -fe | grep bind
bind     18649     1  0 Jan30 ?        00:00:00 /usr/sbin/named -u bind
root     32723 32134  0 11:51 pts/0    00:00:00 grep bind
proxy:~# /etc/init.d/bind9 stop
Stopping domain name service: namedrndc: connect failed: connection refused
.
proxy:~# ps -fe | grep bind
bind     18649     1  0 Jan30 ?        00:00:00 /usr/sbin/named -u bind
root     32731 32134  0 11:52 pts/0    00:00:00 grep bind
proxy:~# killall named
proxy:~# ps -fe | grep bind
root     32734 32134  0 11:52 pts/0    00:00:00 grep bind
proxy:~# /etc/init.d/bind9 start
Starting domain name service: namedReloading Squid configuration files.
done.
.
proxy:~#

Si, actualicé el caché de los repositorios.
Si, es 9.3.4-2etch4
Al revisar el init script en la sección de reload se ve el comando /usr/sbin/rndc reload >/dev/null , interesante ver que nunca investigan si existe el pid.
Y luego me dicen “¿Porqué no utilizas Debian?”

Powered by WordPress with GimpStyle Theme design by Horacio Bella.
Entries and comments feeds. Valid XHTML and CSS.