VERSION ACTUAL :

Inicio de sesión

Raulito el Friki

Raulito El Friki

COMENTARIOS

EN LINEA

Hay actualmente 0 usuarios conectados.

NUEVOS

  • ppardol
  • knight99
  • José Martínez
  • iampa
  • elministro.

Agregador de canales de noticias

Cómo lanzar un VPS: 6+ Tips Fundamentales

Xenode - Jue, 05/08/2014 - 19:48
NOTA: Este es un artículo que originalmente había escrito yo para publicarlo en el blog colaborativo de UsemosLinux, y que debido a unas modificaciones que le hicieron (y de alguna manera me perjudican), les pedí retiraran de su sitio. A continuación verán el artículo original pensado para publicarse allá, este post es simplemente un refuerzo en caso de que los administradores de aquél sitio no tomen en cuenta mis peticiones de eliminar el artículo de su web.

Pueden conocer más acerca del problema y lo que les requerí personalmente (además del porqué) en estos enlaces:


 

Aquí en DesdeLinux se ha hablado ya bastante sobre el tema de los VPS y el amigo KZKG^Gaara ha puesto uno que otro tutorial bastante interesante sobre servidores: Desde jaulas de SSH hasta port knocking. Todos estos tutoriales están geniales y qué mejor que tener un entorno de pruebas REAL para probarlos ¿no? es por esto que he decidido escribir una rápida guía sobre VPS Bootstraping.
¿Qué es un VPS?Primero y antes que nada debemos definir esta "variable". Bueno, un VPS es un Servidor Privado Virtual, básicamente es Infraestructura como Servicio (IaaS) que le rentas a una compañía o en palabras más simples, un servidor (computadora accesible desde Internet para fines variados) que alguien te presta y/o facilita mientras le pagues una cuota cada cierto tiempo, esta infraestructura es cuidada y mantenida en las instalaciones (datacenters) de la empresa y tu la puedes administrar de manera remota vía SSH y/o VNC por ejemplo.
¿Porqué querrías tener un VPS?

Si necesitas tener un servidor para lo que sea (hospedar un sitio web, usar una computadora remota a través de VNC, o bien hacer pruebas isoladas de software y configuraciones entre otras cosas) un VPS (Linux) es y siempre será tu mejor opción, sobretodo si eres Linuxero y has manejado antes alguna distro a través de la línea de comandos. A diferencia de un "hosting" que está muy capado en todos los sentidos (tanto de acceso como de capacidades) un VPS es potente, te da la libertad que quieras y no se mete en tus asuntos, además de que tiene más durabilidad y escalabilidad a largo plazo al ser "una computadora" básicamente que puede agrandar en capacidades con un sólo click. En un artículo pasado KZKG^Gaara menciona que una de las variables a considerar para saber si ocupas un Hosting, un VPS o un Servidor dedicado son los hits únicos que recibe tu sitio web, y es una métrica bastante adecuada... Sin embargo, mi consejo personal es SIEMPRE irse a por un VPS a menos que puedas montar (y realmente mantener) un servidor dedicado al 100%, no se aventuren con los hostings que "nomás no escalan" y de todos modos les van a costar dinero. Vale mejor jugar a la segura. Ahora bien, si comparamos los VPS con los servidores dedicados, aún en esta parte yo apostaría por un VPS (o un mix de VPS + Dedicados, como lo que tengo acá montado para Xenode Systems) ya que un VPS te quita de encima todo tipo de costos tanto económicos como podrían ser los gastos en electricidad y/o internet y también los de manpower que serían los referentes a tener que estar manteniendo "el fierro" (hardware) y todo lo que éste conlleve diariamente (optimizaciones, cambios de piezas, implementaciones de seguridad y planes de contingencia etc) para tener tus sitios arriba, cosa que puede ser un tedio si no estás acostumbrad@ a ello. Todo eso se resume a que por algo así como $20 USD mensuales (hablando de un paquete "medianito") puedas rentar una máquina con las siguientes características:
  • 2GB RAM
  • 40GB SSD
  • Procesador Dual Core
  • 3TB de transferencia en banda ancha
  • ~1Gbps de conexión a internet simétrica
Entre otras cosas sin tener que preocuparte de la factura eléctrica, los achaques de la manutención (como el tener que cambiar una pieza si se quema en un pico de voltaje) o el costo de la conexión a Internet como tal. Cabe destacar que existen planes de VPS desde $5 USD al mes también (y como veremos más adelante, barato no significa "pequeño" per sé).
Encontrando al mejor proveedor

