PROBLEMAS REPOSITORIOS OPENSUSE 10.3

Habrán observado los usuarios de Opensuse que los repositorios (oficiales o no) están dando problemas de conexión y no podéis descargar nada desde Yast o Smart. Por lo visto, los enlaces a esos repos están caídos o no existen.

De cualquier manera he indagado un poco y a continuación pondré otros que sí funcionan y que prácticamente son la totalidad de software y bibliotecas necesarias que existen:

• http://download.opensuse.org/repositories/openSUSE:/10.3:/Testing/openSUSE_10.3/
• http://download.opensuse.org/repositories/KDE:/KDE4/openSUSE_10.3/
• http://download.opensuse.org/repositories/KDE:/Backports/openSUSE_10.3/
• http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_10.3/
• http://download.opensuse.org/repositories/KDE:/Community/openSUSE_10.3/
• http://packman.mirrors.skynet.be/pub/packman/suse/10.3/
• http://download.nvidia.com/opensuse/10.3
• http://download.opensuse.org/update/10.3/

Ir a Yast–Software–Software Repositories y Especificar por URL. Lógicamente cambiar 10.3 por la distribución que uséis.

De todas maneras podéis probar más repos aquí

Ríete con los Errores HTTP

Leyendo Blux 2.0 me he encontrado con una lista de errores HTTP que me ha llamado la atención. Sin duda es una curiosa forma de mostrar éstos errores para que molesten un poco menos a los usuarios y hasta les hagan reir un poco! xD

Aquí os dejo la lista:

400 Bad Request: Dímelo con flores.
401 Unathorized: Estoy casada.
402 Payment Required: Son 10.000 y la cama.
403 Forbidden/Access Required: ¡ZZZZAS! (bofetón).
404 Not Found: He quedado con las amigas.
405 Method Not Allowed: No, por detrás no…
406 Method Not Acceptable: …y en la boca menos.
407 Proxy Auth. Required: Lo hablaré con mi madre.
408 Request Timeout: ¿Sabes cuanto hace que no me llamas?
409 Conflict: ¿Quién era ESA?
410 Document Removed: Quiero el D-I-V-O-R-C-I-O.
411 Lenght Required ?: ¿A eso llamas pedazo polla?
412 Precondition Failed: ¿Que no has traído condones?
413 Request Entity Too Large: Eso no me va a caber ahí dentro.
414 Request URL Too Large: Eso tampoco me va a caber ahí dentro.
415 Unsupported Media Type: A cuatro patas no me gusta.
500 Internal Server Error: Tengo la regla.
501 Not Implemented: Nunca haría eso.
502 Bad Gateway: …y por ahí, menos todavía.
503 Service Unavailable: Me duele la cabeza.
504 Gateway Timeout: ¿Ya está?

Curioso, verdad?

OPENSUSE 10.3: MUY BONITO, PERO…

Me he disgustado un poco con la versión última de Opensuse. Lo que más me ha gustado, como siempre que probé esta distro, es el todopoderoso Yast, que no es sólo un gestor de paquetes, sino una herramienta para configurar TODO el sistema gráficamente, desde por ejemplo la tarjeta gráfica, monitor, sudo, grupos, conexiones, y un largo etcétera…

Pero Suse cojea del sistema de login. Uno puede llevarse una sorpresa al reiniciar la sesión y observar cómo no reconoce al usuario o su contraseña: me ha pasado muchas veces, y no creo que se trate de nada fortuito. Claro, como root puedes entrar, pero para un nóvel, es demasiado complicado reparar o crear otro usuario nuevo. Sin embargo, su “cura” se halla en algo que hay que añadir en /etc/X11/xdm/Xservers

Ahí, tiene que quedar lo siguiente:

0 local /usr/bin/X -nolisten tcp -br vt7
1 local reserve /usr/X11R6/bin/X :1 vt8
2 local reserve /usr/X11R6/bin/X :2 vt9
3 local reserve /usr/X11R6/bin/X :3 vt10
4 local reserve /usr/X11R6/bin/X :4 vt11
5 local reserve /usr/X11R6/bin/X :5 vt12

Otro punto flaco es la lentitud a la hora de instalar software, nada que ver con otras distribuciones GNU/Linux, pero seguro se debe a la cantidad y tamaño de sus repositorios.

