Atacar API de Hexonet mediante Curl

Buenas!

Hoy me ha tocado mirar de hacer una actualización en bulk de dominios para habilitar el Whois privado a unos dominios que hay registrados en Hexonet. Desde el propio panel de control no se puede hacer más que uno a uno, y siendo ciento y muy muchos, decidí tirar unas pocas líneas.

Echando un ojo, conseguí sacar la lista de los dominios mediante esta URL:

https://coreapi.1api.net/api/call.cgi?s_login=<USUARIO>&s_pw=<CONTRASEÑA>&command=QueryDomainList

Que nos devuelve la lista completa de dominios que hay asociados al usuario. Añadiento otro parámetro podemos filtrar mediante una expresión con comodines, así que lo usé para filtrar por TLD:

https://coreapi.1api.net/api/call.cgi?s_login=<USUARIO>&s_pw=<CONTRASEÑA>&command=QueryDomainList&domain=*.com

Una vez sacada la lista, me quedaba ver como modificar en concreto el tema del Whois que rebuscando conseguí encontrar el parámetro "x-accept-whoistrustee-tac" que se le puede pasar un 0 o un 1  para deshabilitar o habilitar (este parámetro es válido para el comando "AddDomain" y "ModifyDomain"). Con esto me quedaba una URL tal que así:

https://coreapi.1api.net/api/call.cgi?s_login=<USUARIO>&s_pw=<CONTRASEÑA>&command=ModifyDomain&domain=<DOMINIO>&x-accept-whoistrustee-tac=1

Con estas dos URLs y un par de bucles for ya se puede hacer la actualización en bulk de forma fácil*:

for TLD in "com" "net" "org" "biz" "info" "mobi" "name" "cc" "la" "tv" "fm" "me"; do
   for DOMINIO in $(curl "https://coreapi.1api.net/api/call.cgi?s_login=<USUARIO>&s_pw=<CONTRASEÑA>&command=QueryDomainList&domain=*.$TLD" 2>&1 | grep DOMAIN | awk -F"=" '{ print $2 }'); do
      curl "https://coreapi.1api.net/api/call.cgi?s_login=<USUARIO>&s_pw=<CONTRASEÑA>&command=ModifyDomain&domain=$DOMINIO&x-accept-whoistrustee-tac=1"
   done
done

* Para que quede un poco más claro voy a separar los for y los comandos en colores, cada uno una línea.

Con esto ya estaría, lo único que no he llegado a probarlo porque el servicio cuesta 0,35$ por cada dominio y al final me han dicho que no lo haga.

Hasta la proxima!

Referencias:
Enlace con info de la API de Hexonet: DOMAIN API Reference
Enlace info Whois Trustee: Hexonet - Private Registrations 

Recuperar disco LVM

Hoy he tenido un problema con un disco LVM, que tras una reinstalación del sistema (sin haber tocado ese disco) no me lo reconocía como LVM así que no podía recuperar las copias de seguridad. Trasteando, rezando y con un par de cafés, he conseguido recuperar la partición y restaurar los datos en el Proxmox.

Resulta que hay una carpeta con copias de seguridad de la información de los LVMs por si pasa algo como esto en /etc/lvm/backup y /etc/lvm/archive. Si somos capaces de tener esos archivos (bien porque se ha roto sin haber reinstalado o bien porque tenemos una copia) es relativamente sencillo:

pvcreate --uuid "XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXX" --restorefile /etc/lvm/archive/vg01_0000X-XXXXXXXXX.vg /dev/sdd1

Eligiendo el archivo correspondiente a nuestra partición a recuperar que sea más reciente.

Ahora bien, como yo he reinstalado el sistema, esa carpeta la perdí. Rebuscando información para ver como recuperar la información para poder hacer ese archivo a mano, encontré en los foros de ubuntu una ayuda (no tengo ahora mismo el enlace pero si alguna vez lo lees, ¡gracias!). Con el comando string podemos ver un volcado en texto plano de algunos datos del disco. En mi caso, no se si siempre es así, los datos correspondientes al LVM me aparecían al principio y por desgracia no estaban completos, aunque tuve suerte ya que lo que necesitaba sí estaba.