Hay varios provedores de VPS en el mundo, de los más conocidos están Amazon Web Services (AWS), DigitalOcean y Linode. Pero fuera de los "pesos pesados" la realidad es que hay decenas de ellos, todos con diferentes características y prestaciones. (DesdeLinux por ejemplo usa uno que se llama GNUTransfer). Yo personalmente he usado AWS y DigitalOcean, de los demás sólo conozco sus prestaciones y precios (aunque no los he usado directamente). Sin embargo les puedo decir que el mejor de todos (al menos para mi) es DigitalOcean, ya que sus VPS funcionan únicamente con SSD's, son súper baratos, la interfaz de usuario (dashboard) es súper cómoda de manejar (además de sencilla pero potente) y presentan varias cosas interesantes (como máquinas súper potentes a excelentes precios para empezar) que explico a fondo en este artículo dentro de mi blog personal.
1) Lanzando tu primer VPS

Para esta parte del tutorial, vamos a necesitar crearnos una nueva cuenta en DigitalOcean. Como todos los servicios de VPS éste tiene un costo, pero gracias a unos cupones que les traigo (mismos que estarán válidos durante todo Mayo 2014) pueden obtener Gratis $10 - $65 USD y en caso de que expirasen para cuando lleguen a este artículo, les dejaré una página donde diariamente ponen otros cupones disponibles de manera que todos los que sigan este tutorial tengan saldo gratis en sus cuentas de DigitalOcean sin importar la fecha en la que estén leyendo esto, veamos entonces: NOTA: Haz click en Crear Cuenta y rellena tus datos para crear tu nueva cuenta, cuando se te pida el "cupón de promoción" utiliza los que verás a continuación según la oferta que quieras. Primera Opción ($65 USD Gratis):
Crear Cuenta - CHEFCONF (Expira 31/05/2014)Segunda Opción ($10 USD Gratis):
Crear CuentaSSDMAY10 (Expira 31/05/2014)Tercera Opción (Cupones Diarios):
Crear CuentaCupones Diarios (Por si no lees este artículo a tiempo)Suponiendo que utilicen el código de $10 USD, dicho saldo será abonado en su cuenta para poder lanzar su primer VPS en DigitalOcean, pueden elegir entre un VPS de $5 USD al mes (2 meses gratis con el cupón) con las siguientes características:
  • 512MB  RAM/ 1 CPU
  • 20GB SSD DISK
  • 1TB TRANSFER
O bien, 1 mes gratis de un VPS ($10 USD/mo) con las siguientes características:
  • 1GB RAM / 1 CPU
  • 30GB SSD DISK
  • 2TB TRANSFER
...Y pues si les toca activar su cuenta con el de $65 USD obviamente pueden montar lo que quieran... La ventaja de DigitalOcean es que no sólo acepta pagos con tarjeta de crédito y/o Paypal para mantener tus "droplets" activos, sino que también provee estos cupones/sistema de referidos que puedes usar para alimentar con un tanto de saldo a tu cuenta de manera gratuita (cuestión bastante útil considerando la situación económica actual). Por otro lado, no es que los VPS cuesten en sí eso que se muestra ahí en la lista al mes (cuestan menos generalmente), los precios de lista se basan en el límite normal establecido, si por alguna razón tu VPS no llegase a consumir lo que cuesta su límite en USD al mes, dicho saldo a favor se queda en tu cuenta para futuros cobros (cosa que tiende a pasar). Una vez activada nuestra cuenta (y con el saldo de regalo) lo que tenemos que hacer es generar nuestro primer "droplet" y/o VPS desde la interfaz de administración de DigitalOcean, cosa que es bastante sencilla: Rellenamos el nombre del Hostname, elegimos cuál plan de VPS queremos, en qué región lo queremos, qué distro/imagen va a usar y listo. NOTA: En mi caso, yo elegí Ubuntu 14.04 de 32 bits limpio como distro y será la que use en mis ejemplos.



Una vez creado el droplet, los de DigitalOcean nos enviarán el login de root por e-mail al correo que hayamos elegido para abrir nuestra cuenta, tomamos nota de la contraseña y proseguimos.
2) Cambiar contraseña de RootTener la contraseña de root de un VPS en el correo electrónico no es buena idea, por lo tanto una vez creado nuestro droplet nos iremos a la pestaña de Access>Console Access, misma que nos dará acceso a una Terminal VNC del droplet para trabajar directamente con el sistema sin necesidad (aún) de conectarnos remotamente vía SSH:


Estando en la consola como root, simplemente corremos el siguiente comando: sudo passwd Escribimos nuestro nuevo password para root y listo.
3) Crear un nuevo usuario estándarAhora necesitamos crear un nuevo usuario estándar (sin privilegios administrativos) que sea el que pueda accesar por SSH al VPS, esto por cuestiones de seguridad. Crear un nuevo usuario es tan sencillo como correr (como root en la terminal VNC del VPS): adduser usuario Reemplazando la palabra usuario por el nombre de usuario que queramos manejar. Este comando nos pedirá entrar una nueva contraseña para dicho usuario y sus datos (tales como nombre, teléfono etc). Rellenamos todo y ya estamos listos para proseguir.
4) Tweaks de SSHAhora tenemos que configurar el acceso SSH de nuestro VPS, yo lo que siempre hago es lo siguiente:
  • Cambiar el puerto 22 por otro
  • Evitar el SSH Login a Root
  • Configurar el acceso sólo con llaves RSA y no passwords
Esto se hace cambiando algunos settings en el archivo /etc/ssh/sshd_config de nuestro VPS con el comando (como root): sudo nano /etc/ssh/sshd_config Y lo que queremos hacer en él es:
  • Cambiar la variable Port de 22 a algo de nuestra elección (y alto) como 8866
  • Cambiar la variable PermitRootLogin a no
  • Añadir la variable AllowUsers user (Reemplazando user por el nombre del usuario que creamos hace rato)
  • Descomentar la variable PasswordAuthentication yes
Guardamos nuestros cambios en dicho archivo con Ctrl+O, ENTER y luego salimos con Ctrl+X. En un momento les daré un ejemplo de cómo queda dicho archivo (ya que nos falta un cambio).
5) FirewallAhora (siguiendo como root en consola) correremos los siguientes comandos:

1. sudo ufw reset
2. sudo ufw enable
3. sudo ufw default deny incoming
4. sudo ufw default allow outgoing
5. sudo ufw allow 8866/tcp
Esto lo que hace es:
  1. Resetea el firewall (borrando reglas existentes del proveedor)
  2. Lo vuelve a encender
  3. Bloquea las conexiones entrantes
  4. Acepta las conexiones salientes
  5. Nos habilita el acceso entrante a través del puerto 8866 TCP (el que configuramos para nuestro SSH en el paso previo)
Recuerda desbloquear todos los puertos que vayas a ocupar en tu VPS, ya sean el 80/tcp (HTTP) el 21/tcp (FTP) u otros (pueden ser UDP obviamente también); Bajo este setup todos quedan bloqueados a entrada excepto los que tu le digas al firewall explícitamente que desbloquee para tí. Puedes checar los puertos abiertos con sudo ufw status cuando quieras.
 6) Configurar acceso RSAPara configurar el acceso RSA, (usando llaves SSH en lugar de contraseñas para entrar al VPS remotamente) ocupamos primero dentro del VPS correr los siguientes comandos:

1. sudo mkdir /home/usuario/.ssh
2. sudo touch /home/usuario/.ssh/authorized_keys
3. sudo touch /home/usuario/.ssh/known_hosts
4. sudo chown -R usuario:usuario /home/usuario/.ssh
(Reemplazando la palabra usuario en los comandos por el nombre de usuario que elegimos hace rato). Ahora necesitamos reiniciar nuestro VPS con sudo reboot para que las nuevas reglas del Firewall y de SSHD tomen efecto y mientras, en nuestra máquina cliente (desde donde queramos conectarnos al VPS vía SSH) crearemos un par de claves para usar como ID con los siguientes comandos (como tu usuario normal):

1. mkdir ~/.ssh
2. cd ~/.ssh
3. ssh-keygen -t rsa
El tercer comando nos hará una serie de preguntas como el nombre de la clave y si queremos que tenga alguna passphrase, mi recomendación es usar el nombre del host+key (por ejemplo si tu máquina se llama "Venus" tu clave idealmente se podría llamar venusKey) y por favor déjenlas sin passphrase (de otra manera pierde sentido la autenticación automática y segura sin contraseña que este método nos provee). NOTA: Recomiendo generar un par de claves por cada cliente que vayas a utilizar para gestionar tu VPS vía SSH según el caso. Acto seguido debemos copiar la clave pública generada al VPS con el siguiente comando (estando dentro de nuestro directorio ".ssh" todavía en nuestra terminal de la máquina cliente): cat hostKey.pub | ssh user@my.vps.ip -p 8866 "cat >> ~/.ssh/authorized_keys" Cambiando:
  • hostKey.pub por el nombre de tu clave
  • user por el nombre de usuario estándar que generamos en el VPS
  • my.vps.ip por la dirección IP de tu VPS (que encontrarás en la pestaña de "Droplets" en DigitalOcean)
  • El puerto SSH por el que le hayas configurado a tu VPS previamente