Su “look” es especialmente bello; predomina el verde (rompe con el azul de antaño), el populoso compiz-fusion se instaló sin ninguna complicación, es más yendo aquí te descargas un script que se encarga de instalarlo automáticamente Yast. Y lo más espectacular, viene con el extra de previsualizar el cacareado KDE4, un preview magnífico pero que quizás a algunos no llegue a gustarle demasiado.

Resumiendo, Opensuse no la veo como una distro tan estable como esperaba, pero en el tema de sofisticación y apariencia no hay quien le supere.

Túneles SSH para escapar de la prisión!

El título sorprende ¿eh? xD

Es lo primero que se me ha ocurrido, pero representa bastante bien lo que voy a explicar, un poco por encima, en éste post. Básicamente os voy a explicar como utilizar cualquier puerto dentro de una red restringida (como la de muchas universidades) donde sólo nos dejan el puerto para http y poco más. Eso sí, para que ésto funcione deberemos tener en algún lado fuera de dicha red un equipo que pueda recibir conexiones ssh.

Situación: Hoy es mi segundo día trabajando como monitor de laboratorio en la universidad. El curro no está mal, son 3 horas diarias (que he cogido de 11:30 a 14:30) durante las que soy responsable de que los ordenadores del laboratorio en el que me toque funcionen, si alguien no sabe muy bien como hacer algo echarle un cable y si algo se jode abrir una incidencia.

Problema: El aburrimiento de 3 horas seguidas sin hacer nada (hoy no tengo ganas de hacer prácticas :P) me ha llevado a conectarme al irc a ver que se contaban en #ubuntu y me he dado cuenta de que, al estar dentro de la red de la universidad, no tengo acceso al 6667, puerto que usa el IRC.

Solución: El ordenador que tengo en casa bajando y que hace de server tiene acceso libre a internet (usando la conexión de mi casa) y, a pesar de tener IP dinámica, puedo acceder a él a traves de un dominio gratuito y la aplicación no-ip así que puede recibir peticiones desde el exterior sin necesidad de saberme de memoria la IP que tiene en éste momento.

Con éste planteamiento inicial la idea parece bastante sencilla: usar la conexión de mi casa para acceder a internet a través del puerto que necesite, o lo que es lo mismo, acceder al IRC a través del ordenador que tengo en casa. OJO! no es lo mismo que utilizar el ordenador de cada de proxy, es algo mucho más sencillo y con ciertas ventajas.

Ahora la parte práctica, vamos a utilizar una conexión ssh para establecer un tunel desde aquí (red capada) hasta el irc a través del ordenador de casa, ¿como se hace? Muy sencillo:

1º - Tiramos el tunel ssh de la siguiente manera:

ssh -L puerto_local:server_destino:puerto_destino -l usuario_ssh -N servidor_casa

Vamos a explicarlo un poco: puerto_local es el puerto del ordenador local por el que accederemos al tunel, server_destino es el servidor objetivo al que queremos acceder (en nuestro caso cualquiera del irc hispano), puerto_destino es el puerto del server_destino, usuario_ssh un usuario con cuenta ssh en servidor_casa y servidor_casa es el ordenador de nuestra casa a través del cual accederemos al servidor_objetivo.

El ejemplo parametrizado para el irc (cambiando el nombre del server de mi casa…):

ssh -L 4000:libres.irc-hispano.org:667 -l nemesis -N trikititran.no-ip.org

2º - Una vez establecido el tunel (no sacará nada por pantalla) debemos dejarlo abierto y desde el cliente de IRC conectarnos al puerto local que hemos redirigido. Al acceder al puerto puerto_local de localhost estaremos accediendo realmente al puerto puerto_destino de server_destino. Para el caso del ejemplo del IRC sería tan sencillo como ésto:

/server localhost 4000

3º - Cuando hayamos terminado ya podéis cerrar el tunel.

Sé que es un procedimiento lioso, yo la primera vez pensaba que me estaba volviendo majara, pero no es tan complicado, leedlo despacio y si no os enteráis tirad de la fuentes que seguro que lo explican mucho mejor que yo!

Fuente: GulTec - Irc en el Campus

PyDev = Python + Eclipse

Python era uno de los lenguajes que tenía en cola esperando tener algo de tiempo para toquetear, pero al final me han dado la oportunidad perfecta porque en la universidad vamos a trabajar con python para la asignatura de Programación Concurrente y Distribuida, así que…manos a la obra.De momento poco os puedo comentar sobre el lenguaje porque todavía no he tirado una sóla línea, lo que si os puedo comentar es cómo montaros un bonito IDE para trabajar con python. La solución pasa por añadir a Eclipse los complementos para trabajar con éste lenguaje, con muy poco esfuerzo (la primera o segunda entrada de google) encuentro PyDev, que vienen a cumplir perfectamente las espectativas. Vamos con lo que necesitamos para poder instalar PyDev:

• Eclipse 3.3
• Python 2.3.x o 2.4.x
• Java 1.4 o superior

En los repositorios de Ubuntu, la versión disponible ahora mismo de Eclipse es la 3.2.2, que a priori no nos vale, así que lo mejor será bajar la última versión de su sitio web e instalarlo de forma manual (hay miles de tutoriales por ahí). Para python si que tenemos paquetes en los repositorios, hasta 3 versiones diferentes: 2.3, 2.4 y 2.5. Si habéis instalado algo que use python seguramente tendréis ya instalada la versión 2.4, sino podéis instalarla así:

sudo aptitude install python2.4

Para Java en los repositos tenemos las versiones 5 y 6 (que vienen a ser 1.5 y 1.6) de Sun, así que tampoco habrá problemas. Para instalarlo (que seguramente lo tendréis todos ya) sería tal que así:

sudo aptitude install sun-java6-jdk

Después de ésto ya tenemos todo el sistema listo para instalar PyDev, que viene a ser algo tan sencillo o incluso más que lo anterior. Tenemos dos opciones para hacer la instalación: bajarnos el paquete e instalarlo a mano (mucho más coñazo) o instalarlo a través del Eclipse Update Manager (mucho más sencillo porque casi no tenemos que hacer nada). Yo me decanto por la segunda opción, vosotros?

Vamos a ello, como podemos ver en la sección de download de PyDev, la dirección del servidor que usaremos para instalarlo desde Eclipse es la siguiente:

http://pydev.sourceforge.net/updates/

Nos copiamos esa dirección a la voz de ya y arrancamos Eclipse… … … tarda un poco si … …

Vale, ahora en los menús vamos a Help -> Software Updates -> Find and Install… Os aparecerá una ventana donde viene una lista de sitios remotos en los que Eclipse buscará nuevo software, añadimos el de PyDev pinchando en el botón Add Remote Site… le damos un nombre, por ejemplo PyDev, y pegamos la dirección debajo. Si queréis instalar todo lo que incluye PyDev marcad también el Europa Discovery Site y pulsad en Finish. Ahora Eclipse va a bajarse los ficheros de índice de esos servidores, que indica el software que está disponible para descargar.

Una vez haya terminado aparecerá otra ventana con desplegables, marcad directamente el de PyDev y os dirá que os falta Mylyn (o algo parecido, no lo recuerdo bien ahora). Para encontrar Mylyn, abrid el desplegable de Europa Discovery Site y buscadlo, no tardaréis en encontrarlo, y lo marcáis, así debería desaparecer el error. Una vez seleccionado todo ésto, dadle a Next, os pedirá confirmación de que aceptáis la licencia del software, marcad que si y dadle a Finish.

A partir de aquí es mucho más automático: Eclipse se bajará los paquetes que le hemos indicado y, cuando los tenga todos, nos pedirá confirmación para instalarlos advirtiéndonos de que no están firmados por alguien de confianza, blablabla…

Aceptamos y listo, nos aconsejará que reiniciemos Eclipse, cosa que hacemos, nos aparecerá una ventana de presentación que podemos cerrar y luego, dando en el menú Window -> Open Perspective -> Others… veremos que podemos seleccionar la perspectiva de PyDev.

Por ahora, poco más, sólo un screenshot para que os hagáis a la idea de cómo es, ya comentaré algo más cuando haya trabajado con él

Estados de los paquetes en Aptitude

No es cosa nueva, pero mucha gente (entre la que me incluyo) no lo tiene muy claro. Voy a dejar la leyenda que he encontrado aquí donde se indica lo que significa la letra que aparece delante de cada paquete al mostrarlos aptitude en la consola (no me acuerdo si en Synaptic aparece o no) que indica el estado del paquete en cuestión. Ahí va:

• i - instalado.
• c - se ha desinstalado el paquete, pero no los archivos de configuración.
• p - se borró tanto el paquete como los archivos de configuración, o bien nunca se instaló.
• v - virtual.
• B - dependencias rotas.
• u - desempaquetado pero no configurado.
• C - no se terminó de configurar el paquete.
• H - no se terminó de instalar.

