Archivo de la Categoría “Gentoo GNU/Linux”
Todo las cosas que se me van ocuriendo hacer con Gentoo GNU/Linux
Con esto lo que quiero conseguir es que mi AMD64 ayude en los procesos de compilación al instalar o actualizar paquetes en un Pentium II que uso como servidor.
Debemos tener instalado distcc en todas las máquinas que participen en la compilación, tanto la que ejecuta emerge como las que reciben las tareas de compilación ditribuida, y, a ser posible, la misma versión de distcc en todas las máquinas. Ejecutamos en todas las máquinas:
# emerge --sync
# emerge distcc
Equipo que lanza emerge (arquitectura i686):
# cd /usr/lib/distcc/bin
# rm -f cc gcc c++ g++
# echo '#!/bin/bash' >i686-pc-linux-gnu-gcc-wrapper
# echo 'exec /usr/lib/distcc/bin/i686-pc-linux-gnu-g${0:$[-2]} "$@"' \
>> i686-pc-linux-gnu-gcc-wrapper
# chmod a+x i686-pc-linux-gnu-gcc-wrapper
# ln -s i686-pc-linux-gnu-gcc-wrapper cc
# ln -s i686-pc-linux-gnu-gcc-wrapper gcc
# ln -s i686-pc-linux-gnu-gcc-wrapper c++
# ln -s i686-pc-linux-gnu-gcc-wrapper g++
Ver versiones exactas de binutils, gcc, linux-headers, y glibc:
*** Si no tienes el comando eix: emerge eix && update-eix
# eix -c sys-devel/binutils$
# eix -c sys-devel/gcc$
# eix -c sys-kernel/linux-headers$
# eix -c sys-libs/glibc$
Añadir los equipos que participan en la granja de compilación:
# distcc-config --set-hosts "nombre_equipo_64bits localhost"
Configurar portage para que haga uso de distcc añadiendo "distcc" a FEATURES en /etc/make.conf y ajustar MAKEOPTS para que se lancen más procesos de compilación:
FEATURES="distcc parallel-fetch"
MAKEOPTS="-j6"
Equipo que asiste a la compilación (arquitectura x86_64):
Instalamos crossdev y creamos el compilador cruzado usando las versiones que vimos del equipo i686 (punto 2 del apartado anterior):
# emerge crossdev
# crossdev -t i686-pc-linux-gnu --b 2.16.1-r3 --g 4.1.2 --k 2.6.17-r2 --l 2.5-r3
Significado de las opciones: --b <versión de binutils> --g <versión de gcc> --k <versión de linux-headers> --l <versión de glibc>
Editar /etc/conf.d/distccd para permitir recibir compilaciones dentro de equipos de nuestra red, por ejemplo:
DISTCCD_OPTS="${DISTCCD_OPTS} --allow 192.168.0.0/24"
Lanzar distcc siempre que vayamos a ejecutar emerge en el equipo al que asistimos (arquitectura i686):
# /etc/init.d/distccd start
Diferencias de tiempo de compilación antes de distcc y después de distcc:
PHP:
Fri May 11 07:27:57 2007 >>> dev-lang/php-5.2.2-r1
merge time: 1 hour, 25 minutes and 13 seconds.
Mon Jun 11 14:06:41 2007 >>> dev-lang/php-5.2.2-r1
merge time: 59 minutes and 24 seconds.
cURL:
Tue Mar 27 02:17:02 2007 >>> net-misc/curl-7.15.1-r1
merge time: 7 minutes and 26 seconds.
Mon Jun 11 13:07:17 2007 >>> net-misc/curl-7.15.1-r1
merge time: 6 minutes and 41 seconds.
Enlaces de interés: Gentoo Documentation y Gentoo-Wiki. Con esto lo que quiero conseguir es que mi AMD64 ayude en los procesos de compilación al instalar o actualizar paquetes en un Pentium II que uso como servidor.
Debemos tener instalado distcc en todas las máquinas que participen en la compilación, tanto la que ejecuta emerge como las que reciben las tareas de compilación ditribuida, y, a ser posible, la misma versión de distcc en todas las máquinas. Ejecutamos en todas las máquinas:
# emerge --sync
# emerge distcc
Equipo que lanza emerge (arquitectura i686):
# cd /usr/lib/distcc/bin
# rm -f cc gcc c++ g++
# echo '#!/bin/bash' >i686-pc-linux-gnu-gcc-wrapper
# echo 'exec /usr/lib/distcc/bin/i686-pc-linux-gnu-g${0:$[-2]} "$@"' \
>> i686-pc-linux-gnu-gcc-wrapper
# chmod a+x i686-pc-linux-gnu-gcc-wrapper
# ln -s i686-pc-linux-gnu-gcc-wrapper cc
# ln -s i686-pc-linux-gnu-gcc-wrapper gcc
# ln -s i686-pc-linux-gnu-gcc-wrapper c++
# ln -s i686-pc-linux-gnu-gcc-wrapper g++
- Ver versiones exactas de binutils, gcc, linux-headers, y glibc:
*** Si no tienes el comando eix: emerge eix && update-eix
# eix -c sys-devel/binutils$
# eix -c sys-devel/gcc$
# eix -c sys-kernel/linux-headers$
# eix -c sys-libs/glibc$
- Añadir los equipos que participan en la granja de compilación:
# distcc-config --set-hosts "nombre_equipo_64bits localhost"
- Configurar portage para que haga uso de distcc añadiendo “distcc” a FEATURES en /etc/make.conf y ajustar MAKEOPTS para que se lancen más procesos de compilación:
FEATURES="distcc parallel-fetch"
MAKEOPTS="-j6"
Equipo que asiste a la compilación (arquitectura x86_64):
- Instalamos crossdev y creamos el compilador cruzado usando las versiones que vimos del equipo i686 (punto 2 del apartado anterior):
# emerge crossdev
# crossdev -t i686-pc-linux-gnu --b 2.16.1-r3 --g 4.1.2 --k 2.6.17-r2 --l 2.5-r3
Significado de las opciones: –b <versión de binutils> –g <versión de gcc> –k <versión de linux-headers> –l <versión de glibc>
Editar /etc/conf.d/distccd para permitir recibir compilaciones dentro de equipos de nuestra red, por ejemplo:
DISTCCD_OPTS="${DISTCCD_OPTS} --allow 192.168.0.0/24"
- Lanzar distcc siempre que vayamos a ejecutar emerge en el equipo al que asistimos (arquitectura i686):
# /etc/init.d/distccd start
Diferencias de tiempo de compilación antes de distcc y después de distcc:
- PHP:
Fri May 11 07:27:57 2007 >>> dev-lang/php-5.2.2-r1
merge time: 1 hour, 25 minutes and 13 seconds.
Mon Jun 11 14:06:41 2007 >>> dev-lang/php-5.2.2-r1
merge time: 59 minutes and 24 seconds.
- cURL:
Tue Mar 27 02:17:02 2007 >>> net-misc/curl-7.15.1-r1
merge time: 7 minutes and 26 seconds.
Mon Jun 11 13:07:17 2007 >>> net-misc/curl-7.15.1-r1
merge time: 6 minutes and 41 seconds.
Enlaces de interés: Gentoo Documentation y Gentoo-Wiki.
No Hay Comentarios »
Usar bash-completion en Gentoo es una gozada, permite autocompletar las opciones de los comandos típicos de Gentoo como genkernel, emerge, equery y otros. Además de mostrar una lista de las coincidencias para autorrellenar.
Para instalarlo basta con:
# emerge bash-completion
Además debemos añadir esta línea de código al fichero /etc/bash/bashrc, teniendo en cuenta que hay que ponerla siempre antes de la ejecución de cualquier sentencia alias:
[[ -f /etc/profile.d/bash-completion.sh ]] && source /etc/profile.d/bash-completion.sh
Si queremos ir probándolo ya, en la sesión bash actual, debemos ejecutar:
# source /etc/profile.d/bash-completion.sh.
Para root la solución más limpia y que menos mantenimiento posterior requiere es añadir una línea en el .bashrc:
# echo "source /etc/profile.d/bash-completion.sh" >> /root/.bashrc
Si queremos dar soporte a otras utilidades y programas para bash-completion hemos de añadir la USE="bash-completion", en /etc/make.conf o algún otro sitio válido que prefieras. Vuelve a emerger los paquetes en los que se hayan activado esta use y luego activa el uso de bash-completion para el comando que quieras usando por ejemplo eselect:
# eselect bashcomp list
Para ver la lista de comandos soportados.
# eselect bashcomp enable gentoo
Activar completado bash en comandos Gentoo para root.
# eselect bashcomp enable --global gentoo
Activar completado bash en comandos Gentoo para todos los usuarios.
Esta entrada fue actualizada el 23 de septiembre de 2010. Usar bash-completion en Gentoo es una gozada, permite autocompletar las opciones de los comandos típicos de Gentoo como genkernel, emerge, equery y otros. Además de mostrar una lista de las coincidencias para autorrellenar.
Para instalarlo basta con:
# emerge bash-completion
Además debemos añadir esta línea de código al fichero /etc/bash/bashrc, teniendo en cuenta que hay que ponerla siempre antes de la ejecución de cualquier sentencia alias:
[[ -f /etc/profile.d/bash-completion.sh ]] && source /etc/profile.d/bash-completion.sh
Si queremos ir probándolo ya, en la sesión bash actual, debemos ejecutar:
# source /etc/profile.d/bash-completion.sh.
Para root la solución más limpia y que menos mantenimiento posterior requiere es añadir una línea en el .bashrc:
# echo "source /etc/profile.d/bash-completion.sh" >> /root/.bashrc
Si queremos dar soporte a otras utilidades y programas para bash-completion hemos de añadir la USE=”bash-completion”, en /etc/make.conf o algún otro sitio válido que prefieras. Vuelve a emerger los paquetes en los que se hayan activado esta use y luego activa el uso de bash-completion para el comando que quieras usando por ejemplo eselect:
# eselect bashcomp list
Para ver la lista de comandos soportados.
# eselect bashcomp enable gentoo
Activar completado bash en comandos Gentoo para root.
# eselect bashcomp enable --global gentoo
Activar completado bash en comandos Gentoo para todos los usuarios.
Esta entrada fue actualizada el 23 de septiembre de 2010.
No Hay Comentarios »
aMSN nos brinda la posibilidad de guardar en disco todas las sesiones de WebCam que hagamos de la misma manera que es capaz de guardar registro de todas las conversaciones que hacemos. De este modo podemos ver luego tanto nuestras conversacines escritas como la sesión de WebCam haciendo uso de aMSN.
El problema es que el vídeo sólo podemos verlo con el propio aMSN, puesto que este guarda en crudo todos los paquetes que recibe de la sesión de vídeo en un fichero .cam, siendo este formato privativo de MicroSoft. He aquí una solución que he encontrado a través de la FAQ de aMSN para hacer una conversión del vídeo a XViD.
En primer lugar debemos tener instalados en el sistema PyQt, transcode y libmimic:
# echo "media-libs/libmimic ~amd64" >> /etc/portage/package.keywords"
# emerge PyQt transcode libmimic
Recuerda sustituir ~amd64 por tu arquitectura si fuera necesario, por ejemplo ~x86.
A continuación descargamos mimictools y mimicdecoder, e instalamos mimictools:
# tar xvzf mimictools-1.0.1.tar.gz
# cd mimictools-1.0.1
# make
# make install
Se instalará en /usr/local/, y solo serán un par de ejecutables, por si queréis desinstalarlo, que sepáis que el Makefile NO tiene la orden uninstall.
Con mimicdecoder es distinto, es un script en Python, por lo que no hay que compilarlo, sólo descomprimimos y ejecutamos:
# tar xvzf mimicdecoder-1.0.1.1.tar.gz
# cd mimicdecoder-1.0.1.1
# ./mimicdecoder
Y es ahora cuando veremos algo como esto:
A partir de aquí solo tenemos que escoger el vídeo que queremos de las sesiones que nos aparecen a la izquierda; a qué formato convertirlo, en este caso Convert to XVID; y el nombre que le vamos a dar al fichero. Si no estamos seguros de que ese es el vídeo que queremos convertir, podemos pulsar sobre Preview para que nos muestre el vídeo antes de codificarlo.
aMSN nos brinda la posibilidad de guardar en disco todas las sesiones de WebCam que hagamos de la misma manera que es capaz de guardar registro de todas las conversaciones que hacemos. De este modo podemos ver luego tanto nuestras conversacines escritas como la sesión de WebCam haciendo uso de aMSN.
El problema es que el vídeo sólo podemos verlo con el propio aMSN, puesto que este guarda en crudo todos los paquetes que recibe de la sesión de vídeo en un fichero .cam, siendo este formato privativo de MicroSoft. He aquí una solución que he encontrado a través de la FAQ de aMSN para hacer una conversión del vídeo a XViD.
Lee el resto de esta entrada »
17 Comentarios »
Una solución para usar el plugin flash 9 de adobe en gentoo es usar el paquete mozilla-firefox-bin, compilado para 32 bits. Tan sencillo como:
# emerge mozilla-firefox-bin
# emerge netscape-flash
¿Por qué funciona con el binario y no con el que es instalado desde código fuente?
Porque el binario está precompilado para 32bits, netscape-flash también, al instalar el binario de firefox conseguimos que todas las bibliotecas que necesita firefox para ejecutarse sean de 32Bits, así no se mezclan bibliotecas de 32Bits con otras de 64Bits, pudiéndose ejecutar el programa sin problemas. El firefox instalado desde el código fuente genera binarios de 64Bits, por eso no es posible usar netscape-flash, mezclaría las bibliotecas de 64Bits de firefox con las de 32Bits de netscape-flash.
Esta no es una solución que me guste demasiado, pues lo ideal sería poder tener un plugin de flash de 64Bits. Sería posible tenerlo si Adobe lo ofreciera para 64Bits, pero no lo hace. También podríamos usar software libre alternativo, como gnash, que se puede compilar para 64bits, pero no me han gustado los resultados que da por ahora, además de que sólo soporta Flash 7. Una solución para usar el plugin flash 9 de adobe en gentoo es usar el paquete mozilla-firefox-bin, compilado para 32 bits. Tan sencillo como:
- # emerge mozilla-firefox-bin
- # emerge netscape-flash
Lee el resto de esta entrada »
No Hay Comentarios »
El driver para la tarjeta de sonido de la placa Asus M2N-E, que lleva chips de NVidia, nForce y demás, es el snd-hda-intel de alsa. En el post anterior comenté que tenía problemas con el audio de algunos archivos de vídeo al reproducirlos con xine. Estuve mirando por los foros de gentoo y me encontré un post en el que hablaba sobre que el driver de alsa no manejaba bien el dispositivo de sonido de mi placa madre. Probé con lo que vi ahí, pero no me sirvió.
Al probar rhythmbox y cargar unos cuantos mp3 y ogg en la lista de reproducción, me saltó un aviso que decía que los mp3 no podían ser cargados pues no se disponía de un plugin para tratarlos :-O, increíble, miré a ver con qué USEs había instalado rhythmbox. Resultó ser que no tenía activada USE="mad", así que la añadí a mi /etc/make.conf, luego hice un emerge -Nu world y listo, ahora puedo escuchar todos los vídeos perfectamente.
Sin embargo, rhythmbox no reproduce bien mp3, va como entrecortado, cosa que no ocurre con audacious. Curioso, ahora me ocurre con rhythmbox algo parecido a lo que me pasaba con xine. El driver para la tarjeta de sonido de la placa Asus M2N-E, que lleva chips de NVidia, nForce y demás, es el snd-hda-intel de alsa. En el post anterior comenté que tenía problemas con el audio de algunos archivos de vídeo al reproducirlos con xine. Estuve mirando por los foros de gentoo y me encontré un post en el que hablaba sobre que el driver de alsa no manejaba bien el dispositivo de sonido de mi placa madre. Probé con lo que vi ahí, pero no me sirvió.
Al probar rhythmbox y cargar unos cuantos mp3 y ogg en la lista de reproducción, me saltó un aviso que decía que los mp3 no podían ser cargados pues no se disponía de un plugin para tratarlos :-O, increíble, miré a ver con qué USEs había instalado rhythmbox. Resultó ser que no tenía activada USE=”mad”, así que la añadí a mi /etc/make.conf, luego hice un emerge -Nu world y listo, ahora puedo escuchar todos los vídeos perfectamente.
Sin embargo, rhythmbox no reproduce bien mp3, va como entrecortado, cosa que no ocurre con audacious. Curioso, ahora me ocurre con rhythmbox algo parecido a lo que me pasaba con xine.
No Hay Comentarios »
Este viernes me compré un AMD Dual-Core 4200+, con un par de gigas de ram. No veas si he notado el cambio, de un Athlon a 1GHz y 640MiB de ram, una locura, no digo más. Lo que más me intrigaba era cómo se iba a comportar Gentoo con un procesador de doble núcleo, por ahora parece que bien. Detecta los dos núcleos como si fueran dos procesadores, es bastante curioso.
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 75
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
stepping : 2
cpu MHz : 2210.492
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy
bogomips : 4424.16
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 75
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
stepping : 2
cpu MHz : 2210.492
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy
bogomips : 4420.44
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
Unos pantallazos del Monitor del Sistema de Gnome:
Fijaos en el primer pantallazo, la gráfica del uso de los dos cores, ¡son completamente simétricas entre sí! Jejeje, es una tontería pero me resultó curioso.
Por otro lado aún tengo que ajustarlo todo a mi gusto. Estoy teniendo unos problemillas con el audio en Xine con ciertos archivos de vídeo, no sé si será la tarjeta de sonido integrada o un problema puntual con la arquitectura amd64, lo que no cabe duda es que la tarjeta Sound Blaster Live! 1024 que tengo del PC antiguo, y que compré hace siete años, le da mil vueltas a esta. Acabaré poniendo la tarjeta esa también, fijo.
Este viernes me compré un AMD Dual-Core 4200+, con un par de gigas de ram. No veas si he notado el cambio, de un Athlon a 1GHz y 640MiB de ram, una locura, no digo más. Lo que más me intrigaba era cómo se iba a comportar Gentoo con un procesador de doble núcleo, por ahora parece que bien. Detecta los dos núcleos como si fueran dos procesadores, es bastante curioso.
Lee el resto de esta entrada »
4 Comentarios »
Un SAI (Sistema de Alimentación Initerrumpida) es un cacharrito que se usa para que los equipos no se apaguen directamente cuando hay un corte de luz, tienen una batería que consigue mantenerlos encendidos durante unos minutos, suficiente para que se apaguen correctamente o que te de tiempo a volver a conectar la luz.
Mi idea es tener conectados el cable-modem de Ono (por poco tiempo, hasta que tenga ADSL), el router wifi, el servidor web y mi sobre mesa. De este modo no me quedaré sin conexión a internet cuando se vaya la luz en mi casa. Además, la idea es que se mantengan encendidos, pero si la batería llega al 30%, entonces apagar el sobremesa y una vez apagado este, apagar el servidor web.
Primero haré unos comentarios sobre el SAI que me he comprado, es un MGE (Merlin) UPS System modelo Protection Center 675, con conexión USB.
Como podeis ver en la foto, dispone de 8 enchufes normales, así que podemos conectar casi lo que queramos, 4 son sólo con filtro de tensión (los que van marcados sólo con el dibujito de la tormenta) y los otros 4 con fitro de tensión y batería (marcados con la tormenta y la batería). En el lateral tiene el enchufe para conectalo a la red electrica y 3 conectores rj45. Uno de ellos (el más separado) aunque os parezca raro a algunos es el conector USB, sí, el USB, es un rj45 a USB, el que usaremos para conectarlo al PC, en mi caso al servidor, que es el que siempre estará encendido monitoreando y controlando al SAI. Los otros dos son 2 rj45 para conectar tan teléfono, fax, o cables de red para que hagan de filtro de tensión, por si cayera un rayo en el tendido telefónico, por ejemplo, que no se quemara el fax o el termina telefónico.
Una vez conectado al servidor, todos los equipos conectados a los enchufes de batería y el SAI conectado a la corriente, le damos al botón verde durante unos 0.5 segundos hasta que pite. Y voilá, ya está funcionando, podemos encender nuestros ordenadores, routers, modems y demás que tengamos conectado al SAI.
Ahora tendremos que instalar sys-power/nut teniendo en cuenta que debemos tener la USE usb activada (obligatorio para el equipo en el que esté conectado el SAI por USB). Añadimos USE="usb" a nuestro make.conf si fuera necesario y ejecutamos emerge sys-power/nut.
Configuración de nut en el equipo al que está conectado el SAI. En este equipo necesitaremos usar tanto upsmon como upsd. Primero editaremos /etc/nut/ups.conf donde hay que configurar el SAI que tenemos conectado:
[merlin]
driver = newhidups
port = auto
desc = "Web server"
Newhidups es el driver que se necesita para comunicarnos con el SAI, auto es para indicar que el puerto por el que está conectado es el USB.
Editamos ahora /etc/nut/upsd.conf:
ACL all 0.0.0.0/0
ACL localhost 127.0.0.1/32
ACL psicotropo 192.168.1.127/8
ACCEPT localhost
ACCEPT psicotropo
REJECT all
Con esto indicamos qué máquinas podrán comunicarse con upsd para monitorizar o controlar el SAI.
Seguimos con /etc/nut/upsd.users:
[merlin]
password = tupassword
allowfrom = localhost otro_equipo
actions = SET
instcmds = ALL
upsmon master
[merlin-slave]
password = tupassword
allowfrom = otro_equipo
actions = SET
instcmds = ALL
upsmon slave
Ya tenemos creados los usuarios que podrán acceder al upsd de la máquina conectada al SAI por USB, lo de master y slave es para saber qué equipo hay que apagar antes, primero se apagarán los equipos que corran upsmon con usuarios que monitoricen SAIs en modo esclavo.
Para acabar con la máquina que está conectada al SAI por USB, editamos el archivo /etc/nut/upsmon.conf:
RUN_AS_USER nut
MONITOR merlin@localhost 1 merlin tupassword master
RUN_AS_USER nut hace que se ejecute uspmon como usuario nut, que ha sido creado por portage al instalar sys-power/nut de forma automática. La lína de MONITOR quiere decir monitorear el SAI merlin en localhost como el usuario merlin con el password tupassword en modo master.
Ya tenemos configurado el equipo que está conectado al SAI. Ahora sólo falta iniciar los servicios y añadirlos a la secuencia de arranque:
# /etc/init.d/upsd start
# /etc/init.d/upsmon start
# rc-update add upsd default
# rc-update add upsmon default
Y por último queda instalar sys-power/nut en el otro equipo y configurar upsmon. La instalación la haremos del mismo modo que para el equipo al que esta conectado el SAI, pero no necesitaremos preocuparnos por la USE="usb". Editamos el /etc/nut/upsmon.conf:
RUN_AS_USER nut
MONITOR merlin@server 1 merlin-slave tupassword slave
Añadimos iniciamos el servicio upsmon y lo añadimos a la secuencia de arranque:
# /etc/init.d/upsmon start
# rc-update add upsmon default
Ya sólo me queda configurarlo para que los upsmon de cada máquina reaccionen a ciertos sucesos como son que el SAI comience a funcionar en modo batería, que llegue al 30% de carga y esas cosas, de modo que los equipos inicien las secuencias de apagado y demás. Esto creo que se configura en /etc/nut/upssched.conf y creando unos scripts que controlan todo esto. He estado leyendo como es, pero lo seguiré explicando en otra entrada. Hoy no tengo más ganas de seguir con esto. En cuanto lo tenga hecho os cuento como fue.
Si véis algún fallo o creéis que se puede mejorar esto hacédmelo saber si queréis. Un SAI (Sistema de Alimentación Initerrumpida) es un cacharrito que se usa para que los equipos no se apaguen directamente cuando hay un corte de luz, tienen una batería que consigue mantenerlos encendidos durante unos minutos, suficiente para que se apaguen correctamente o que te de tiempo a volver a conectar la luz.
Mi idea es tener conectados el cable-modem de Ono (por poco tiempo, hasta que tenga ADSL), el router wifi, el servidor web y mi sobre mesa. De este modo no me quedaré sin conexión a internet cuando se vaya la luz en mi casa. Además, la idea es que se mantengan encendidos, pero si la batería llega al 30%, entonces apagar el sobremesa y una vez apagado este, apagar el servidor web.
Primero haré unos comentarios sobre el SAI que me he comprado, es un MGE (Merlin) UPS System modelo Protection Center 675, con conexión USB.