Este último comando nos va a mostrar una advertencia parecida a la siguiente (misma a la que responderemos con yes si es necesario) y luego nos dejará loguearnos al VPS remotamente con nuestro acceso y/o login:

The authenticity of host '12.34.56.78 (12.34.56.78)' can't be established.RSA key fingerprint is b1:2d:33:67:ce:35:4d:5f:f3:a8:cd:c0:c4:48:86:12.Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '12.34.56.78' (RSA) to the list of known hosts.
Verificamos que la clave haya sido agregada con éxito (en el VPS):
1. cd ~/.ssh
2. cat authorized_keys
(El último comando debe mostrarnos la clave); Y procedemos a editar de nuevo nuestro archivo de configuración de ssh con:

1. su -
2. nano /etc/ssh/sshd_config
Para cambiar la variable PasswordAuthentication a no; Una vez hecho esto, reiniciamos el VPS una vez más con sudo reboot y en la máquina cliente que utilizaremos para acceder al VPS (donde generamos nuestro KeyPair) corremos los siguientes comandos (como usuario normal desde nuestra carpeta personal):

1. touch ~/.ssh/config
2. nano ~/.ssh/config
Y en el archivo vacío que nos saldrá para editar, pondremos lo siguiente:

host my.vps.ip
user usuario
Port 8866
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
CheckHostIP no
IdentityFile ~/.ssh/hostKey
ServerAliveInterval 120
Cambiando los datos en negrilla de manera acorde a nuestro caso. Nótese que la hostKey que estoy usando es la privada del cliente y no la pública. Guardamos los cambios y salimos... Ahora hacemos (obviamente desde la máquina cliente) un: ssh usuario@my.vps.ip y ya nos debería dejar acceder sin contraseña usando nuestra clave privada como ID. Es importante recordar que a partir de ahora es VITAL guardar un backup de todos los directorios ".ssh" de tus clientes de gestión en algún lado, para evitar perder las claves y el archivo de configuración de c/u en algún "desastre informático". Finalicemos con una copia de mi archivo sshd_config ya "terminado" para que corroboren que hicieron bien sus cambios: sshd_config - Jmlevick's Gists
Extras
A) Google DNS: Seguridad y VelocidadCambiar los DNS de tu VPS por los de Google es algo importante que no solo lo protege de ciertos tipos de ataques sino que también puede ayudar en otros apartados como velocidad de respuesta y consumo de banda ancha. Afortunadamente aquí no hay nada que hacer ya que los VPS/Droplets de DigitalOcean ya vienen configurados para funcionar con dichos DNS en ipv4 e ipv6.
B) Cloudflare: Protección, Ahorros y DisponibilidadCloudflare es una plataforma de "optimización y protección" de servidores que más bien funciona a nivel dominio, pero es bastante útil porque entre las cosas que ofrece están la protección contra ataques DDoS en tiempo real, la reducción en el consumo de recursos por parte del VPS y también un sistema de mirroring que permite que tu contenido siga disponible aún si tu servidor llega a caerse entre otras cosas. Es un buen servicio y lo mejor es que incluso tienen un plan gratuito (es el que yo uso en mis dominios/VPS) que ofrece todo esto que les comento y otras cosas más. Conoce más sobre Cloudflare y cómo te beneficia usarlo si tienes un VPS por acá.
C) Ksplice: Actualizaciones en vivo (no downtime)Ksplice es un gestor de actualizaciones de seguridad que aplica dichas actualizaciones (como las referentes al kernel y derivadas) en vivo sin necesidad de reiniciar. Es interesante porque para empezar evita el downtime en nuestros VPS y por otro lado se enfoca únicamente a actualizaciones críticas, evitando que de pronto actualicemos todo el sistema comiéndonos valioso espacio en disco. Más info sobre Ksplice en este tutorial.
D) Zswap: Mayor eficiencia en gestión de RAM/SWAPZswap es un sistema de compresión de paginado que está disponible desde el Kernel 3.11 en todas las distros GNU/Linux allá afuera, pero no viene activado por defecto. Sin importar cuánta RAM tenga tu VPS es una buena idea habilitarlo. Aprende más sobre Zswap y cómo activarlo checando este artículo para ello.
E) ZSH: Un shell más completoZ-Shell es un shell más completo que bash con un montón de goodies y/o comodidades añadidas, un buen aliado si manejas mucho el VPS por consola. Checa más de ZSH por acá.
F) Ranger: Gestión de archivos cómoda desde terminalRanger es un gestor de archivos por consola, otra herramienta interesante que además viene a probar otro punto que me encanta de DigitalOcean, sus tutoriales online a modo de soporte (¡Tienen uno para todo!). Checa el post que hicieron sobre Ranger en este enlace. Y pues bueno, yo con esto me despido por ahora. Creo que no se me pasó nada de lo más importante y vital al momento de montar un VPS. A partir de aquí ya cada uno puede configurar su VPS como mejor le parezca para la función que desee, estando confiados en que se mantendrá funcional, eficiente y seguro. P.D. ¿Llegaste hasta acá y sólo leíste el artículo? ¡Qué esperas!
Lanza tu primer VPS ahorita mismo

