QuarkBlog_2.0

Este es el primer post sobre hacks del Raidsonic Icy Box NAS-4220-B y en él voy a explicar cómo instalar un servidor SSH para conectarnos de forma segura a través de Internet o de una red inalambrica.

El primer paso es actualizar el firmware del aparato a la última versión disponible (en este momento es la 2.6.0.IB.1.RS.1). Esta actualización incluye acceso remoto mediante telnet que aprovecharemos para modificar ciertos parámetros del sistema.

El servidor SSH es un paquete oficial disponible en la pagina web del fabricante. Para instalarlo hay que conectarse al NAS mediante FTP/SMB/NFS con el usuario admin y dejar el archivo ssh-server.tgz en la ruta /public/applications/new_software.

Después de esto, reiniciamos la máquina y ella sola instala el software en los directorios correspondientes. Esta manera de instalar cosas me ha gustado mucho.

Ahora viene el problema: por lo visto alguien en Raidsonic con una mente preclara ha hardcodeado los paths de los binarios a /mnt/IDE1. Este es el punto de montaje de los discos, pero cambia en función de la cantidad y la configuración de los discos que tengas puestos (RAID0, RAID1, JBOD, etc.).

En mi caso el punto de montaje es /mnt/ide3 (en minúscula), con lo que el servidor SSH se instala pero nunca llega a ejecutarse porque no encuentra sus librerías ni sus archivos de configuración.

A mi todo esto me huele un poco mal. Vale que Raidsonic no es una multinacional del software, pero este es un error de bulto que está en la web desde hace tiempo en un paquete “oficial”. Me parece trabajo de becarios mal pagados, porque eso de poner las rutas en mayúsculas y hardcodeadas muy profesional no suena. Pero bueno, hay una solución sencilla.

Podemos hacer un enlace simbólico que apunte al punto de montaje correcto y todo funcionará como se espera. Para esto necesitamos una shell del sistema mediante telnet.

El acceso a traves de telnet no está habilitado por defecto, para activarlo hay que ir a la siguiente URL http://[ip del nas]/cgi/telnet/telnet.cgi y marcar el checkbox (curiosamente el acceso a telnet no sale en el interfaz web, está escondido).

Nos logeamos como root con la contraseña del usuario admin y ya tenemos shell.

En mi caso el enlace simbólico quedaría de la siguiente manera:

Para comprobar que el servicio se inicia correctamente, vamos al directorio de la aplicación y ejecutamos el script de inicio:

Finalmente, activamos el servidor SSH desde el interfaz web y probamos la conexión.

Debido a la combinación de memoria flash + partición en disco que utiliza el NAS para ejecutar el sistema, este enlace simbólico se pierde cada vez que reiniciamos la máquina.

Esto se soluciona instalando el paquete userscript (descarga) que permite ejecutar scripts personalizados durante el arranque del sistema, una especie de cron para que nos entendamos.

El comando para lanzar el servidor es el siguiente:

Justo termino de leer Beautiful Code: Leading Programmers Explain How They Think, por recomendación indirecta del gaditano, y me invade una paz Zen y una satisfacción interior difícil de describir.

Este libro es especial; no es el típico libro técnico, se podría decir que es un recopilatorio de poemas escritos en C, Python, Perl, Lisp, … por los mejores poetas que este peculiar arte ha dado a la humanidad. Tienen su espacio en el libro piezas como Map/reduce (el mecanismo que utiliza Google para escalar hasta el infinito sus sistemas), el Mars Rover de la NASA (una de las misiones más exitosas de toda la carrera espacial), Gene Sorter (un programa que facilita la investigación del Proyecto Genoma Humano) y, mi preferido, el Delta Editor de Subversion.

Te inspira a programar, a ser elegante y cuidadoso con tu código, a mimarlo y presumir de él. Sólo el libro de Kernighan & Ritchie sobre C llegó a hacerme ver esa belleza en un puñado de ceros y unos.

Citando al gaditano:

La programación es una forma de entender los problemas de forma lógica y una forma de abstracción y casi si me da el día pedante digo que una manera de entender la vida. Habré escuchado (y pensado) más de una vez que esa tendencia tan cerebral de pensar que todo es información y todo es un problema cuya solución puede encontrarse puede joderte la vida de la manera más miserable y es que pese a que nos intenten siempre poner a los constructores de puentes como modelo de elegancia a imitar en nuestros desarrollos, la programación (el sentarse a resolver problemas sistemáticamente, día a día y del modo más elegantemente posible) tiene mas puntos en común con las artes que con cualquiera de las ciencias.

