Administrar scripts de arranque

— [ edit | raw ] migrated from node/991
Es posible crear scripts y hacer que se ejecuten durante el arranque del sistema, antes de que se nos muestre el login. En esta receta veremos cómo incluirlos y cómo borrarlos.

Introducción

Durante el arranque y la parada del ordenador, el sistema entra en varios niveles de ejecución. Los niveles 2, 3, 4, 5 son los de arranque o inicio; 0, 1, 6 son los niveles de parada o apagado; y S es el nivel monousuario. En el directorio /etc hay una serie de directorios nombrados rcX.d, donde la X indica el nivel de ejecución. Dentro de estos directorios hay una serie de enlaces simbólicos hacia los scripts que se ejecutan en cada nivel. Los enlaces se llaman igual que el script al que apuntan, pero con un prefijo consistente en una S o una K más un número de dos dígitos. La letra indica si es un script de inicio (Start) o de parada (Kill), y el número indica el orden en que se ejecuta. Por defecto, este número es 20, aunque se puede cambiar, como veremos más adelante.

Manejando los Scripts

Lo primero es crear el script. Es necesario que exista antes de incluirlo para su ejecución en el arranque. Si echamos un ojo a los directorios rcX.d, veremos que la gran mayoría de los scripts están en /etc/init.d, así que es de suponer que ese es un buen lugar para colocar el nuestro (de hecho, no puede estar en otro sitio)

Añadir un script

El comando que vamos a utilizar es update-rc.d. Para añadir un script de inicio, lo haremos de la siguiente forma:
# update-rc.d miscript.sh defaults
Con esto incluimos miscript.sh para que se ejecute en el arranque (en los niveles 2, 3, 4 y 5), y en la parada (niveles 0, 1 y 6). Es equivalente a escribir:
# update-rc.d miscript.sh start 20 2 3 4 5 . stop 0 1 6 .
(nótese el punto al final) Supongamos ahora que queremos incluir nuestro script sólo en el inicio, con orden de ejecución 95, y sólo en los niveles 2 y 3:
# update-rc.d miscript.sh start 95 2 3 .
(nótese el punto al final)

Borrar un script

Para borrar un script haríamos:
# update-rc.d miscript.sh remove
Esto borra únicamente los enlaces simbólicos, no el script; y siempre y cuando se haya borrado el script previamente. Si se quiere borrar los enlaces aunque no se haya borrado el script, hay que utilizar la opción -f (force):
# update-rc.d -f miscript.sh remove
Para evitar liarla parda, tanto en la adición como en el borrado, es útil utilizar la opción -n (not really). Esto hace que no haga realmente las operaciones, si no que solamente nos diga qué habría hecho.
# update-rc.d -n miscript.sh defaults
Adding system startup for /etc/init.d/miscript.sh ...
   /etc/rc0.d/K20miscript.sh -> ../init.d/miscript.sh
   /etc/rc1.d/K20miscript.sh -> ../init.d/miscript.sh
   /etc/rc6.d/K20miscript.sh -> ../init.d/miscript.sh
   /etc/rc2.d/S20miscript.sh -> ../init.d/miscript.sh
   /etc/rc3.d/S20miscript.sh -> ../init.d/miscript.sh
   /etc/rc4.d/S20miscript.sh -> ../init.d/miscript.sh
   /etc/rc5.d/S20miscript.sh -> ../init.d/miscript.sh

Usar Pidgin para unirte a una sala Jabber

— [ edit | raw ] migrated from node/988
Sí tienes una cuenta jabber (o gtalk que es lo mismo) puedes usar Pidgin para unirte a salas de chat al más puro estilo de IRC. En esta receta te explico cómo unirte a la de tu portal favorito: CRySoL

Unirse a un Chat

En la ventana principal de Pidgin, pulsa en Amigos --> Unirse a un chat
Si conoces los datos de la sala, puedes rellenarlos directamente, tal como se ve en la imagen. Si no, puedes buscar una sala en la lista de salas disponibles, pulsando en Lista de salas.

Añadir la Sala como contacto

Se puede también añadir la sala como si fuera un contacto más de jabber. Una vez dentro de la sala, pulsa en Conversación --> Añadir. De esta forma podrás tenerlo siempre a mano, a sólo un doble-click de distancia.
Para que se conecte automáticamente cuando abras pidgin, abre el menú contextual de CRySoL en la lista de contactos y marca «Conectar automáticamente».

Primeras reacciones al banner anti-software privativo de CRySoL

— [ edit | raw ] migrated from node/989
"ves, ahora sigo de vacaciones y me apetece contestar...

Cambiar el "timezone" en Debian

— [ edit | raw ] migrated from node/990
Resulta que ahora en veranito muchos de vosotros habréis viajado a algún sitio y puede que (como frikis/hackers que somos) llevéis vuestra Debian en la mochila. Si esto es así y habéis cambiado de uso horario, tendréis que cambiar la hora de vuestro equipo... ¿es necesario esto?... pues claro que no!

El problema

Cuando instalamos nuestro sistema, en uno de los primeros pasos, elegimos nuestro país, en ese paso se configura nuestro timezone, que es un servicio que permite compensar la hora de nuestro sistema con la hora local donde se ubica el mismo. No se si soy muy torpe o no he mirado bien o qué, el caso es que no he encontrado ninguna utilidad que permita cambiarlo así pues vamos a explicar como cambiarlo, es muy sencillo.

