Los botones del brillo no funcionan en Linux con una gráfica de Intel y i3 WM

Si estás usando i3 WM en Linux con una gráfica moderna de Intel, probablemente estés utilizando el driver de Mesa. En este caso el problema es que la orden «xbacklight«, que es la que utiliza el script por defecto, no te va a funcionar.

Yo estoy utilizando Endeavour OS con su configuración por defecto para i3 WM, y claro, me molestaba bastante no poder bajarle el brillo al portátil cuando no estaba conectado a la red eléctrica. La solución es cambiar la orden «xbacklight» por una llamada a «brightnessctl» equivalente.

Para ellos vamos a editar el archivos «~/.config/i3/scripts/volume_brightness.sh» y haremos los siguientes cambios:

--- volume_brightness-old.sh	2023-11-28 22:32:59.867716528 +0100
+++ volume_brightness.sh	2023-11-24 17:58:54.184428340 +0100
@@ -21,7 +21,10 @@
 
 # Uses regex to get brightness from xbacklight
 function get_brightness {
-    xbacklight | grep -Po '[0-9]{1,3}' | head -n 1
+    max=`brightnessctl m`
+    actual=`brightnessctl get`
+    echo $((actual*100/max))
 }
 
 # Returns a mute icon, a volume-low icon, or a volume-high icon, depending on the volume
@@ -84,13 +87,15 @@
 
     brightness_up)
     # Increases brightness and displays the notification
-    xbacklight -inc $brightness_step -time 0 
+    brightnessctl set +$brightness_step% 
     show_brightness_notif
     ;;
 
     brightness_down)
     # Decreases brightness and displays the notification
-    xbacklight -dec $brightness_step -time 0
+    brightnessctl set $brightness_step%- 
     show_brightness_notif
     ;;
 esac

Y lo tenemos. Ahora ya podemos subir y bajar el brillo sin problemas.

Emular terminal desde PHP en Servidores Virtuales Gestionados (caso de Comvive)

Desde que trabajo en Pórtico Legal quería empezar a usar el sistema de control de versiones (yo siempre lo uso y aquí no tenían nada, una locura) y poder usarlo para los despliegues en preproducción y producción como solución intermedia hasta que tengamos algo más avanzado. Hasta la fecha se estaban haciendo mediante ftp con todos los problemas que eso supone, entre ellos los siguientes y sus posibles soluciones:

  • Mientras se ha subido un archivo y se está subiendo otro que depende de este la web se puede romper, lo más probable es que ocurra. Esto no se solventa completamente usando git sobre un único servidor pero se minimiza muchísimo.
  • Nunca se sabe que versión está en producción. En algunos momento se habían subido archivos por diferentes personas y una no sabía lo que había subido la otra.
  • Si se toca algo en el servidor un simple «git status» te lo va a chivar, y un simple «git checkout …» te va a solucionar la papeleta.
  • Se va a poder desplegar nuevas versiones simplemente etiquetando y haciendo un «git checkout tag«

 

Aquí el problema venía por parte del hosting de comvive que al ser un VPS gestionado no te dan cuenta de shell. Para solucionarlo al final utilicé un pequeño script php que ejecutaba la orden que le pasas como parámetro:

<?php

$command = $_GET[«command»];

$res = execute($command, __DIR__ . ‘/..’);
echo «<pre>»;
echo «\nCódigo de salida: » . $res[‘code’];
echo «\n» . $res[‘out’];
echo «\nSalida de error:\n» . $res[‘err’];
echo «</pre>»;

function execute($cmd, $workdir = null) {
if (is_null($workdir)) {
$workdir = __DIR__;
}

$descriptorspec = array(
0 => array(«pipe», «r»), // stdin
1 => array(«pipe», «w»), // stdout
2 => array(«pipe», «w»), // stderr
);

$process = proc_open($cmd, $descriptorspec, $pipes, $workdir, null);

$stdout = stream_get_contents($pipes[1]);
fclose($pipes[1]);

$stderr = stream_get_contents($pipes[2]);
fclose($pipes[2]);

return [
‘code’ => proc_close($process),
‘out’ => trim($stdout),
‘err’ => trim($stderr),
];
}

 

La etiqueta pre la utilizo para que la salida se vea bien si la llamamos desde un navegador. Pues bien, una vez subido podemos ejecutar cualquier orden como:

https://dominio/path/script.php?command=orden

Pero como estarás pensando esto no es seguro. Lo que hice yo es meterlo en un directorio y en este meter un .htaccess para que sólo yo tuviera acceso.

Al final lo único que quería era poder usar git, así que me creé un shell script con wget para llamar a esta url. El script es tal que así:

#!/bin/bash

domain=»»

command=»wget -qO – \»http://$domain/commands/command.php?command=git $*\» | sed ‘1d’ | sed ‘\$d'»
echo «Dominio: $domain»
echo «Parámetros: $*»
eval $command

 

Ahora sólo hay que darle permisos de escritura y en mi caso lo he llamado rgit y lo he puesto en el path por comodidad. Esta sería una salida de la orden «rgit status -s«, en este caso un status limpio:

Dominio: www.dominio.com
Parámetros: status -s
Código de salida: 0
Salida de error:

Lo suyo es que el directorio .git con todo el ínidice esté fuera del htdocs del servidor, para ello se puede usar el parámetro –work-tree de git. Si por algún motivo no puede estar fuera podéis utilizar de nuevo un .htaccess para que nadie pueda entrar:

 

deny from all

 

Y con esto he conseguido un rodeo para poder usar una «shell» remota a través de un script PHP. Espero que os sea de ayuda.

 

 

 

Calidad del Soporte de Openbravo 2

Tenía mucha curiosidad por saber cual era la tabla de nivel de soporte de Openbravo y finalmente he tenido acceso a ella. Cómo a Openbravo le gusta mucho compararse con Red Hat me he puesto a mirar una y otra a ver que diferencias había.

 

Red Hat SLA

 

Openbravo SLA

 

A simple vista se ve la influencia de Red Hat, Openbravo copia el mismo esquema pero lamentablemente ahí terminan las similitudes. Mientras que los tiempos de respuesta de Red Hat se miden en horas o días los de Openbravo se miden en días o semanas, y yo puedo dar fe de ello. Y no creais que es porque el soporte de Openbravo es más barato, más bien lo contrario. Por poner un ejemplo, la suscripción de Red Hat Enterprise Linux Server para 2 sockets, 1 nodo físico o 2 virtuales en la modalidad de suscripción estándar cuesta $799 al año. Una suscripción de Openbravo estándar para el back-office cuesta $500 al año por usuario concurrente, si le añades el WebPos privativo entonces son $175 más por terminal y año.

A ver si en una próxima ocasión comparamos los precios de Openbravo con los de OpenERP. Ya os adelanto que en este sentido los dos van muy parejos, eso sí, las propuestas son diferentes, OpenERP ofrece soporte sobre su sistema tanto alojado en su nube como en una instalación en nuestras dependencias mientras que Openbravo sólo ofrece la segunda opción, almenos hasta donde yo se.

 

Cheli

Red Hat en los TPV (terminal punto de venta) del supermercado «Mi Comisariato» de Quito

El que se use Gnu / Linux en prácticamente cualquier sistema dejó de ser noticia hace mucho tiempo, pero a mi no deja de llamarme la atención. En este caso me sucedió que cuando fuí a pagar en el supermercado «Mi Comisariato» del centro comercial Quicentro de Quito me di cuenta que la interfaz del TPV me sonaba, y resulta que era una versión antigua de KDE, parecía una versión 3, la aplicación de TPV parecía desarrollada en QT y al salir ya de mi caja me di cuenta que en el resto estaba el logo de Red Hat. Por deducción debe tratarse de un Red Hat Enterprise Linux 4 o 5.

 

El Comisariato

Un saludo.

 

Cheli

Fedora y OpenSuse cambian Mysql por MariaDB

Es un tema que he revisado varias veces y personalmente ya había decidido utilizar MariaDB en mis nuevos proyectos. El caso es que estaba viendo el anuncio de OpenSuse 12.3RC1 y justamente uno de los cambios era este. Revisando los enlaces he llegado a un artículo de finales de enero donde se confirmaba que tanto Fedora como OpenSuse harán el cambio. Por lo visto Oracle replicó en la lista de Fedora porque no les parecía bien, argumentando que su trayectoria desarrollando InnoDB, Mysql y Linux les avala. Muy buena la respuesta por parte de Fedora, «En efecto, vuestra trayectoria os avala, estamos seguros que los desarrolladores de Solaris están de acuerdo con eso. Nosotros en Fedora valoramos la apertura y la libertad».

 

A ver cuando llega el cambio a Debian que es la distro que suelo utilizar, aunque bueno, siempre tenemos la posibilidad de agregar el repo correspondiente.

 

Cheli

Kill y la gestión de procesos en GNU/Linux

La semana pasada volví a grabar para el podcast Enredando. Está vez tuvimos varios problemas con la grabación, varios cortes y al final ya no escuchaba correctamente a Mikel. Después de escucharlo no ha quedado tan mal, eso sí, me trababa en algún momento, pero es que entre que estaba ya nervioso y que tenía que imaginarme lo que me estaba diciendo Mikel para poder contestarle, pues salió lo que salió :D.

 

469 Software Libre

 

Cheli

 

Optimización del rendimiento en Mysql

En el podcast de Java Hispano hacen referencia a esta conferencia sobre optimización en Mysql.

 

 

Me ha gustado bastante, explica algunos truquillos como ejemplos de consultas y índices, optimización de consultas o pruebas de rendimiento.

 

Cheli

Balanceadores: ldirectord vs haproxy

Hace unas semanas os comenté un taller de replicación en mysql, pues desde hace un par de días ya tenemos disponible el segundo taller sobre balanceadores. Igual que dije la vez anterior me ha parecido muy interesante y muy bien explicado todo. Estos talleres los ofrece una empresa de Madrid, si estáis por allí tenéis la posibilidad de asistir presencialmente y sino pues podéis hacer como yo y seguirlos en youtube. Ya han anunciado un nuevo taller de como montar un Cluster Apache con PHP y Memcached y una charla sobre estos temas.

 

 

Cheli

Replicación MySQL

Vi este curso en Barrapunto y lo he seguido desde youtube. Me ha parecido interesante, muy bien explicado, con un ritmo muy bueno que hace que el taller se haga ameno. Si estás interesados en este tema os lo recomiendo.

 

 

Cheli