Si para ti programar es una pasión, leelo.

Si programas por dinero, coge un PC-Actual y lárgate de aquí.

Está movidito este comienzo de año, el otro día Sun compró MySQL, Oracle compró BEA (que no lo dije) y hoy Nokia hace una oferta pública a Trolltech que acabará en compra de un momento a otro si no se ha materializado ya. Viva el capitalismo.

Trolltech es una empresa noruega que hasta la fecha vivía de vender licencias de la librería Qt, una librería que permite construir aplicaciones multiplataforma (Linux, OSX y Windows) de manera sencilla y que constituye el pilar principal sobre el que está construido KDE. En los últimos meses hemos podido ver mucho feedback entre Trolltech y KDE: algunas tecnologías desarrolladas para KDE 4 han pasado a Qt y viceversa.

Creo que a Nokia no le interesa Qt, lo que pasa es que le han visto las orejas al lobo y su hegemonía en el mercado de los móviles se puede ver comprometida con Google Android; así que como más vale prevenir que curar, se hacen con Qtopia y el proyecto Greenphone (que viene a ser la plataforma de desarrollo de Trolltech para dispositivos móviles).

No se si es un movimiento estratégico para que nadie más entre en competencia o realmente van a utilizar esta tecnología, recordemos que Nokia ya lleva tiempo jugando con la plataforma Maemo. El futuro de Maemo está un poco en el aire, lo más probable es que recoja el testigo Canonical para el Ubuntu Mobile.

En cualquier caso, tanto por un lado como por el otro, Linux y software libre en los todos teléfonos móviles. Menos los iPhone de Apple, los SmartPhone de Microsoft y lo que queda todavía con Symbian.

¿Cual será la plataforma para dispositivos móviles dentro de 3 años?. Lo que utilicen los chinos. Y me da a mi que no va a ser ni el iPhone ni el Windows Mobile …

PD. Qt y KDE siguen como hasta el momento y sin previsión de cambio.

Links

• Comunicado oficial de Trolltech
• Comunicado oficial de Nokia
• Google Android
• Qtopia
• Maemo
• GreenPhone

PDO es una de las muchas abstracciones de acceso a datos que existen en PHP que intenta unificar la manera en la que PHP habla con las bases de datos. La característica que diferencia a PDO del resto es que está escrito en C y no en PHP (con lo que utiliza drivers nativos y esta enfocado en ser rápido y eficiente).

Wez Furlong quiere convertir a PDO en la manera estándar de acceso a datos para PHP, para ello ha estado rediseñando la arquitectura y los interfaces de “PDO versión 2″ para producir una especificación abierta en la que los fabricantes de bases de datos puedan construir drivers, ampliar y mejorar la cobertura de tests unitarios y mejorar los metadatos.

Para obtener la atención de los fabricantes, especialmente IBM, ha propuesto un Contributor License Agreement para facilitar la inclusión de código por parte de las empresas privadas (existen problemas legales por la cesión de propiedad intelectual a un proyecto open source). Existe una versión para empresas y otra a título individual, y la licencia de PDO que es diferente a la de PHP. Wez también ha preparado un FAQ sobre todas las cuestiones legales de este asunto.

Este movimiento ha causado sentimientos enfrentados dentro de la comunidad de desarrolladores de PHP: mientras que Jay Pipes (MySQL) opina que no es para tanto, hay otras muchas personas que han puesto el grito en el cielo. Y es que el conflicto está en que todo aquel que quiera aportar código a PDOv2 o simplemente leer la especificación debe firmar el CLA y atenerse a sus condiciones. Lo que lo convierte en esencia en software no-libre.

PHP no es GPL (su licencia es incompatible) pero es considerado software libre. El requisito de firmar una CLA antes de remitir código o mirar la especificación de PDO v2 elimina directamente la libertad 3 (libertad para mejorar el programa y distribuir cambios al público, por los que se beneficia toda la comunidad), haciendo a PDO no-libre.

Dado que la GPL no se aplica a PHP ni a PDO, veamos la definición de software libre que proporciona la OSI que es más o menos lo que viene a decir el contrato social de Debian haciéndolo un poco más universal. Aquí ya me pierdo un poco (no soy abogado y es posible que me equivoque en muchas de estas cosas) pero creo que la obligación de firmar una CLA viola el espíritu de la definición de la OSI así como los puntos 3 y 5 de la carta.

