Nginx como proxy inverso con SSL

Hace unos días me plantearon la necesidad de publicar en Internet u servicio que estaba corriendo sin ningún tipo de encriptacion, con lo que los passwords se estaban transmitiendo en claro.
Dándole vueltas encontré este tutorial donde se exponía un caso similar con la aplicación Jenkins:
(por cierto, muy buena la página de tutoriales de Digital Ocean)

La idea de este tutorial es la de montar un nginx delante del servicio que se quiere securizar de forma que encripte las comunicaciones que van por la red publica. Esta configuración se conoce como “reverse proxy” y el diagrama seria el mostrado a continuación:

Instalación de nginx

Para instalar nginx descargaremos el rpm ccorrespondiente desde la web del proyecto Nginx . Éste rpm nos configurara el repositorio lo que nos permitira instalarlo con yum:

[root@nginxprxy tmp]# yum -y install nginx-release-rhel-6-0.el6.ngx.noarch.rpm [root@nginxprxy tmp]# yum install -y nginx

Configuración del proxy reverso con ssl 

Como este servidor va a servir exclusivamente para la securización de un servicio no seguro editaremos el fichero de configuración default.conf. Lo deberemos dejar de la siguiente forma:
[root@nginxprxy tmp]# cd /etc/nginx/conf.d 
[root@nginxprxy conf.d]# cat default.conf 
server {
listen 80;
return 301 https://$host$request_uri;
}


# HTTPS server
#
server {
listen 443;
server_name service.enterprise.com;

ssl_certificate /etc/nginx/certs/service.enterprise.com.crt;
ssl_certificate_key /etc/nginx/certs/service.enterprise.comm.key;

ssl on;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;

access_log /var/log/nginx/service.access.log;

location / {

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

# Fix the “It appears that your reverse proxy set up is broken" error.
proxy_pass http://
unsecureservice.enterprise.com;
proxy_read_timeout 90;

proxy_redirect http://unsecureservice.enterprise.com https://service.enterprise.com;
}
}
En la primera parte, se redigirán todas las peticiones a la misma URL pero al puerto de HTTPS. Así, cualquier petición al puerto por defecto de HTTP será redirigida, sin posibilidad de servir contenido que no esté cifrado.
En la segunda parte, es donde se especifica el puerto de escucha HTTPS, los certificados y varias opciones del protocolo SSL. 

Por último se establecen las reglas de redirección del proxy de forma que todo lo que entre a través de la URL https://service.enterprise.com; lo redirija a la http://unsecureservice.enterprise.com.

Antes de arrancar el servidor deberemos conseguir los certificados. Lo primero será generar el CSR en el directorio que hemos especificado en el fichero de configuración:

[root@nginxprxy tmp]# cd /etc/nginx/
[root@nginxprxy tmp]# mkdir certs
[root@nginxprxy certs]# openssl req -new -newkey rsa:2048 -nodes -keyout service.enterprise.com.key -out service.enterprise.com.csr
Generating a 2048 bit RSA private key
……………………………………….+++
…+++
writing new private key to ‘service.enterprise.com.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [XX]:XX
State or Province Name (full name) []:XXXX
Locality Name (eg, city) [Default City]:XXXX 
Organization Name (eg, company) [Default Company Ltd]:XXXX
Organizational Unit Name (eg, section) []:XXXX
Common Name (eg, your name or your server’s hostname) []:service.enterprise.com
Email Address []:XXXX@enterprise.com

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Una vez obtengamos el certificado deberemos crear el fichero crt con el contenido del certificado: 

[root@nginxprxy certs]# vi service.enterprise.com.crt  —–BEGIN CERTIFICATE—– MIIFWjCCBEKgAwIBAgIDCmMEMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBAYTAlVT8WjFirPK7+2Gbq+9w4DpJ+a5FJjTOKfcRvIrZION 

—–END CERTIFICATE—–

Será el momento de arrancar el servidor Nginx y probar la conexión desde un navegador, donde deberemos ver que inmediatamente se redirecciona a un puerto seguro y que el certificado es válido:

[root@nginxprxy conf.d]# service nginx stop Stopping nginx: [FAILED] [root@nginxprxy conf.d]# service nginx start  Starting nginx: [ OK ]

Anuncios

Conseguir Root en OnePlus One

Ayer me llegó el OnePlus One y después de utilizarlo un rato y acostumbrado a tener acceso root en mi anterior móvil me decidí a rootearlo para poder bloquear anuncios y utilizar el Greenify. El proceso es muy sencillo y se puede dividir en tres partes: Desbloquear el bootloader, instalar el recovery y instalar el SuperSU.

Como prerequisito para todo el proceso será necesario tener las utilidades fastboot y ADB en el PC que vayamos a utilizar. Para instalar las android tools en ubuntu podemos hacerlo desde los repositorios de ubuntu (fastboot y adb) con el siguiente comando:

$ sudo apt-get install android-tools-fastboot android-tools-adb

Vayamos ya con el proceso de rooteo.

1. DESBLOQUEAR EL BOOTLOADER

Debemos activar el modo Depuración. Para ello habilitaremos primero las opciones de desarrollo. Iremos a Ajustes-> Información del teléfono y tocaremos 7 veces en compilación. Una vez habilitado en el menú principal de los ajustes nos saldrá la opción “opciones de desarrollo”. Una vez dentro habilitaremos el debug de USB en el teléfono dejándolo como en la siguiente imagen:

Habilitar la opción de Depuración

Conectaremos el teléfono al ordenador con el cable USB y desde una terminal reiniciaremos en modo “fastboot”:

$ adb reboot bootloader

Una vez en modo “Fastboot” verificar que el PC vea el dispositivo con el comando “sudo fastboot devices“. El comando nos devolverá el número de serie del teléfono. En el modo fastboot en la pantalla aparece el logo de OnePlus y un texto con el mensaje fastboot.

Desde el mismo terminal desbloquear el bootloader:

$ sudo fastboot oem unlock

OKAY [ 0.005s]
finished. total time: 0.005s

NOTA: En este paso se borran todos los datos del teléfono. Haz una copia de seguridad de lo que necesites antes.

A continuación el teléfono se reiniciará, aparecerá un Android ejecutando el proceso y finalmente se vuelve a reiniciar.

Será necesario volver a habilitar el debug de usb para continuar con la instalación del recovery.

2. INSTALAR RECOVERY

