El Historias » linux

Módulos en Perl multiplataforma

dayer — Sat, 25 Feb 2012 02:54:35 +0000

El lenguaje Perl permite escribir scripts multiplataforma sin demasiados problemas. Aunque siempre puede haber algunos impedimentos como por ejemplo la carga de módulos que no están disponibles para todos los sistemas operativos. Aquí va un ejemplo con Linux y Windows.

Puede darse el caso de necesitar un script que pueda correr como demonio en Linux o servicio de sistema en Windows. Para el segundo entorno el asunto se complica dado que se necesita de un módulo como Win32::Daemon, el cual si intentamos endosarle a Linux nos dirá que tararí. Y es que, aunque pudiera parecer suficiente con algo así:

if($^O ne 'linux'){
  #Estoy en Windows
  use Win32::Daemon;
  #...
}

El script fallará cuando se ejecute en Linux porque no encuentre el módulo Win32::Daemon. A pesar de que sólo deba cargarlo en el caso de no estar funcionando en Linux. Pero gracias a eval y require algo se puede arreglar:

if($^O ne 'linux'){
  #Estoy en Windows
  eval{require Win32::Daemon;};
  #...
}

De esta manera Linux pasará por el aro y Windows hará lo que esté indicado. Sin embargo puede darse el caso de módulos que necesiten recibir un hash en el momento de su carga, como el caso de Win32::Daemon::Simple —versión simplificada de Win32::Daemon—, y para los que habrá que hacer la carga desde otro script que será requerido desde el principal:

#servicio.pl
use Win32::Daemon::Simple
  Service => 'follonero',
  Name => 'servicio follonero',
  #...
  ;

#script principal
if($^O ne 'linux'){
  #Estoy en Windows
  require 'servicio.pl';
  #...
}

De esta forma Linux no se pasará de listo inspeccionando y Windows hará lo que se espera de él.

Esto de la portabilidad entre scripts tiene su atractivo. En el caso de servicios el lidiar con la carga de módulos es sólo la punta del iceberg, seguida por el manejo de archivos, directorios, detección de señales, etc.

Inspiración → How can I detect the operating system in Perl? @ Stack Overflow.

Compartir esta entrada en:

Cosas relacionadas:

Aumentando la seguridad de SSH en Linux

dayer — Thu, 16 Jun 2011 22:03:54 +0000

Por defecto el acceso remoto utilizando SSH suele ocurrir a través del puerto 22 y permitir la identificación directa como root. Demasiado obvio para cualquier atacante. Sin embargo a la seguridad de los servidores siempre se le puede dar una vuelta de rosca más para intentar que cualquier asaltante desista de su intento, o se convierta en un reto para él. Unos consejos para intentar, no siempre con éxito, desquiciar a malhechores:

Cambiar el puerto en /etc/ssh/sshd_config por el 6969 —por ejemplo :
```
Port 11810
```
Cambiar el tiempo de espera en segundos para identificarse —en el mismo archivo— por un valor inferior
```
LoginGraceTime 30
```
No permitir acceder directamente como root; para ello se puede utilizar el su root una vez identificado un usuario normal —también en /etc/ssh/sshd_config
```
PermitRootLogin no
```

Estos son básicos. Luego hay mil y un consejos más que pueden llegar a hacer estallar a los administradores cuando estén llenos de nervios intentando resolver algún problema que tiene inutilizado el servidor. De primeras parecen muy útiles pero no siempre serán deseables:

Cerrar la sesión de root por inactividad, que si el administrador se despista y se olvida del asunto no pueda luego llegar un pillo en persona y aprovecharse. En /root/.bashrc se añade el tiempo en segundos:
```
TMOUT = 300
```
aunque si se prefiere que sea para todos los usuarios se puede añadir en /etc/profile:
```
readonly TMOUT = 300
```
Limitar las direcciones IP desde las que poder conectarse —si el demonio de SSH tiene soporte para TCP Wrappers— añadiendo al archivo /etc/hosts.deny:
```
sshd : ALL
```
y a /etc/hosts.allow las direcciones IP autorizadas:
```
sshd : IP1,IP2,IP3,IPn
```
Limitar con iptables el número máximo de conexiones por minuto, útil por ejemplo contra los ataques por fuerza bruta para el puerto configurado para SSH (6969):
```
iptables -A INPUT -p tcp --dport 6969 -m limit --limit 3/minute -m state --state NEW -j ACCEPT
```
Bloquear el puerto para el primer intento de conexión y aceptar conexiones a continuación en el plazo de un minuto. Práctico para intentar esconder que el puerto está abierto ante escaneos de puertos:
```
iptables -A INPUT -p tcp --dport 4587 -m limit --limit 1/minute -m state --state NEW -j DROP
```
OJO: esta regla se ha de aplicar antes de la del punto anterior.

Esto ha sido en cuanto a SSH. No obstante hay un montón de reglas más para ipfilter válidas para otros servicios del servidor, ajustes del núcleo, eliminar la consola para usuarios de sistema, etc. Muchas vulnerabilidades que pueden ser detectadas con la herramienta Tiger.

Fuente → Reforzando la instalación de Debian GNU/Linux [esdebian.org].

Compartir esta entrada en:

Cosas relacionadas:

Corregir ruidos en Flash para Linux AMD64

dayer — Fri, 10 Jun 2011 13:03:05 +0000

Cada año o así a la gente de Adobe le suele surgir un problema con su plugin de Flash para Linux sobre la plataforma de 64 bits, concretamente la versión 10.3 d162. Esta vez se trata de unos ruidos molestos que aparecen en vídeos, juegos y demás donde dicho plugin tenga que entrar en marcha. En mi caso se me asemejan a cortes y distorsiones que se repiten a lo largo de toda la reproducción. Pero de momento tiene arreglo.

Según comentan en la sección de bugs se trata de problemas que tiene Flash con la implementación memcpy de glibc. Mientras glibc lo corrige en la distribución que utilicen, o Adobe en sus siguientes versiones —lo cual sí que sería novedoso— hay que usar un parche:

Instalar si no lo está el paquete bspatch.
Descargar el parche de aquí o de este hilo de los informes de errores de Adobe.
Copia de seguridad de la librería por si las moscas: # cp /usr/lib64/flash-plugin/libflashplayer.so /usr/lib64/flash-plugin/libflashplayer.so.old
Ubicarse en la consola en donde se halle guardado el parche descargado.
Parchear la librería con: # bspatch /usr/lib64/flash-plugin/libflashplayer.so.old /usr/lib64/flash-plugin/libflashplayer.so ./memcpy-10.3.162.29.bsdiff
Cerrar y volver a abrir el navegador web y probar si funciona.

Ojo: # indica que han de ejecutarse los comandos desde root o mediante sudo … Como corresponda a cada sistema.

Compartir esta entrada en:

Cosas relacionadas:

Enviar menos información sobre Apache

dayer — Fri, 08 Apr 2011 01:57:58 +0000

Por el motivo que sea puede que quieran que el servidor web Apache desvele algo menos de información de la que acostumbra. Para ello hay un par de directivas muy interesantes y que se configuran, al menos en el caso de Debian, en el archivo /etc/apache2/conf.d/security:

ServerSignature. Es la más conocida y la responsable de que cuando Apache devuelve un documento generado por él mismo, como mensajes de error, en el pie del mismo informe de su versión, sistema operativo, correo del administrador,.. Para evitarlo se cambia su parámetro a off, quedando: ServerSignature Off.
ServerTokens. Es la que dice qué información se devuelve, tanto en el pie de página —si lo está— como en las cabeceras de la respuesta del servidor web. Tiene varios niveles de mostrar información. El más restrictivo consiste en sólo informar del nombre del servidor web: Apache. Esto se logra con el parámetro Prod: ServerTokens Prod.

Apache sería pues un poco más disimulado con la información del servidor web que envía al cliente —también a nivel de cabeceras:

Compartir esta entrada en:

Cosas relacionadas:

Problemas de desplazamiento en Debian con ATI