La inclusión de CLAs es algo nuevo en el mundo de PHP pero es habitual e inevitable en otros proyectos de gran calado e importancia empresarial como Apache o Mozilla. El software libre no es sólo código abierto, es participación y las CLAs ponen trabas al libre intercambio de información porque determinadas empresas podrían influir negativamente en el desarrollo de PDO desplegando su cartera de patentes y segmentaría a los desarrolladores en dos grupos irreconciliables: los que la firman y los que no. Si alguien en PHP necesita drivers privativos para acceso a datos es mejor que estén fuera del núcleo de desarrollo.

Son muchos los desarrolladores que se niegan a pasar por el aro (la mayoría), asi que si las cosas no cambian y se llega a un acuerdo, probablemente se produzca un fork en PDO o directamente se quite del core, lo que sería una verdadera putada …

El formato de llavero PKCS#12 (extensiones .p12 y .pfx) es uno de los más populares para almacenar
claves criptográficas. En PHP podemos gestionar este tipo de claves a partir de la versión 5.2.2
gracias al módulo OpenSSL.

Como es muy nuevo y no hay documentación al respecto, dejo aquí un ejemplo de uso:

Un poquito de rant gracioso en formato twittero.

Autoload es uno de los llamados métodos mágicos de PHP que se dispara “mágicamente” cuando, al instanciar una clase, el interprete no es capaz de localizarla porque no se ha hecho el include/require del archivo correspondiente. Con autoload podemos sobrecargar esta funcionalidad y especificarle a PHP donde debe buscar sin tener que indicar explicita mente todos los archivos de clases de nuestro proyecto mediante include/require.

El problema viene cuando nuestro proyecto utiliza su propio autoload y un componente de un tercero utiliza otro autoload completamente diferente: sólo puede haber un punto para interceptar la llamada “autoload” e inevitablemente colisionan.

Afortunadamente la SPL proporciona un mecanismo para apilar métodos autoload, tantos como sean necesarios, y evitar las colisiones. Veamos un ejemplo:

Las clases Component1 y Component2 tienen dos funciones __autoload() diferentes.

Los dos callbacks autoload colisionan.

Utizando SPL podemos detectar si ya hay un callback autoload definido para sobreescribirlo, o apilar el nuestro. Además la función autoload puede meterse como metodo de una clase y mejorar un poco el aspecto del codigo:

Cuidado porque la función autoload no es demasiado liviana y un uso abusivo puede provocar una bajada de rendimiento en el programa, pero de momento y hasta la versión 5.3, sin espacios de nombres en PHP no podemos hacer gran cosa

Os dejo un task para Phing que programé para crear automáticamente paquetes Phar en PHP. Como no hay demasiada documentación sobre cómo extender Phing y crear nuevas tareas, os puede servir de guía para implementar las vuestras porque la verdad es que yo programé esta casi a ciegas.

La tarea: PHPArchiveTask

Y aquí el ejemplo de uso del XML del build.xml correspondiente:

<project name=“builder” default=“package”>
	<!– custom tasks –>
	<taskdef name=“phar” classname=“phing.task.PHPArchiveTask” />
	
	<!– custom properties –>
	<property name=“phar.version” value=“1″ />
	<property name=“dist.dir” value=“./dist” />
	<property name=“src.dir” value=“./src” />
	
	
	<target name=“package”>
		<echo msg=“Building package …” />
		<phar
			version=“${phar.version}” 
			bootstrap=“lib/phar-bootstrap.php” 
			gzip=“true” 
			output=“{dist.dir}/packages/myFirstPharPackage${phar.version}.phar” 
			stub=“{src.dir}/phar-stub.php”>
	
			<fileset dir=“{src.dir}”>
				<include name=“classes/**/*.php” />
			</fileset>
		</phar>
	</target>

</project>

Deberéis colocar la tarea en la ruta phing/task/PHPArchiveTask.php a partir del lugar donde esté el build.xml, tal y como indica el espacio de nombres (de esos espacios de nombres de mentira que hay en PHP…). El resto de opciones creo que están bastante claras.