Antes de instalar el nuevo recovery deshabilitaremos la opción “Actualizar recovery de CM” para que no nos lo machaque la próxima vez que arranque el teléfono. Esta opción esta en las opciones de desarrollo:

Deshabilitar la opción “Actualizar recovery de CM”

Descargaremos la última imagen correspondiene para el OnePlus desde la URL:

http://techerrata.com/browse/twrp2/bacon

En mi caso he descargado la siguiente imagen:

http://techerrata.com/file/twrp2/bacon/openrecovery-twrp-2.8.0.1-bacon.img

Filename: openrecovery-twrp-2.8.0.1-bacon.img

MD5sum: d03de30d110d0075a2a6c5cf5f2706a2

Verficaremos el MD5 por seguridad, ya que si instalamos una imagen dañada el teléfono no arrancaría:

$ md5sum openrecovery-twrp-2.8.0.1-bacon.img
d03de30d110d0075a2a6c5cf5f2706a2 openrecovery-twrp-2.8.0.1-bacon.img

Vemos que el MD5 corresponde con el publicado en la web, con lo que procederemos a reiniciar en modo “Fastboot”:

$ adb reboot bootloader

Otra vez verificaremos que el PC vea el dispositivo con el comando “sudo fastboot devices“. En caso correcto grabaremos la imagen del nuevo recovery (tarda apenas unos segundos):

$ sudo fastboot flash recovery openrecovery-twrp-2.8.0.1-bacon.img

En la pantalla del teléfono no se aprecia ningún cambio, pero realmente se ha instalado bien si la salida del comando no da errores.
Una vez flasheada la partición de recovery se continua con el arranque con el siguiente comando:

$ sudo fastboot continue
resuming boot…
OKAY [ 0.002s]
finished. total time: 0.003s

Una vez se haya completado correctamente, reiniciar el teléfono en modo recovery para verificar la instalación. Para arrancar en modo recovery con el teléfono apagado pulsar las teclas Volumen-Abajo y la tecla de encendido.

3. ROOTEAR:

Hay que bajar la última versión del fichero UPDATE-SuperSU-v2.37.zip desde http://download.chainfire.eu/supersu y grabarlo en la raíz de la memoria del teléfono.

Una vez el recovery instalado, arrancar en modo recovery con el siguiente comando:

$ adb reboot recovery

Seleccionar “Install” en el TWRP Recovery. Buscar el fichero que hemos copiado e instalarlo.

Reiniciar el teléfono y ahora encontrarás la aplicación SuperSU. Abre la aplicación y si no se obtienen errores el teléfono se habrá rooteado correctamente.

Jugando con Docker

Últimamente se esta oyendo mucho hablar de Docker. Se trata de una tecnología similar a la que ya existía en Solaris con las zonas, y en Linux con LXC (de hecho utiliza LXC por debajo). Parece que viene patrocinado por algunas de las grandes en internet como eBay, Spotify e incluso Google parece que venia utilizando algo parecido desde hace tiempo.
Docker
La gran ventaja, como en el caso de las zonas, es que te permite “virtualizar” sin depender de un hipervisor y con un overhead mínimo en comparación a la virtualización tradicional.

Instalación

Como todo en Linux es muy fácil de instalar y ya viene preparado en la mayoría de distribuciones. En el caso de CentOS hay que habilitar el repositorio EPEL editando el fichero de configuración del repositorio y poniendo la variable enabled a 1:

[root@centos1 ~]# vi /etc/yum.repos.d/epel.repo

[epel]
name=Extra Packages for Enterprise Linux 6 – $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
A continuación ya podemos instalar docker con yum. Como veremos, una de las dependencias es LXC:
[root@centos1 ~]# yum install docker-io
Dependencies Resolved

================================================================================
 Package            Arch            Version                 Repository     Size
================================================================================
Installing:
 docker-io          x86_64          1.0.0-3.el6             epel          4.5 M
Installing for dependencies:
 lxc                x86_64          0.9.0-2.el6             epel           78 k
 lxc-libs           x86_64          0.9.0-2.el6             epel          116 k

Transaction Summary
================================================================================
Install       3 Package(s)

Total download size: 4.7 M
Installed size: 24 M
Is this ok [y/N]: y

Así de sencillo es instalarlo. Y como vemos, la versión es la primera estable que se ha publicado recientemente:
[root@centos1 ~]# docker -v
Docker version 1.0.0, build 63fe64c/1.0.0
Para empezar a utilizarlo se debe iniciar el servicio y configurarlo para que arranque en el runlevel predeterminado:
[root@centos1 ~]# service docker start
Starting cgconfig service:                                 [  OK  ]
Starting docker:                                                [  OK  ]
[root@centos1 ~]# chkconfig docker on

Imágenes y contenedores

Con el servicio ya en marcha podemos descargar las imágenes que docker mantiene, así como imágenes que la comunidad ha creado y ha subido. Por ejemplo descargaremos las últimas para centos y para ubuntu:

[root@centos1 ~]# docker pull centos:latest
Pulling repository centos
0c752394b855: Download complete
511136ea3c5a: Download complete
34e94e67e63a: Download complete

[root@centos1 ~]# docker pull ubuntu:latest
Pulling repository ubuntu
e54ca5efa2e9: Download complete
511136ea3c5a: Download complete
d7ac5e4f1812: Download complete
2f4b4d6a4a06: Download complete
83ff768040a0: Download complete
6c37f792ddac: Download complete
Para ver las imágenes que tenemos descargadas y disponibles para utilizar bastará con ejecutar el subcomando “images”:
[root@centos1 ~]# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
ubuntu              latest              e54ca5efa2e9        41 hours ago        276.1 MB
centos              latest              0c752394b855        10 days ago         124.1 MB
Pasando el parámetro -a podemos ver el historial de versiones de cada imagen:
[root@centos1 ~]# docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
ubuntu              latest              e54ca5efa2e9        41 hours ago        276.1 MB
                            6c37f792ddac        41 hours ago        276.1 MB
                            83ff768040a0        41 hours ago        192.7 MB
                            2f4b4d6a4a06        41 hours ago        192.7 MB
                            d7ac5e4f1812        41 hours ago        192.5 MB
centos              latest              0c752394b855        10 days ago         124.1 MB
                            34e94e67e63a        2 weeks ago         0 B
                            511136ea3c5a        12 months ago       0 B