En mi caso tenía una VG llamado vg1 con dos LVMs: "backup" y "data". En este caso la que me importaba recuperar era backup. En mi caso esta es la info (editada) que conseguí recuperar:

LABELONE
LVM2 001bIgag30QmYiGlP3Z3yB4WdBP0983IAKnG
 LVM2 x[5A%r0N*>
vg1 {
id = "XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXX"
seqno = 4
format = "lvm2"
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0
metadata_copies = 0
physical_volumes {
pv0 {
id = "YYYYYY-YYYY-YYYY-YYYY-YYYY-YYYY-YYYYYY"
device = "/dev/sdd1"
status = ["ALLOCATABLE"]
flags = []
dev_size = 7814035087
pe_start = 2048
pe_count = 953861
logical_volumes {
backup {
id = "ZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZ"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_host = "localhost"
creation_time = 1463086567
segment_count = 1
segment1 {
start_extent = 0
extent_count = 681575
type = "striped"
stripe_count = 1
stripes = [
"pv0", 262144

Así que me generé un fichero en /etc/lvm/archive con esos datos:

contents = "Text Format Volume Group"
version = 1

description = "Created *before* executing 'lvconvert --type thin-pool pve/data'"

creation_host = "localhost"  # Linux sd16 4.10.15-1-pve #1 SMP PVE 4.10.15-15 (Fri, 23 Jun 2017 08:57:55 +0200) x86_64
creation_time = 1499844119      # Wed Jul 12 09:21:59 2017

vg1 {
        id = "XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXX"
        seqno = 4
        format = "lvm2"                 # informational
        status = ["RESIZEABLE", "READ", "WRITE"]
        flags = []
        extent_size = 8192              # 4 Megabytes
        max_lv = 0
        max_pv = 0
        metadata_copies = 0

        physical_volumes {

                pv0 {
                        id = "YYYYYY-YYYY-YYYY-YYYY-YYYY-YYYY-YYYYYY"
                        device = "/dev/sdd1"     # Hint only

                        status = ["ALLOCATABLE"]
                        flags = []
                        dev_size = 7814035087   # 893.626 Gigabytes
                        pe_start = 2048
                        pe_count = 953861       # 893.625 Gigabytes
                }
        }

        logical_volumes {

                backup {
                        id = "ZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZ"
                        status = ["READ", "WRITE", "VISIBLE"]
                        flags = []
                        creation_time = 1463086567      # 2017-07-12 08:10:32 +0200
                        creation_host = "localhost"
                        segment_count = 1
           
                        segment1 {
                                start_extent = 0
                                extent_count = 681575     # 15 Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv0", 262144
                                ]
                        }
                }

        }

}

Una vez hechora podemos ejecutar:

pvcreate --uuid "XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXX" --restorefile /etc/lvm/archive/vg01_0000X-XXXXXXXXX.vg /dev/sdd1

Y restaurar y activar el VG:

vgcfgrestore -f /etc/lvm/archive/vg01_0000X-XXXXXXXXX.vg vg1
vgchange -ay vg1

Que ya me dejó en mi caso el LV backup disponible para restaurar, ¡Yay!

Atacar al API Restful de MXTOOLBOX usando curl

Mxtoolbox proporciona una API para poder interactuar con su servicio. Los ejemplos que dan están en Ajax:

var apiUrl = 'https://api.mxtoolbox.com/api/v1/Monitor';
var apiKey = '<KEY_PERSONAL>';

$.ajax({
    url: apiUrl,
    type: 'GET',
    dataType: 'json',
    success: function (result) {
        //OnSuccess Callback
    },
    error: function (xhr, status, error) {
        //OnError Callback
    },
    beforeSend: function (xhr) {
        if (apiKey) {
            xhr.setRequestHeader('Authorization', apiKey);
        }
    }
});
Así listaríamos los monitores según el ejeplo que dan

Por limitaciones, tenía que hacer esto usando cURL, así que buscando buscando quedaría una cosa así:

curl -X POST  -H "Content-type: application/json"  -H "Authorization: <KEY_PERSONAL>" --request GET "https://api.mxtoolbox.com/api/v1/Monitor"

 La otra que me interesaba era el borrar un monitor, que con el ejemplo que dan sería así:

var apiUrl = 'https://api.mxtoolbox.com/api/v1/Monitor/<id monitor>';
var apiKey = '<KEY_PERSONAL>'; 

$.ajax({ 
    url: apiUrl, 
    type: 'DELETE',
    dataType: 'json', 
    success: function (result) { 
        //OnSuccess Callback
    },
    error: function (xhr, status, error) { 
        //OnError Callback
    },
    beforeSend: function (xhr) { 
        if (apiKey) { 
            xhr.setRequestHeader('Authorization', apiKey); 
        } 
    } 
});
Para borrar un monitor

Que en cURL quedaría:

curl -X POST  -H "Content-type: application/json"  -H "Authorization: <KEY_PERSONAL>" --request DELETE "https://api.mxtoolbox.com/api/v1/Monitor/<id monitor>"

Con estas dos llamadas y un poco de bash, conseguí hacer lo que necesitaba que era borrar todos los monitores de una tacada:

curl -X POST  -H "Content-type: application/json"  -H "Authorization: <KEY_PERSONAL>" --request GET "https://api.mxtoolbox.com/api/v1/Monitor" | grep MonitorUID | awk -F ":" '{ print $2 }' | sed 's/^ "//g' | sed 's/,//' |sed 's/ //'| sed 's/^/https:\/\/api.mxtoolbox.com\/api\/v1\/Monitor\//' | sed 's/^/curl -X POST -H "Content-type: application\/json" -H "Authorization: <KEY_PERSONAL>" --request DELETE "/'

Bueno, esto me imprime por pantalla y toca hacer copy paste, ¡pero la idea está ahí y había prisa!

Instalar Proxmox4 en Hetzner - Parte 2

Vamos a pasar ahora a configurar la red en nuestro Proxmox. Por política de Hetzner, para usar múltiples IPs en virtuales, necesitaremos hacer que el propio Proxmox enrute las IPs.

Tendremos que editar el fichero /etc/network/interfaces que por defecto está así:

#### Hetzner Online GmbH - installimage
# Loopback device:
auto lo
iface lo inet loopback
iface lo inet6 loopback

# device: eth0
auto  eth0
iface eth0 inet static
  address   <IP Pública>
  netmask   <Máscara subred>
  gateway   <Puerta enlace>
  # default route to access subnet
  up route add -net <IP Red> netmask <Máscara subred> gw <Puerta enlace> eth0

iface eth0 inet6 static
  address <IPv6>
  netmask 64
  gateway fe80::1

Para dejarlo así:

auto lo
iface lo inet loopback

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
        address  <IP Pública>
        netmask  <Máscara subred>
        gateway  <Puerta enlace>
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        pointopoint <Puerta enlace>
        up route add -net <IP Red> netmask <Máscara subred> gw <Puerta enlace> eth0

Es decir, cambiamos la configuración para dejarlo todo en base a vmbr0 y quitando IPv6 si no lo vamos a utilizar. Luego a partir de esta configuración, ya crearemos vmbr1 en la que configuraremos las nuevas IPs:

auto vmbr1
iface vmbr1 inet static
        address <IP Pública2>
        netmask 255.255.255.255
        bridge_ports none
        bridge_stp off
        bridge_fd 0

De las IPs que nos dan, ahí configuraremos una de ellas, que es la que usaremos como GW para el resto de IPs, y como GW ponemos la IP princinpal del servidor.

Es importante editar el /etc/sysctl.conf y comprobar que están estos valores así:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1 // Si usamos IPv6
net.ipv4.conf.all.send_redirects=0

Si no están así, tendremos que cambiarlo. Una vez cambiado esto tendremos que reiniciar la máquina.

Con esto, ya podremos configurar la red de nuestras VM en LXC. En la configuración de la red, tendremos que seleccionar  en Bridge vmbr1 para que funcione la red y como GW tenemos que poner la IP principal del Proxmox.

Instalar Proxmox4 en Hetzner - Parte 1

Para instalar un Proxmox 4 en Heztner usaremos la imagen que ofrece, pero siempre podremos instalar una Debian y pasarla a Proxmox. Al contratar el servidor o querer reinstalarlo, entraremos en el modo rescue que ofrecen y ejecutamos:

installimage

Ahí nos vamos a Virtualization y seleccionamos "Proxmox-Virtualization-Environment-on-Debian-Jessie" que se corresponde con Proxmox4. Si quisiésemos instalar Proxmox 3.4, seleccionaremos la imagen basada en Wheezy. Ahí nos abrirá un editor de texto para personalizar un poco la instalación si lo necesitásemos, por lo que lo explicaré un poco:

HARD DISK DRIVE(S): Nos mostrará los discos duros o discos ssd que tiene el equipo. Es importante dejar sólo los que vayamos a querer usar para la instalación. Por ejemplo yo suelo quitar los discos destinados a backups, ya que me encargaré luego de prepararlos a mano.

SOFTWARE RAID: Para configurar el raid por software su queremos usarlo, pondremos SWRAID a 1 o a 0 según nuestros planes. Luego en SWRAIDLEVEL indicaremos el tipo de raid que queremos usar (para 0 y 1 necesitaremos dos discos al menos, pero para 10 necesitaremos al menos cuatro discos). Ojo aquí ya que no se si en el caso del raid 1 si metemos 3 discos lo configura como spare o lo mete en el raid, haciendo cosas raras.

HOSTNAME: Es el nombre de la máquina. En caso de proxmox, tiene que ser FQDN aunque no hace falta que resuelva. Si no se pone FQDN casca la instalación.

PARTITIONS / FILESYSTEMS: Esto ya tiene más miga, ya que se va a definir el particionado. Tenemos que tener claro lo que necesitamos para no cometer errores. En el caso de Proxmox4 dejaremos tal y como está:

PART /boot ext3 512M
PART lvm vg0 all //Podemos poner pve para dejar la misma nomenclatura que Proxmox, pero da un poco igual.

LV vg0 root / ext3 15G
LV vg0 swap swap swap 6G

Si nos fijamos, se va a quedar dos volúmenes lógicos ocupando 21G y el resto estará desasignado. Esto nos viene bien para crear luego una partición LVM-thin y tenerlo fetén, ya que en Proxmox4 se usa LVM-Thin y no LVM para las VM en LXC ya que permite hacer snapshots. En el caso de Proxmox3 podríamos añadir la línea:

LV vg data /var/lib/vz ext4 all

para crear el volumen lógico en el que pondremos las VM en OpenVZ. Una vez listo, seguimos con la instalación tal y como indican.

Una vez finalice la instalación y arranque de nuevo, nos quedará definir la partición donde guardaremos los virtuales y si queremos/podemos, preparar los discos extra para backups.

El crear el LVM-Thin es sencillo, ya que está creado el VG y tiene espacio, lo único que necesitaremos será ejecutar:

lvcreate -l 95%FREE -n data vg0
lvconvert --type thin-pool vg0/data

Ajustando los nombres a los que hayamos usado. Como la idea mía es usar todo el espacio libre posible, es posible que al ejecutar el lvconvert se queje de que no hay "exents" disponibles, por lo que tendremos que reducir el tamaño de vg0/data hasta que nos deje. En mi caso opto por quitar el lv con:

lvremove /dev/vg0/data

Y lo recreo ajustando el porcentaje. Esto se puede hacer al no tener datos aún ya que evidentemente eso se cepilla todo. Sólo nos quedaría preparar los discos para backups y tendremos la parte del almacenamiento quedará apañado. Si instalamos un Debian sólo para luego instalar el Proxmox, el particionado será el mismo, luego nos tendríamos que ocupar de instalar el Kernel y los paquetes necesarios para ejectutar el Proxmox.

Lo siguiente será configurar la red que eso ya tiene más jaleo, pero ¡será en el siguiente post!

Hetzner - Conectar remotamente carpeta CIFS en Linux

Para configurar que se conecte automáticamente al espacio de backups que ofrece Hetzner, tenemos que añadir en el fstab:

//u000000.your-backup.de/backup /mnt/remoto cifs credentials=/root/.smbcredentials,iocharset=utf8,rw,uid=root,gid=root,file_mode=0660,dir_mode=0770 0 0

Donde u000000.your-backup.de es el servidor backup a conectar.

En el archivo /root/.smbcredentials pondremos los datos de acceso (usuario/pass) de esta forma:

username=u0000000
password=M1C0ntR@s3N4b0N1c4

 Y al hacer mount -a debería dejar conectado.

S nos da este error o similar:

mount: wrong fs type, bad option, bad superblock on //u127491.your-backup.de/backup, missing codepage or helper program, or other error (for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program)

In some cases useful info is found in syslog - try dmesg | tail or so.

 Con instalar el paquete cifs-utils nos valdrá, ya que así tendremos el soporte para contectar con comparticiones SAMBA/CIFS.

Consumo RAM de un Wordpress

Para ajustar la configuración de un servidor web en cuanto al máximo de memoria que le vamos a permitir consumir usarmos esta fórmula:

MaxConexiones = (RAM Disponible / RAM Consumida por web)

Vamos, que dividimos la ram total que le vamos a querer asignar al servicio por lo que ocupa cada página en memoria y nos dará el número de páginas concurrentes que va a poder mostrar antes de caer el servicio.

Podemos sacar esos valores a través de los comandos "ps" o "top", pero no es sencillo si se usan virtual hosts con distintos usuarios o si se usa PHP-FPM que se ejecuta a parte.

Para sacar un valor más acertado, podemos usar unas funciones de php para que a la hora de cargar la página nos lo muestre en el navegador. En este ejemplo voy a ponerlo para Wordpress, pero será extrapolable a lo que necesitemos con algún ajuste.

Tendremos que añadir éste código al footer.php de nuestra plantilla:

<!-- <?php if (is_user_logged_in()) { ?>
<p>Consumo de PHP: <?php echo round(memory_get_usage()/1048576,2) ?>MB.</p>
<p>Peticiones: <?php echo get_num_queries(); ?> consultas.</p>
<p>Tiempo de carga: <?php timer_stop(1); ?> segundos.</p>
<?php } ?> -->

Entre </body> y </html> que nos mostrará los datos viendo el código fuente de la página sólo si estamos logueados.

Si queremos que se muestre aunque no estemos logueados lo podemos poner así:

 <!-- <p>Consumo de PHP: <?php echo round(memory_get_usage()/1048576,2) ?>MB.</p>
<p>Peticiones: <?php echo get_num_queries(); ?> consultas.</p>
<p>Tiempo de carga: <?php timer_stop(1); ?> segundos.</p>  -->

Con esta información podremos ajustar fácilmente la configuración para dejar el Apache a nuestro gusto y poder dimensionar los servicios bien. 

Pasar Windows 10 Home a Pro

Hoy vengo con una nota, de esas pa' mí que luego sacan de un apuro a cualquiera. El caso es que necesitaba pasar un Windows 10 Home a Pro, así a pelo, para poder meter unos equipos en un Directorio Activo.

El caso es que rebuscando, en todos los sitios decían que no se podía, que había que reinstalar (hasta me lo dijeron un "soporte técnico postventa"). Yo como siempre, dije que nones, que se tenía que poder hacer porque es algo que desde M$ tienen que dejar hacer: es un upgrade.

Así que... Buscando y buscando, encontré la forma de hacerlo y es bien sencillica.  Sería tal que así:

• Vamos a "Configuración"

• Entramos en "Actualización y seguridad:

• Vamos a "Activación":

• Y ahí pulsamos sobre "Cambiar la clave de producto", que nos pedirá poner una nueva:

Ahí ponemos la clave "VK7JG-NPHTM-C97JM-9MPGT-3V66T" que lo que permite es precisamente pasarlo a Pro. Una vez acabados los reinicios, ya tendremos que poner una clave válida para Pro y ¡listo el pollo!