1. Si un método puede ser static, decláralo estático. La velocidad se incrementa en un factor de 4.
2. echo es más rápido que print, aunque la diferencia es despreciable.
3. Inicializa el contador de tus bucles for antes y no en el propio bucle.
4. Si tienes que iterar un objeto o un array, utiliza SPL en lugar de bucles recursivos.
5. Destruye las variables que ya no utilices con unset() para liberar memoria, especialmente si son objetos o arrays pesados. Si utilizas OOP, revisa el destructor __destruct() en este sentido.
6. Si tienes que recorrer un array enorme y no te interesa guardarlo, considera utilizar array_shift() para ir leyendo y borrando a la vez.
7. No abuses de __get(), __set() y __autoload().
8. require_once() es pesado. Muy pesado en PHP < 5.0.
9. Utiliza paths absolutos a los ficheros en los include() y require(), el SO tarda menos en resolver las rutas al fichero.
10. Si necesitas saber el timestamp de acceso a un script, considera utilizar $_SERVER['REQUEST_TIME'] en lugar de time()
11. Comprueba si puedes usar strncasecmp(), strpbrk() y stripos() en lugar de expresiones regulares.
12. str_replace() es más rápido que preg_replace(), pero strtr() es hasta 4 veces más rápido que str_replace().
13. Si la función, como la función de reemplazo de cadenas, acepta dos arrays y un carácter como argumentos, y tu lista de argumentos no es muy larga, considera escribir varias sentencias de reemplazo redundantes, pasando un carácter cada vez, en lugar de una linea de código que acepte arrays como búsqueda y reemplazo.
14. La supresión de errores con @ es bastante ineficiente a la par que desaconsejable.
15. eval() is evil (y además horrorosamente lento).
16. $row['id'] es hasta 7 veces más rápido que $row[id]
17. Si una variable de clase es constante, utiliza const.
18. Los mensajes de error son ineficientes, utilizalos sólo cuando sea necesario.
19. No uses funciones dentro de los bucles, como for ($x=0; $x < count($array); $x++). La función count() se ejecuta cada vez que se repita el bucle.
20. Incrementar una variable local en un método es lo más rápido. Casi lo mismo que llamar a una variable local en una función.
21. Incrementar una variable global es dos veces más lento que hacerlo con una variable local.
22. Incrementar una propiedad de un objeto (por ejemplo $this->prop++) es 3 veces más lento que hacerlo sobre una variable local.
23. Incrementar una variable indefinida es hasta 10 veces más lento que hacerlo en una ya inicializada.
24. Declarar una variable global sin utilizarla también enlentece la ejecución. PHP comprueba si existe.
25. La cantidad de métodos definidos en una clase no afecta al rendimiento.
26. Los métodos de la clase concreta se ejecutan más rápidos que los de la clase base.
27. $localvar++ es hasta 15 veces más rápido que function inc(){ $localvar++; }.
28. Las cadenas encerradas entre comillas simples son más rápidas que las que lo están con comillas dobles porque PHP no expande las variables que puedan contener. Si usas PHP 5+, la diferencia es mínima.
29. Cuando se aplica echo a una lista de cadenas por argumento, es más rápido separarlas con una coma (,) en lugar del operador de concatenación (.). Esto sólo funciona con echo por ser una construcción del lenguaje y no una función.
30. Un script PHP es servido por Apache entre 2 y 10 veces más lento que una página estática. Cachea resultados cuando sea posible.
31. Los scripts PHP se “compilan” cada vez que son ejecutados a menos que se guarde el código objeto en un cache. Las diferentes herramientas de compilación de PHP incrementan el rendimiento hasta un 100%.
32. Puestos a cachear, Memcached es mucho más rápido y versátil que un cache a disco. APC también da buen resultado pero es menos escalable.
33. Usa ip2long() y long2ip() para almacenar direcciones IP como números en lugar de como cadenas. Reduce el espaco en un factor de 4 y los cálculos de rango, máscara y ordenaciones son más sencillos y rápidos.
34. Usa la extensión SOAP nativa en lugar de NuSOAP.
35. Valida las direcciones de correo electrónico con checkdnsrr().
36. php_filter() mejor y más rápido que tu sistema home made de validación.
37. Las funciones mysql_* son más lentas que mysqli_*, pero no tan eficientes como el driver mysqlnd para PDO (disponible en el inminente PHP 5.3)
38. Usa sentencias preparadas, en lugar de concatenar las consultas a mano, para mejorar el rendimiento y frenar significativamente las SQL-Injections. ( y Matt puede decir misa, hacedme caso a mi )
39. No reinventes la rueda, mira a ver si puedes aprovechar algo de PEAR, PECL, SourceForge, CakePHP, CodeIgniter, Zend Framework, …
40. Utiliza highlight_file() para postear código formateado y bonito en los foros (por favor!!).
41. Si guardas un objeto o array serializado en la base de datos, considera usar gzcompress() y gzuncompress() para ahorrar espacio. GZip puede reducir el tamaño de un texto plano hasta en un 90%.
42. El operador ternario no es más rápido que un if-else.
43. empty() es más rápido que $var == '', pero es más rápido el operador identidad $var === ''. En general la identidad es más rápida en cualquier situación.
44. do-while es más rápido que while, pero más lento que for. Lo primero a optimizar de un programa son los bucles ( un viejo truco de Algoritmia y Arquitectura de computadores )
45. Si necesitas determinar si una cadena tiene un cierto tamaño, es más rápido utilizar la construcción del lenguaje !isset($str{5}) que la función strlen($str) < 5
46. el preincremento ++$i es más rápido que el postincremento $i++ debido a interioridades del interprete de Zend, de echo es una de las optimizaciones a nivel de OPCODE más utilizadas por los compiladores de PHP.
47. Usa preg_* en lugar de ereg_*, está a punto de desaparecer y es mucho más lento.
48. Usa direcciones IP en lugar de nombres de dominio.
49. El manejador de flujos ob_start() puede aumentar el rendimiento hasta en un 25%.
50. El paso de argumentos por referencia en PHP no es igual al paso de una referencia en C mediante un puntero. En PHP una referencia sirve para acceder a una variable mediante dos nombres distintos (nombre de variable y valor de la variable son cosas distintas en PHP). Por tanto pasar arrays por referencia como en C, en realidad, es más lento que hacerlo por valor. En PHP 5+ los objetos se pasan explícitamente por referencia.
51. Un uso apropiado de las referencias como alias de nombre de variable:
    1.  
    2. $a[‘b’][‘c’] = array();
    3. // 2 accesos por iteración a la tabla hash
    4. // donde PHP almacena las variables
    5. for($i = 0; $i < 5; $i++)
    6.         $a[‘b’][‘c’][$i] = $i;
    7.  
    8.  
    9. // con un alias por referencia es mas rápido
    10. $ref =& $a[‘b’][‘c’];
    11. for($i = 0; $i < 5; $i++)
    12.         $ref[$i] = $i;
    13.  