Podremos arrancar instancias o contenedores con las imágenes que queramos de la siguiente manera:
[root@centos1 ~]# docker run -i -t centos /bin/bash
bash-4.1# more /etc/centos-release
CentOS release 6.5 (Final)
bash-4.1# hostname
3ce460cbb9d8

[root@centos1 ~]# docker run -i -t ubuntu /bin/bash
root@60d6e0455be0:/# more /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION=”Ubuntu 14.04 LTS”
root@60d6e0455be0:/# hostname
60d6e0455be
Al pasar el parámetro -i al comando run se ejecutará el contenedor de forma interactiva, de forma que, en cuanto termine el comando que pasamos como parámetro la ejecución del contenedor terminará.
Mientras estemos ejecutando la shell, veremos que el contenedor está ejecutándose:
[root@centos1 ~]# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
49087a343e7f        centos:latest       /bin/bash           12 seconds ago      Up 11 seconds                           dreamy_curie   
Si quisiesemos ver un historial de las instancias ejecutadas pasaríamos el parámetro -a:
 [root@centos1 ~]# docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                      PORTS               NAMES
15dc7c59189c        centos:latest       /bin/bash           27 seconds ago      Up 26 seconds                                   compassionate_fermi  
49087a343e7f        centos:latest       /bin/bash           12 minutes ago      Exited (0) 17 seconds ago                       dreamy_curie         
9e69f5b64254        ubuntu:latest       uname -r            15 minutes ago      Exited (0) 15 minutes ago                       high_engelbart       
f5aa352a5ce9        centos:latest       uname -r            15 minutes ago      Exited (0) 15 minutes ago                       jovial_meitner       
60d6e0455be0        ubuntu:latest       /bin/bash           17 minutes ago      Exited (0) 16 minutes ago                       cocky_leakey         
961b10b9bbbf        ubuntu:latest       hostname            17 minutes ago      Exited (0) 17 minutes ago                       insane_mayer         
3ce460cbb9d8        centos:latest       /bin/bash           19 minutes ago      Exited (0) 17 minutes ago                       loving_yonath  
Si por contra, quisiesemos ejecutar un contenedor en background o demonizado, como sucede en Solaris con las zonas, al comando run le pasaríamos el parámetro -d. En el siguiente ejemplo arrancaríamos una instancia de la imagen ubuntu y dos instancias de la imagen de centos y finalmente veríamos que se están ejecutando las tres:
[root@centos1 ~]# docker run -d -t ubuntu  /bin/bash
abc254ab2e8eb392ce80938c8f2b8fa8cb1603ab6935b2121b7cb0cddbdd64c3
[root@centos1 ~]# docker run -d -t centos  /bin/bash
59adfe1998cc678cf2c9db964f1b57e60a301ffa2139c7a4635ebe315db2b718
[root@centos1 ~]# docker run -d -t centos  /bin/bash
6714217732adadec19f47399fe5f7252823787869a96e8fed72457cd5106589c
[root@centos1 ~]# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
6714217732ad        centos:latest       /bin/bash           3 seconds ago       Up 2 seconds                            romantic_shockley 
59adfe1998cc        centos:latest       /bin/bash           7 seconds ago       Up 6 seconds                            thirsty_bartik    
abc254ab2e8e        ubuntu:latest       /bin/bash           14 seconds ago      Up 13 seconds                           naughty_yonath 
Al arrancar cada contenedor nos devuelve un número muy largo. Este número es el container_id que mas adelante vemos en la primera columna del comando ps. La última columna es un nombre que se asigna automáticamente y servirá para identificar las instancias de una forma mas amigable. Para parar las zonas que están corriendo podríamos pasar como identificador tanto el container_id como el nombre:

[root@centos1 ~]# docker stop romantic_shockley
romantic_shockley
[root@centos1 ~]# docker stop thirsty_bartik
thirsty_bartik
[root@centos1 ~]# docker stop naughty_yonath
naughty_yonath
[root@centos1 ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 

Como vemos, el kernel que se está ejecutando es el del host:

[root@centos1 ~]# uname -r
2.6.32-431.el6.x86_64
[root@centos1 ~]# docker run -i -t centos uname -r
2.6.32-431.el6.x86_64
[root@centos1 ~]# docker run -i -t ubuntu uname -r
2.6.32-431.el6.x86_64

Otra forma de arrancar un contenedor es con el comando start y pasando como parámetro el id del contenedor o el nombre que docker le asigno en su momento (lo podemos encontrar con docker ps -a)
 [root@centos1 ~]# docker start romantic_shockley
romantic_shockley
[root@centos1 ~]# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
6714217732ad        centos:latest       /bin/bash           15 minutes ago      Up 3 seconds                            romantic_shockley
Para acceder a la consola del contenedor ejecutaríamos el comando attach:
 [root@centos1 ~]# docker attach romantic_shockley

Obtener información

Existe una serie de comandos que nos servirán para obtener información, tanto de docker, como de las imagenes o contenedores que tenemos creados. El comando info nos devolverá información general de la instalación actual de docker:
[root@centos1 ~]# docker info
Containers: 6
Images: 8
Storage Driver: devicemapper
 Pool Name: docker-8:1-132310-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 784.9 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 1.4 Mb
 Metadata Space Total: 2048.0 Mb
Execution Driver: native-0.2
Kernel Version: 2.6.32-431.el6.x86_64
Con el comando history veremos el historial de versiones de la imagen que le hayamos especificado:
[root@centos1 ~]# docker history centos
IMAGE               CREATED             CREATED BY                                      SIZE
0c752394b855        10 days ago         /bin/sh -c #(nop) ADD file:ce8fdb737386beb5fd   124.1 MB
34e94e67e63a        2 weeks ago         /bin/sh -c #(nop) MAINTAINER The CentOS Proje   0 B
511136ea3c5a        12 months ago                                                       0 B
También tendremos el comando inspect, que nos devolverá un objeto JSON con información detallada de la imagen. Tambien sirve para obetner información de un contenedor.

[root@centos1 ~]# docker inspect centos
[{
    “Architecture”: “amd64”,
    “Author”: “The CentOS Project \u003ccloud-ops@centos.org\u003e – ami_creator”,
    “Comment”: “”,
    “Config”: {
        “AttachStderr”: false,
        “AttachStdin”: false,
        “AttachStdout”: false,
        “Cmd”: null,
        “CpuShares”: 0,
        “Cpuset”: “”,
        “Domainname”: “”,
        “Entrypoint”: null,
        “Env”: [
            “HOME=/”,
            “PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin”
        ],
        “ExposedPorts”: null,
        “Hostname”: “b2d0f1281acd”,
        “Image”: “34e94e67e63a0f079d9336b3c2a52e814d138e5b3f1f614a0cfe273814ed7c0a”,
        “Memory”: 0,
        “MemorySwap”: 0,
        “NetworkDisabled”: false,
        “OnBuild”: [],
        “OpenStdin”: false,
        “PortSpecs”: null,
        “StdinOnce”: false,
        “Tty”: false,
        “User”: “”,
        “Volumes”: null,
        “WorkingDir”: “”
    },
    “Container”: “b2d0f1281acd040292b36f6623feca10a89df1637c8d86e54079d473da4d05e3”,
    “ContainerConfig”: {
        “AttachStderr”: false,
        “AttachStdin”: false,
        “AttachStdout”: false,
        “Cmd”: [
            “/bin/sh”,
            “-c”,
            “#(nop) ADD file:ce8fdb737386beb5fd9aff7c9bbe9e6c9e60db290809dd6407c61b377e444b59 in /”
        ],
        “CpuShares”: 0,
        “Cpuset”: “”,
        “Domainname”: “”,
        “Entrypoint”: null,
        “Env”: [
            “HOME=/”,
            “PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin”
        ],
        “ExposedPorts”: null,
        “Hostname”: “b2d0f1281acd”,
        “Image”: “34e94e67e63a0f079d9336b3c2a52e814d138e5b3f1f614a0cfe273814ed7c0a”,
        “Memory”: 0,
        “MemorySwap”: 0,
        “NetworkDisabled”: false,
        “OnBuild”: [],
        “OpenStdin”: false,
        “PortSpecs”: null,
        “StdinOnce”: false,
        “Tty”: false,
        “User”: “”,
        “Volumes”: null,
        “WorkingDir”: “”
    },
    “Created”: “2014-06-09T21:38:41.281490617Z”,
    “DockerVersion”: “0.10.0”,
    “Id”: “0c752394b855e8f15d2dc1fba6f10f4386ff6c0ab6fc6a253285bcfbfdd214f5”,
    “Os”: “linux”,
    “Parent”: “34e94e67e63a0f079d9336b3c2a52e814d138e5b3f1f614a0cfe273814ed7c0a”,
    “Size”: 124078508
}

Para obtener informacion específica de un contenedor especificaremos al comando inspect la clave que queremos que nos devuelva, como por ejemplo el hostname o la dirección IP:
[root@centos1 ~]# docker run -d -t centos  /bin/bash
d7e7938ab7e98ff8e2413179d5222201de6a0c66716b99aafb35a0805fbf279e
[root@centos1 ~]# docker  ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
d7e7938ab7e9        centos:latest       /bin/bash           11 seconds ago      Up 11 seconds                           nostalgic_newton   

[root@centos1 ~]# docker inspect -f ‘{{ .Config.Hostname }}’ nostalgic_newton
d7e7938ab7e9
[root@centos1 ~]# docker inspect -f ‘{{ .NetworkSettings.IPAddress }}’ nostalgic_newton
172.17.0.22

Borrado de contenedores

Para norrar contenedores utilizaremos el comando rm. Le podremos pasar un único identificador de contenedor o varios en el mismo comando:
[root@centos1 ~]# docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                       PORTS               NAMES
abc254ab2e8e        ubuntu:latest       /bin/bash           22 minutes ago      Exited (0) 18 minutes ago                        naughty_yonath      
90ae553f4384        centos:latest       /bin/bash           23 minutes ago      Exited (-1) 22 minutes ago                       ecstatic_mcclintock

[root@centos1 ~]# docker rm ecstatic_mcclintock naughty_yonath
ecstatic_mcclintock
naughty_yonath

VPNSSL Juniper en Ubuntu 14.04 64bits

Recientemente necesitaba acceder a una VPNSSL de Juniper y obviamente estas soluciones están pensadas para sistemas operativos Windows. En Ubuntu funciona, pero hay que instalar varias dependencias.

Esto está testeado en Ubuntu 14.04 Trusty Tahr sobre 64bits, aunque también lo he hecho funcionar en versiones anteriores. Al lanzar el “Network Connect” nos dará un error quejándose de la falta de unas librerías de 32 bits.
Lo primero que haremos será instalar el JRE y el plugin para el navegador, en este caso de OpenJDK:

$ sudo apt-get install openjdk-7-jre icedtea-7-plugin

A continuación instalaremos la versión de 32 bits, con todas las dependencias que nos pida:

$ sudo apt-get install openjdk-7-jre:i386

Tendremos que instalar otra serie de paquetes para poder utilizar la versión de 32 bits:

$ sudo apt-get install libstdc++6:i386 lib32z1 lib32ncurses5 lib32bz2-1.0 libxext6:i386 libxrender1:i386 libxtst6:i386 libxi6:i386

Por último deberemos crear un link en el directorio sbin. Por algún motivo el “Network Connect” usa el listado “update-alternatives” para determinar si la versión de 32 bits está instalada y lo busca bajo el directorio /usr/sbin. Para solucionarlo basta con crear el link apuntando a /usr/bin:

$ sudo ln -s /usr/bin/update-alternatives /usr/sbin/

Una vez hechos estos cambios ya podremos utilizar nuestra vpn desde Ubuntu:

 

Referencias:

Ubuntu 14.04 y el maldito UEFI

Cada vez que me toca realizar un upgrade de versión de Ubuntu en mi portátil me tengo que pelear con el Boot Manager de UEFI. Mi portátil vino preinstalado con Windows 8 y lo mantuve porque nunca se sabe para que lo puedo necesitar.

La cuestión es que con cada cambio sobre el gestor de arranque hace que o el sistema se quede colgado en el modo rescate de grub o que directamente se salte el grub y entre en Windows.

En la documentación de Ubuntu salen una serie de recomendaciones que no me han servido en ningún caso. Por último recomiendan utilizar el programa Boot repair que en mi caso no me sirvió. Se trata de un arduo proceso de prueba y error hasta que das con la tecla.


En mi caso, al pulsar la tecla F11 arranca el Boot Manager donde me permite arrancar Ubuntu o Windows (en el menú aparece como OS Boot Manager :-O):

Descubrí la herramienta efibootmgr que permite solucionar el problema con unos pocos comandos. Voy con el ejemplo:

  • Listado de los sistemas instalados en mi portátil, donde se muestra el orden de arranque y como se ve arranca directamente en el Windows Boot Manager:

root@jupiter:# efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 3002,3000,3001,3003,3004,3005,2001,2002,2003
Boot0000* ubuntu    HD(2,c8800,82000,882c04c8-a541-4a44-aeaa-522da6211d8d)File(\EFI\ubuntu\shimx64.efi)
Boot0001* Ubuntu    HD(2,c8800,82000,882c04c8-a541-4a44-aeaa-522da6211d8d)File(\EFI\ubuntu\grubx64.efi)RC
Boot0002* Windows Boot Manager    HD(2,c8800,82000,882c04c8-a541-4a44-aeaa-522da6211d8d)File(\EFI\Microsoft\Boot\bootmgfw.efi)RC
Boot0003* Ubuntu    HD(2,c8800,82000,882c04c8-a541-4a44-aeaa-522da6211d8d)File(\EFI\ubuntu\grubx64.efi)RC
Boot0004* Ubuntu    HD(2,c8800,82000,882c04c8-a541-4a44-aeaa-522da6211d8d)File(\EFI\ubuntu\grubx64.efi)RC
Boot0005* Ubuntu    HD(2,c8800,82000,882c04c8-a541-4a44-aeaa-522da6211d8d)File(\EFI\ubuntu\grubx64.efi)RC
Boot2001* USB Drive (UEFI)    RC
Boot3000* Internal Hard Disk or Solid State Disk    RC
Boot3001* Internal Hard Disk or Solid State Disk    RC
Boot3002* Internal Hard Disk or Solid State Disk    RC
Boot3003* Internal Hard Disk or Solid State Disk    RC
Boot3004* Internal Hard Disk or Solid State Disk    RC
Boot3005* Internal Hard Disk or Solid State Disk    RC

  • Para limpiar el orde de arranque se ejecuta efibootmgr con la opción -O.
  • Establezco de nuevo el orden que yo quiero con el siguiente comando:

 root@jupiter:# efibootmgr -o 0000,0001,0002

  • También cambié el fichero de arranque de EFI de Windows, lo vi comentado en stackoverflow, pero creo que realmente no hacia falta:

 root@jupiter:# cd /boot/efi/EFI/Microsoft/Boot/
 root@jupiter:# mv bootmgfw.efi bootmgfwB.efi
 root@jupiter:#  cp ../../ubuntu/grubx64.efi bootmgfw.efi

Espero que este post me sirva para acordarme de lo que hice la última vez! 

Widgets en Ubuntu: Conky

Hoy me he encontrado con una aplicación que nos permite tener unos widgets perfectamente integrados con el escritorio de Unity en Ubuntu. Se trata de Conky. Lo he probado y me parece mucho mas ligero que otros que había utilizado antes, y ademas, parece que hay muchos temas disponibles en internet. Para instalarlo simplemente basta con instalarlo desde el Ubuntu Software Center o desde un terminal:
sudo apt-get install conky-all
En la documentación oficial de Ubuntu indica como se puede configurar tocando un fichero de configuración. Sin embargo existe un programa que nos puede servir de gran ayuda. Este es Conky Manager y para instalarlo, desde un terminal añadimos el PPA y lo instalamos:
sudo apt-add-repository ppa:teejee2008/ppa
sudo apt-get update
sudo apt-get install conky-manager
Una vez instalado se puede lanzar desde el panel de Unity. Es un programa muy sencillo que nos permite seleccionar los widgets y temas que queremos tener habilitados y dependiendo del seleccionado alguna opción adicional. Permite ademas configurar opciones como la transparencia o la posición del widget. Ademas existe la opción de habilitar el arranque automático con el sistema.
Resumiendo, me parece una muy buena opción para tener un escritorio mucho mas interesante. Estos son algunos de los widgets que yo me he puesto:
Existe un paquete de temas que se puede importar desde la aplicación. Se puede descargar aqui.

Openstack: Prueba de concepto – Parte 2

En relación a la entrada anterior, he querido mostrar una demostración en un vídeo en YouTube. El vídeo esta grabado sobre la prueba de concepto que monté. En el siguiente gráfico se puede ver la arquitectura:


Existen cuatro nodos de computación, y uno de ellos además, lleva el resto de elementos de Openstack. Todo está funcionando sobre Ubuntu 12.04 y montado con servidores con una única interfaz física.

Para las instancias he descargado las imágenes UEC que ya tiene preparadas Canonical.

El vídeo se podría dividir en dos partes. En la primera parte se muestran los principales comandos para trabajar con imagenes, “flavors”, arrancar instancias y terminarlas.

A continuación se hace un repaso por la Dashboard viendo como es sumamente sencillo la creación y despliegue de nuevas instancias. También he aprovechado para trabajar con volúmenes y demostrando que se pueden mover de una instancia a otra manteniendo la información que contienen.

Aquí se puede ver el vídeo:

OpenStack: Prueba de concepto – Parte 1

Estos días he tenido la opción de montar una pequeña prueba de concepto sobre Openstack. La idea es ver como funciona y analizar si en un futuro se podría implementar en un entorno productivo.

Me he basado en la documentación de Cloud – IES Gonzalo Nazareno concretamente en el documento bk-admin-openstack.pdf. También he seguido el libro de “recetas”: OpenStack Cloud Computing Cookbook.

Lo que he montado es básicamente una arquitectura de cuatro nodos. Uno de ellos es el Cloud Controller, donde estará todo el software necesario de Openstack: nova-compute, nova-network, nova-volume, glance y keystone. En los otros tres nodos únicamente se ha instalado el modulo de computación, nova-compute.

El hipervisor elegido para las pruebas ha sido KVM, con la idea de poder tener imagenes de otros sistemas operativos, además de imágenes de distribuciones GNU/Linux.

El esquema lógico sería el siguiente:

Por ciertas limitaciones únicamente he podido disponer de una interfaz de red cableada, por ello he apostado por el diseño mas sencillo con FlatDHCP. Aún así, las instancias son capaces de verse entre si a pesar de correr en diferentes hosts.

Ficheros de configuración:
Tal y como se explica en la documentación, el único fichero que hay que ir tocando es el /etc/nova/nova.conf. Yo copié el que indica en el documento  bk-admin-openstack.pdf y lo adapté a mi entorno. Básicamente hay que cambiar la IP que aparece por cada servicio por la del nodo que yo utilizaba como controlador. El apartado que me dió mas problemas fue el de red. Hay que tener mucho cuidado con los segmentos que se definen para las redes privadas, ya que es posible que se den problemas de routing. El apartado de configuración de red quedó de la siguiente manera:

# NETWORK
network_manager=nova.network.manager.FlatDHCPManager
force_dhcp_release=True
dhcpbridge_flagfile=/etc/nova/nova.conf
dhcpbridge=/usr/bin/nova-dhcpbridge
firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver
my_ip=X.X.3.91
public_interface=eth0
flat_network_bridge=br100
flat_interface=eth1
fixed_range=192.168.221.0/27
floating_range=192.168.221.32/27
routing_source_ip=X.X.3.91
start_guests_on_host_boot=true
resume_guests_state_on_host_boot=true
network_size=10
flat_network_dhcp_start=192.168.221.10
flat_injected=False
force_dhcp_release=True
root_helper=sudo nova-rootwrap

El fichero nova.conf será el mismo en todos los nodos, lo único que habrá que cambiar es la variable my_ip. También hay que tener en cuenta la configuración de la consola vnc para poder acceder desde la interfaz web:

# VNC
novnc_enabled=true
vnc_keymap=es
novncproxy_base_url=http://10.150.3.91:6080/vnc_auto.html
vncserver_proxyclient_address=10.150.3.92
vncserver_listen=10.150.3.92
vnc_console_proxy_url=http://10.150.3.91:6080

Aquí habrá que modificar las IPs en las variables vncserver_proxyclient_address y vncserver_listen. En las otras dos variables se dejará la IP del nodo donde se instala la Dashboard.

Como punto importante, ya en la configuración de Keystone, es necesario configurar las variables de entorno del usuario que vamos a autilizar para manejar los servicios de Nova. Para ello, en el fichero .bahsrc hay que introducir las siguientes líneas (en mi caso en el de root):

export SERVICE_ENDPOINT=”http://X.X.3.91:35357/v2.0″
export SERVICE_TOKEN=PASSWORD
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=PASSWORD
export OS_AUTH_URL=”http://X.X.3.91:5000/v2.0/”

Una vez con esto configurado ya podemos empezar a hacer pruebas con Openstack.

Problemas encontrados:
Hasta encontrar la configuración que funciona he tenido que ir jugando con los diferentes flags de los ficheros de configuración. Alguna vez, después de arrancar instancias, se han quedado en un estado inconsistente, siendo imposible el borrado de de las instancias de forma convencional. Para ello hay que conectarse a la base de datos y borrar los datos que hacen referencia a las instancias. Para hacerlo mas sencillo me monté un pequeño script en python que saca un listado de las instancias y permite borrar una o el borrado de todas. El script es el siguiente:

#!/usr/bin/python
#coding: iso-8859-15
import MySQLdb
import sys

db = MySQLdb.connect(host=’HOST’,user=’nova’, passwd=’PASSWORD’, db=’nova’)
cursor = db.cursor()
consulta = ‘select id, uuid from instances’
cursor.execute(consulta)
instances = cursor.fetchall()

for inst in instances:
    print “Instancia: %s UUID: %s” % (str(inst[0]), str(inst[1]))



if “–all” in sys.argv:
    print ‘Limpiando todas las instancias’
    cont = raw_input(‘¿Continuar? (s/n): ‘)
    if cont == ‘s’ or cont == ‘S’:
        for inst in instances:
            id=str(inst[0])
            print ‘Borrando instancia %s’ % id
            consulta = ‘delete from instance_info_caches where id=%s’ % id
            cursor.execute(consulta)
                        consulta = ‘delete from security_group_instance_association where id=%s’ % id
                        cursor.execute(consulta)
                        consulta = ‘delete from instances where id=%s’ % id
                        cursor.execute(consulta)
            db.commit()
        print ‘Todas las instancias borradas’
else:
    id = raw_input(‘Selecciona la instancia a borrar: ‘)
   
    for inst in instances:
        if str(inst[0]) == id:
            print “Se va a borrar la instancia %s con UUID %s” % (str(id), str(inst[1]))
            cont = raw_input(‘¿Continuar? (s/n): ‘)
            if cont == ‘s’ or cont == ‘S’:
                print ‘Borrando instancia %s’ % id
                consulta = ‘delete from instance_info_caches where id=%s’ % id
                cursor.execute(consulta)
                consulta = ‘delete from security_group_instance_association where id=%s’ % id
                cursor.execute(consulta)
                consulta = ‘delete from instances where id=%s’ % id
                cursor.execute(consulta)
                print ‘Ejecute “nova list | grep %s” para confirmar que se ha borrado la instancia’ % str(inst[1])
                db.commit()

En una ocasión no pude borrar la instancia con el script y era porque a la instancia le había asignado un volumen. Al borrar daba un error de clave referenciada en una tabla, con lo que tuve que borrar dicha entrada en la tabla que indicaba el error. Una vez limpiado se pudo borrar con el script.

Es importante, en caso de tener algún problema, revisar los logs. Allí encontraremos muchas pistas de que puede estar fallando y es muy probable que a alguien le haya pasado antes. Los logs de nova se encuentran en /var/logs/nova y los de KVM, no menos importantes, están en /var/logs/libvirt.

SNMP y Trabajo con MIBs

Muchas veces debemos monitorizar elementos que disponen del protocolo SNMP. Normalmente es fácil encontrar el fichero de MIB del dispositivo que queremos monitorizar, ya sea en a través del fabricante o a través de webs de terceros como oidview. Una vez tenemos el fichero de la MIB, ¿que hacemos?¿Como podemos obtener el OID de un nodo en particular?

Como para todo, existirán múltiples formas de trabajar con este fichero, pero para los usuarios de Linux tenemos disponible el paquete “snmp” con un grupo de herramientas que nos servirán para nuestro propósito. Lo primero que deberemos hacer es instalar dicho paquete, si no lo hemos hecho ya antes, con un simple “sudo apt-get install snmp“. Una vez instalado tendremos disponibles comandos como snmpwalk, snmpget o snmptranslate.
En el siguiente ejemplo veremos como obtener el valor de algunas variables que nos pueden interesar para monitorizar un SAI con un adaptador CS121. Con dicho módulo venia su correspondiente CD de utilidades donde podíamos encontrar la MIB del producto, en concreto la RFC1628cs121.MIB. 
Nos podríamos ver tentados por visualizar dicho fichero, pero la sintaxis que utiliza (ASN1) no es la mas amigable para su lectura. 
La herramienta snmptranslate nos sirve para interpretar dicho fichero MIB. A primera vista podríamos analizar el arbol de la mib para evaluar que variables nos pueden interesar en la monitorización, para ello ejecutaremos el siguiente comando, especificando que carge el fichero de MIB del módulo:

julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -Tp 
+–iso(1)
   |
   +–org(3)
      |
      +–dod(6)
         |
         +–internet(1)
            |
            +–mgmt(2)
               |
               +–mib-2(1)
                  |
                  +–upsMIB(33)
                     |
                     +–upsObjects(1)
                     |  |
                     |  +–upsIdent(1)
                     |  |  |
                     |  |  +–upsIdentManufacturer(1)
                     |  |  |
                     |  |  +–upsIdentModel(2)
                     |  |  |
                     |  |  +–upsIdentUPSSoftwareVersion(3)
                     |  |  |
                     |  |  +–upsIdentAgentSoftwareVersion(4)
                     |  |  |
                     |  |  +–upsIdentName(5)
                     |  |  |
                     |  |  +–upsIdentAttachedDevices(6)
                     |  |
                     |  +–upsBattery(2)
                     |  |  |
                     |  |  +– -R– EnumVal   upsBatteryStatus(1)
                     |  |  |        Values: unknown(1), batteryNormal(2), batteryLow(3), batteryDepleted(4)
Si en la herramienta de monitorización podemos cargar el fichero de MIB, con interrogar al dispositivo con el nombre del nodo que nos interesa será suficiente (mas adelante explicaré algún ejemplo). En cambio, muchas herramientas de monitorización no permiten la carga del fichero de MIB y le debemos especificar el OID que queremos interrogar. El árbol de OIDs de la MIB lo podemos ver de la siguiente forma:
julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -To
.1.3
.1.3.6
.1.3.6.1
.1.3.6.1.2
.1.3.6.1.2.1
.1.3.6.1.2.1.33
.1.3.6.1.2.1.33.1
.1.3.6.1.2.1.33.1.1
.1.3.6.1.2.1.33.1.1.1
.1.3.6.1.2.1.33.1.1.2
.1.3.6.1.2.1.33.1.1.3
.1.3.6.1.2.1.33.1.1.4
.1.3.6.1.2.1.33.1.1.5
.1.3.6.1.2.1.33.1.1.6
.1.3.6.1.2.1.33.1.2
.1.3.6.1.2.1.33.1.2.1
.1.3.6.1.2.1.33.1.2.2
.1.3.6.1.2.1.33.1.2.3
.1.3.6.1.2.1.33.1.2.4
.1.3.6.1.2.1.33.1.2.5
.1.3.6.1.2.1.33.1.2.6
.1.3.6.1.2.1.33.1.2.7
.1.3.6.1.2.1.33.1.3
.1.3.6.1.2.1.33.1.3.1
.1.3.6.1.2.1.33.1.3.2
.1.3.6.1.2.1.33.1.3.3
.1.3.6.1.2.1.33.1.3.3.1
.1.3.6.1.2.1.33.1.3.3.1.1
.1.3.6.1.2.1.33.1.3.3.1.2
.1.3.6.1.2.1.33.1.3.3.1.3
.1.3.6.1.2.1.33.1.3.3.1.4
.1.3.6.1.2.1.33.1.3.3.1.5
El problema ahora es que no sabemos cual es la correspondencia entre el OID y el nodo que evaluamos. Esto se soluciona pasando como parámetro en el snmptranslate la opción -Tz, que nos devolverá la forma numérica y etiqueta de todos los objetos:
julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -Tz
“org” “1.3”
“dod” “1.3.6”
“internet” “1.3.6.1”
“mgmt” “1.3.6.1.2”
“mib-2” “1.3.6.1.2.1”
“upsMIB” “1.3.6.1.2.1.33”
“upsObjects” “1.3.6.1.2.1.33.1”
“upsIdent” “1.3.6.1.2.1.33.1.1”
“upsIdentManufacturer” “1.3.6.1.2.1.33.1.1.1”
“upsIdentModel” “1.3.6.1.2.1.33.1.1.2”
“upsIdentUPSSoftwareVersion” “1.3.6.1.2.1.33.1.1.3”
“upsIdentAgentSoftwareVersion” “1.3.6.1.2.1.33.1.1.4”
“upsIdentName” “1.3.6.1.2.1.33.1.1.5”
“upsIdentAttachedDevices” “1.3.6.1.2.1.33.1.1.6”
“upsBattery” “1.3.6.1.2.1.33.1.2”
“upsBatteryStatus” “1.3.6.1.2.1.33.1.2.1”
“upsSecondsOnBattery” “1.3.6.1.2.1.33.1.2.2”
“upsEstimatedMinutesRemaining” “1.3.6.1.2.1.33.1.2.3”
“upsEstimatedChargeRemaining” “1.3.6.1.2.1.33.1.2.4”
“upsBatteryVoltage” “1.3.6.1.2.1.33.1.2.5”
“upsBatteryCurrent” “1.3.6.1.2.1.33.1.2.6”
“upsBatteryTemperature” “1.3.6.1.2.1.33.1.2.7”
“upsInput” “1.3.6.1.2.1.33.1.3”
“upsInputLineBads” “1.3.6.1.2.1.33.1.3.1”
“upsInputNumLines” “1.3.6.1.2.1.33.1.3.2”
“upsInputTable” “1.3.6.1.2.1.33.1.3.3”
“upsInputEntry” “1.3.6.1.2.1.33.1.3.3.1”
“upsInputLineIndex” “1.3.6.1.2.1.33.1.3.3.1.1”
“upsInputFrequency” “1.3.6.1.2.1.33.1.3.3.1.2”
“upsInputVoltage” “1.3.6.1.2.1.33.1.3.3.1.3”
“upsInputCurrent” “1.3.6.1.2.1.33.1.3.3.1.4”
“upsInputTruePower” “1.3.6.1.2.1.33.1.3.3.1.5”

Para obtener mas información de un nodo en concreto primero deberíamos obtener la forma mas completa:

julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -Onf -IR upsInputTruePower
.iso.org.dod.internet.mgmt.mib-2.upsMIB.upsObjects.upsInput.upsInputTable.upsInputEntry.upsInputTruePower

Ya ejecutando el snmptranslate con el OID completo obtendremos mas información del nodo, con una descripción de la variable, las unidades, la  sintaxis, etc.

julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -Td -OS .iso.org.dod.internet.mgmt.mib-2.upsMIB.upsObjects.upsInput.upsInputTable.upsInputEntry.upsInputTruePower
UPS-MIB::upsInputTruePower
upsInputTruePower OBJECT-TYPE
  — FROM UPS-MIB
  — TEXTUAL CONVENTION NonNegativeInteger
  SYNTAX INTEGER (0..2147483647) 
  DISPLAY-HINT “d”
  UNITS “Watts”
  MAX-ACCESS read-only
  STATUS current
  DESCRIPTION “The magnitude of the present input true power.”
::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) upsMIB(33) upsObjects(1) upsInput(3) upsInputTable(3) upsInputEntry(1) 5 }

