Archivo por meses: febrero 2013

Truco: Android, mala conexión inhabilitada.

Igual en algún momento alguno os encontráis con el mismo problema con el que me he encontrado yo hoy cuando de repente y tras mucho tiempo de funcionar sin problemas, vuestro móvil decide no conectarse a vuestra WiFi.

La única señal es ver en los ajustes de red, en las redes WiFi, que vuestro móvil intenta conectarse continuamente a vuestra red habitual sin éxito, hasta que finalmente os da un mensaje:

mala conexión inhabilitada

De momento la única solución pasa por cambiar la configuración por defecto, por DCHP, por configurar la IP de forma manual.

Poner una IP fija dentro del rango de las configuradas en vuestro router, los mismos servidores DNS configurados en vuestro router, y como puerta de enlace la IP del propio router.

Tras ello probar a conectar y volveréis a disfrutar de vuestra conexión WiFi habitual.

No he encontrado explicación oficial, aunque en los foros de HTCMania un usuario daba una solución definitiva (aunque yo no la he probado aún):

La solución es:

1. “Olvidar” la wifi en cuestión en el móvil
2. Desactivar la wifi
3. borrar todos los ficheros de la carpeta /data/misc/dhcp (yo lo hice con Root Explorer, supongo que es necesario ser root)
4. reiniciar, volver a activar la wifi, volver a poner el password de tu wifi, etc

A mí me pasaba y esto lo solucionó definitivamente.

Actualizaré cuando la haya podido probar y validar.

Actualizado:

Efectivamente con esto funciona, aunque hay que ser un poco más precisos con las instrucciones.

Los ficheros a borrar están en /data/misc/dhcp, y son:

  • dhcpcd-wlan0.lease
  • dhcpcd-wlan.pid

Para eliminarlos, siendo root en vuestro móvil, lo mejor es bajarse una aplicación de terminal (por ejemplo esta) , abrir una sesión y hacer:

$ su

Con esto nos pedirá otorgar permisos de superusuario (root), permitirlo para ser root.

#cd /data/misc/dhcp
#rm dhcpcd-wlan*

Ahora volvemos a la configuración de la WiFi, borramos nuestra red, volvemos a configurarla y debe funcionar de nuevo sin problemas.

Actualización – 26 de enero de 2014

Sois muchos los que dejáis comentarios mencionando que no encontráis los ficheros a eliminar en la ruta especificada.

Ante esto, dado que a mí no me ha sucedido y no puedo investigarlo, solo os puedo decir que os aseguréis de:

  • Acceder al directorio como usuario root (no olvidéis tener permisos de root y hacer el ‘su’ en la ventana de terminal).
  • Acceder a la ruta en la partición adecuada, muchos móviles traen la memoria principal particionada con dos particiones.
  • Si con el terminal no veis los archivos, descargar una aplicación como Root Explorer o Root Browser (la segunda es gratuita) para intentar acceder al directorio como root.
  • Probar a configurar una IP estática.
  • Si la IP estática no funciona, probar a cambiar el nombre y el canal de vuestra red en el router (según el modelo de router podéis encontrar información sobre cómo hacerlo buscando en Google) para que el teléfono la reconozca como una red distinta.

Para cualquier otro problema no os vamos a poder ayudar, dado que estas cosas requieren de probarlas en persona para poder discernir qué es lo que está ocurriendo y cómo solucionarlo.

Un saludo.

cabecera-git

Usando GIT desde eclipse.

Ahora que Sebas nos ha dado las explicaciones correctas para saber cómo montar GIT en nuestro servidor y unas nociones de uso básico, vamos a proceder a ponerlo en práctica con algo que es de lo más habitual, usarlo desde eclipse.

Para ello, tras seguir las explicaciones de Sebas he instalado GIT en mi Raspberry Pi con un simple:

pi@raspberrypi ~ $ sudo apt-get install git
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Se instalarán los siguientes paquetes extras:
  git-man libcurl3-gnutls liberror-perl rsync
Paquetes sugeridos:
  git-daemon-run git-daemon-sysvinit git-doc git-el git-arch git-cvs git-svn
  git-email git-gui gitk gitweb
Se instalarán los siguientes paquetes NUEVOS:
  git git-man libcurl3-gnutls liberror-perl rsync