Configuración del timezone

La configuración de esto se encuentra en un extraño archivo ubicado en /etc/localtime (digo extraño porque no es texto plano). Así pues lo que tenemos que hacer es cambiar ese archivo por otro...
# mv /etc/localtime /etc/localtime.old
Y ahora... ¿qué ponemos en su lugar? pues fácil... en /usr/share/zoneinfo tenemos un montón de archivos, sólo hay que elegir uno...
# cp /usr/share/zoneinfo/America/El_Salvador /etc/localtime
Y ahora, la próxima vez que se actualice nuestro reloj, con ntpdate por ejemplo, tendremos el equipo con la nueva hora local.

scapy 2.0.0.5 en Debian

— [ edit | raw ] migrated from node/985

Hace tan solo unos días, Phil (el autor de scapy) anunciaba en la lista de correo una nueva (y muy remodelada versión de scapy): la 2.0.0.0. Y como es menester, ya está empaquetada para Debian y disponible en los repos oficiales de Debian con el nombre python-scapy.

ZeroC Ice: recogiendo estadísticas.

— [ edit | raw ] migrated from node/984

Esta receta describe cómo recoger estadísticas de uso de red mediante la interfaz Ice::Stats en una aplicación que utilice ZeroC ICE.

Herramientas

  • ZeroC ICE (en este enlace se describe su instalación en Debian).
  • La interfaz Ice::Stats.

Uso de la interfaz Ice::Stats

La interfaz Ice::Stats permite informar sobre el número de bytes enviados y recibidos por cada invocación:

local interface Stats {
     void bytesSent(string protocol, int num);
     void bytesReceived(string protocol, int num);
};

El proceso a seguir consiste en implementar la interfaz Ice::Stats y registrar ese sirviente a la hora de inicializar el communicator. Una implementación sencilla consistiría en imprimir la información de uso de red:

// MyStats.h
#include <Ice/Stats.h>

using namespace std;

class MyStats : public virtual Ice::Stats {
 public:

  virtual void bytesSent(const string& prot, Ice::Int);
  virtual void bytesReceived(const string& prot, Ice::Int);
};

// MyStats.cpp
#include <MyStats.h>

using namespace std;

void MyStats::bytesSent(const string& prot, Ice::Int num) {
  cerr << prot << ": sent " << num << "bytes" << endl;
}

void MyStats::bytesReceived(const string& prot, Ice::Int num) {
  cerr << prot << ": received " << num << "bytes" << endl;
}

A continuación, tendremos que instalar un objeto de la clase MyStats en el communicator del cliente, del servidor o de ambos. Este paso se lleva a cabo a la hora de crear el communicator y mediante una estructura del tipo Ice::InitializationData. Como lo normal es que utilicemos la clase Ice::Application, el código del cliente, por ejemplo, quedaría más o menos así:

#include <Ice/Ice.h>
#include <Demo.h>
#include <MyStats.h>

using namespace std;
using namespace Demo;

class Client : public Ice::Application {
public:
  virtual int run (int argc, char* argv[])   {
    Ice::ObjectPrx prx = communicator()->stringToProxy("dummy:default -p 9999");
    Demo::DummyPrx dummy = Demo::DummyPrx::uncheckedCast(prx);

    dummy->hello();

    return 0;
  }
};

int
main (int argc, char* argv[]) {
  Client app;
  Ice::InitializationData id;
  id.stats = new MyStats;
  return app.main(argc, argv, id);
  return app.main(argc, argv);
}

En este caso, en la parte del cliente obtendríamos una salida similar a ésta al invocar la operación hello del proxy dummy:

tcp: received 14bytes
tcp: sent 40bytes
tcp: received 14bytes
tcp: received 11bytes
tcp: sent 14bytes

Referencias

Prácticas de Programación Infames: OpenJDK

— [ edit | raw ] migrated from node/971

Más de una vez (y de dos) he oído hablar sobre extrañas normas no escritas (o eso espero) sobre «buenas prácticas» de programación. De entre todas ellas, me permito destacar:

  • El break solo se puede usar en los switch (en cada case).
  • Usar el continue es un pecado capital, al infierno de cabeza.
  • El return solo puede ir en la última línea de una función o método, y únicamente para retornar algo. De lo contrario sufrirás indecible tormento.
  • Y la clásica: Usar el goto está penado con sufrimiento eterno.

Lo único seguro es que no lo es

— [ edit | raw ] migrated from node/970

Con esta paradoja se puede resumir la situación de la seguridad informática últimamente. Empezamos con la clave privada predecible de SSL en Debian (y Ubuntu y derivados, que son muchos), seguramente la cagada más grande en materia de seguridad de su historia.

Drupal 6.3

— [ edit | raw ]
migrated from node/968

Gracias al inestimable y considerable esfuerzo de lk2, que ha incluido portar parte de algunos módulos y arreglar algún que otro bug en otros, ya tenemos el site de CRySoL migrado a Drupal-6.3. Muchas horas de pruebas y más PHP del que nos gustaría aprender. Como siempre, si encontráis cualquier anomalía en el funcionamiento del portal, o alguna feature perdida, no dudéis en dejar un comentario en este mismo post.
Saludos