La mosca cojonera

Jose Salgado - Jue, 05/08/2014 - 17:10
la mosca cojonera

Hay un libro que está a la altura del Necronomicon, que es The unwritten book of management. En esta obra, que nadie ha leído pero la cual todos citamos, está condensado el saber que cualquier directivo necesitará a lo largo de toda su carrera profesional. No importa la época, no importa el contexto, este libro siempre tiene la respuesta adecuada a cada necesidad. De este libro he extraído la idea que inspira el post de hoy: Si en tu consejo de administración nadie te lleva la contraria, o sobran ellos o sobras tú.

Estamos de acuerdo que hemos de compartir metas y objetivos, pero es tan o más importante, que antes de definir estas metas y objetivos en el corto, medio y largo plazo, ha de existir una crítica dura pero constructiva, y sobretodo fundamentada.

Si en una empresa, la dirección se basa en un modelo militar y de disciplina, ocurre que puede que se consigan los objetivos, pero lo más probable es que el equipo no esté a la altura. Esto no ocurrirá por falta de capacidad, sino por falta de motivación y por miedo a expresar opiniones divergentes. Si no escuchar a tu equipo no fuera suficiente, otra amenaza importante es que podemos estar perdiendo oportunidades de negocio, o en su versión más cruel, llevando el tren de la empresa a un descalabro seguro.

En el otro lado de la balanza están los que confiando en que tienen al mejor equipo y les dejan hacer directamente sin tener directivas, ni ninguna instrucción de como han de conseguir el objetivo. El resultado tiende a ser un pequeño caos, donde cada cual va a su aire, no hay cooperación y donde todos pasan de implicarse porque a nadie le importa lo que hacen o dejan de hacer. El resultado es un producto de muy baja calidad, poca implicación y un seguro descenso de ventas .

Según cuentan los estudios, dicen que el mejor sistema para tener moscas cojoneras y poder utilizarlas es tener un sistema participativo, donde todas las ideas se debaten, todas las propuestas se discuten, y al final, se llega a una solución más menos de consenso y donde todas las propuestas puedan ser recogidas e incluidas en la planificación.

También es cierto, que la tercera opción es la ideal, pero no siempre es la más practica. Se tarda más en establecer el clima necesario para poder conseguir un flujo abierto y sincero de información, eliminar egos y aprender a construir en positivo. Lo más habitual en estos mundos es que no tengamos tiempo para nada y acabemos siempre aplicando una versión más o menos relajada del sistema autoritario. Pero seamos conscientes de que nos puede sacara de un apuro momentáneo, no es la solución a largo plazo, con lo que es importante empezar a establecer políticas claras de inclusión y de disensión en el proceso de toma de decisiones.

Película: The Fly

Esto es un resumen del artículo La mosca cojonera escrito para Exelisis. Visita la web para más información y compártelo si crees que es interesante.

Openmailbox

eliasbrasa - Jue, 05/08/2014 - 10:51

Si estás preocupado que las grandes compañías lean el contenido de tus correos electrónicos, hay un servidor de correo electrónico que te puede interesar, se trata de Openmailbox. ¿Por qué? porque, por ejemplo, solo usan software libre, permite archivos adjuntos en los correos electrónicos de hasta 500Mb, etc. (recomiendo que le echéis un ojo al enlace que os especifican todos los detalles)

Lo bueno de Openmailbox es que no solo ofrecen el servicio de correo electrónico, sino que también ofrece espacio en la nube y la posibilidad de compartir esos archivos a través de enlaces, eso sí solo 1024Mb de capacidad, muy lejos de la capacidad de Mega…

Podéis visitar su sitio web aquí, si os aparece en francés, solo tenéis que bajar al final de la página para cambiarla a castellano o al idioma que deseéis.


El diablo está en los detalles

Jose Salgado - Jue, 05/08/2014 - 02:57
El diablo está en los detalles

