Archivo de la categoría: Sistemas Operativos

Todo lo relacionado con la administración y funcionamiento interno de un sistema operativo.

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