Aumentando espacio de maquina virtual,huésped Centos

Hace dos semanas tuve un problema que me detuvo en mi trabajo :

Hace meses me había bajado una máquina de Cloudera para para montar una aplicación piloto de pruebas con Bigdata,la máquina virtualidad, pero con poco espacio en disco.Luego de comenzar mis pruebas ,bajarme ficheros de datos de considerable tamaño e instalar buena cantidad de cosas mi Linux comenzó a gritar que apenas tenia espacio en disco.

Mi problema :

Como aumentar el espacio en disco de una maquina virtual,en mi caso un Centos(el que 

tienen las máquinas de Cloudera(4.X),la 5.X tiene mas espacio).Pues si tienes la version 

5.x aunque tiene bastante espacio en disco puedes tener en un futuro el problema.

Haciendo googling por una parte y preguntando a amigos llegue a esta solución :

Los comandos : sistema anfitrión Windows pero es exactamente igual para los que trabajamos linux/mac

Referenecia a los comandos de virtualbox:

https://www.virtualbox.org/manual/ch08.html

Es recomendable hacer una copia de la máquina virtualizada antes de comenzar a realizar 

cualquier tipo de modificación sobre este servicio.

El proceso de resize de VirtualBox debe ser sobre copias .vdi (virtual desktop infrastructure) con lo que si tenemos una copia en formato vmdk(virtual machine disk) tendremos que convertirla a formato .vdi ,hacer nuestra operación y luego volver a convertirla a .vmdk.Si tenemos una copia .vdi pues obviaremos el paso de la conversión.

Nos ubicaremos en este escenario :

#convertimos de vmdk a vdi

- \path_virtualBox\VBoxManage clonehd “centos-virtualizado.vmdk” “centos-virtualizado.vdi” –format VDI

#cambiamos el tamaño de la imagen existente,muy importante ,el tamaño lógico no se altera tamaño fisico 

- \path_virtualBox\VBoxManage modifyhd “centos-virtualizado.vdi” –resize <espacio a aumentar en MegaBytes>

#convertimos de vdi a vmdk

- \path_virtualBox\VBoxManage clonehd “centos-virtualizado.vdi” “centos-virtualizado-final.vmdk” –format VMDK

En este punto nuestra máquina virtual tiene el tamaño lógico que queremos ,ahora necesitamos el físico.

Una vez que tenemos el tamaño lógico necesitamos lo siguiente :

Aumentar el tamaño físico de la partición,algo interesante a través de fdisk si eres un experto.Recuerda 

que vía comando tendrás que tener en cuenta el tamaño lógico que haz aumentado(en el escenario anterior 

el cambio tamaño de la imagen .vdi) 

De cualquier modo si te quieres ahorrar los anteriores cálculos tenemos para ti otra recomendación mucho más 

sencilla aunque ligeramente mas larga.

Lo primero : 

Descargase gparted como una imagen (.iso) desde: http://gparted.sourceforge.net/download.php.

Una vez descargada dicha imagen son estos los pasos a seguir : 

• Crearemos una nueva máquina virtual desde VirtualBox 
• El sistema operativo base : un linux ,por ejemplo un Fedora 64bits
• NO le agregamos ningún disco a la misma ,aún  cuando nos de un aviso por ello.

Luego de tener solucionado los 3 puntos anteriores :

Vamos a agregar la imagen .iso que anteriormente descargamos tal y como lo indica la imagen con lo que quedaría agregada como controlador IDE.

Además de ello agregamos como controlador SATA la imagen (.vmdk o .vdi) .  

Una vez que tenemos totalmente configurada nuestra nueva máquina virtual vamos a la pantalla principal que será tal como sigue :

Ya tenemos nuestra nueva máquina GParted ,que es la nueva máquina creada y cuyo único objetivo será  aumentar el tamaño físico de la máquina virtual puesta como disco(SATA).

Ahora nos queda arrancar la máquina GParted.Al arrancar la máquina  se inicia gparted y a partir de aquí con esta herramienta visual asignamos todo el espacio necesario.

Luego de asignar el espacio deseado salimos de la máquina y le desconectamos el disco virtual(al que le hemos cambiado el tamaño).

A partir de aquí y como última etapa seguimos los siguientes pasos :