La diferencia entre el estado c y p es una de las grandes ventajas y a la vez engorros de éste sistema de paquetes. Cuando un paquete se encuentra en el estado c quiere decir que se ha desinstalado el paquete pero se han dejado por ahí los ficheros de configuración del paquete, mientras que en el estado p no se han dejado ni el paquete ni sus ficheros de configuración. Ahora vamos por partes:

¿por qué es una gran ventaja? Supongamos que no vas a usar por un tiempo el paquete Apache (famoso servidor de contenidos web) y quieres quitarlo del sistema pero no quieres perder la configuración que tenías montada por si te hace falta ni los sitios web que habías construido. Bien, pues con un simple

sudo aptitude remove apache

Abrás quitado el paquete pero todas esas cosas que no querías perder seguirán ahí de forma que cuando hagas un:

sudo aptitude install apache

tendrás otra vez apache funcionando y se mantendrá la configuración que tenías hecha.

¿por qué es un gran tostón? Porque si lo que quieres es quitar el paquete apache y todo lo que tenga que ver con él, configuración y demás con un:

sudo aptitude remove –purge apache

debería bastar, peeeeero…no sé si es un bug o qué, pero a mi muchas veces se me queda en estado c, es decir, que mantiene la configuración y tengo que hacer también un

sudo aptitude purge apache

después del comando anterior.

Cada uno que elija, si para él es una ventaja o una desventaja

getdeb en tus repositorios

Para el que no lo conozca getdeb es uno de los sitios donde más paquetes actualizados podemos descargar para las distros basadas en debian (ubuntu, linux mint, etc…)

Ya de por si me parecía interesante seguir su feed RSS para poder seguir las aplicaciones que iban sacando y las versiones con sus cambios, pero ahora ésto me parece todavía más interesante: he leido en Blux 2.0 cómo añadir getdeb a los repositorios de nuestra ubuntu.

Sólo hay que editar el archivo de repositorios (/etc/apt/sources.list) y añadir el siguiente repositorio:

deb http://ubuntu.org.ua/ getdeb/

Y listo, sólo necesitamos actualizar la lista de paquetes y ya los tendremos listos para buscar e instalar.

La configuración de Xorg será gráfica

Si hace unos días citaba una noticia donde se indicaba que Gutsy Gibbon no incluiría la versión 7.3 de Xorg (que era la que incluía la configuración automática de hardware y demás) también comenté que más razón todavía para incluir éste interfaz gráfico de configuración de Xorg, aunque los demás blogs mantenían que no habría cambios en lo que respectaba a la configuración de las X hasta la versión siguiente a Gibbon (que por cierto, puede que se llame Hungry Hyppo).

Finalmente se sabe ya, que definitivamente si, se incluirá un interfaz gráfico para configurar el xorg.conf que a muchos (y me incluyo) nos trae de cabeza muchas veces. Por lo que he visto permitirá configurar la tarjeta de vídeo y tambíen el monitor, aunque parece una herramienta bastante completa para salir del paso hasta la inclusión de Xorg 7.3 (que por la pinta va a tener más tutoriales que beryl en sus días xD). ¿qué donde he visto la aplicación? En éstos screenshots que os dejo aquí:

Fuente: Blux 2.0

Gutsy Gibbon no incorporará Xorg 7.3