Para obtener el OID numérico que utilizaremos en la herramienta de monitorización para este nodo ejecutaremos la siguiente consulta:

julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -On UPS-MIB::upsInputTruePower
.1.3.6.1.2.1.33.1.3.3.1.5
Con estos datos ya podemos montar nuestro sistema de monitorización, evaluando únicamente las variables que nos interesen. 
También tendremos dos utilizades que nos permitirán obtener los valores directamente desde el módulo. El snmpwalk hará un recorrido por las ramas del árbol desde el nodo que le especifiquemos mientras que el snmpget nos devolverá el valor específico de un nodo. En ambos métodos podemos especificar el fichero de MIB que queremos utilizar o especificar el OID en formato numérico. Veamos varios ejemplos:
julian@ubuntu:$ snmpget -Os -c comunidad -m “./RFC1628cs121.MIB” -v 1 DireccionIP upsOutputPower.1
upsOutputPower.1 = INTEGER: 700 Watts

julian@ubuntu:$ snmpget -Os -c comunidad -v 1 DireccionIP 1.3.6.1.2.1.33.1.4.4.1.4.1
mib-2.33.1.4.4.1.4.1 = INTEGER: 700

julian@ubuntu:$  snmpwalk -Os -c comunidad -m “./RFC1628cs121.MIB” -v 1 DireccionIP upsInputEntry
upsInputLineIndex.1 = INTEGER: 1
upsInputFrequency.1 = INTEGER: 500 0.1 Hertz
upsInputVoltage.1 = INTEGER: 230 RMS Volts
upsInputCurrent.1 = INTEGER: 0 0.1 RMS Amp
upsInputTruePower.1 = INTEGER: 0 Watts