Como podeis ver en la foto, dispone de 8 enchufes normales, así que podemos conectar casi lo que queramos, 4 son sólo con filtro de tensión (los que van marcados sólo con el dibujito de la tormenta) y los otros 4 con fitro de tensión y batería (marcados con la tormenta y la batería). En el lateral tiene el enchufe para conectalo a la red electrica y 3 conectores rj45. Uno de ellos (el más separado) aunque os parezca raro a algunos es el conector USB, sí, el USB, es un rj45 a USB, el que usaremos para conectarlo al PC, en mi caso al servidor, que es el que siempre estará encendido monitoreando y controlando al SAI. Los otros dos son 2 rj45 para conectar tan teléfono, fax, o cables de red para que hagan de filtro de tensión, por si cayera un rayo en el tendido telefónico, por ejemplo, que no se quemara el fax o el termina telefónico.
Una vez conectado al servidor, todos los equipos conectados a los enchufes de batería y el SAI conectado a la corriente, le damos al botón verde durante unos 0.5 segundos hasta que pite. Y voilá, ya está funcionando, podemos encender nuestros ordenadores, routers, modems y demás que tengamos conectado al SAI.
Ahora tendremos que instalar sys-power/nut teniendo en cuenta que debemos tener la USE usb activada (obligatorio para el equipo en el que esté conectado el SAI por USB). Añadimos USE=”usb” a nuestro make.conf si fuera necesario y ejecutamos emerge sys-power/nut.
Lee el resto de esta entrada »
1 Comentario »
He instalado http-replicator en una máquina de la red local de mi casa. Es un proxy para portage, del estilo a lo que es apt-proxy para apt en debian. Lo que hace básicamente es que cuando usamos portage para instalar un paquete en una máquina, esta lo pide al proxy, si está en el proxy lo descargará a la velocidad que nos permita nuestra red local, si no está el proxy lo descargará y lo irá enviando en streaming a la máquina que lo pidió mientras lo descarga. Así conseguimos reducir la carga de nuestra conexión a internet cuando actualizamos gentoo en varias de nuestras máquinas. En este caso muchos de los paquetes que descargamos son los mismos para todas las máquinas, pero sólo serán descargados de internet una vez.
Los pasos que he seguido para instalarlo han sido muy simples. Primero lo que hay que hacer en la máquina que va a hacer de proxy para portage:
# emerge http-replicator
Añadir la línea http_proxy="http://localhost:8080" a /etc/make.conf
# repcacheman
# /etc/init.d/http-replicator start
# rc-update add http-replicator default
Es muy importante tener en cuenta que cada vez que usemos emerge para actualizar gentoo, instalar, eliminar o actualizar paquetes en la máquina que hace de proxy debemos ejecutar repcacheman para que elimine ficheros duplicados de la caché proxy, y también para que añada los nuevos ficheros a la caché. Esto no es necesario cuando hacemos emerge --sync o comando equivalente.
# emerge -Du world && repcacheman
o bien,
# emerge -Du world
# repcacheman
Para terminar, hay que hacer sólo un pequeño cambio en el fichero /etc/make.conf de cada máquina gentoo que queramos que use el proxy. Debemos añadir la línea http_proxy="http://nombre_o_ip_del_servidor_proxy:8080"
Con esto ya tendremos funcionando nuestro proxy para portage. Espero que sea de utilidad para álguien.
¡Hasta otra! He instalado http-replicator en una máquina de la red local de mi casa. Es un proxy para portage, del estilo a lo que es apt-proxy para apt en debian. Lo que hace básicamente es que cuando usamos portage para instalar un paquete en una máquina, esta lo pide al proxy, si está en el proxy lo descargará a la velocidad que nos permita nuestra red local, si no está el proxy lo descargará y lo irá enviando en streaming a la máquina que lo pidió mientras lo descarga. Así conseguimos reducir la carga de nuestra conexión a internet cuando actualizamos gentoo en varias de nuestras máquinas. En este caso muchos de los paquetes que descargamos son los mismos para todas las máquinas, pero sólo serán descargados de internet una vez.
Los pasos que he seguido para instalarlo han sido muy simples. Primero lo que hay que hacer en la máquina que va a hacer de proxy para portage:
- # emerge http-replicator
- Añadir la línea http_proxy=”http://localhost:8080″ a /etc/make.conf
- # repcacheman
- # /etc/init.d/http-replicator start
- # rc-update add http-replicator default
Es muy importante tener en cuenta que cada vez que usemos emerge para actualizar gentoo, instalar, eliminar o actualizar paquetes en la máquina que hace de proxy debemos ejecutar repcacheman para que elimine ficheros duplicados de la caché proxy, y también para que añada los nuevos ficheros a la caché. Esto no es necesario cuando hacemos emerge –sync o comando equivalente.
# emerge -Du world && repcacheman
o bien,
# emerge -Du world
# repcacheman
Para terminar, hay que hacer sólo un pequeño cambio en el fichero /etc/make.conf de cada máquina gentoo que queramos que use el proxy. Debemos añadir la línea http_proxy=”http://nombre_o_ip_del_servidor_proxy:8080″
Con esto ya tendremos funcionando nuestro proxy para portage. Espero que sea de utilidad para álguien.
¡Hasta otra!
4 Comentarios »
|