Category Archives: Centos

How to upload to e-qsl from Linux shell

So, for example: you are using WSJT-X and would like to automatically upload your new contacts from your Linux to EQSL.

WSJT-X store its logs in ~/.local/share/WSJT-X/wsjtx_log.adi

I have created a small script to check if wsjtx_log.adi has been modified, extract the last 2 QSO from the file to a temporary file and upload that file to eQSL, here is how:

git clone https://github.com/hc6pe/adifupload.git
cd adifupload
chmod +x adifupload.sh

Edif adifupload.sh and change ADIFILE, EQSLUSER and EQSLPASS to suit your needs:

vi ~/adifupload/adifupload.sh
....
#Where is your .adi file located? 
#Specify the full path (change YOURUSERNAME):
ADIFILE="/home/YOURUSERNAME/.local/share/WSJT-X/wsjtx_log.adi"
#your eQSL username. Use CAPS altough I think
# lowercase will work as well
EQSLUSER="N0CALL"
#your EQSL password.
EQSLPASS="not-my-pass"
...

And add a crontab task to start adifupload.sh on every reboot (change YOURUSERNAME to your user’s home dir):

crontab -e
@reboot /home/YOURUSERNAME/adifupload/adifupload.sh

Now, the script will start on your next reboot. And keep started checking if your ADIFILE has changed, if it notice it has changed, then it will upload the last 2 lines of the files (just in case it missed the previous upload).

Of course, if you have “massaged” the logfile, for example updating some QSO info (date, time, band, etc), this script will not upload the changed QSOs unless it is one of the last 2 lines.

So I suggest, from time to time, to do a full upload of your adif file by signing into eQSL.cc and do a manual upload. This way you may catch any missing to upload QSO.

¿Cómo activar consola serial en CentOS-7?

Esto puede no funcionar para CentOS-8

  • Edito /etc/sysconfig/grub
  • en GRUB_CMDLINE_LINUX agrego: console=ttyS0
  • En GRUB_TERMINAL_OUTPUT agrego: serial
  • En la línea de comando: stty -F /dev/ttyS0 speed 9600
  • Ejecuto: grub2-mkconfig -o /boot/grub2/grub.cfg
  • systemctl enable --now getty@ttyS0
  • Reinicio la VM: reboot
  • Desde el hospedero puedo ejecutar: virsh console vm
  • Para salir de la consola presiono: CTRL 5

¿Cómo redimensionar un qcow2?

Este howto funciona perfectamente para CentOS-8. En CentOS-7 no tenemos nbd por lo que no funcionará tal cual aquí se ve.

  • Apagas la vm: virsh shutdown vm
  • Verificas que ya se haya apagado: virsh list
  • Incrementas el qcow2: qemu-img resize /var/lib/libvirt/images/vm.qcow2 +40G
  • Cargas el módulo de nbd en el kernel: modprobe nbd
  • Asignas el disco duro a un dispositivo nbd: qemu-nbd -c /dev/nbd0 /var/lib/libvirt/images/vm.qcow2
  • instalas gparted: dnf install -y gparted
  • Ejecutas gparted en el dispositivo nbd: gparted /dev/nbd0
  • Cuando finalizas el proceso de redimensionar y cierras el gparted, procedes a eliminar el dispositivo nbd:
    • qemu-nbd -d /dev/nbd0 && rmmod nbd
  • Enciendes la vm: virsh start vm

Cómo agregar un bridge para KVM en CENTOS-8

No es muy difícil, pero al momento es la forma que he hallado para agregar un bridge al CentOS-8 de forma tal que se pueda usar en KVM.

Quizá hayan otras formas, pero esta es la que me ha funcionado luego de tanta prueba y error.

Vamos a asumir que tenemos una interfaz de red llamada “enp2s0“. Por supuesto se debe verificar cuál es el nombre de su interfaz de red en su instalación y cambiar enp2s0 por el nombre correcto de su interfaz.

Edito el archivo /etc/sysconfig/network-scripts/ifcfg-br0 y le pongo estos contenidos (tener en cuenta cambiar la IP a la IP de su server):

DEVICE=br0
NAME=br0
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
IPADDR="192.168.1.120"
PREFIX="24"
GATEWAY="192.168.1.1"
DNS1=8.8.8.8
BOOTPROTO=none
DEFROUTE=yes
AUTOCONNECT_SLAVES=yes
IPV6INIT=no

Ahora edito el archivo de configuración de mi interfaz (/etc/sysconfig/network-scripts/ifcfg-enp2s0) y le dejo tal y como se ve aquí, ni una letra más, ni una menos (tener en cuenta poner el nombre correcto en NAME y en DEVICE:

TYPE="Ethernet"
NAME="enp2s0"
DEVICE="enp2s0"
ONBOOT="yes"
BRIDGE=br0

Ahora procedo a agregar el bridge a KVM:

Creo un xml : /root/br0.xml con estos contenidos exactamente:

network>
    <name>br0</name>
    <forward mode="bridge"/>
    <bridge name="br0" />
</network>

Y procedo a darle de alta al KVM:

virsh net-start br0
virsh net-autostart br0
virsh net-list --all

Si todo parece bien, reiniciamos el equipo y deberá regresar con la IP asignada a la interfaz br0.

Cómo configurar tunnel de IPv6 con tunnelbroker

Quieres navegar por IPv6? Puedes probar usar las IPs que te da tunnelbroker

Edita un nuevo archivo, llamado por ejemplo:

/etc/sysconfig/network-scripts/ifcfg-sit1

Dentro le pones esto:

DEVICE=sit1
BOOTPROTO=none
ONBOOT=yes
IPV6INIT=yes
IPV6TUNNELIPV4=<IPv4delServerDeTunnelBroker>
IPV6TUNNELIPV4LOCAL=<IPv4LocalTuya>
IPV6ADDR=<IPv6QueTeAsignaron>
IPV6_DEFAULTGW=<IPv6DelServidor>

IPv6DelServidor=Server IPv6 Address (no pongas el /64)

IPv6QueTeAsignaron=Client IPv6 Address (ponle con /64 y todo)

IPv4LocalTuya=Client IPv4 Address. Ponle tu IP privada si es que el equipo lo tienes detrás de un NAT

IPv4DelServerDeTunnelBroker=Server IPv4 Address

Reinicias la red, o el equipo, y listo, puedes hacer ping6 www.google.com o lo que quieras

 

Notas para instalar KVM en CentOS-7

Estas notas son para mi, que las entiendo, sin embargo posiblemente te sirvan también si necesitaras instalar KVM en CentOS-7.

  • Reviso en el BIOS que tenga activada la opción de virtualización: A veces está oculta/a veces no está. Si estuviera y estuviera desactivada, el sistema correrá en modo emulación (lento) y dirá solamente QEMU y no QEMU/KVM
  • En mi caso me falló el arranque con EFI, desde el BIOS desactivé el EFI para que arrancara la flash. Esto puede no aplicar a todo el mundo.
  • Bajé el CentOS-7 liveCD
    • Configuré teclado
    • Configuré la red
    • Particioné el disco (/boot – 500M, / para el resto del disco). (Puedes particionarle para usar LVM, ahora no es el caso en este rapido tuto)
    • Al inicial la primera vez le dije que no al kdump
    • Deshabilité el SELINUX en /etc/sysconfig/selinux
    • apagué el firewall: systemctl disable firewalld , systemctl stop firewalld
    • Actualicé el sistema (yum update)
    • Instalé los siguientes paquetes y arranqué los siguientes servicios:
      • yum install virt-manager
      • yum groupinstall “Virtualization host”
      • systemctl start libvirtd
      • systemctl enable libvirtd
    • Creé un bridge en el virt-manager, este bridge tiene a la tarjeta de red de mi servidor como componente de él, pero no le “activé ahora” al bridge pues te quedas sin conectividad.

      Sólo le puse onboot y ya. Fíjate en lo marcado en amarillo en la imagen:

      Selección_085

      • Reinicié para que el bridge funcione.
    • De ahora en adelante toda máquina virtual la debo crear conectándose al bridge br0 para que esté en la misma conexión de la red.
    • Al crear las máquinas debo veificar que tanto el disco como la tarjeta de red sean de tipo “virtio” si no lo son, podrá ser potencialmente menos rápido el trabajo el sistema.

Nota lo que he marcado en amarillo (lo del writeback es solamente si tienes un raid por hardware con respaldo por bateria):

Selección_086

Selección_087

Usando webalizer con geo-localización

Si has usado Linux y tienes un sitio web seguramente has oído hablar de webalizer, es una herramientas que brinda estadísticas de acceso al sitio web. Sin embargo hay una configuración que por defecto no me gusta y es que en el gráfico que sale al final, muestra los accesos “por países” pero los obtiene de acuerdo a la reversa de una IP. Por ejemplo si la reversa de una IP es X-Y-Z.telconet.net, que es un proveedor de internet aquí en Ecuador, el sistema lo catalogará como .net y no de Ecuador.

En el país tenemos varios proveedores cuyas reversas no terminan en .ec sino en .net o .com por lo que los gráficos de webalizer nos nos ofrecen una realidad de lo que hay.

Sin embargo, hace tiempo webalizer permite el uso de la BD de GeoIP (maxmind) para resolver IPs a países.

Cómo se activa esto? Suponiendo que ya tengas el paquete webalizer instalado entonces son dos sencillos pasos:

Editamos /etc/webalizer.conf y agregamos:

GeoDB yes

No creo que sea necesario un orden o posición para agregarle, pero yo le hago delante de donde hay un comentario que comienza con “DNSCache”

Luego creamos el directorio /usr/share/GeoDB, traemos el archivo geodb-latest.tar.gz y le abrimos al directorio, en realidad yo le hice en un script para ejecutarle cada mes pues cada mes actualizan las IPs:

#!/bin/bash

[ -d “/usr/share/GeoDB” ] || { mkdir /usr/share/GeoDB; };
cd /usr/share/GeoDB
rm -f geodb-latest.tgz
wget ftp://ftp.mrunix.net/pub/webalizer/geodb/geodb-latest.tgz
tar zxf geodb-latest.tgz

y listo! con esto para la siguiente ejecución del webalizer ya saldrán al final de las estadísticas el listado por países.

PD: Estos directorios son los que usa el webalizer para CentOS, para otros sistemas quizá debas averiguar si es exactamente el mismo directorio el /usr/share/GeoDB

 

Descripción del proceso de instalación de CentOS-6 bajo VirtualBox

En esta página de mi sitio pueden encontrar un breve manual de instalación de CentOS-6 bajo VirtualBox. El VirtualBox puede estar instalado en Windows sin problema alguno:

http://ernestoperez.com/?page_id=2014

Cómo instalar los mismos paquetes de un servidor CentOS en otro servidor usando yum?

A veces me sucede, quiero migrar la información de un servidor CentOS, porque me conviene más tenerlo en otro hardware, porque el otro hardware tiene mejores especificaciones, porque el usuario lo requiere, en fin. Supongamos que tenemos la necesidad de tener en un servidor CentOS recién instalado los mismos paquetes que en el servidor anterior.

Lógicamente se puede no hacer este paso, simplemente a veces lo mejor es ir viendo uno a uno los sistemas que tenemos, entonces instalándoles, reconfigurándoles, etc.. hasta llegar a un estado en el cual el nuevo servidor es muy similar al viejo. Sin embargo a veces esta forma es medio aburrida.

Lo primero que debemos es garantizar que los mismos repositorios del server viejo estén configurados en el server nuevo, para ello deberás mirar en /etc/yum.repos.d/ de ambos equipos y si algún repositorio faltara, le instalas en el nuevo. (por ejemplo el de epel que es bien famoso). Es importante este paso pues si un repo no está presente, lógicamente terminarás no instalando uno o varios paquetes por falta de este repo, etc.

Ahora qué tal que yo en el servidor viejo ponga esto:

yum –disablerepo=* list “*”|awk -F”.” ‘{print $1 ” \\”}’

Este es EL COMANDO. Es el comando que me permitirá listar todos los paquetes instalados en el servidor viejo, y los imprimirá con un \ al final.

Esta salida me la llevo a un editor de texto, elimino el último \ y arriba arriba pongo yum install \

Entonces le copio toooooda la salida de este comando en el nuevo quedaría algo así como:

yum install \

paquete1 \

paquete2 \

.

.

paqueteX

(fíjate que al último le quité el \)

Y listo, el yum se encargará de instalar todos los paquetes que en el nuevo servidor no existan pero que sí habían en el viejo.

De esta forma garantizo al menos que por falta de paquetes nada me va a fallar. Lógicamente luego de este paso me tocaría copiar los archivos importantes del /etc del viejo servidor al /etc del nuevo. Para esto lo que hago realmente es una copia del /etc del viejo y lo pongo en /root/etc (no le pongo directamente en /etc!!!)

Luego con rsync le voy sacando, digamos que me interesa el archivo /etc/mail del viejo, hago esto:

rsync -avP /root/etc/mail /etc/

digamos que me interesa copiar así mismo el archivo /etc/httpd/conf y /etc/httpd/conf.d del viejo al nuevo.. cómo haría? Exacto!

rsync -avP /root/etc/httpd/conf /etc/httpd/

rsync -avP /root/etc/httpd/conf.d /etc/httpd

y bueno, ya el resto es aburrido, levantar los servicios, copiar los archivos de /home y/o de /var que quiera, etc…

Full virtual vs Paravirtual

En la lista de CentOS en Español, surgió un hilo muy interesante el mes pasado sobre sistemas de virtualización para CentOS, derivó a un tema sin salida de sistemas de virtualización que no son para CentOS, luego regresó al tema.. un usuario de la lista habló muy bien de Xen y a mi me gusta Xen y uso Xen desde fines del 2004! Pero igual he visto y probado que KVM es bueno, y en la lista puse un breve escrito sobre cómo comprender que KVM es igual de bueno pues usa algunas técnicas de paravirtualización en algunos dispositivos, aquí va (le he corregido algunas faltas y aclarado cosas que me quedaron en el aire por el apremio):

Dijo el otro usuario (y luego le respondo yo):

xen me parece mejor, porque soporta paravirtualizacion, si tienes un
micro con soporte V-XM, puedes correr incluso un SO instalado y
funcionando en otro disco duro. Ademas de poder direccionar hardware
para un huesped en particular.
No soy experto ni nada pero lo que he leido acerca de xen dan mas que ganas.
Pero tambien hay que ver que quieres virtualizar, porque una cosa es
un SO completo y otra es virtualizar tu propio SO para hacer como
jaulas clonando tu instalacion para otros servicios.
Es verdad lo que indicas y lo apruebo. La paravirtualización es
maravillosa. Y me encanta Xen y le usé mucho tiempo, y le usaré si es
necesario.
Sin embargo, la brecha entre sistemas full virtualizados y paravirtuales
se ha ido reduciendo a casi nada. Y me explico (con simples palabras):

La full virtualización (kvm por ejemplo, xen también) le asigna un slice
de tiempo de procesador a la máquina virtual, esta máquina le usa
directamente al procesador durante este periodo, y le guste o no, a
través de herramientas incorporadas en el procesador, se le saca a la
máquina del procesador y se le devuelve el control al hospedero.

Ventajas: no hay que emular el procesador, no hay que usar llamadas al
hospedero por parte de los invitados para acceder al procesador. Es
acceso directo al procesador! Maravilloso!!!

Sin embargo la full virtualización tenía algunos inconvenientes que no
tenía la paravirtualización (xen por ejemplo soporta paravirtualización)
y es que para el resto de dispositivos (red, disco, ram) había que 
emular para que las máquinas virtuales full virtualizadas accedieran
a ellos. En pocas palabras: Emulación=lentitud.

Entonces algunos (yo incluído) siempre decíamos que la full
virtualización, tal y como se usaba en principio no traía ventajas, o
mejor aún, digamos que la paravirtualización era más rápida.

Por qué? porque en la paravirtualización el invitado está programado
para ejecutar llamadas pre-establecidas al hospedero para realizar
ciertas labores hacia dispositivos. Por ejemplo, no accede directamente
a la tarjeta de red, sino que invoca a llamadas preestablecidas
(funciones) en el hospedero y este le hace la comunicación de red. Lo
mismo al disco, lo mismo a la ram y a otros dispositivos menos
importantes ahora.

Entonces no había que emular hardware.. simplemente llamadas, y el
hospedero a través de su sistema operativo y drivers específicos,
realizaba la labor de comunicación con la red, disco, etc... esto era
rapidísimo, tan rápido como acceder desde el hospedero mismo.

Lo único que podía ralentizar un poquiiiiiiiiiiiiiiiiiiiito era el hecho
de la llamada misma.. pero era algo negligible.. es algo que impacta poco.

Es por eso que decíamos:
-> paravirtual=rapido,
-> full virtual=rapido el procesador, emulado el resto.

Por qué no se puede hacer una mezcla? Qué tal algo full virtual para el
procesador (que es lo que es a la final) y paravirtual el resto? Bueno,
pues "porque los sistemas operativos privativos no pueden ser
modificados" pensaban algunos.. y si no puedo incorporar las llamadas
pre-establecidas entre el invitado que corre un sistema operativo
privativo y el invitado con KVM por ejemplo.. pues no puedo hacer
paravirtualización!

Full virtualización sin embargo no requiere de modificaciones en el
SO con la finalidad de que corra como máquina virtual. Esto lo hacía 
útil para SO privativos. Pero lento por otro lado.

Ahh.. entonces full virtualización para los privativos y
paravirtualización para los que pueden ser modificados (SL)? En
principio algunos pensaron así.

Hasta que alguien sacó a la luz una idea: Pensemos que tengo windows, y
que hago un driver de red llamado digamos virt-net que ese driver, se
incorpora como todo driver de windows al kernel que corre.. y este
driver tiene las llamadas pre-establecidas para comunicarse y
enviar/recibir las peticiones de red con el hospedero en KVM por ejemplo.

Además hago un driver llamado virt-block que igual se comunicará con el
hospedero para enviar/recibir las peticiones de disco. Y hago uno
llamado virt-balloon que se ocupará de mantener las llamadas
pre-establecidas para comunicarse con el hospedero y atender las
llamadas a las operaciones con la ram (fundamentalmente reducir/ampliar
la ram en uso del invitado).

Ah bacán! Todos esos drivers serán drivers "paravirtuales" y sustituirán
la necesidad de drivers "emulados". Qué hay en tu mente?
paravirtual=rápido, emulación=lento.

Entonces qué logro? rapidez! Un sistema full virtual para acceso nativo
y directo al procesador + drivers paravirtuales de red, disco y ram que
permiten acceso casi directo a estos recursos a través del hospedero..

Esto lo hace KVM:
- Al usar un SO Linux, estos ya vienen con los drivers paravirtuales, y
funciona rapidísimo el sistema.
- Al usar un SO tipo windows por ejemplo, le indicas a Windows que por
favor use un disco de drivers (virtio-win)
http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers y
windows detectará tu tarjeta de red paravirtual, disco paravirtual y
balloon paravirtual. Para esto es necesario decirle al KVM antes de
comenzar a instalar que estos tres dispositivos serán de tipo virtio..
windows no verá disco al inicio, hasta que introduzcas el CD de drivers
y entonces ahi verá el disco PV, red PV, etc.

Rápido? rapidísimo, además de que hace latente una de las ventajas de la
virtualización que es la independencia de las máquinas virtuales del
hardware.. ellas no conocen el hardware bajo el que se ejecutan, sino
que quien sabe del hardware es elhospedero, esto facilita la migración
(cosa que también KVM hace) entre hardware, etc.

Para terminar insisto: KVM y Xen son los dos sistemas de virtualización
más importantes en nuestro mundillo de CentOS.. también puedes usar LXC,
qemu, virtuozzo y otras cosillas, pero fundamentalmente kvm y xen son
los duros. Proxmox y todos esos paneles que hablan, simplemente son
paneles que manejan y facilitan el uso de los sistemas de virtualización
KVM, Xen, LXC, virtuozzo... tal y como virt-manager o virsh lo hacen a
su forma. Pero para mi me parece importante comprender lo que hay
debajo, antes de saltar a usar un panel  y ya.

saludos
epe