[Gutl-l] Re: BACKUP - RESTORE EN PROXMOX
https://forum.proxmox.com/threads/restore-failed-wrong-vma-extent-header-chechsum.34965/ -Mensaje original- De: Arian Molina Aguilera [mailto:linuxc...@teknik.io] Enviado el: Monday, March 18, 2019 7:48 PM Para: Lista cubana de soporte técnico en Tecnologias Libres Asunto: [Gutl-l] Re: BACKUP - RESTORE EN PROXMOX Importancia: Alta En 18 de marzo de 2019 1:40:01 p. m. Pedro Ramos escribió: > ARIAN no soy porfiado si le estoy consultando es porque voy a probar las > soluciones q me brinden ya lo restaure en una instancia con suficiente > espacio. ya no me brinda la advertencia del espacio pero me repite el > mismo error > > restore vma archive: vma extract -v -r /var/tmp/vzdumptmp19727.fifo > /var/lib/vz/dump/vzdump-qemu-101-2019_03_11-06_30_56.vma > /var/tmp/vzdumptmp19727 > CFG: size: 323 name: qemu-server.conf > DEV: dev_id=1 size: 268435456000 devname: drive-scsi0 > CTIME: Mon Mar 11 06:30:59 2019 > Using default stripesize 64.00 KiB. > Logical volume "vm-101-disk-1" created. > new volume ID is 'local-lvm:vm-101-disk-1' > map 'drive-scsi0' to '/dev/pve/vm-101-disk-1' (write zeros = 0) > > ** (process:19728): ERROR **: restore failed - wrong vma extent header > chechsum > Logical volume "vm-101-disk-1" successfully removed > temporary volume 'local-lvm:vm-101-disk-1' sucessfuly removed > TASK ERROR: command 'set -o pipefail && vma extract -v -r > /var/tmp/vzdumptmp19727.fifo > /var/lib/vz/dump/vzdump-qemu-101-2019_03_11-06_30_56.vma > /var/tmp/vzdumptmp19727' failed: got signal 5 > > Pues asegúrese que en /var/tmp y /var/lib/vz/dump, donde están esos 2 directorios tiene suficiente espacio, creo haber explicado en un hilo anteriormente, que el archivo /etc/vzdump.conf, controla el comportamiento de dónde estará ese directorio temporal, donde se extraerá el dump del backup para posteriormente copiarse la imagen al storage donde se almacenará la VM posteriormente. > El 3/18/2019 a las 2:25 PM, Arian Molina Aguilera escribió: >> El 18/3/19 a las 12:20, Pedro Ramos escribió: >>> ** (process:8656): ERROR **: restore failed - wrong vma extent header >>> chechsum >> Ese error es debido a lo que ya se te dijo, es producto que al >> descomprimir en el servidor este no se puede completar, y el resultante >> es que no concuerda con su suma de chequeo, no sea porfiado y aumente el >> storage o restaure en otro lugar con más espacio donde se pueda >> descomprimir sin problema dicha salva. >> >> >> >> ___ >> Gutl-l mailing list -- gutl-l@listas.jovenclub.cu >> To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu > > > > > -- > ___ > Gutl-l mailing list -- gutl-l@listas.jovenclub.cu > To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu > ___ Gutl-l mailing list -- gutl-l@listas.jovenclub.cu To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu ___ Gutl-l mailing list -- gutl-l@listas.jovenclub.cu To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu
[Gutl-l] Sobre servidor web
Gracias atodos muchacos, ya he hecho algo con el 9, pero sogo sin recibir respuesta sobre la implementacion del servidor web. Quisiera saber que paquetes se instalan para esto en debian 9, si hay algun tuto se lo agradeseria. Gracias a calvo fernandez por la sugerencia y atodos. -- Pavel Hiubel Germán Gómez. Radioaficionado. Téc. Electrónica. Tel.Fijo: 23367652. Tel. Movil: +53-53211665. Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece la Federacion de Radioaficionados de Cuba. La persona que envia este correo asume el compromiso de usar el servicio y cumplir con las regulaciones establecidas. FRCUBA: https://www.frcuba.cu/ ___ Gutl-l mailing list -- gutl-l@listas.jovenclub.cu To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu
[Gutl-l] Sobre repo local
Hola muchacos. Sigo con las preguntas. Necesito configurar un repo local con los paquetes que ya he instalado en la PC en Debian 9, tengo un tuto pero me da bateo. Alguien ha hecho esto en debian 9, si fuera posible me ayudaran. Voy a por todas en Debian 9, me ha gustado despues de todo. 73. -- Pavel Hiubel Germán Gómez. Radioaficionado. Téc. Electrónica. Tel.Fijo: 23367652. Tel. Movil: +53-53211665. Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece la Federacion de Radioaficionados de Cuba. La persona que envia este correo asume el compromiso de usar el servicio y cumplir con las regulaciones establecidas. FRCUBA: https://www.frcuba.cu/ ___ Gutl-l mailing list -- gutl-l@listas.jovenclub.cu To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu
[Gutl-l] Sobre servidor web
Gracias Vladi, espero que por la noche al conectame en la wifi instalar todo y luego te digo. 73 El 19/3/19 a las 16:12, Lic. Vladimir Valero escribió: Te paso un tiny de mi servidor web con un lxc de proxmox. Mira el adjunto. Cualquier duda me notificas por esta via. El 3/19/19 a las 4:05 PM, CO8PHG escribió: Gracias atodos muchacos, ya he hecho algo con el 9, pero sogo sin recibir respuesta sobre la implementacion del servidor web. Quisiera saber que paquetes se instalan para esto en debian 9, si hay algun tuto se lo agradeseria. Gracias a calvo fernandez por la sugerencia y atodos. -- Pavel Hiubel Germán Gómez. Radioaficionado. Téc. Electrónica. Tel.Fijo: 23367652. Tel. Movil: +53-53211665. Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece la Federacion de Radioaficionados de Cuba. La persona que envia este correo asume el compromiso de usar el servicio y cumplir con las regulaciones establecidas. FRCUBA: https://www.frcuba.cu/ ___ Gutl-l mailing list -- gutl-l@listas.jovenclub.cu To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu
[Gutl-l] Re: Sobre servidor web
fácil, Nginx+ php7-fpm + php7 + mariadb-server + phpmyadmin, listo. Luego a estudiar y leerte la documentación de todo eso. ___ Gutl-l mailing list -- gutl-l@listas.jovenclub.cu To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu
[Gutl-l] Re: Configurando subdominios en Bind9
En 18 de marzo de 2019 6:04:41 p. m. "Ing. Eduardo R. Barrera Pérez"
escribió:
Tenemos una VPN a Nivel Nacional, donde hay muchas empresas de todo el
ministerio y el Nodo Nacional, de momento no hace delegación de zona
internamiente hacia dentro de la VPN para nadie, por lo que actualmente
hoy ellos tienen tienen declarados en los DNS Nacionales, las zonas de
todos los que estamos dentro de la VPN, declarandose ellos mismos como
master en todas esas zonas y estableciendo nombres escogidos por ellos,
tanto para los registros de tipo NS como MX para todos los clientes que
están en dicha VPN, aun cuando en la mayoria de los casos, eso nombres
declarados nacionalmente, no coinciden con los nombres de los servidores
de correo de las empresas en algunos territorios, aunque la IP si concuerda.
Supongamos que el bloque IP 192.168.250.0/24 es del Nodo Nacional y que
los ip 192.168.250.2 y 192.18.250.3 son los DNS nacionales internos de
cara a dicha VPN, (Master y slave). Yo como administrador provincial,
monte para mi red (192.168.5.0/24) 2 DNS externos de cara a la VPN,
cuyas ip son: 192.168.5.2 y 192.168.5.3 respectivamente (master y slave).
Acorde con los administradores nacionales, que mi zona DNS
(pri.dominio.cu) ellos la cambiaran de master a slave, para yo ser el
master y entonces yo les transferiría una copia de las zonas DNS (esto
solo se está haciendo con la zona directa, no con la inversa)
Todo fue bien hasta ahi y así está funcionando desde algun tiempo sin
lio. Pero resulta que tengo muchas empresas en el territorio que no
tienen informaticos y ya hemos instalado una buena cantidad de
servidores en estas empresas, donde tenemos la posibilidad de
administración remota y he querido hacer en estas empresas lo mismo que
hice en mis DNS, es decir llamar a los de la habana, para que cambien la
zona de tipo master a tipo slave, yo les digo la ip del servidor master
y después les transfieron la copia de la zona a ellos para allá arriba.
Hasta ahi todo bien, pero resulta que son una pelota de empresas y al
parecer los de la habana se han cansado, de esas pinchitas y me han
pedido, que yo en mi servidor me encargue de la zona (pri.dominio.cu) y
todas aquellas empresas donde yo vaya a realizar cambios, que al final
van a ser siempre un subdominio de (pri.dominio.cu) que configure todo
dentro de mi zona, y asi cuando les transfiera a ellos para allá arriba,
ya no tengo que estar llamandolos para que hagan los cambios en los DNS
nacionales, al menos no en los internos, lo que estan de cara a internet
es otra historia...
Entonces, he realizado este configuración:
En /etc/bind/named.conf.local tengo esto:
zone "pri.dominio.cu" {
type master;
file "/var/cache/bind/pri.dominio.cu";
allow-transfer { 192.168.250.1; 192.168.250.2; 192.168.5.3; };
notify yes;
};
zone "5.168.192.in-addr.arpa" {
type master;
file "/var/cache/bind/5.168.192.in-addr.arpa";
allow-transfer { 192.168.250.1; 192.168.250.2; 192.168.5.3; };
notify yes;
};
Como ven hago transferencia de zonas a 3 IP, los 2 primeros los DNS
nacionales, y el 3ro es el DNS secundario mio (el externo)
En el fichero de la zona (la directa) he puesto algo como esto en:
/var/cache/bind/pri.dominio.cu
Aqui hay 2 ejemplos para 2 empresas, llamadas emp1 y emp2 para las
cuales tienen los bloques ip 192.168.1.0/24 y 192.168.2.0/24
respectivamente.
##
$ORIGIN pri.dominio.cu.
$TTL 3600 ; 1 hour default TTL
@ IN SOA ns1.pri.dominio.cu.
postmaster.pri.dominio.cu. (
2019031810 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
300 ; Negative Response TTL
)
; DNS Servers
@ IN NS ns1.pri.dominio.cu.
@ IN NS ns2.pri.dominio.cu.
; MX Servers
@ IN MX 10
mx1.pri.dominio.cu.
; Machine Names
ns1 IN A 192.168.5.2
ns2 IN A 192.168.5.3
mx1 IN A 192.168.5.4
jabber IN A 192.168.5.5
; Aliases
$ORIGIN _tcp.pri.dominio.cu.
$TTL 3600 ; 1 hour
_jabber IN SRV 5 0 5269
jabber.pri.dominio.cu.
_xmpp-client IN SRV 5 0 5222
jabber.pri.dominio.cu.
_xmpp-client IN SRV 5 0 5223
jabber.pri.dominio.cu.
_xmpp-server IN SRV 5 0 5269
jabber.pri.dominio.cu.
; Subdominios de Empresas en el Territorio
;
; Empresa #1
$ORIGIN emp1.pri.dominio.cu.
;$TTL 3600 ; 1 hours
; NS Record
@