dayer — Wed, 05 Jan 2011 01:03:30 +0000

Llevaba yo un tiempo usando felizmente la aceleración gráfica con los drivers libres, aunque no sin algunas deficiencias en cuanto a aceleración gráfica y el manejo de ventanas y algunos desplazamientos —el llamado scroll en inglés. Y como soy un leal salsero allá que me aventuré a volver a los tiempos de los drivers privativos, que tiempo atrás tuve que abandonar por unas incompatibilidades de ATI con la versión 7.5 de X.Org.

En realidad, las cosas como son, estos son mejores siempre y cuando sigan soportando la tarjeta gráfica .Para las antiguas los libres sí que son fieles y nunca las abandonan. Pero con los privativos bien instalados es fácil apreciar cómo el entorno va más liviano. El contenido de los navegadores web parece que pesara menos. Sin embargo las nuevas tecnologías de aceleración aún no están muy pulidas y causan inestabilidades en cuanto al abanico de aplicaciones que las toleran bien. Por ejemplo en el navegador Opera el desplazamiento vertical va de lujo, pero en Chromium o Evince tironea y en Iceweasel directamente faltan partes del navegador si son versiones anteriores a la cuatro, o de lo contrario tironea cuando se encuentra con contenido distinto de texto, como imágenes.

Pero como casi todo tiene arreglo, esto también lo tiene. Volver por el momento a XAA mientras EXA sigue evolucionando y sacrificar algo de velocidad, aunque la vista agradecerá un entorno gráfico fluido. En el caso del driver libre bastaba con editar el archivo de configuración del X.Org, pero para el privativo es necesario utilizar un comando que viene a deshabilitar esa aceleración 2D que todavía da los problemas antes descritos. Como root y fuera de las X, con ellas desactivadas:

aticonfig --set-pcs-str=DDX,ForceXAA,TRUE

y santas pascuas. Por lo visto esto tiene algo que ver con X.Org y por ello, según dicen, otra solución es actualizar la versión de X.Org a la 7.6, pero en mi caso eso todavía está en la rama experimental de Debian y de momento no me convencen el jaleo de dependencias que Aptitude me propone.

Fuente → Scrolling problems Iceweasel (Radeon HD 3850 problem?) @ NGINX.

Compartir esta entrada en:

Cosas relacionadas:

Arreglando reconocimiento de cámaras para gThumb y Shotwell en Debian

dayer — Sat, 09 Oct 2010 03:29:44 +0000

Resulta que con las versiones para Debian testing o unstable de gThumb y Shotwell ahora las cámaras de fotos no son reconocidas como tales por este par de aplicaciones. Al menos con la Canon Digital IXUS 60 que lo he intentado. Gnome detecta una cámara y pregunta con qué abrirla —gracias al paquete gnome-volume-manager—, pero cuando le indico que la abra con gThumb el programa no detecta la cámara ni muestra las fotos que contiene. Con Shotwell pasa algo parecido, pues lo abro y no detecta cámara alguna o la mostraría en su barra lateral.

Pero el problema en realidad, salvo que se recurra a la versión de gThumb para lenny, está en udev y las reglas que libgphoto2 le indica sobre cada cámara. Le faltan un par de propiedades para que estos se enteren de que es una cámara lo que está conectado:

ID_GPHOTO2 = 1
GPHOTO2_DRIVER = proprietary

Así que hay dos soluciones:

Añadirle las propiedades necesarias a dichas reglas.
O extraer la tarjeta de memoria de la cámara e insertarla en el típico lector de tarjetas. Además suelen transferir a mayor velocidad al ordenador que la propia cámara.

Pero no siempre se dispondrá de un lector de tarjetas, o habrá a quien le guste complicarse la vida. Estos son los pasos que yo he seguido:

Conectar por USB la cámara de fotos al ordenador.

Extraer el identificador del fabricante y del producto, por ejemplo con dmesg.