Es cierto que toda empresa ha de tener visión, misión y valores, una guía de a dónde quiere llegar, que quiere significar para la sociedad y para sus accionistas. Esto está claro, hay que soñar a lo grande, tienen que apuntar alto para motivar. Pero una vez hecho este proceso, toca un trabajo todavía más duro que el conceptualizar estas palabras.

Una vez tenemos claros estas ideas, toca definir el camino a recorrer. Si queremos llegar a la luna, toca definir cada fase del trabajo, definir los objetivos, los tiempos, los recursos, en resumen, toca dejar el power point, o los más listos el lápiz y el papel, y usar un programa de gestión de proyectos para definir las fases y recursos necesarios.

Más de un proyecto y más de dos han fracasado miserablemente por no precisar de forma detallada estas líneas de trabajo. Crear un submarino fantástico, pero que no se ha pensado en en un sistema de reciclaje para los residuos sólidos, edificios que no soportan peso porque en los cálculos se han olvidado añadir el propio peso de la estructura, o aquel generador para un datacenter de última generación que era tan bueno que solo le faltaba arropar a los técnicos cuando estaban haciendo intervenciones en los racks, sólo había un pequeño problema: se habían olvidado de que no cabía por la puerta de entrada para instalarlo, y como estas os puedo contar unas cuantas más.

Esta es una de las razones por las que ese CEO que lejos de saber dar discursos y usar frases retóricas para que la gente le aplauda con las orejas, se centra más en el día a día, en los costes, objetivos, milestones, la interpelación entre cada fase y las necesidades que hay que prever para que nadie se quede con los brazos cruzados.

He tenido la suerte de conocer a algunos de ellos y el privilegio de poder aprender a gestionar proyectos a su lado. Y si los visionarios ven el bosque, estos perfiles ven los árboles con tal detalle que serían capaces de decirte cuantas acacias, robles y cipreses hay en ese bosque, como han de hacer el camino, por dónde ha de pasar para aprovechar la geografía del terreno, y sobretodo, como llegar al objetivo en el mínimo tiempo posible, con la mayor calidad y el menor coste.

Por eso es importante, ya seas un emprendedor o un gestor de proyecto, tener visión y saber comunicar esa pasión a tu equipo, pero tan o más es saber ver las dificultades que pueden aparecer, dotar de medios, ver las relaciones que pueden surgir entre varias fases, y prever esos pequeños detalles que a veces se nos pasan a todos.

Película: Apollo 13

Esto es un resumen del artículo El diablo está en los detalles escrito para Exelisis. Visita la web para más información y compártelo si crees que es interesante.

Haz tu Linux más rápido con Zswap

Xenode - Jue, 05/08/2014 - 00:05

Zswap es un módulo que se integró a partir del Kernel 3.11 a Linux y básicamente lo que hace es funcionar como compresor de paginado para mejorar el uso de RAM y Swap en un sistema. No lo confundan con zRAM, pues son cosas distintas que sin embargo se utilizan para fines similares. La ventaja de Zswap con respecto a Zram radica en el hecho de que ya viene integrado en cualquier kernel Linux de cualquier distro a partir de la versión 3.11 (sólamente tenemos que habilitarlo) mientras que zRAM se tiene que instalar aparte y en algunas distros como fedora esto es un tedio. Por otro lado, Zswap está pensado para beneficiar a todo tipo de equipos, desde el más antiguo con el mínimo de RAM disponible hasta el más nuevo y moderno al ser sólo un compresor que en términos simples hace que "más aplicaciones quepan en la memoria RAM" (o ante los ojos del usuario así se nota aunque de fondo sea más compleja su función) mientras que zRAM ocupa equipos con al menos 1GB de RAM para "hacer impacto" pues realmente sólo es una swap que corre dentro de la RAM.

Además de lo ya mencionado, Zswap también manda a RAM ciertos procesos de I/O de la swap. Con estas dos funcionalidades básicas Zswap hace que en cualquier caso la necesidad de acceso a la swap de un sistema se vea retardada lo más posible. Es complicado de explicar pero el punto es que cuando un sistema Linux empieza a usar su swap es porque ya no hay RAM capaz de sobrellevar los procesos que están corriendo, por lo tanto la SWAP (que está en disco duro) toma los sobrantes y los ejecuta ahí (provocando lo que muchos conocemos como computadoras "lentas o poco responsivas pero no congeladas" cuando esto sucede).

Al tener Zswap activado no sólo hay una mejor gestión de RAM en el sistema sino que también los procesos enviados a swap son muchísimo más rápidos al intercambiar I/O con la RAM, traduciéndose esto en una computadora que:


  • A) Va a ser difícil que se vuelva poco responsiva
  • B) En caso de que pase va a regresar pronto a operación rescatable en lugar de congelarse