julian@ubuntu:$ snmptranslate -m “./RFC1628cs121.MIB” -On UPS-MIB::upsInputEntry
.1.3.6.1.2.1.33.1.3.3.1
julian@ubuntu:$  snmpwalk -Os -c comunidad -v 1 DireccionIP .1.3.6.1.2.1.33.1.3.3.1
mib-2.33.1.3.3.1.1.1 = INTEGER: 1
mib-2.33.1.3.3.1.2.1 = INTEGER: 500
mib-2.33.1.3.3.1.3.1 = INTEGER: 230
mib-2.33.1.3.3.1.4.1 = INTEGER: 0
mib-2.33.1.3.3.1.5.1 = INTEGER: 0
Se puede encontrar mas información en los siguientes enlaces:

Uso de proxy en Linux

Uno de los problemas que nos encontramos al utilizar máquinas con Linux en entornos corporativos es la restricción de acceso a Internet. Muchas compañías disponen de un proxy de navegación que limita y controla donde pueden acceder los usuarios. En Linux disponemos diferentes formas de configurarlo, muchas veces no es trivial y dependiendo de si el proxy requiere autenticación o no, puede llevar mas de un quebradero de cabeza.

A continuación comentaré los diferentes casos que me he ido encontrando:
  • Uso del proxy desde la línea de comandos:
    • En la línea de comandos hay que configurar las variables de entorno que se utiliza para definir el proxy:
export http_proxy=”http://X.X.X.X:8080″
export https_proxy=”http://X.X.X.X:8080″
export ftp_proxy=”http://X.X.X.X:8080″
    • Para hacer el cambio permanente habría que editar el fichero del perfil para cargarlo al iniciar la shell (.bashrc para bash)
    • Si el proxy requiere autenticación, se puede especificar el usuario o el usuario y password de la siguiente manera:
    • Si no se configura el usuario y password se puede pasar como parámetro del wget, por ejemplo:
julian@ubuntu:~$ wget –proxy-user=usuario –proxy-password=password http://wwww.blabla.com/index.html
  • Uso del proxy para el gestor de paquetes de Ubuntu (apt, synaptic, software center):
  • Uso del proxy para el gestor de paquetes de Red Hat (y derivados):
    • Añadir en el fichero de configuración de yum los parámetros del proxy (/etc/yum.conf):

      proxy=http://X.X.X.X:8080 proxy_username=usuario proxy_password=password
  • Uso del proxy en el escritorio de ubuntu:
    • Desde la llegada de Unity ha cambiado un poco la configuración del proxy. Se configura en “System Settings” y ahí en Network. En el panel de la izquierda aparece la opción de configurar el proxy. Ahí para cada protocolo se debe especificar el servidor y el puerto a utilizar. El problema viene a la hora de utilizar autenticación, para eso deberemos configurarlo mediante el dconf-editor. Si no lo tenemos instalado se deberá instalar el paquete dconf-tools (sudo apt-get install dconf-tools).
Una vez abierto el dconf-editor iremos a la rama system->proxy. En esa rama general podremos configurar las excepciones para las que no utilizar el proxy. En la rama system->proxy->http podremos configurar el usuario y password de nuestro proxy:

Nota: En caso de que el password contenga algún carácter especial como una @ se deberá sustituir por el caracter ASCII en los ficheros de configuración (a excepción del de Yum, que se puede escribir sin modificaciones). Por ejemplo:
p@ssword pasaría a ser p%40ssword