1. Conectamos el disco virtual(al que le hemos cambiado el tamaño) a otra nuestra maquina virtual de trabajo.
2. La arrancamos 
3. Una vez dentro tenemos que aumentar el tamaño físicamente y dependerá en  en buena medida del file system instalado en las particiones .

A continuación adjuntamos 2 link que explican el 3.

Para el caso de particiones xfs ver referencias a  xfs_growfs en el siguiente link aumentando particiones xfs .

Para el casi de particiones LVM ver referencias a LVM en el siguiente link aumentando particiones LVM

Hay muchas vías  para hacer esto,ninguna de ellas corta cuando hablamos de aumentar el espacio en la máquina virtualizada cuando el huésped es un Linux.Esto desde luego es para cuando ya no tengamos otra opción.

Salud que haya que belleza SOBRA... 

Instalando e inspeccionando aplicación java en Openshift

Instalando un .war en openshift :

Suponemos que tienes instaladas las tools (rhc) de no ser así puedes encontrar en la web de openshift todos los detalles de esta instalación .Una vez que tenemos instaladas las tools procedemos a realizar el despliegue de nuestro war.

vias para desplegar el war :

- git
- a traves de las tools de rhc

Nos centramos en la instalación de las tools veo que caso de los despliegues por git de un modo todavía no eficiente y explico :
Dado el caso que tengamos algún proyecto mavenizado y subido al repositorio hemos de eliminar los respectivos POMs y además cambiar la estructura del proyecto dejando solo la carpeta src de nuestro proyecto con una serie de especificaciones más en la que no entraremos en detalles.

A través de las tools de rhc mirar que simple :

- Generamos el .war (dado el caso que lo tengamos en un contenedor web,en nuestro caso Tomcat 7 (JBoss EWS 2.0)) pero podríamos estar hablando de un jboss y de un ear.
- Una vez generado el .war lo renombramos (ROOT.war).Este ROOT.war será el war a agregar en  
   nuestro siguiente paso

- Creamos un comprimido tar.gz  con la siguiente estructura :

build_dependencies/ (directorio vacio)
dependencies/
   jbossews/
       webapps/
           ROOT.war
repo/
   .openshift/ (directorio vacio,de momento y para nuestro intereses)

- Para los que no trabajan con linux en el mundo cloud ,lo de No linux es imposible o mejor aun luego doy una visión al respecto de momento te indico que comando ejecutar para crear nuestro .tar.gz :

En el directorio donde quiero crear el fichero (en nuestro caso justo encima de la carpeta de dependencias ejecuto el comando que sigue) :

tar czf testfile.tar.gz *

ya tengo mi fichero creado ,que quiero comprobar si todo ha salido bien :

tar tf testfile.tar.gz esta opción la he probado con Mac OSX  pero ha de valer para todo.

Toda vez que tenemos ya nuestro comprimido con la estructura y formato solicitando por nuestra plataforma vamos a proceder a subirlo a la nuestra plataforma PaaS :

1 - rhc app configure -a <nombre_de_app_desplegada_en_opneshift> --deployment-type binary
2 - rhc app deploy -a <nombre_de_app_desplegada_en_opneshift> path/de/testfile.tar.gz

Y ya hemos desplegado nuestra aplicación ,ven que fácil ?

Algunas consideraciones ,el hecho de renombrar el .war a ROOT.war hace ,de acuerdo a la plataforma que pase del content roto de la app y para acceder a ella lo hagamos a través del contentroot estándar que nos brinda openchift + urlparam establecido en el .war a la hora de mapear la navegacióndel servle de carga de alta aplicación.


Otro detalle de nuestra aplicación en el momento de definir el sistema de logger de la misma,en nuestro caso usamos log4j y tuvimos algún problema debido a que no encontraba la ruta donde deja los blog .Para todo ello openshift cuenta con variables de entornos que nos dicen :
- ip de nuestro entorno cloud,puertos ,path donde son alojados los logs etc.

Como acceder a toda esta información :

La unica via a través de la cual podemos conectarnos con nuestra plataforma y poder acceder a la máquina donde tenemos todo nuestro entorno virtualizado es vía SSH con lo que les indico varias cosas :

1 - crear clave publica en nuestra máquina sino la tenemos ya.
2 - esta clave publica podemos agregarla a nuestro dominio(No Aplicación ) en openshift.