0 actualizados, 5 se instalarán, 0 para eliminar y 15 no actualizados.
Necesito descargar 7.624 kB de archivos.
Se utilizarán 13,8 MB de espacio de disco adicional después de esta operación.
¿Desea continuar [S/n]? S
Des:1 http://mirrordirector.raspbian.org/raspbian/ wheezy/main libcurl3-gnutls armhf 7.26.0-1+wheezy1 [306 kB]
Des:2 http://mirrordirector.raspbian.org/raspbian/ wheezy/main liberror-perl all 0.17-1 [23,6 kB]
Des:3 http://mirrordirector.raspbian.org/raspbian/ wheezy/main git-man all 1:1.7.10.4-1+wheezy1+rpi1 [1.074 kB]
Des:4 http://mirrordirector.raspbian.org/raspbian/ wheezy/main git armhf 1:1.7.10.4-1+wheezy1+rpi1 [5.864 kB]
Des:5 http://mirrordirector.raspbian.org/raspbian/ wheezy/main rsync armhf 3.0.9-4 [356 kB]
Descargados 7.624 kB en 12seg. (597 kB/s)
Selecting previously unselected package libcurl3-gnutls:armhf.
(Leyendo la base de datos ... 90142 ficheros o directorios instalados actualmente.)
Desempaquetando libcurl3-gnutls:armhf (de .../libcurl3-gnutls_7.26.0-1+wheezy1_armhf.deb) ...
Selecting previously unselected package liberror-perl.
Desempaquetando liberror-perl (de .../liberror-perl_0.17-1_all.deb) ...
Selecting previously unselected package git-man.
Desempaquetando git-man (de .../git-man_1%3a1.7.10.4-1+wheezy1+rpi1_all.deb) ...
Selecting previously unselected package git.
Desempaquetando git (de .../git_1%3a1.7.10.4-1+wheezy1+rpi1_armhf.deb) ...
Selecting previously unselected package rsync.
Desempaquetando rsync (de .../rsync_3.0.9-4_armhf.deb) ...
Procesando disparadores para man-db ...
Configurando libcurl3-gnutls:armhf (7.26.0-1+wheezy1) ...
Configurando liberror-perl (0.17-1) ...
Configurando git-man (1:1.7.10.4-1+wheezy1+rpi1) ...
Configurando git (1:1.7.10.4-1+wheezy1+rpi1) ...
Configurando rsync (3.0.9-4) ...
update-rc.d: using dependency based boot sequencing

Una vez que lo tenemos instalado, en mi caso he creado un directorio ‘git-repo’ en el disco USB que tengo montado (para no castigar la tarjeta SD con continuas re-escrituras), al que he enlazado desde el ‘home’ de mi usuario con un:

pi@raspberrypi ~ $ ln -s /media/usb1/git-repo git-repo

Ahora nos creamos un repositorio de ejemplo y estamos listos para pasar a eclipse para configurarlo.

Para ello, con la versión de eclipse Java Developer tenemos suficiente, ya que integra GIT por defecto, aunque en los pantallazos que pondré a continuación veréis otra versión distinta.

Para empezar abrimos la perspectiva ‘Git Repository Exploring’ en eclipse y podremos ver que en la pestaña de la izquierda tenemos un listado de los repositorios de Git definidos.

Sobre los repositorios veremos 3 iconos que nos permiten:

  • Añadir un repositorio existente de GIT.
  • Clonar nuestra repositorio y añadirlo a la vista.
  • Crear un nuevo repositorio y añadirlo a la vista.

Seleccionaremos la segunda opción, dado que ya tenemos el repositorio creado en el Raspberry y lo que queremos es clonarlo y empezar a usarlo.

En la ventana que sale seleccionamos URI, ya que es un repositorio personal y no de GitHub, y en la siguiente ventana rellenaremos los datos de la conexión:

Configuración de la conexión

Configuración de la conexión

Rellenamos el campo Host con la IP o el nombre de la máquina, poniendo en ‘Repository Path’ el path al directorio donde hemos creado nuestro repositorio de ejemplo. En nuestro caso usamos ‘~’ para indicar que la ruta es relativa al directorio home del usuario.

A continuación intentará realizar la conexión y si es correcta, nos preguntará si queremos aceptar el certificado, a lo que debemos de responder que sí.

Seguridad - Certificado

Seguridad – Certificado

Luego debemos seleccionar la rama para la que queremos realizar la configuración, aunque al tratarse de un repositorio vacío no tenemos ninguna y nos engancharemos a la rama principal o ‘master’.

Selección de una rama

Selección de una rama

Ahora, hemos creado un proyecto de ejemplo que queremos incluir en nuestra rama, cosa que haremos mediante la opción Team -> Share Project del menú desplegable sobre nuestro proyecto.

Share Project en nuestro repositorio

Share Project en nuestro repositorio

