El SysAdmin del 3er Mundo

todo lo que expliqué mientras nadie prestaba atención

Apps islámicas android

| Comments

Si queremos decir una aplicación islámica de android bien completa, la que más se acerca es sin duda es “MuslimPro”. Por tener, tiene hasta los 99 nombres de dios, recitados con un corito de lo más lindo. Sin embargo, cosas sensillas como cambiar el adhan, se vuelven complicadas. Si no te cuadran los 3 adhan que trae, te jodiste, por que lo más bonitos son para la versión de pago.

"portada de Muslim Daily, note como falta la sesión de noticias"

En mi opinión, el adhan debe sonar más enérgico de día, pero el adhan de Isha’a, lo prefiero pasivo. Por ello, recomiendo más usar Muslim Daily. Antes contaba con una sesión de noticias muy interesante, que se adaptaba a tu gusto como por arte de magia. No se por qué se la quitaron. También tiene la Qibla y un calendario islámico bastante poco funcional por cierto; me costó trabajo entender como conmutar las fechas.

Entre los 9 adhan que ofrece, tenemos el Adhan Nasse Al Qatmi muy apropiado para Isha’a, suena bastante sereno.

El corán que esta aplicación provee en español es la traducción de Cortés; una gran porquería en mi opinión. Pero de igual, si de coranes se trata, prefiero El noble corán Este cuenta con una buena gama de recitaciones en audio para todos los gustos. Además, el texto en los tres idiomas.

"«la apuertura» mostrando texto arábico, transliteración y traducción"

Recuerda, que mientras la app esté mostrando el texto en árabe, será entonces entonces un corán (no una traducción) y debes tener en cuenta el respeto que esto amerita; así que nada de leer en el baño. También tiene gestor de aleyas favoritas y permite añadirle notas.

"transcripción a alfabeto de chat"

Pero lo que más me gusta es que tiene una transliteración escrita fonéticamente con árabe de chat.

Por si no lo sabes, esta es una manera de leer árabe con alfabeto latino. Es la mejor transliteración, ya que fue creada por los árabes de manera espontanea. En vez de valerse de dígrafos para representar las consonantes; usan simplemente números. Por ejemplo, ayn (ع) es el 3 y la ha gutural (ح) con el 7. Además, las vocales entre paréntesis, representan las vocales casi inaudibles que acompañan de manera implícita a una consonante, como la «i» de la mim (م).

Por último, una aplicación de plegarias. Nada mal para afinar la fonética; la aplicación 34 Duaas.

Conclusión, el corán transliterado con árabe de chat de com.chaks.quran, es un batazo y los adhanes de com.honey.prayerassistant son más variados.

Si este artículo te resultó interesante, considere donar 0.06 BTC: 14iNmkfULf5jggumVh963kUg4UPScEZHgz

squid y navegar a .cu

| Comments

Aveces las necesidades de nuestros clientes, son tan raras que nos dejan anonadados. Pero ante necesidades extravagantes; soluciones extravagantes. Este post me lo dejo a modo de reflexión, para recordar; que muchas veces, el ingenio combinado con la simpleza, puede desembocar en soluciones tan hermosas como raras.

Es común, que en algunos lugares, la navegación a sitios “.cu” no requiera autenticación. Aveces poner una ACL como esta

“squid.conf”
1
2
 acl cuba url_regex \.cu
 http_access allow cuba

Aparentemente matamos la jugada, pero luego, metemos una ACL relacionada con usuarios autenticados y se jodió bicicleta.

El cartel de “por favor autentique” cae a cuanto “.cu” se navegue.

Pero tocando el squid.conf, vi esta cosa hermosa

“squid.conf”
1
 #   acl aclname localport 3128  # TCP port the client connected to [fast]

Decidí que los que vallan a navegar con autenticación, usarán el puerto 8080 y los vuelos nacionales saldrán por el 3128.

De esta manera, se hace una ACL que niegue las peticiones NO cubanas sin mostrar el puto login.

“squid.conf”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 # aquellos que se conectan por el puerto 3128
 acl mortales localport 3128

 # aquellos que se conectan por el 8080
 acl olimpo localport 8080

 # los sitios a los que se entran sin contraseña
 acl cuba url_regex -i "/etc/squid3/cuba.lst"

 # CUBANOS
 # lo que valla a cuba,
 # sale sin autenticación
 http_access allow mortales cuba
 http_access allow CONNECT mortales cuba

 # deniega a los mortales, lo que no sea cuba
 http_access deny mortales !cuba
 http_access deny CONNECT mortales !cuba


 # PRIVILEGIADOS
 # lo que NO valla para cuba debe autenticarse
 http_access allow CONNECT olimpo autenticados
 http_access allow olimpo autenticados

 # y más nada pasa
 http_access deny CONNECT all
 http_access deny all
 icp_access deny all

¿Se entendió? Pasa que squid, al hacerle cualquier petición, que involucre internet, le mostrará al pobre puntoseunauta el cuadro de diálogo, ya que para acceder a internet real requiere autenticación; y squid te da la posibilidad probar que eres usuario de internet. Para evitar esta conducta, ponemos una cláusula permitiendo que los “.cu” usando el 3128, pasan. Luego ponemos otra ACL negando el acceso a lo que NO sea .cu por el mismo puerto. De esta manera, los que tengan solo acceso “.cu”, usarán el 3128 y la ACL que involucra autenticación nunca es probada.

Para los autenticados, pusimos una ACL que machea el puerto 8080. O sea, los usuarios de internet, al hacer su peticiones por el puerto 8080, enseguida las pedirá autenticación.

Si este artículo te resultó interesante, considere donar 0.05 BTC: 14iNmkfULf5jggumVh963kUg4UPScEZHgz

instalar node rápido

| Comments

Desde que surgió node, estaba deseando que hubiera una herramienta como RVM para instalar nodejs. Resulta que la hay!!! Al igual que RVM, requiere cURL. Por cierto, se llama n

1
2
3
 curl -o /usr/local/bin/n https://raw.githubusercontent.com/visionmedia/n/master/bin/n
 chmod +x /usr/local/bin/n
 n lts

Instala hasta npm!

En debian, otra manera de hacer esto, es usando el repo oficial que provee node:

1
2
3
 curl -sL https://deb.nodesource.com/setup | bash -
 aptitude update
 aptitude install nodejs

Acuérdate que algunos paquetes (por no decir que los más usados) requieren compilar librerías. Así que no olvides instalar build-essential.

Si este artículo te resultó interesante, considere donar 0.08 BTC: 14iNmkfULf5jggumVh963kUg4UPScEZHgz

autoridad certificadora

| Comments

Es un gran mojón tener que generar un certificado para cada servicio. Y aquí, en el 5to infierno de infomed usar cualquier proveedor de CA gratis (como let’s encrypt) es por gusto.

En estos caso, no queda otro remiendo que usar un CA firmado localmente. La idea es.

Generamos un par de claves que harán la función de “autoridad certificadora”

  • crear un Clave Privada (.key) y mantenerla bien escondida
  • crear la Clave Pública del anterior (.pem) y la distribuimos

Una vez que tengamos nuestra autoridad certificadora. Empezamos a generar certificados y lo firmamos con esta.

  • generamos una clave privada (el .key para este certificado)
  • hacer una solicitud de certificado (.csr) al .key anterior
  • generamos el dichoso certificado
  • firmamos el certificado usando el .key de la CA

Usaremos al tan legalmente controversial OpenSSL para esta tarea.

La clave (.key) del CA, debe crearse en una máquina desconectada de la red y preferiblemente sepultada a 3 metros bajo tierra. Si esto le parece demasiado paranoico, entonces mantenga el “.key” en el servidor más aislado de la red. Preferiblemente, aquel que parezca menos importante y lejos de internet. En mi caso, yo uso mi laptop personal para tareas administrativas y es ahí donde tengo todas las claves privadas.

Supón que lo hagas en un servidor determinado. Creamos entonces en el home del root, un espacio adecuado para esto.

“creando el directorio”
1
2
3
 mkdir -m700 CA
 cd CA
 unmask 077

Creamos la super-secretísima clave privada, que hará la función de CA:

openssl genrsa -out rootCA.key 2048

“creando el .key en la máquina secreta”
1
2
3
4
5
 [lazaro@artema CA]$ openssl genrsa -out rootCA.key 2048
 Generating RSA private key, 2048 bit long modulus
 ..............................+++
 .......................................................+++
 e is 65537 (0x010001)

Ya tenemos la piedra angular de nuestro CA; pero así no sirve. Esa es la clave primaria, o sea, la que tiene la facultad de descifrar y derivar nuevos certificados. No nos conviene que nuestros “usuarios finales”, o lo servidores, usen esta clave. Necesitamos crear una “clave pública”, esta clave pública se deriva de la privada, pero solo tiene la facultad de cifrar, así la puede tener cualquiera y mandarnos datos cifrados. Sin embargo, NO se puede usar la clave pública para DEScifrar. Al menos no; usando tecnología civil.

Nota para los imbéciles: El rootCA.key no se le puede dar a nadie.

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.pem

“creando la clave pública”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 [lazaro@artema CA]$  openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.pem
 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) [AU]:CU
 State or Province Name (full name) [Some-State]:Havana
 Locality Name (eg, city) []:Plaza
 Organization Name (eg, company) [Internet Widgits Pty Ltd]:Calixto Garcia
 Organizational Unit Name (eg, section) []:Calixto Garcia
 Common Name (e.g. server FQDN or YOUR name) []:Hospital Calixto Garcia
 Email Address []:ssl@hcg.sld.cu

Ya tenemos la clave pública (el “.pem”). Este fichero será distribuido a nuestros clientes para que puedan hacer dos cosas: Cosa 1, cifrar los datos, sin poder descifrarlos. Cosa 2, identificar a la autoridad certificadora.

“la clave privada y publica de nuestra CA”
1
2
 [lazaro@artema CA]$ ls
 rootCA.key  rootCA.pem

Nota para los imbéciles: El rootCA.pem se instalará en los clientes, navegadores, teléfonos, etc…

Note además, que hemos dado a nuestra clave pública, 10 años antes de su caducidad (-days 3650). Quizás quieras darle un solo.

"Enigma, un disposotivo criptográfico de cuando no existía SSL."

Ya puedes hacer público el “.pem” para que todo el que sepa que hacer con este, se lo instale. Por ejemplo, si tienes una intranet local, podrías dejarla con http plano y brindar información (así como la descarga) sobre el dicha clave. Puedes crear una página de HTML plano explicando porque SSL y como instalarlo en los navegadores. Ahí dices además, que se debe iniciar la conexión usando el prefijo “https”. Podrías poner esa página como el destino de redirección para todos los virtualhsot que usen “http” y así hacer conciencia a los usuarios. Por ejemplo, en servidores con información sensible (como los webmails), solo debe ser alcanzado usando ssl.

Pero sin extremismos. Una intranet que brinda información pública, no tiene que ser obligado por SSL (a menos que sea un wordpress con login).

Por cierto, Firefox tiene su propio almacén de certificados. Dirígete a Configuraciones, Avanzada, Certificados.

"localizando el almacén de certificados"

Una vez ahí, ve a donde dice Autoridades (no a tus certificados) y procede a importar el certificado.

"importando el certificado a firefox"

En android también es tremenda balasera instalar el “.pem” y no dejará de meterme miedo diciendo que “un tercero podría estar manipulando tu información”. Lo cual no deja de ser cierto, poner un SSLbumper a squid bataría para hacer horrores.

"instalando el .pem en android"

Llégate a la configuración de seguridad y verás una opción que dice “instalar certificados desde la tarjetaSD” o “desde el almacenamiento”.

En algunos android 4, si te pide una clave y no sabes cual es, debes configurar el acceso al teléfono mediante clave. O sea, quita el patrón, pon una clave y prueba importar el “.pem”. Al pedir la clave pones la que estableciste para entrar. Una vez importado el certificado, vuelves a poner el mecanismo de seguridad que deses (patrón, ninguno, etc…)

de vuelta al servidor secreto

Pasemos ahora a crear uno (o varios) certificados para nuestros servidores. Para empezar, crearemos el certificado del servidor de correo, pero no del smtp, si no del webmail.

MUY IMPORTANTE en los certificados, el CN (Common Name) no puede ser el que te de la gana a tí. Si por ejemplo tu servidor de correo está en webmail.dominio.cu, ese ha de ser su CN

Nota para los imbéciles: Creas un certificado para cada servicio y su CN será el mismo nombre del virtualhost.

Creamos una clave privada para este servidor (para que pueda cifrar, te requiero que es bilateral y simétrico).

openssl genrsa -out webmail.key 2048

“la clave privada del webmail”
1
2
3
4
5
 [lazaro@artema CA]$ openssl genrsa -out webmail.key 2048
 Generating RSA private key, 2048 bit long modulus
 .+++
 ......................................................................................+++
 e is 65537 (0x010001)

Le pedimos a esta clave que genera un certificado (certificate request).

openssl req -new -key webmail.key -out webmail.csr

“solicitud de certificado”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 [lazaro@artema CA]$ openssl req -new -key webmail.key -out webmail.csr
 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) [AU]:CU
 State or Province Name (full name) [Some-State]:Havana
 Locality Name (eg, city) []:Plaza
 Organization Name (eg, company) [Internet Widgits Pty Ltd]:Calixto Garcia
 Organizational Unit Name (eg, section) []:Calixto Garcia
 Common Name (e.g. server FQDN or YOUR name) []:webmail.hcg.sld.cu
 Email Address []:ssl@hcg.sld.cu
 
 Please enter the following 'extra' attributes
 to be sent with your certificate request
 A challenge password []:
 An optional company name []:

Ya tenemos las dos máquinas enigmas listas, pero no están sincronizadas y por ende, los cifrados producidos producidos por estos dos ficheros, serán simétricos pero no bilaterales. Alguien debe decirle que son padre e hijo.

Eso lo haremos, firmando con nuestro CA, el certificado generado.

openssl x509 -req -in webmail.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out webmail.crt -days 3650 -sha256

“firmando el certificado con la CA”
1
2
3
4
[lazaro@artema CA]$ openssl x509 -req -in webmail.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out webmail.crt -days 3650 -sha256
Signature ok
subject=C = CU, ST = Havana, L = Plaza, O = Calixto Garcia, OU = Calixto Garcia, CN = webmail.hcg.sld.cu, emailAddress = ssl@hcg.sld.cu
Getting CA Private Key

Note como hacemos uso de las claves pública y privada del CA. Por tanto, si un atacante adquiere los certificados del webmail y los colocase en otro sitio, este no machea el CN webmail.hcg.sld.cu y desata una advertencia en el navegador de nuestros usuarios. Además, no podrá firmar el certificado para modificarlo e incluir su CN.

“los certificados del webmail”
1
2
[lazaro@artema CA]$ ls
rootCA.key  rootCA.pem  rootCA.srl  webmail.crt  webmail.csr  webmail.key

Bueno, todo listo, hagamos un paquete con todo lo necesario para que nuestro servidor de correo se lo configure en el webmail. Para postfix y para dovecot, debemos hacer otro que machee smtp.hcg.sld.cu y pop3.hcg.sld.cu sucesivamete.

REPITO! el rootCA.key NO puede hacerse público. Así que le daremos una copia del rootCA.pem

“empaquetando la entrega”
1
2
3
4
5
6
7
8
9
10
 [lazaro@artema CA]$ mkdir webmail
 [lazaro@artema CA]$ mv webmail.* webmail/
 [lazaro@artema CA]$ cp rootCA.pem webmail/
 [lazaro@artema CA]$ tar cvfz webmail.tar.gz webmail/
 webmail/
 webmail/webmail.crt
 webmail/webmail.csr
 webmail/webmail.key
 webmail/rootCA.pem
 [lazaro@artema CA]$ scp webmail.tar.gz root@webmail.hcg.sld.cu:/root/

Instálale esos certificado a tu apache/nginx y todo el que tenga el rootCA.pem instalado en su dispositivo; verá a “Calixto Garcia” como una legítima autoridad certificadora al abrir el webmail.

Lo que si no me queda claro es como se le instala el “.pem” a Windows. ¿Sugerencias?

"autoridad certificadora, o al menos, eso dicen"

Aquí les dejo el script que uso para hacer esto de forma automatizada. Para correrlo cree un directorio. Por ejemplo:

“CA”
1
2
3
 mkdir miCA
 cd miCA
 mkcert.sh

Al correrlo la primera vez te creara el rootCA.pem, luego al correrlo con argumentos, se generan certificados para dichos dominios.

“CA”
1
2
3
 mkcert.sh fulanito.dominio.cu
 ...
 echo fulanito.dominio.cu.tar.gz está listo para despachar

Te devolverá un .tar.gz con todo dentro.

Si este artículo te resultó interesante, considere donar 0.07 BTC: 14iNmkfULf5jggumVh963kUg4UPScEZHgz

xen y virt-manager

| Comments

La miseria, es lo único que; aun repartida a muchos, toca en abundancia.

La superioridad tecnológica de XenServer es indiscutible: seguro (esquema de pacheo de XOA), versátil (la XAPI), robusto (CentOS) y sencillo (Xen Orchestra Appliance) y enterprise (next, next, next, install, boot, ready!) PERO:

"el xenfu panda, el logo de Xen, olvidado o desconocido por los usuarios de Citrix XenServer"

Cuando los megas de RAM se cuentan con los dedos de una mano, el peso de la XAPI y la necesidad de tener otra máquina corriendo para el XenOrchestra, DUELEN. Tomemos por ejemplo, una máquina con 2 gigas de RAM. En mi caso tengo Xen Orchestra en la laptop, pero desplegar node+servidor en una máquina virtual más; no es una opción en este escenario. Que se jodan XOA, XenServer y los capitalistas de la Citrix ¡Hora de ser completamente libre!

Yo hubiera matado la jugada con LXC pero el cliente insiste en usar los 3 sistemas; tal como está en mi esquema del calixto. Lo cierto es que 3 contenedores no inspiran mucha confianza. Tampoco KVM es una buena opción, sobre todo cuado no hay un super microprocesador.

Rercordemos que: Xen, mejor con CPU, peor peor IO. Mientras que: KVM, mejor IO, pero CPU más penalizado.

El menú:

Dos interfaces de red, un disco de 500G, 2G de ram, y un CPU que por suerte soporta virtualización. Un switch de 24 puertos a 100 megas, otro a gigabit. Un friki que oye reguetton, su mujer, la mía, 5 pesos de café en un vaso plástico y YO.

Las VM y su RAM:

  • debian como servidor de correo (postfix y dovecot, sin webmail) - 512M
  • alpine como ruter (dns, dhcp y firewall) - 512M
  • FreeBSD como proxy (squid) - 1G

La brujería:

Con suerte No se matarán por los 2 Gigas de RAM. El squid con usuarios PAM como autenticación y casi nada en las ACL, además en BSD no come mucha ram. Alpine es un chiste en lo que a RAM se refiere y el de correo no tendrá un webmail así que plin.

Los 3 servidores tendrán unos cortafuegos super estrictos. Descartarán todo tipo de ICMP para evitar cuellos de botella. La LAN funciona a 100 megas y el servidor está conectado al ÚNICO switch a gigabit. Osea, el server, un switch y un cable al netgear viejo que está a 100 megas. Con eso, la difusión “uno a varios” será mayor y no habrá congestiones, mientras que la peticiones entrantes (individual) no excederán el 10% el ancho de vianda del servidor. La ley del embudo.

Entrando en materia:

Volvemos a la génesis de xen pero usaremos virt-manager para manejar el hypervisor.

Primero que todo, llevamos a cabo una instalación típica de Xen en un debian 8. Nada que contar; el clásico Dom0.

“xen-linux-system”
1
2
3
 aptitude update
 aptitude install xen-linux-system
 dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen

Esta PC tiene dos interfaz de red. Una de cara al router, con una ip/29 “públicas” y otra interfaz, de cara a la LAN. Por tanto crearemos 3 puentes:

  • br0 de eth0 hacia el router
  • br1 de eth1 hacia la LAN
  • br2 para comunicación interna (costumbre, nunca está de más)

Así me quedó el /etc/network/interfaces

“/etc/network/interfaces”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 # arriba todo el mundo
 auto lo eth0 eth1 br0 br1 br2

 # el lo
 iface lo inet loopback

 # levanta las dos interfacess
 # pa cuando el bridge se levante
 iface eth0 inet manual
 iface eth1 inet manual

 # puente de la interfaz onboard (WAN)
 iface br0 inet static
    bridge_ports eth0
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0

 # puente de la interfaz PCI (LAN)
 # y la ip del hypervisor para hacer SSH
 iface br1 inet manual
    address 192.168.99.10
    netmask 255.255.255.0
    bridge_ports eth1
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0

 # una interfaz de red local de las VM
 # note que el puente apunta a la interfaz none
 iface br2 inet static
    bridge_ports eth0
    address 169.254.0.1
    netmask 255.255.255.0
    bridge_ports none
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0

Ahora vienen los toques mágicos. Libvirt!

“libvirtd”
1
 apt-get install libvirt-bin

De más está que te diga, que este debian fue instalado sobre LVM. Crea el directorio /etc/libvirt/storage/ y dentro, le pondremos un fichero llamado xenvg.xml o comotedelagana.xml. Al instalar con el particionado guiado; el grupo llama hostname-vg, en este caso xen-vg. Note como la cláusula path, apunta hacia el mapper del grupo de volumen group y que tanto nombre del fichero como del pool; no deben contener espacios ni “-”.

“/etc/libvirt/storage/xenvg.xml”
1
2
3
4
5
6
<pool type='logical'>
  <name>xenvg</name>
  <target>
    <path>/dev/xen-vg</path>
  </target>
</pool>

Ahora inicializaremos el pool de libvirt:

“virsh”
1
2
3
 virsh pool-define /etc/libvirt/storage/xenvg.xml
 virsh pool-start xenvg
 virsh pool-autostart xenvg

Corre virsh pool-info xenvg para ver si todo pinchó. Llegado a este punto te recomiendo reiniciar…

De regreso a la máquina del informático…

Arrancamos el virt-manager:

"iniciando virt-manager desde gnome-shell"

De más está que te diga, que las operaciones de libvirt se hacen por ssh, así que debes tener ssh en la máquina remota; preferiblemente con autenticación por llaves y no por password.

“ssh”
1
2
 ssh-keygen
 ssh-copy-id root@192.168.99.10

Vamos a File y Add connection, agregaremos una conexión del tipo Xen.

"conectando al libvirtd del servidor xen"

De aquí en adelante, es la misma mecánica básica de virt-manager. Solo quiero hacer un apartado para crear un pool más y me refrito a un pool donde pondremos los ficheros “.iso”.

Creamos el directorio donde meteremos los ISO y copiamos el iso que querramos para allá. Como ya me conocen, soy el enemigo de las plantillas. Confío más en lo que yo mismo hago que en lo que hacen otros.

“mkdir”
1
2
 ssh root@192.168.99.10 mkdir /opt/isos/
 scp ~/Downloads/ISO/*.iso root@192.168.99.10:/opt/isos/

Selecciona la conexión al Xen, y haz click en el botón de crear nueva máquina.

"creando el repositorio con las iso"

El asistente nos llevará al gestor de almacenamiento. Seleccionamos “Local install media” y click en siguiente. Luego “Use ISO image”.

"Local Install Media" "Use ISO image"

Aquí haces click en Browse y te conduce al lugar donde crearemos los ISO. Inmediatamente te verás en la pantalla donde te pedirá que selecciones los storage volume. En la imagen se puede apreciar que ya existe uno llamado “iso”, pero de igual, para el ejemplo mostraremos como se creará.

Odio las interfaz visual, como hacen pasar trabajo! Pero virsh no es cosa jamón para mi cliente que no es del todo un hacha en linux.

Bueno… has click en el signo de más color azul y te mostrará un dialogo que muestra “Create Storage Pool”. Lo nombramos “iso” y le decimos que será del tipo “dir”. O sea un directorio común en el sistema de archivos.

"creando el storage pool de los ISO"

Como segundo argumento, nos pedirá la ruta. Le daremos la que creamos en el servidor, en este caso /opt/isos.

"la ruta del SR"

Sí todo salió bien, verás los .iso que tiene el directorio.

"los .iso del directorio"

Al hacer click en el iso seleccionado, vuelve el asistente y muestra que se usará dicho iso.

"selecciona el iso"

Lo demás es pa mongo, la RAM el disco que creamos en el SR “default”, etc…

"custumise configeichon befor instal"

Marcamos el check que dice “Customize configuration before install” y caeremos en la pantalla que muestra todos los detalles de la máquina.

"modificando el hardware"

Esta pantalla es importante; no permite configurar de manera más exquisita el hardware. Por ejemplo, las interfaces de redes, yo quiero que tenga como primera interfaz, la que apunta a br0 y como segunda, la que apunta a br2. Además, algunas veces la máquinas traen una wacom tablet como interfaz (mariconerías del virt-manager).

En fin, así me quedó la mía.

"arrancando"

Si este artículo te resultó interesante, considere donar 0.08 BTC: 14iNmkfULf5jggumVh963kUg4UPScEZHgz

jugar teeworlds en LAN

| Comments

Un otorrino me ha dejado sorprendido cuando me pidió que le instalara ArchLinux en su laptop (las todos tenemos de los médicos). La primera vez le instalé fedora, pero lo quitó y volvió pidiéndome que le instalara arch. El doctor Bershard, me cuenta las epopeyas de los usuarios de linux en la red de la habana.

Durante el proceso de “que te instalo” me mencionó “el tiwol” como un juego muy importante. No me imaginé que sería tan fascinante. Similar al minimilitia de android. Me di cuenta que crear un server, es lanzar un comando y dejarlo funcionando. La gente se conecta y desconecta del servidor cuando quiera. Se pueden jugar partidas de equipo, pero la más caliente es el “death match”. Entra mata un rato y sale cuando te aburras.

En el calixto el jueguito causó furor (está para windows y se conecta perfectamente). A cada rato entro y me encuentro 3 o 4 con nombres cada vez más creativos matándose a tiros y dando brincos.

Según la documentación, al correr teeworlds_srv -f fichero.cfg cargará ese fichero. Muy útil para crear múltiples modos de juego. Al lanzar el comando teeworlds_srv noté que dice:

1
2
3
4
5
[58db3577][storage]: using standard paths
[58db3577][storage]: added path '$USERDIR' ('/home/lazaro/.teeworlds')
[58db3577][storage]: added path '$DATADIR' ('/usr/share/teeworlds/data')
[58db3577][storage]: added path '$CURRENTDIR' ('/home/lazaro/.teeworlds')
[58db3577][console]: failed to open 'autoexec.cfg'

Así que al crear el fichero /home/lazaro/.teeworlds/autoexec.cfg resultó que se cargaba solo. Pero… ¿qué metemos ahí?

“autoexec.cfg”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#
# teeworld_srv -f este_fichero.cfg
#

# Los mapas y la secuencia de mapas
#
# ls /usr/share/teeworlds/data/maps/
sv_map dm7
sv_maprotation dm7 dm6 dm2 dm9 md8 dm1

# como se ve el servidor
sv_name Masacre en el Calixto
sv_motd "las teclas son «a», «d» y Espacio"

# que tipo de juego jugamos
sv_gametype dm
sv_scorelimit 30
sv_timelimit 0

# configuración del servidor
bindaddr 0.0.0.0
sv_register to 0

# permite usar la consola remota
sv_rcon_password secretisimo

Dice: Jugaremos una ronda de 30 puntos, sin límite de tiempo, que empieza por el mapa “dm7”.

El comando sv_maprotation recibe como argumento la lista de mapas. Cada vez que termine una ronda, se cambiará el mapa.

Más información en el sitio de teeworlds www.teeworlds.com

Si este artículo te resultó interesante, considere donar 0.07 BTC: 14iNmkfULf5jggumVh963kUg4UPScEZHgz