whmapi1 listaccts search=reseller searchtype=owner |grep -e "domain: " |sort
Las Aventuras de Tux
6.05.2018
Comando del día: dominios de un servidor WHM desde linea de comandos
Si se quiere obtener los dominios y subdominios (no dominios adicionales o addon domains) por usuario propietario (resellers):
5.01.2018
Snipet #3 - Añadir disco a un LVM-RAID1
Si se quiere añadir un disco a un LVM-RAID1 cuando haya fallado el LV
Se desactiva el LV, se crea el PV, se extiende el VG y se repara el LV:
Si el disco añadido es de menor tamaño que el anterior:
Se desactiva el LV, se crea el PV, se extiende el VG y se repara el LV:
lvchange -an /miVG/miLVSe puede ver el avance del proceso con
pvcreate /dev/sdX
vgextend miVG /dev/sdX
lvconvert --repair miVG/miLV
lvs -a -o +devices
Si el disco añadido es de menor tamaño que el anterior:
vgreduce --removemissing miVG
4.10.2018
Snipet #2 - Reconstruir espejo de cualquier disco dentro de un LVM-RAID1
Mediante pvscan averiguamos el UUID del disco faltante.
Se desactiva el LV (Logical Volume)
Se desactiva el LV (Logical Volume)
lvchange -an miVG/miLVSe crea el PV (Phisical Volume)
pvcreate --uuid "UUID" /dev/sdXSe restaura el VG (Volume Group)
vgextend --restoremissing /dev/miVG /dev/sdX
3.22.2018
Grabar acciones en VIM para repetirlas despues
Hay ocasiones en las que debemos editar un archivo y que esta edición es prácticamente eliminar tal linea, quitar unos caracteres y aumentar otros.. una y otra vez. Para esto existe la opción de grabar las acciones una vez y luego simplemente repetirlas las veces que necesitemos.
Lo mejor de esto es que podemos tener tantas grabaciones casi como teclas tiene el teclado, por lo que si se trata de un archivo de gran tamaño que requiere de este tipo edición el trabajo resulta mucho más eficiente y rápido.
Para iniciar la grabación se presiona q seguida de la letra a la que queremos asignar la grabación, por ejemplo a. Veremos que en la barra de estado se muestra el mensaje grabando @a.
De aquí todo lo que hagamos está siendo grabado, todo, sea cual sea el modo en el que estemos (normal, visual, edición, etc) Una vez que deseemos terminar la grabación, en modo normal presionamos q nuevamente.
En el momento que queramos reproducir dicha grabación presionamos (en modo normal) la tecla @ seguido de la letra de la grabación deseada, por ejemplo @a.
Lo mejor de esto es que podemos tener tantas grabaciones casi como teclas tiene el teclado, por lo que si se trata de un archivo de gran tamaño que requiere de este tipo edición el trabajo resulta mucho más eficiente y rápido.
Para iniciar la grabación se presiona q seguida de la letra a la que queremos asignar la grabación, por ejemplo a. Veremos que en la barra de estado se muestra el mensaje grabando @a.
De aquí todo lo que hagamos está siendo grabado, todo, sea cual sea el modo en el que estemos (normal, visual, edición, etc) Una vez que deseemos terminar la grabación, en modo normal presionamos q nuevamente.
En el momento que queramos reproducir dicha grabación presionamos (en modo normal) la tecla @ seguido de la letra de la grabación deseada, por ejemplo @a.
3.06.2018
Snipet #1 - reiniciar hosts scsi para reconocer discos añadidos a una VM
Cuando se añaden discos a una VM y se requiere recargar los hosts scsi.
ls /sys/class/scsi_host/ |while read host; do echo "- - -" > /sys/class/scsi_host/$host/scan; done
9.28.2016
LVM-RAID1 - Alta disponibilidad de discos lógicos.
Muchas veces (siempre?) se necesita tener la seguridad de que tanto el sistema operativo como la información van a estar disponibles aún cuando exista un fallo en el disco duro.
Ya sea para una estación de trabajo o personal o en servidores, el contar con redundancia a nivel de discos facilita muchísimo la gestión de recursos ante una posible recuperación de desastres, en este caso el fallo total de un disco duro.
Por ejemplo, en una oficina pequeña no se suele disponer de personal para soporte informático permanente el cual descargue de la responsabilidad de mantener los respaldos al día a los usuarios de la red, contratar o mantener una solución de respaldo para todos los equipos suele ser demasiado costoso y en el otro lado, hacerlo únicamente para el equipo crítico para la empresa hace que la solución sea sub-utilizada. En este caso, pueda que sea mucho más factible simplemente añadir redundancia a los discos y de esta forma en caso de que uno falle no existe afectación alguna y da tiempo para colocar el reemplazo del disco dañado.
Voy a contar otro escenario de la vida real:
Se tienen unos servidores que reciben sus discos desde desde un storage, tiempo atrás una de las controladoras del storage falló y fue necesario migrar y reconstruir el arreglo de cada uno de los servidores (si alguien ha reconstruido un RAID5 en 4 discos sas de 8TB sabe lo que puede llevar). Debido a esto se tuvo una caída del servicio de horas, algo inaceptable.
Lo solución que propuse fue que se cuente con redundancia en los discos generando un LVM-RAID1. Porqué un LVM-RAID y no un raid con MDADM? Principalmente porque los puntos de montaje de los sistemas Linux ya estaban sobre LVM y no se quería añadir otra capa de administración.
Y porqué RAID1? La parte interesante es que en lvm-raid1 se puede definir la cantidad de espejos para el arreglo, por lo que el disco principal tiene n espejos y tendrían que fallar TODOS los discos para que se pierda el acceso a la data. Esto sumado a que cada disco viene de un storage distinto da aún mayor seguridad ante fallos sobre todo de hardware.
Así que manos a la consola :D
- Primero añadimos los discos físicos como pvs:
Si han usado raid por lvm o planean hacerlo póngalo en los comentarios!
Saludos.
Ya sea para una estación de trabajo o personal o en servidores, el contar con redundancia a nivel de discos facilita muchísimo la gestión de recursos ante una posible recuperación de desastres, en este caso el fallo total de un disco duro.
Por ejemplo, en una oficina pequeña no se suele disponer de personal para soporte informático permanente el cual descargue de la responsabilidad de mantener los respaldos al día a los usuarios de la red, contratar o mantener una solución de respaldo para todos los equipos suele ser demasiado costoso y en el otro lado, hacerlo únicamente para el equipo crítico para la empresa hace que la solución sea sub-utilizada. En este caso, pueda que sea mucho más factible simplemente añadir redundancia a los discos y de esta forma en caso de que uno falle no existe afectación alguna y da tiempo para colocar el reemplazo del disco dañado.
Voy a contar otro escenario de la vida real:
Se tienen unos servidores que reciben sus discos desde desde un storage, tiempo atrás una de las controladoras del storage falló y fue necesario migrar y reconstruir el arreglo de cada uno de los servidores (si alguien ha reconstruido un RAID5 en 4 discos sas de 8TB sabe lo que puede llevar). Debido a esto se tuvo una caída del servicio de horas, algo inaceptable.
Lo solución que propuse fue que se cuente con redundancia en los discos generando un LVM-RAID1. Porqué un LVM-RAID y no un raid con MDADM? Principalmente porque los puntos de montaje de los sistemas Linux ya estaban sobre LVM y no se quería añadir otra capa de administración.
Y porqué RAID1? La parte interesante es que en lvm-raid1 se puede definir la cantidad de espejos para el arreglo, por lo que el disco principal tiene n espejos y tendrían que fallar TODOS los discos para que se pierda el acceso a la data. Esto sumado a que cada disco viene de un storage distinto da aún mayor seguridad ante fallos sobre todo de hardware.
Así que manos a la consola :D
- Primero añadimos los discos físicos como pvs:
pvcreate /dev/sde /dev/sdf /dev/sdX- Creamos el grupo de volúmenes (VolumeGroup) indicando los discos que deseamos formen parte del mismo:
vgcreate miVG /dev/sde /dev/sdf /dev/sdX- Creamos un volumen lógico que ocupará toda la extensión del disco, esto es importante ya que nos asegura que la data se almacenará en un solo disco. el número para el argumento -m indica la cantidad de espejos que deseamos para el arreglo, el primer disco será el principal el resto las réplicas:
lvcreate --type raid1 -m 3 -l 100%FREE -n miLV miVG /dev/sde /dev/sdf /dev/sdXEsto creará el lv miLV en el grupo miVG y empezará la sincronización entre todos los discos, esto puede llevar varias horas dependiendo de la capacidad de los discos, su velocidad, etc. Para ver el porcentaje de sincronización podemos ejecutar el comando con watch con actualización por defecto cada 2 segundos:
watch lvs -a -o +devices miVG/miLVUna vez que se complete el proceso anterior podemos dar el sistema de archivos que deseemos:
mkfs.ext4 -L data /dev/miVG/miLVLa ventaja de LVM-RAID es que podemos añadir o remover espejos al arreglo y deshacer el arreglo por completo sin tener que migrar la información. Eso y muchas cosas más, recomiendo leer la documentación de RedHat sobre Administración LVM para tener una idea de sus alcances.
Si han usado raid por lvm o planean hacerlo póngalo en los comentarios!
Saludos.
9.19.2016
Migración de correos en masa con Imapsync a WHM/cpanel
La anterior semana se me presentó la necesidad de migrar una gran cantidad de correos de dos servidores distintos a otro. Los servidores de origen eran muy diferentes si se puede decir; el uno era un servidor "a mano" con webmin, postfix, dovecot, etc. El otro, un Zimbra CE.
Más allá de la diferencia de los servidores era la cantidad de cuentas de correo a migrar y el peso total de estas. Fueron alrededor de 150 cuentas y requerían de 150GB de espacio en el nuevo servidor. 150 para servidores de correo grandes no es nada, pero crear/migrar a mano una a una no es algo que ni deba ponerse como posibilidad.
Realmente nunca había tenido la necesidad de migrar de esta forma, siempre fue de Zimbra --> Zimbra, cpanel --> cpanel, etc. Pero esta vez la migración era desde los servidores antes mencionados hacia un WHM/cpanel.
Las cuentas de hosting ya se encontraban creadas en el WHM, la idea era automatizar la creación de las cuentas de correo en cada una de ellas y posteriormente migrar el correo.
Creación de correos en WHM:
Esto lo hice en línea de comandos en el servidor mediante la API de WHM whmapi1. El comando en cuestión es addpop y toma como parámetros usuario, contraseña, cuota de buzón. De esta forma, cree un archivo (llamado USERLIST) por cada dominio con el listado de cuentas de correo pertenecientes a el en el formato:
username;password:quotaUna vez se tiene el archivo, ejecuto el siguiente one-liner en el servidor WHM usando la API de cpanel:
while IFS=";" read u p q; do cpapi2 --user=acc-username Email addpop domain=acc-domain email=$u password=$p quota=$q; done < USERLIST
Donde:
- IFS es la variable que indica el separador del fichero USERLIST, en este caso ";", si por ejemplo obtiene un cvs se puede indicar que el separador es ","
- acc-username y acc-domain son los datos de usuario y dominio para la cuenta de cpanel en el WHM.
- $u, $p, $q son usuario, contraseña y quota para cada cuenta respectivamente.
MIgración de correos con Imapsync:
Debemos tener un fichero (llamado en el ejemplo como USERLIST) con el siguiente formato:
(usuario1;contraseña1;usuario2;contraseña2)
Donde:
- usuario1, contraseña1: credenciales de la cuenta de origen, usuario es sólo el nombre sin el @dominio.com
- usuario2, contraseña2: : credenciales de la cuenta de destino, usuario es sólo el nombre sin el @dominio.com
En cualquier equipo instalamos imapsync, la instalación depende de la distribución que elijamos y existe mucha documentación al respecto por lo que no lo trataré aquí.
Con imapsync instalado en el equipo que usaremos para ejecutar la migración, podemos usar el script de bash indicado a continuación:
Con esto tendríamos sincronizada la información de las cuentas de correo y podemos ejecutarla cuantas veces queramos ya que solo actualizará en el destino la información nueva. En mi caso tuve que esperar a que se refresquen las respuestas DNS de los registros MX de los dominios para poder dar de baja el servidor de origen.
Con el one-liner en el cpanel y el script de para imapsync migré las cuentas de forma semi-automatizada sin tener que estar pendiente en todo momento del proceso. Como dato extra al script de imapsync lo puse como un cronjob diario para mantener al día las cuentas en el destino hasta que me notifiquen del refresco de la zona DNS.
Gracias!.
imapsyncpath=/ubicacion/del/ejecutable/imapsyncOJO, recomiendo leer la documentación ya que tiene muchas, MUCHAS opciones de sincronización. Las opciones que uso son un tanto generales y pensadas para cubrir las necesidades de mi caso.
origen=10.0.1.1
destino=10.0.2.1
options="--tls1 --usecache --delete2 --nofoldersizes --no-modules_version --addheader --subscribeall"
while IFS=";" read u1 p1 u2 p2; do
{ echo "$u1" |egrep "^#" ; } > /dev/null && continue # skip comment lines in USERLIST
echo "============== Migrating mail from user $u1 to $u2 =============="
.$imapsyncpath/imapsync --host1 $origen --host2 $destino --user1 $u1 --password1 $p1 --user2 $u2 --password2 $p2 $options --dry
echo
echo "============== Ended migration for user $u1 in $u2 =============="
done < USERLIST
echo "Migration Complete."
exit 0
Con esto tendríamos sincronizada la información de las cuentas de correo y podemos ejecutarla cuantas veces queramos ya que solo actualizará en el destino la información nueva. En mi caso tuve que esperar a que se refresquen las respuestas DNS de los registros MX de los dominios para poder dar de baja el servidor de origen.
Con el one-liner en el cpanel y el script de para imapsync migré las cuentas de forma semi-automatizada sin tener que estar pendiente en todo momento del proceso. Como dato extra al script de imapsync lo puse como un cronjob diario para mantener al día las cuentas en el destino hasta que me notifiquen del refresco de la zona DNS.
Gracias!.
Suscribirse a:
Entradas (Atom)
Comando del día: dominios de un servidor WHM desde linea de comandos
Si se quiere obtener los dominios y subdominios (no dominios adicionales o addon domains ) por usuario propietario (resellers): whmapi1 li...
-
Una vez que hemos completado la instalación del servidor OpenMediaVault , seguramente necesitemos tener almacenamiento compartido en un ento...
-
La anterior semana se me presentó la necesidad de migrar una gran cantidad de correos de dos servidores distintos a otro. Los servidores de...
-
Para realizar un dump en vivo de una máquina virtual, tanto openvz como kvm podemos ejecutar el siguiente comando: vzdump --dumpdir /ubica...