Cómo activar Zswap en cualquier distro

NOTA: Para empezar desinstala zRAM si lo estás usando actualmente

Instalar Zswap es sencillo en cualquier distro que tenga el kernel 3.11 o superior, sólo tenemos que editar el archivo /etc/default/grub (como root con nuestro editor de texto favorito) y en la línea GRUB_CMDLINE_LINUX añadir zswap.enabled=1 separado a un espacio del último parámetro dentro de esa línea:

NOTA: También añádanlo a GRUB_CMDLINE_LINUX_DEFAULT si tienen esa variable.


Corremos el comando de actualización del GRUB 2 según nuestra distro:

sudo update-grub (Ubuntu)
grub2-mkconfig -o /boot/grub2/grub.cfg (Fedora)

y listo, al reiniciar el comando:

dmesg | grep zswap

(En sistemas Fedora por ejemplo) nos debería mostrar algo de output como:


Ksplice: Actualizaciones de seguridad en vivo para Linux

Xenode - Mié, 05/07/2014 - 23:31

Ksplice Uptrack es un gestor de paquetes especializado en actualizaciones de seguridad (como las del kernel y similares) para GNU/Linux y su ventaja sobre de las herramientas comunes para el trabajo es que permite la aplicación de dichas actualizaciones en vivo (sin necesidad de reiniciar) cosa que es increíblemente buena para los que manejamos servidores. El uso de Ksplice es sencillo: Simplemente tenemos que descargar e instalar el paquete desde su web oficial (Es gratuito para Ubuntu y Fedora) y entonces tendremos a la mano tanto una GUI como una CLI para manejar el nuevo gestor de paquetes. Cabe destacar que Ksplice no se contrapone a tu gestor de paquetes actual, es más bien un refuerzo que cumple con esta tarea específica de instalar actualizaciones de seguridad en vivo en lugar de un reemplazo.


NOTA: Aunque supuestamente Ksplice funciona en Fedora y Ubuntu, la realidad es que debido a las políticas de actualización del kernel en sistemas fedora éste gestor de paquetes no es efectivo en dicho sistema, haciendo que se tenga que reiniciar después de aplicar ciertos tipos de parches y a veces incluso provocando que ya no arranque. Mi recomendación es no usarlo a menos que estén en Ubuntu y/o derivad@s.

Y si estás en un servidor (Por ejemplo con Ubuntu 14.04), puedes instalarlo con:

1. wget https://www.ksplice.com/uptrack/dist/trusty/ksplice-uptrack.deb -O /home/user/ksplice-uptrack.deb
2. sudo dpkg -i /home/user/ksplice-uptrack.deb
3. sudo apt-get install -f
(Obviamente reemplazando user por tu nombre de usuario); Luego lo puedes controlar con los comandos de la CLI que están por acá.

Convertir una imagen de máquina virtual a LVM

Mis notas de Linux - Mié, 05/07/2014 - 14:42

Primero creamos el logical volume para la máquina virtual, en este caso de 9GB:

# lvcreate -L9G -n vm-rhel59 z600

Pasamos la imagen al logical volume:

# qemu-img convert RHEL59.img -O raw /dev/mapper/z600-vm--rhel59

Modificamos el archivo .xml de la máquina virtual, cambiamos el siguiente contenido:

<disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/data/kvm/images/RHEL59.img'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk>

Por éste:

<disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source dev='/dev/mapper/z600-vm--rhel59'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk>

Ahora solo queda reinicir el servicio libvirtd para que recargue la configuración de la máquina virtual


Convertir una imagen de máquina virtual a LVM

Mis notas de Linux - Mié, 05/07/2014 - 14:42

Primero creamos el logical volume para la máquina virtual, en este caso de 9GB:

# lvcreate -L9G -n vm-rhel59 z600

Pasamos la imagen al logical volume:

# qemu-img convert RHEL59.img -O raw /dev/mapper/z600-vm--rhel59

Modificamos el archivo .xml de la máquina virtual, cambiamos el siguiente contenido:

<disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/data/kvm/images/RHEL59.img'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk>

Por éste:

<disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source dev='/dev/mapper/z600-vm--rhel59'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk>

Ahora solo queda reinicir el servicio libvirtd para que recargue la configuración de la máquina virtual


Utilizar el botón de menú en aplicaciones GTK en Kubuntu