$ dmesg
[...]
[ 3163.740042] usb 1-2: new high speed USB device using ehci_hcd and address 21
[ 3163.896554] usb 1-2: New USB device found, idVendor=04a9, idProduct=311c
[ 3163.896559] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3163.896562] usb 1-2: Product: Canon Digital Camera
[ 3163.896564] usb 1-2: Manufacturer: Canon Inc.
[ 3163.896707] usb 1-2: configuration #1 chosen from 1 choice
[ 3186.295973] usb 1-2: USB disconnect, address 21
[...]

Lo importante, en este caso, es idVendor=04a9 e idProduct=311c.
Editar el archivo /etc/udev/rules.d/025_libgphoto2.rules y buscar donde ponga 311c, comprobando que pertenezca a la propiedad idProduct y que la idVendor correspondiente valga 0419, y añadir en la misma línea el par de propiedades que le faltan separadas también por comas.
Originalmente:
```
# nano /etc/udev/rules.d/025_libgphoto2.rules
[...]
ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="311c", MODE="0664", GROUP="plugdev"
[...]
```
Resultando:
```
[...]
ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="311c", ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary", MODE="0664", GROUP="plugdev"
[...]
```
Guardar los cambios. En el caso de nano es con Ctrl+O.
Recargar udev.
```
# /etc/init.d/udev reload
```
Volver a conectar la cámara de fotos al ordenador y a esperar tener suerte con gThumb y Shotwell.

Fuente → Debian Bug y Launchpad.

Compartir esta entrada en:

Cosas relacionadas:

Varios protocolos de mensajería instantánea con Empathy

dayer — Fri, 08 Oct 2010 00:09:45 +0000

Pantallazo de lista de contactos en Empathy

Con los tiempos que corren raro es quien no utiliza ninguna vía de comunicación a través de mensajería instantánea. Con raro no me refiero a marginal, ojo. Más raro es aún quien sólo utiliza la respectiva a un solo programa. Pero para nada raro es que la gente tenga abierta a la vez dos, tres, cuatro, o las que sean aplicaciones para manejar a la vez tanto programa o protocolo de mensajería.

Motivos los hay muchos. Yo por ejemplo siempre había pensado que la gente importante la tengo en cualquiera, además de en otros medios más propios de toda la vida, pero con el tiempo he ido comprobando que eso no es así. Pepito usa Google Talk porque es el único que le funciona desde el trabajo, Fulanito Skype porque lo lleva en el móvil último modelo, Menganita Facebook que es lo único que no le bloquean en el trabajo, Perico de los palotes Messenger y a través de una web que utiliza un proxy para saltarse las restricciones,.. y así un enorme etcétera.

Y para intentar aglutinar a tanto contacto disperso existen para Linux programas como Empathy y Pidgin —deriva del archiconocido Gaim y está para otras plataformas también—, que permiten utilizar Messenger, Facebook, Google Talk, Skype, ICQ, Yahoo!, AIM, Jabber, MySpace,.. y hasta el IRC de siempre. Cada uno con sus limitaciones puesto que por separado cada invento de estos tienen sus mil y una cosas como iconos personalizados, zumbidos, enviar archivos, compartir carpetas, webcam, sonidos, videollamadas ¡y hasta compartir fondos melosos con las churris! Pero para quien se limite al uso sencillo de escribir y leer le sobra con este par de programas. Mi cantidad de iconos junto al reloj del escritorio y de pestañas del navegador ha disminuido considerablemente. Y eso que también disponen de posibilidad de añadirles Twitter.

Compartir esta entrada en:

Cosas relacionadas:

Mitter el cliente de Twitter desaparece

dayer — Thu, 09 Sep 2010 23:51:13 +0000