Ahora seleccionamos sobre dónde queremos compartirlo, seleccionando Git:

Seleccionamos Git

Seleccionamos Git

A continuación seleccionamos el repositorio sobre el que hacer el Share.

Seleccionando el repositorio en el que compartir

Ahora podemos añadir nuestra clase de ejemplo al repositorio con la opción ‘Add’ y a continuación realizar nuestro primer commit:

Añadiendo el archivo

Haciendo commit del archivo

Nuestro primer commit

Nuestro primer commit

Ahora el fichero ya está incluido en el repositorio:

Fichero versionado

Fichero versionado

Lo único que nos queda es hacer un Push sobre el servidor:

Push

Push

Y así ya tenemos configurado en eclipse nuestro respositorio en Git.

Instalación en Ubuntu y uso básico de GIT, parte II

Continuamos con la Instalación y uso básico de Git…

GIT

GIT es un sistema de control de versiones distribuido, bastante diferente a SVN o CVS

En local no se almacena únicamente la copia de trabajo con la ultima versión del software si no que tenemos una copia completa del repositorio.

Esto significa que no hay que “ir” al servidor central para las operaciones contra el repositorio, lo cual incrementa enormemente acciones como consultar la historia de un archivo y agiliza todo el proceso con el repositorio. Prácticamente se puede realizar todo el trabajo típico contra un repositorio sin tener que estar conectado al repositorio central.

Además, guarda los datos como snapshots en vez de como diferencias respecto de una versión base

Usando GIT

Hay documentación exhaustiva y muy buena en la web sobre GIT. Solo por citar algún sitio, tenemos

Existen varios sitios que nos pueden alojar nuestros repositorios, si no queremos/podemos tener uno propio. Entre los más conocidos están estos dos:

GIThub, que nos permite crear de forma gratuita repositorios únicamente públicos (aunque ilimitados en número y colaboradores)

Bitbucket, que permite repositorios privados ilimitados pero con un máximo de 5 usuarios en su plan gratuito.

Empecemos configurándolo. GIT guarda la configuración en tres niveles:

Usuario

Con la opción –global podemos almacenar valores para el usuario

Usa el archivo ~/.GITconfig

Repositorio

en .GIT/config almacena valores para el repositorio en el que se crea.

Para todos los repositorios

en /etc/GITconfig se guarda la configuración para todos los repositorios, pasando la opción –system

Una de las primeras cosas a configurar es nuestro usuario y el proxy, si estamos detrás de uno.

$ GIT config --global user.name "John Doe" 
$ GIT config --global user.email johndoe@example.com 
$ GIT config --global http.proxy http.proxy=http://usuario:contraseña@nombreProxy: puerto 

O el editor a usar para los comentarios y otros mensajes…

$ GIT config --global core.editor emacs 

O la herramienta para comparar diferencias a la hora de resolver conflictos…

$ GIT config --global merge.tool vimdiff 

Para ver los valores configurados, solo hay que hacer: GIT config –list

Algunas opciones interesantes son estas

user.name=sbgermanm
user.email=sbgermanm@gmail.com
http.proxy=http://usuario:contraseña@nombreProxy: puerto

Para cerrar el artículo, voy a poner algunos comandos básicos, en una secuencia más o menos posible.

En el servidor

En el servidor, creamos un repositorio central creamos un directorio para nuestros proyectos

$ mkdir projects 
$ cd projects/ 

Dentro de él, un directorio para los repositorios que creemos

~/projects$ mkdir repos                                                                                                         
~/projects$ cd repos 

Crearemos un directorio para el primero de esos repositorios

~/projects/repos$ mkdir project.GIT 
~/projects/repos$ cd project.GIT/ 

Ahora creamos un repositorio GIT

~/projects/repos/project.GIT$ GIT init --bare 

En local

Ahora que ya tenemos el repositorio central, creamos una copia local del repositorio (suponiendo que ya está configurado el SSH)

$ GIT clone usuario@servidor:projects/repos/project.GIT  (1)

Como está vacío, nos lanzará una advertencia bastante lógica

warning: You appear to have cloned an empty repository.

También podemos hacer un repositorio vacio (2)

$ GIT init 

Y despues configurar el remoto

$ GIT remote add origin user@server:~/repos/project.GIT/ 

o también

$GIT config remote.origin.url "usuario@servidor:/projects/repos/project.GIT" 

(es posible clonar un repositorio existente como está en (1) o podemos crear uno nuevo en nuestra maquina y configurar el remoto como en (2), es exactamente lo mismo)

Creamos un archivito con cualquier cosa

$ vi readme.txt 

Ahora, vamos a añadir el archivo al indice repositorio local

$ GIT add . 

Si ejecutamos “GIT status” el archivo readme.txt aparecerá como “staged

Lo siguiente seria subir esos cambios al repositorio local…

$ GIT commit -m "primer archivo" 

Y así podríamos seguir trabajando en local, tanto nosotros como cualquiera que tenga acceso a la ruta donde lo tenemos.

Cuando queramos subir al repositorio “central”, haremos lo siguiente

$ GIT push origin master

Creación de ramas y merges

Para crear una nueva rama llamada “experimento”,

$ GIT branch experimento 

Para obtener la lista de todas las ramas existentes

$ GIT branch 

experimento

* master

El asterisco marca nuestra rama actual.

Para cambiarnos a la rama experimento:

$ GIT checkout experimento

[Editamos el archivo y lo subirlo]

$ GIT commit -a 

Volvemos a la rama principal.

$ GIT checkout master 

[Editamos el archivo]

$ GIT commit -a 
$ GIT merge experimental 

Si no hay conflictos en los cambio, ya está. En caso contrario podremos ver las diferencias:

$ GIT diff 

Si hay conflictos, se mostrará marcas en la izquierda de las líneas problemáticas y GIT commit no funcionaria, diría algo como  esto: file.txt: needs merge

$GIT status

Con GIT status podemos listar los archivos no mergeados. Los archivox con conflictos tendrán algo como esto:

<<<<<<< HEAD:file.txt
Hello world
=======
Goodbye
>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt

Solo tenemos que editar los archivos para resolver los conflictos y entonces:

$ GIT add file.txt 
$ GIT commit 

Ahora subimos el resultado del merge

$GIT commit -a 

Una vez finalizado el trabajo en la rama “experimento”, podemos borrarla:

$ GIT branch -d experimento

Si ni siquiera queremos mergear la rama y solo queremos borrarla

$ GIT branch -D prueba_basura 

Y esto es todo. Ha quedado un poco extenso, pero creo que son las instrucciones mínimas para lanzar desde cero nuestro propio repositorio.

Instalación en Ubuntu y uso básico de GIT, parte I

Recientemente hemos instalado GIT en nuestro hosting para empezar a controlar las versiones de nuestro software de forma más eficiente.

Aunque ya había usado GIT desde Github y bitbucket, no lo había instalado nunca en un servidor y me dije, “esta es la mía…”.

De paso, aprovecho para escribir estas líneas, recapitular lo que he hecho y añadir unas líneas muy, muy básicas del uso de GIT. Empecemos….

Pasos previos

Cliente Local

Lógicamente, para poder acceder a los comandos de GIT, tenemos que tener instalado en local GIT, El sitio oficial de GIT es http://git-scm.com/. Para instalar el cliente de Windows, redirige a  http://msysgit.github.com/.

En el caso de instalar el cliente en Windows, tenemos un plus adicional, nos pregunta si quieremos instalar diversos comandos típicos de Linux, lo cual es muy útil, así como una shell bash para Windows, git_bash. En este artículo usaré algunos de ellos, por comodidad.

Acceso por SSH.

Aunque GIT se puede usar con otros protocolos, el más conveniente es SSH. Nos permitirá limitar el acceso al repositorio a solo aquellas personas cuyas claves publicas hayamos instalado en el servidor, sin necesidad de crear usuarios específicos en nuestro servidor.

Vamos a empezar por ver el proceso de creación de las claves SSH.

No me propongo explicar cómo funciona el tema de las claves publicas porque queda fuera del alcance artículo, pero si alguien lo necesita, por aquí cuentan algo: http://git-scm.com/book/en/Git-on-the-Server-Generating-Your-SSH-Public-Key

Es necesario saber que en Ubuntu se usa openssh, con lo que las claves no son compatibles claves SSH como las generadas desde Putty… pero podemos convertirlas…. Tenemos varias posibilidades para usar SSH correctamente, pero la mejor es la última reseñada.

1. Podemos generar las claves en ubuntu:

DESDE UBUNTU

  1. Generar las claves openssh en Ubuntu, ejecutar ssh-keygen para generar una par de claves.
  2. Meter la clave en el almacén: cat clave.publica >> ~/.ssh/authorized_keys
  3. Copiar la clave privada al Windows:

scp GIT@123.123.123.123:/home/GIT/kk/clave.privada c:windowstemp

DESDE WINDOWS

Como hemos dicho antes, putty necesita claves de tipo SSH no openSSH. Para convertir la clave generada en Ubuntu,

ejecutar puttygen

hacer un “load” de la clave privada que hemos copiado en Windows.

Al hacerlo, puttygen lo reconoce como openssh y la importa. Tenemos que guardarla (como SSH) para usarla desde el putty

A partir de aquí, ya podemos usar putty dándole la clave privada ssh

2. Otra posibilidad es generarla desde Windows

Podemos generar claves SSH con puttygen

Si generamos con puttygen y guardamos las claves, las guarda como SSH pero muestra la clave pública en formato openSSH en la propia ventana:

Podemos copiar esta clave pública y ponerla en el fichero ~/.ssh/authorized_keys

También es posible subir la clave pública (o privada) generada desde Windows y convertirla y almacenarla en Ubuntu de esta forma:

ssh-keygen -i -f clave.pub >>.ssh/authorized_keys

3. La mejor opción es usar el ssh-keygen que trae el cliente para Windows de http://msysGIT.GIThub.com/,:

Arrancar GIT_bash
Generar clave:  ssh-keygen -t rsa -C “pepito@sevidor.com”

Importante para Windows: este comando crea las claves en %USERPROFILE%/.ssh

Importante: el nombre del archivo de clave (privada) tiene que ser id_rsa.

  1. Esto nos habrá generado un par de claves openSSH
  2. Lo siguiente será subir la clave publica al servidor y, en el caso de Linux, añadirla  en ~/.ssh/authorized_keys: cat id_rsa.pub >> ~/.ssh/authorized_keys
  3. Si además queremos usarla desde putty, tenemos que convertir la clave privada al formato de putty:
    1. Entrar en puttygen
    2. En el menu, conversions, import key
    3. Elegimos nuestro id_rsa
    4. Damos a “save private key” y le damos un nombre
    5. Este es el que debemos usar desde putty.

Instalación de GIT en UBUNTU

Para instalar GIT tenemos dos posibilidades:

  1. Usar un PPA(<http://www.makeuseof.com/tag/ubuntu-ppa-technology-explained/> )
  2. Ir por los repositorios oficiales

1. PPA

Una forma de actualizar/obtener el software en Ubuntu es a través de los repositorios oficiales. Estos son actualizados cada 6 meses, que es cuando se libera una nueva versión del sistema operativo. Actualizar a través del repositorio oficial es muy cómodo, evita tener que ir buscando el software a cada uno de los proveedores y además, pasa el filtro oficial del equipo de Ubuntu. Pero claro, cada 6 meses.

Si tu software favorito ha sido actualizado, tienes que esperar a la liberación semestral para instalarlo desde el Ubuntu Software Center. A no ser que uses un PPA, un Personal Package Archives, que es la forma de acceder rápidamente a la última versión publicada.

Un PPA suele centrarse en un único paquete de software. Te permite, por ejemplo, instalar software que aun no ha sido liberado.

Para usarlo, lo primero que se hace es añadir el repositorio del programa al “sources.list”. De esta forma obtendremos el programa y además, obtendremos las futuras actualizaciones, de la misma forma que el resto del software.

Por lo tanto los pasos para añadir la última versión de GIT serian los siguientes:

  1. Añadimos el repositorio

sudo add-apt-repository ppa:git-core/ppa

  1. Hacemos un update de APT

sudo apt-get update

  1. instalamos el paquete GIT-core:

sudo apt-get install git-core

Y ya está. Mucho más fácil de hacer que de explicar.

 

2. Repositorio por defecto

Simplemente tenemos que hacer lo siguiente:

sudo apt-get install git-core

Crear un usuario con acceso SSH dedicado para GIT

Crear el usuario, por ejemplo “GIT”

sudo adduser git

Ahora necesitamos que los desarrolladores que vayan a usarlo nos pasen sus claves públicas para añadirlas al ssh.

Tienen esta forma

cat /tmp/id_rsa.pepe.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4LojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4kYjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9EzSdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myivO7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq dAv8JggJICUvax2T9va5 gsg-keypair

Tenemos que añadir todas al fichero .ssh/authorized_keys

$ cat /tmp/id_rsa.pepe.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.maria.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.javineitor.pub >> ~/.ssh/authorized_keys

 

Ya tenemos todo listo, ahora ya podemos crear el repositorio

  1. cd $someWhere
  2. mkdir repositoriosGIT
  3. cd !$
  4. mkdir proyecto1.GIT
  5. cd !$
  6. git –bare init

A partir de aquí, cada desarrollador tendrá que “bajarse” el repositorio.

Pero, como esto se está alargando, lo veremos en una segunda entrada…