Chgonzalez - Mié, 05/07/2014 - 09:08
Últimamente he estado utilizando una configuración de escritorio que privilegia la simplicidad. Una de las grandes virtudes del escritorio Plasma de KDE es su capacidad de personalización para adaptarse a la forma de trabajo del usuario, por lo que no me fue difícil llegar a un resultado satisfactorio.

Entre otros ajustes, uno de los que más me gustó fue la posibilidad de ocultar el menú de cada aplicación en un único botón en la barra de título dela ventana. Para lograr esto, simplemente hay que ir a Preferencias del sistema - Apariencia de las aplicaciones - Estilo - Ajuste fino y ajustar el estilo de la barra de menú a "Botón de la barra de título".
Esto funciona sin problemas para las aplicaciones Qt y/o KDE, pero no así para las aplicaciones GTK, tal como se observa en la siguiente imagen:
Se puede ver que el explorador de archivos Dolphin (primera ventana a la izquierda) tiene su menú oculto en un botón que se sitúa en la esquina superior izquierda de la ventana. Pero las otras dos aplicaciones (GIMP y Zim, ambas escritas con GTK) siguen utilizando el menú tradicional.

Para lograr consistencia en las aplicaciones GTK en Kubuntu, 13.10 y 14.04, la solución pasa por instalar una versión de GTK modificada que está disponible en este PPA, de la siguiente forma:
sudo add-apt-repository ppa:joe-yasi/appmenu
sudo apt-get update && sudo apt-get upgrade
sudo apt-get install appmenu-gtk
sudo apt-get autoremoveLuego se debe cerrar la sesión de escritorio (o directamente reiniciar el equipo). Al volver a ingresar, se podrá observar que las aplicaciones GTK también utilizan el botón de menú en la barra de título, como se muestra en la siguiente imagen:

Es importante notar que esta solución no es perfecta, ya que algunas aplicaciones escritas con otros frameworks (como Java) seguirán utilizando el menú tradicional. Pero en mi caso, la mayoría de los programas que utilizo están escritos en Qt/KDE y GTK, por lo que el resultado es muy satisfactorio.

Referencias:

Reviviendo mi blog, enésimo intento

Chgonzalez - Mié, 05/07/2014 - 08:26
Tengo que reconocer que practicamente me había olvidado de mi blog. Muchas cosas han cambiado en estos últimos años, y bloguear dejó de ser una prioridad. Entre las causas están:

  • Ya utilizo bastante tiempo escribiendo documentos en mi trabajo, por lo que mis "ansias de escritor frustrado" se satisfacen en ese ámbito.
  • Sigo utilizando Twitter (y en menor medida Facebook) para compartir enlaces de interés o comentar hechos que me parecen relevantes. Y la verdad es que la comodidad y rapidez del microblogging hacen que, en comparación, la publicación de una entrada en mi blog se vea como una tarea pesada.
  • Ya no es una, sino dos :). Ahora tenemos dos hermosas hijas que copan todo nuestro tiempo y nos llenan de alegrías y desafíos cada día. (Otro día voy a escribir acerca de esta experiencia.)
  • La comunidad en torno a Linux (y el software libre en general) ha cambiado bastante. La llegada de nuevos usuarios (especialmente relacionados a Ubuntu) ha hecho aumentar exponencialmente la cantidad de información relativa a la solución de problemas simples, aunque al mismo tiempo he notado una baja en la calidad y cantidad de contenido asociado a temas de mayor profundidad.
  • Yo mismo he cambiado mi perfil de usuario de Linux. Ya no utilizo Fedora en mi equipo personal, sino Kubuntu. Ya no dedico tanto tiempo a "vivir al límite", instalando software inestable y probando cuanta distribución aparecía en el horizonte. Ahora privilegio un entorno sólido y que no requiera invertir demasiado tiempo en ajustes. (De todas formas, en prácticamente todos los servidores que administro sigo utilizando CentOS y no creo que eso vaya a cambiar en el corto plazo.)  Por lo mismo, ya no tengo el incentivo para escribir acerca de los "trucos" que utilizo en mi sistema, ya que la cantidad es mucho menor que antes. (También tengo pendiente la publicación de otro artículo acerca de por qué cambié Fedora por Kubuntu.)
Por todos estos motivos y otros más, se me hacía difícil encontrar la motivación y el tiempo para seguir manteniendo mi blog. Sin embargo, creo que voy a hacer un nuevo intento de revivir este sitio, ya que últimamente he notado que me hace falta poner por escrito varias ideas que dan vueltas en mi cabeza y además creo que es interesante que exista otra fuente de conocimiento relacionada a Kubuntu.


Veremos en qué queda este nuevo revival.

Páginas

Suscribirse a Fedora-es sindicador