Luego de pasados los puntos 1 y 2 la vía para conectaron Ssh seria la siguiente :

ssh -t 53c920c9e0b8cd1e12000045@nombre_de_app-nombre_de_dominio.rhcloud.com una vez hecho esto ya estamos en nuestra plataforma.
Detalle importante del que seguramente te habrás dado cuenta,los dígitos alfanuméricos son los del ssh son los que aparecen debajo de Source Code en la imagen anterior.Esta imagen corresponde a la imagen de propiedades de la aplicación en el propio entorno de openshift.
Un detalle ,ya una ves dentro de la máquina de openshift el comando  ls .\env nos brinda todos las variables entorno que contiene nuestro entorno y que necesariamente será de gran utilidad.Ver imagen que sigue .

Creo que por hoy será suficiente nuestra entrega de java sobre openshift ,es probable aunque no seguro que aun nos quede otra entrega lo siguiente a ello ruby o scala sobre openshift ,cassandra ,spark,map reduce ,lucene ,solr y demás.Justo luego que culminemos una última entrega de java.Eso será luego que volvamos de las vacaciones que justo comienzan hoy.Algo pendiente y que seria muy interesante ver seria OPENSTACK de Redhat un producto cuando menos interesante y enfocado a cambiar una tendencia...hasta septiembre ..

Entendiendo Platform as a Service RedHat OpenShift

Dejamos los protocolos Bittorrent aparcados por un tiempo.tengo pendiente imágenes a subir así que vamos con otro amigo PaaS(Platform as a Service) ,de RedHat. Una plataforma desde mi punto de vista y para lo que conozco del tema que esta muy bien.Tiene como ventajas algunas prestaciones free en las que además no necesitamos introducir tarjeta de crédito como en Amazon si bien es cierto que toda esa libertad de apertura de puertos para recibir peticiones ,hacer bindings con sockets etcétera en redhat aun es impensable incluso en la versión enterprise de Openshift.
No se si están familiarizados con Cloud Computing tanto el termino como lo que ello implica,de momento suponemos que si .De no ser así les adjunto un video que en cierto modo da una idea sobre el término y los distintos módulos que engloba,no es nada complejo el concepto a nivel global ni tampoco su uso.Otra cosa bien distinta es la construcción de los mismos,pero de eso hablaremos en próximas entregas.

Si entras en el link : https://www.openshift.com/ tienes 3 opciones vamos a coger la free ,estamos empezando :) .

Toda vez que creamos una cuenta ya podemos :
1- crear un dominio
2- crear hasta 3 aplicaciones para ese dominio con capacidad para 1Gb en cada una.

Como funciona ?
Cada aplicación que creamos le agregamos los llamados Cartridges que no son más que funcionalidades o servicios que estarán a nuestra disposición .
Por ejemplo tenemos una aplicación web y la necesitamos desplegar en un Tomcat (contenedor web)  o en Jboss pues agregamos un Cartridge que los tenga y ya nos lo deplegara en dicho tomcat,todo ello para entorno Java aunque también encontramos Cartridges  para PHP o para Ruby  lenguaje al que nos iremos inclinando junto con Scala en futuras entradas.Nos iremos desvinculando de JAVA poco a poco ,ninguna queja en particular salvo que se nos ha vuelto aburrido luego de tantos años.

Aspectos básicos de la implementación del protocolo BitTorrent

Lo primero para la implementación del protocolo Bittorrent es ver la especificación del mismo.
Lo tenemos en http://www.bittorrent.org/beps/bep_0003.html a partir de aquí tenemos varias cosas a tener en cuenta una de ellas es el lenguaje en el que realizar las implementaciones.
Podríamos detallar código pero es perdida de tiempo,a continuación algunas implementaciones interesantes :
- https://github.com/mpetazzoni/ttorrent  esta implementación es totalmente fiel al protocolo pero las descargas son excesivamente lentas.

- http://bitpower.sourceforge.net esta es la implementación mas completa

Una porción del código

File metadataDirectory = new File("/Users/ldipotet/javaapps/testclientTor/TorrentClientProject");
   