Julio Biason, el desarrollador de Mitter, informó ayer en su blog [http://juliobiason.net, en inglés] del abandono en el desarrollo y mantenimiento de dicha aplicación. Hace unos meses lo mencioné en una entrada sobre clientes de Twitter para Debian Lenny, aunque donde funciona bien es en versiones más al día. La verdad que tardé un tiempo en probarlo, pero me llamó mucho la atención por su ligereza y poco consumo de recursos, aunque en su contra tenía la ausencia de un recortador de direcciones y gestor de mensajes directos.

El autor aludió principalmente a dos razones que le han llevado a abandonar el proyecto. La más grande explicó que es la manera en que Twitter está manejando la implementación del protocolo OAuth, que no hace mucho caso de los desarrolladores y ello complica su inclusión en los clientes de código abierto. La segunda, el verdadero «ya ha sido suficiente» según él, fue cuando señaló que los usuarios bloqueados todavía aparecían en la timeline, y obtuvo por respuesta que el bloqueo debía hacerse en el lado del cliente. Y este par de desavenencias junto con la mala leche que te va generando error tras error que hay que andar corrigiendo cuando programas pues han acabado por hacer que se le quiten las ganas de seguir con el asunto. No obstante pone el código fuente a disposición de quien lo quiera y se ofrece para ayudar en dudas con el diseño o a quien quiera hacer una nueva versión.

Yo lo entiendo. Desarrollar por amor al arte es bonito, le dedicas el tiempo que te da la gana, pero cuando empiezan a surgir demasiados cambios y en donde se supone que dan soporte pasan de ti o te dan largas, cansa. Y lo digo ahora mismo que estoy un poco aburrido ya de la desgana de los desarrolladores de SilverStripe en sus foros.

Compartir esta entrada en:

Cosas relacionadas:

Solucionar errores con caracteres inválidos en /var/lib/dpkg/available

dayer — Thu, 09 Sep 2010 08:31:15 +0000

Llevaba unos días encontrándome al actualizar paquetes en Debian testing el siguiente error:

atención, in file ‘/var/lib/dpkg/available’ near line 48034 package ‘virtualbox-3.0′: error in Version string ’3.0.12-54655_Debian_lenny’: invalid character in revision number

Al parecer se trata de un error con los caracteres utilizados en la versión del paquete Virtualbox-3.0, que encima ya ni tengo instalado. Y hoy echando un vistazo he dado con que a más gente le ocurre [bugs.debian.org], también algún español [linuxparatodos.net], y he dado con la solución [azitech.wordpress.com]. Es decir:

# dpkg --clear-avail

que «elimina la información sobre qué paquetes están disponibles» como dice el manual de dpkg. Aunque también es posible solucionarlo comentando el repositorio correspondiente al paquete que da el error, actualizando, y descomentándolo. O supongo que también vaciando el contenido del archivo /var/lib/dpkg/available.

Compartir esta entrada en:

Cosas relacionadas:

Iceweasel 4.0 beta 4

dayer — Sun, 05 Sep 2010 12:27:31 +0000

Hoy miren por donde me ha dado por probar en un momentico a ver cómo va el Iceweasel 4 —Firefox 4 en otros lugares. Concretamente en su cuarta versión beta. Y la verdad que me ha parecido más ligero con trece pestañas abiertas que la por ahora versión estable 3.6.8. Pero de momento por muchas extensiones que digan que ya son compatibles con él —dicen que más de mil [bitelia.com] de las más de trece mil que acabo de contar—, a mi por ejemplo de nueve sólo me ha seguido funcionando una.

Es posible probarlo sin necesidad de instalarlo, y por mi parte lo recomendable. Muy sencillo de instalar en Debian y similares, como indican en Glandium [en inglés]. A mi me han funcionado estos pasos en Debian testing:

Instalar xulrunner-2.0 y libmozjs4d_2.0. Se descargan estos .deb de los repositorios para Mozilla en Debian.net seguidos de un #dpkg -i para instalarlos.
Descargar iceweasel_4.0~b4-0_.deb, pero no instalarlo, extraerlo en donde se quiera tener la aplicación con dpkg-deb -x iceweasel_4.0b1-0_*.deb /ruta/dondesequiera.
Crear el enlace simbólico: ln -s /usr/lib/xulrunner-2.0 /ruta/dondesequiera/usr/lib.
Y cada vez que se quiera usar abrirlo con: /ruta/dondesequiera/usr/bin/iceweasel.

A ver si se dan prisa y se aplican bien estos de Mozilla, que Chromium —Chrome— me va como una bala.

Compartir esta entrada en:

Cosas relacionadas: