CH3HNAS

Ayer me decidí a “pegar” un repaso a este magnífico NAS, ya en su día intenté habilitar el funplug proveniente del CH3SNAS, pero lo que más me interesaba, openssh (u openvpn) no conseguí que funcionase.

Asi que investigando, descubrí que un compañero freak, ha sacado sus propios scripts/repositorio personalizado para el CH3HNAS:
* http://visscher.dyndns-home.com/ (ejecutado desde el propio NAS según el autor).
* http://henkjan.net/

Siguiendo instrucciones ya para empezar me dio error el script de instalación, pero esta vez tenía que ser si o sí, así que revisé el script de instalación (setuphfp) y me sorprendió bastante la sencillez, paso por paso, ejecuté:
[cc lang=”bash” theme=”blackboard”]
DEFAULT_ROOT=/home/Public/funplug/hfp
REPOSITORY=http://visscher.dyndns-home.com/packages
mkdir -p ${dir}
mkdir ${dir}/tmp
mkdir ${dir}/sbin
cd ${dir}/..
ln -s hfp ffp
cd ${dir}/sbin
wget ${REPOSITORY}/hfppkg
chmod +x hfppkg
${dir}/sbin/hfppkg update
${dir}/sbin/hfppkg -c install setuphfp
${dir}/sbin/hfppkg install busybox
[/cc]
Con lo que ya está “instalado” el hfp y busybox.
Omito que estuve revisando el script hfppkg :)

Revisando el sistema de arranque, ví que el proceso es el siguiente:

/etc/init.d/rc.sysinit ->
/home/Public/funplug/ffp/etc/rc ->
/home/Public/funplug/ffp/etc/start/*.sh

Es decir, desde el rc.sysinit (que no se puede “alterar” ya que está dentro de la parte de la “BIOS” del NAS y se reescribe cada arranque), está hardcodeado arrancar el script /home/Public/funplug/ffp/etc/rc.
Desde este script, entre otras cosas (a gusto del consumidor, ya que está dentro del disco duro), se arrancarán todos los scripts “*.sh” dentro del directorio /home/Public/funplug/ffp/etc/start/ que tengan permisos de ejecución.

En mi caso y para no cargar demasiado el NAS, he optado por quitar del arranque el telnet y el propio hfp que no sirve para mucho.

Según Henk-Jan “openssh” reemplaza dropbear, que tampoco me interesa demasiado, lo que yo quiero es arrancar openssh desde otro puerto, asi que… instalo el paquete y procedo a cambiar el script de arranque, lo he dejado así:
vi /home/Public/funplug/hfp/start/sshd.sh
[cc lang=”bash” theme=”blackboard”]
#!/hfp/bin/sh

# PROVIDE: sshd done

. ${HFP:-/hfp}/etc/hfp.subr

name=”sshd”
command=”${HFP:-/hfp}/sbin/$name”
required_files=”${HFP:-/hfp}/etc/ssh/sshd_config”
# sshd_flags=”-p 22″

start_cmd=”sshd_start”

sshd_start()
{
echo “Running dropbear processes:”
proc_start ${command}
}

run_rc_command “${1}”
[/cc]


Duro, eh!!!??? :D
Por supuesto, he cambiado el fichero de configuración del sshd según mis necesidades (fichero “/home/Public/funplug/hfp/etc/ssh/sshd_config“), por ejemplo para denegar “root” login y permitir pubkeys :)
De todas formas si no queréis cambiar el fichero de config, en el propio script de arranque del sshd, existe la variable “sshd_flags” que le indica al demonio en qué puerto arrancar.

crontab express

Hoy me he encontrado algo así en un servidor:

00,10,20,30,40,50 * * * * su - USUARIO02 -c /opt/oracle/bin/SESSIONS_USER/monitoriza.sh 2>&1

Me ha extrañado mucho… no sé si la gente no sabe lo del “cron.allow” y ponerle el cron al usuario.
Aparte de lo del 0,10,20… que un */10 queda bastante mejor y comprensible :P

Kernel Panic!

Estaba claro que si tienes algún dispositivo con linux… en algún momento tiene que aparecer el mensajito :)
Pero no por ello es menos sorprendente que en un entorno más o menos “cerrado” aparezca sin motivo aparente.
En este caso mientras escuchaba música (aunque seguramente sea la tarjeta microsd que tengo que es una mier**).
Subo una bonita foto :)

Restuarando Grub

Hoy por desgracia me he cargado el grub de un servidor RHEL5.
Asi que me he puesto a restaurarlo desde “linux rescue“.
Cual ha sido mi sorpresa cuando ninguna de las sugerencias disponibles por internet me ha funcionado (o no he dado por las correctas).
Intentando cosas he “dado” con la solución…

El rescue de linux por supuesto me ha detectado y montado las particiones en /mnt/sysimage:

/dev/mapper/rootvg-LVsystem 12G 1.5G 9.6G 14% /mnt/sysimage/
/dev/sda1 99M 13M 82M 13% /mnt/sysimage/boot
/dev/mapper/rootvg-home_lv 2.0G 120M 1.8G 7% /mnt/sysimage/home
/dev/mapper/rootvg-usr_lv 4.9G 1.2G 3.5G 26% /mnt/sysimage/usr
/dev/mapper/rootvg-var_lv 2.0G 135M 1.8G 8% /mnt/sysimage/var
/dev/mapper/rootvg-tmp_lv 992M 34M 908M 4% /mnt/sysimage/tmp
/dev/mapper/rootvg-logs_lv 992M 34M 908M 4% /mnt/sysimage/logs

El problema es que grub-install no me funcionaba por no “detectar” grub, he intentado pasarle varios parametros pero nada.
Tampoco funcionaba un chroot.

Asi que a “las bravas”:

ln -s /mnt/sysimage/sbin/grub /sbin/grub
grub --batch --device-map=/boot/grub/device.map --config-file=/boot/grub/grub.conf -no-floppy

Y desde el prompt de grub:

grub> root (hd0,0)
grub> setup (hd0)
grub> quit

Es paradógico lo que se consigue con un symlink :D

Zimbra y disclaimers

Después de una actualización de zimbra fallida debido a que “alguien” había alterado el ldap para añadir un disclaimer corporativo, me he visto en la paradoja de tener que volver a implementarlo.
No me gusta nada como lo hacen en Zimbra, es un mero parche, no soportado y en mi opinión, una chapuza.
Así que lo he simplificado.
Hay miles de tutoriales en internet de como integrar postfix+altermime, asi que esto es lo mismo solo que traspasado al entorno propietario de nuestro querido zimbra.

Lo podéis ver en la wiki.