try {
//lo cierto es que aun no se para que usan este metadirectory,se crea la carpeta en el sitio indicado con un id 
//luego esta carpeta la entramos siempre vacía 
     controller = new TorrentSetController (metadataDirectory);
    } catch (IOException e) {
 e.printStackTrace ();
 exitWithError ("Could not open server socket");
    }

 // Can't actually happen. Satisfies compiler stupidity
 if (controller == null) return;

   TorrentManager manager = null;
 try {
 //implica que el fichero el fichero sera descargado en la raiz del proyecto....
 //podriamos agregar un TorrentManager por cada peticion??? 
    
 manager = controller.addTorrentManager (torrentFile, new File("."));
    manager.start (false);

Tal y como detallo en el código el código descargado se deja en la raíz del proyecto y el metadatadirectory solo es necesario para seguir los trackers dado el caso que se interrumpa por alguna razón la descarga.
En esta implementación (bitpower) la clase ConnectionManager es la que gestiona las conexiones.

public synchronized int listen (InetAddress listenAddress, int listenPort, InboundConnectionListener listener) throws IOException {

if (this.closed) {
 throw new IOException ("ConnectionManager is closed");
}

  // Open a server channel and register it with the selector
final ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
serverSocketChannel.configureBlocking (false);
InetSocketAddress socketAddress = new InetSocketAddress (listenAddress, listenPort);
serverSocketChannel.socket().bind (socketAddress);
int boundPort = serverSocketChannel.socket().getLocalPort();

  // Associate the server channel with the specified listener
this.inboundConnectionListeners.put (serverSocketChannel, listener);

  // Queue the server socket for registration, asynchronously
synchronized (this.queuedTasks) {
 this.queuedTasks.add (new Runnable() {
  public void run() {
    try {
  serverSocketChannel.register (ConnectionManager.this.selector, SelectionKey.OP_ACCEPT);

.............

public synchronized Connection connect (final InetAddress remoteAddress, ...) 

throws IOException
{
 if (this.closed) {
 throw new IOException ("ConnectionManager is closed");
  }
final SocketChannel socketChannel = SocketChannel.open();
socketChannel.configureBlocking (false);
final Connection connection = new Connection (this, socketChannel);

  // Queue the connection to be opened
synchronized (this.queuedTasks) {
  this.queuedTasks.add (new Runnable() {
  public void run() {
 try {
              boolean completeConnection = socketChannel.connect 

               (new InetSocketAddress (remoteAddress, remotePort));
  SelectionKey key = socketChannel.register 

                (ConnectionManager.this.selector, SelectionKey.OP_CONNECT);
  key.attach (connection);
  Long deadline = (connectTimeout == 0) ? 

                Long.MAX_VALUE : System.currentTimeMillis() + 

                (connectTimeout * 1000);
  ConnectionManager.this.pendingConnections.put 

                (socketChannel, deadline);
  ConnectionManager.this.outboundConnectionListeners.put 

                (socketChannel, listener);
  if (completeConnection) {
        processConnect (key);

Para no hacer esto tedioso con tanto código, los dos métodos básicos listen y connect implementan los sockets aquí se registran y además se hacen los binding a las respectivas direcciones.
Esta información así como la cantidad de piezas la coge de los hash y las direcciones a conectarse de los torrent tracker server .
En fin para ser una implementación en cliente standalone es una buena opción .

Si fuera constituir el core para el lugar de llamar a un torrent llamar a un conjunto de torrent implementan un elasticseed,este no lo he probado os lo dejo a vosotros.

El core de este tema para hacer llamadas múltiples es una explotación a fondo del api de concurrencia de java http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-summary.html que va desde los tipos thread safe hasta la implementación de Executors o Semaphores.

He aquí algunos enlaces de clientes torrent online :

- http://www.noobstogeek.com/free-online-torrent-downloader/
- https://www.furk.net/
- https://www.furk.net/


Vale destacar que además de ellos tenemos algunas versiones en c++ standalone para linux que funcionan de muerte tanto como librerías para ser usadas digase por ejemplo a través de un servicio rest o a través de  la shell en linux :

- http://aria2.sourceforge.net/manual/en/html/README.html

Esta implementación esta fenomeno ..totalmente indescriptible con un consumo mínimo de memoria, el problema es la limitación a usuarios linux para el caso que queramos disfrutar de esta máxima eficiencia......


People hasta otra entrega ...seguimos sin poner imágenes ,para la próxima ...
 

Bittorrent on cloud ,crónica de una muerte anunciada.

Intento fallido de montar en un entorno cloud un proyecto bittorent.

El principal problema ha sido la plataforma OpenShift ,no permite abir puertos al exterior.El core del problema funciona en mi local , intentamos subirlo a una plataforma cloud (PaaS) y no ha sido posible.En un principio por nuestras direcciones locales.Luego de ello hemos sustituido por las variables de entorno de OpenShift y entonces podía hacer un binding desde una dirección local via socket pero toda vez que intentaba cambiar dichas direcciones SocketDenied!!!!!!.Si hubieramos conseguido una implementación del protocolo BitTorrent via Websocket podríamos haber tenido nuestra solución en las manos SI los Miami HEAT hubieran ganado la liga Lebron no estaría en Cleveland , así es la vida. 

Existían 2 soluciones al respecto una de ellas buscar un servidor Dedicado y subir alli nuestro .war y empezar a trabajar.

Hemos optado por la segunda ,pasar del tema .Ha salido la ley de la Propiedad Intelecual  o al menos la han aprobado,sale en el 2015.Multas muy grandes de 30 000 - 300 000 para temas que se ajustaban al proyecto que nos encontramos desarrollando.

La solución sera ir a por otro tema así que al menos de momento esta es la muerte un un proyecto que apenas empezó en sus pruebas.

Voy a empezar a poner imágenes a este blog ..de todos modos nadie lo mira. 

Entendiendo el protocolo BitTOrrent

Sabemos que BitTorrents es un protocolo, lo usamos para la distribución de ficheros que generalmente suelen ser ficheros de tamaños considerables. No existe un servidor con todo el fichero en su totalidad.
El usuario que quiere compartir un fichero lo primero que tiene que hacer es crear un fichero descriptor torrent que se distribuirá a través de red para todos aquellos que deseen descargarse el archivo. En este momento está haciendo disponible el fichero a través de un nodo Bittorrent(estamos en presencia de una semilla). Aquellos que se descarguen el fichero descriptor torrent se convertirán en un nodo Bitttorrent que puede actuar como un colega o igual (este es el caso en el que servirá de fuente a otros consumidores del torrent) o puede actuar como una sanguijuela(leechers) en este caso consumirá de otros una parte del fichero.Dependiendo de su roll se conectara a una semilla(siendo un leecher) o será la semilla de otro(peer).

 El fichero que queremos distribuir es dividido en varias partes y cada peer recibirá una de estas partes con lo cual se convertirá en una fuente de esta parte (o pieza del fichero ) para otros peers. De este modo ayuda en la tarea a la semilla original del fichero para no tener que enviar ella(seed) sola la copia a cada usuario que la quiera. De este modo la tarea de obtener un fichero es compartida por todos los usuarios que le quieran. 

Cada parte del fichero a distribuir es protegido  por un  cryptographic hash, para otra entrega veremos las cryptographic hash function en profundidad. Algunos algoritmos que  podemos incluir   (MD2,MD4,MD5). EN nuestra próximas entregas trataremos en profundidad estos algoritmos y sus diferentes tipos de implementaciones.

 Elementos que componen la implementación  de este protocolo:

•  seed (semilla)  - las que contienen la información del fichero  
•  peers (colegas,iguales)  - los que ademas de coger información(partes del fichero)  también comparten algunas piezas del mismo.
•  leechers (sanguijuelas) - los que solo cogen información (partes del fichero,no comparten  nada)

Todo gira en torno a compartir la información,en nuestro ejemplo un file y el modo en darle a conocer al resto de la RED lo referente a este fichero es a través de un  fichero metadata que contiene todo lo necesario para bajar nuestra información:
fichero metadata : mifichero.torrent

Notas del Autor

Buenas a todos. Se nos ocurre, de momento, comenzar un blog. Y lo haremos sin pensar y como nos salga.

Nuestros artículos no serán de definiciones, para ello existe Wikipedia y seguramente lo hará  mucho mejor, estamos convencidos. Con lo que nuestra diferenciación estará en el punto técnico.

Cogeremos un producto OpenSource o no y lo abriremos al mundo de la programación. ¿Por qué hacerlo? Pues de momento sólo porque nos apetece, aunque también podremos poner en este espacio algún producto en el que hayamos trabajado o estemos trabajando la Compañía greenMojito.