Dicho así no parece tanto, pero viendo las mejoras que incluye ésta nueva versión de Xorg se le va a echar de menos. Entre otras cosas incluía detección automática de hardware de vídeo (sin tener que tocar el xorg.conf, cosa que aliviaría a muchos colegas de #ubuntu en el hispano xD) y un mejor soporte para monitores duales (a través de RandR 1.2. Cosa que, personalmente, me vendría bastante bien).

Ayer salió la noticia de que Gutsy Gibbon iba a incluir una herramienta gráfica para la configuración de xorg, que, en palabras de barrapunto nos permitiría lo siguiente:

Podremos elegir la tarjeta gráfica instalada navegando por las marcas o ingresando directamente su modelo. Luego podremos configurar el tipo de monitor que tenemos instalado, ya sea de tubo o LCD, las resoluciones, el refresco de pantalla, la cantidad de monitores, la orientación de la pantalla, entre otras cosas

Al parecer ésta herramienta también se retrasa hasta que ubuntu incluya la versión 7.3 de Xorg.

Una verdadera lástima provocada, para variar, por la falta de tiempo (contra la que no se puede hacer nada). Ojo, no es que los desarrolladores de ubuntu sean unos vagos (como comenta alguno por ahí) sino que ésta versión de Xorg tiene como fecha de salida el 29 de Agosto y la gente de Canonical tendrían menos de un mes para integrarla y hacer las pruebas pertinentes.

Por un lado es una pena no poder disfrutar de las ventajas que incluiría, pero por otro me gusta que los desarrolladores no se dejen llevar por el entusiasmo repentino y se mantengan en su objetivo de mantener una distribución actualizada pero, sobre todo, estable.

Yo la verdad es que no entiendo demasiado que no incluyan dicha herramienta gráfica, porque para muchos usuarios sería un alivio poder configurar el xorg.conf desde un interfaz gráfico similar a ese. ¿podrían adaptarla para trabajar con la versión actual de xorg no?

Fuentes:

Barrapunto - Anuncio de la herramienta de configuración gráfica en Gutsy Gibbon
Barrapunto - Anuncio del retraso en la inclusión de Xorg 7.3

SSH sin contraseña pero más seguro

Un poco contradictorio el título ¿no? Pues puede verse así. Hablando de temas de seguridad muchas veces (como en todo el mundo de la informática) las cosas cambian mucho según el punto de vista de cada uno.

Lo que voy a explicar de manera breve es algo que vi en 120%Linux, concretamente en éste post, y que me pareció bastante interesante, en gran parte porque me ahorra meter una contraseña bastante veces al día xD

El objetivo es el siguiente: poder logearnos en nuestros servidor a través de ssh sin tener que introducir ninguna contraseña pero manteniendo cierto nivel de seguridad en el servidor. Lo que haremos será eliminar el hecho de introducir la contraseña y añadir la necesidad de indentificarse (de forma automática) mediante una firma RSA que tendremos almacenada. Aquí os va el resumen de lo que tenéis que hacer:

- Generar el par de claves RSA (pública y privada):

ssh-keygen -t rsa

nos preguntará la passphrase que queremos usar para éste par de claves y en qué fichero queremos guardar la clave, de forma que guardara con ese nombre la clave privada y con el mismo nombre seguido de .pub la clave pública (por defecto ~/.ssh/id_rsa y ~/.ssh/id_rsa.pub). OJO! si lo que queremos es no tener que meter clave al conectar por ssh debedos dejar el passphrase en blanco.

- Ahora mandaremos la clave pública al servidor:

ssh-copy-id -i ~/.ssh/id_rsa.pub usuario@servidor

- Ya sólo nos queda configurar el servidor. Lo hacemos editando el fichero /etc/ssh/sshd_config y cambiando los siguientes valores:

PasswordAuthentication no
RSAAuthentication yes
PubkeyAuthentication yes

más o menos se entiende, pero quiero aclarar que si dejamos “PasswordAuthentication no” ya no se podrá entrar en el servidor si no disponemos de la clave privada en la máquina desde la que estamos trabajando. Yo lo he dejado como yes porque alguna vez conecto desde casa de algún amigo y otro colegas míos tienen cuentas ssh en el servidor de mi casa. Tenedlo en cuenta porque afecta a todos los usuarios del sistema.

En el tutorial original añaden éste otro paso más, pero no estoy muy seguro de que haga falta, probad antes de hacerlo y si no os funciona ya sabéis (de paso dejad un comentario para aclararlo :D):

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

- Por último, pero no menos importante, reiniciar el servicio ssh en el servidor así:

sudo /etc/init.d/ssh restart

Y listo. Ahora deberíamos poder logearnos sin problemas como siempre:

ssh usuario@servidor

Podéis hacerlo así para ver todos los mensajes y aseguraros de que está usando el par de claves rsa:

ssh -v usuario@servidor

Si queréis hacer cambios tened en cuenta que no se puede cambiar la passphrase, vamos, si que se puede pero el concepto es distinto: tenéis que generar otro par de claves distintas con otra passphrase y añadirlas. Pero sabed que sino elimináis la clave pública vieja del fichero ~/.ssh/authorized_keys seguirá siendo válida. Podéis hacerlo borrando directamente ese fichero antes de pasarle la clave pública nueva o editándolo se ve bien donde termina una clave y empieza otra.

Que no os engañe el hecho de que no haya que meter contraseña, si controláis bien el acceso a vuestro clave privada es mucho más seguro que la contraseña que usábais hasta ahora.