52. La manera más rápida a este lado de Rio Grande para detectar si el SO es Unix o no es utilizar la constante DIRECTORY_SEPARATOR.
53. La manera más rápida de concatenar muchas cadenas de poco tamaño es abrir un flujo de salida con ob_start() y hacer un echo de todas ellas para despues recoger la cedena final con ob_get_contents(). Esto es así porque en el tratamiento de cadenas el factor limitante es la reserva de memoria y al crear un flujo se reservan de golpe 40K, aumentando en pedazos de 10K cuando hace falta más.
54. En las sentencias switch() ordena los casos empezando por los más frecuentes.
55. Procesar ficheros XML con expresiones regulares es más rápido que hacerlo con SAX o DOM. Atención: el uso de expresiones regulares para procesar XMl puede acortar significativamente su esperanza de vida.
56. Eliminar los comentarios o escribir en una sola linea no hace que se ejecute más rápido, lo único que consigues es que los demás te odien a muerte.
57. Usar objetos no hace que todo sea más rápido, más bien al contrario, pero utilizarlos mejora otras muchas cosas.
58. Cuanto menos (x)HTML en la salida del script, más rápido renderiza la pagina.
59. Utiliza constantes en lugar de funciones: PHP_VERSION vs. php_version(), PHP_OS vs. php_uname(), PHP_SAPI vs. php_sapi_name(), etc.
60. Si todo lo demás falla … escribe una extensión en C.

Conclusión: no prestes mucha atención a todo esto; dependiendo de la carga y la máquina, algunas optimizaciones apenas van a ser apreciables por el usuario final. Sólo con cambiar los while por do-while no va a hacer que tu programa corra como el viento, cuanto mejor conozcas tu stack de software y los entresijos de la aplicación más profundas serán las mejoras que puedas aplicar.

¿Alguien conoce alguna más?

PHP Archive es una extensión que permite desplegar aplicaciones PHP autocontenidas en un único archivo, con extensión .phar obviamente.

Esta extensión todavía no forma parte de la distribución oficial (pero esto cambiará en PHP6, sino antes) así que para instalarla hay que compilarla o utilizar PEAR/PECL, pero he encontrado problemas para hacerlo con los paquetes de Ubuntu/Debian y me consta que en otras distros ocurre lo mismo. ¿Solución? Compilar todo el stack de PHP a mano para después compilar la extensión.

Como esto es un coñazo he decidido publicar la extensión compilada y lista para utilizar (si os fiáis de mí claro):

MD5: f4e82469c7a4d98df5daa30b02b35db4