[Gutl-l] Re: zeroshell
Man no pierdas el tiempo monta pfsense. En 12 de julio de 2019 4:45:04 p. m. "Informatica" escribió: Alguien tiene conocimiento de este soft -- ___ 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] zeroshell
Zeroshell alguien que me ayude con esto ___ Gutl-l mailing list -- gutl-l@listas.jovenclub.cu To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu
[Gutl-l] zeroshell
Alguien tiene conocimiento de este soft ___ Gutl-l mailing list -- gutl-l@listas.jovenclub.cu To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu
[Gutl-l] Re: Como reparar contenedor proxmox?
El viernes, 12 de julio de 2019 15:46:10 CDT Jose J. Rodriguez escribieron: > On Fri, Jul 12, 2019 at 2:58 PM Rommel Rodriguez Toirac > wrote: > > > > > > > Mis saludos; > > > > tengo Proxmox 5.4 con contenedores lxc, en su mayoría CentOS 7 > > actualizados. > > > Uno de ellos tiene instalado samba 4 con bind_dlz como servidor DNS. > > Me está sucediendo que cuando hago una salva de ese contenedor, todo > > funciona > > > bien; pero cuando estoy intentando realizar una restaura de ese > > contenedor, me da error. > > > > > > > > ¿Me dan una idea de qué pudiera estar sucediendo y/o como poder > > repararlo? > > > > > > > Este tipo de errores puede ser porque el contenedor no es un > "Unprivileged container" (traducción: contenedor no privilegiado), > mientras que en versiones recientes del Proxmox, ésa es la opción por > defecto al crear o restaurar un contenedor. Prueba a desmarcar esta > opción cuando vayas a restaurar. > > Saludos, > Joe1962 > ___ Gracias Joe1962, haciendo eso que me sugieres extrajo el contenedor sin problemas. No he probado si funcionan todos los servicios sin problemas pero al menos se que lo extrajo. -- Rommel Rodriguez Toirac rommel.rodrig...@gtm.onat.gob.cu Teléfono: 21327444 ext 120 ___ Gutl-l mailing list -- gutl-l@listas.jovenclub.cu To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu
[Gutl-l] Re: Como reparar contenedor proxmox?
On Fri, Jul 12, 2019 at 2:58 PM Rommel Rodriguez Toirac wrote: > > Mis saludos; > tengo Proxmox 5.4 con contenedores lxc, en su mayoría CentOS 7 actualizados. > Uno de ellos tiene instalado samba 4 con bind_dlz como servidor DNS. > Me está sucediendo que cuando hago una salva de ese contenedor, todo funciona > bien; pero cuando estoy intentando realizar una restaura de ese contenedor, me > da error. > > ¿Me dan una idea de qué pudiera estar sucediendo y/o como poder repararlo? > Este tipo de errores puede ser porque el contenedor no es un "Unprivileged container" (traducción: contenedor no privilegiado), mientras que en versiones recientes del Proxmox, ésa es la opción por defecto al crear o restaurar un contenedor. Prueba a desmarcar esta opción cuando vayas a restaurar. Saludos, Joe1962 ___ Gutl-l mailing list -- gutl-l@listas.jovenclub.cu To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu
[Gutl-l] Como reparar contenedor proxmox?
Mis saludos;
tengo Proxmox 5.4 con contenedores lxc, en su mayoría CentOS 7 actualizados.
Uno de ellos tiene instalado samba 4 con bind_dlz como servidor DNS.
Me está sucediendo que cuando hago una salva de ese contenedor, todo funciona
bien; pero cuando estoy intentando realizar una restaura de ese contenedor, me
da error.
¿Me dan una idea de qué pudiera estar sucediendo y/o como poder repararlo?
Esta es la secuencia de trazas que me deja al realizar la restaura desde el
ambiente gráfico:
Using default stripesize 64.00 KiB.
Logical volume "vm-106-disk-0" created.
mke2fs 1.43.4 (31-Jan-2017)
Discarding device blocks: 4096/20971520 done
Creating filesystem with 20971520 4k blocks and 5242880 inodes
Filesystem UUID: ea8d69f7-41ce-4d8e-b6d0-38622db7fc0f
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 2048
Allocating group tables: 0/640 done
Writing inode tables: 0/640 done
Creating journal (131072 blocks): done
Multiple mount protection is enabled with update interval 5 seconds.
Writing superblocks and filesystem accounting information: 0/640 done
extracting archive '/var/lib/vz/dump/vzdump-
lxc-100-2019_07_12-11_05_30.tar.lzo'
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{6AC1786C-016F-11D2-945F-00C04FB984F9}/GPT.INI: Cannot change ownership to uid
308, gid 308: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{6AC1786C-016F-11D2-945F-00C04FB984F9}/USER: Cannot change ownership to uid
308, gid 308: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{6AC1786C-016F-11D2-945F-00C04FB984F9}/MACHINE: Cannot change ownership to uid
308, gid 308: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{6AC1786C-016F-11D2-945F-00C04FB984F9}: Cannot change ownership to uid
308, gid 308: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI: Cannot change ownership to uid
308, gid 308: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/USER/Registry.pol: Cannot change
ownership to uid 300, gid 100: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/USER/Documents & Settings: Cannot
change ownership to uid 300, gid 100: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/USER/MICROSOFT/IEAK: Cannot change
ownership to uid 300, gid 100: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/USER/MICROSOFT: Cannot change ownership
to uid 300, gid 100: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/USER/Scripts/Logon: Cannot change
ownership to uid 300, gid 100: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/USER/Scripts/Logoff: Cannot change
ownership to uid 300, gid 100: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/USER/Scripts: Cannot change ownership
to uid 300, gid 100: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/USER/Applications: Cannot change
ownership to uid 300, gid 100: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/USER: Cannot change ownership to uid
308, gid 308: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/MACHINE/Registry.pol: Cannot change
ownership to uid 300, gid 100: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/MACHINE/Scripts/scripts.ini: Cannot
change ownership to uid 300, gid 100: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/MACHINE/Scripts/Startup/OcsPackage.exe:
Cannot change ownership to uid 300, gid 100: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/MACHINE/Scripts/Startup: Cannot change
ownership to uid 300, gid 100: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/MACHINE/Scripts/Shutdown: Cannot change
ownership to uid 300, gid 100: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/MACHINE/Scripts: Cannot change
ownership to uid 300, gid 100: Invalid argument
tar: ./var/lib/samba/sysvol/gtm.onat.gob.cu/Policies/
{31B2F340-016D-11D2-945F-00C04FB984F9}/MACHINE/Microsoft/Windows NT/SecEdit/
GptTmpl.inf: Cannot change ownership
[Gutl-l] Re: creando escenario virtual del dns para que entre servidores openfire puedan conectarse
ok, ya habia pensado en esa posibilidad, que en el nodo central deben estar declarado los server provinciales, incluso le puse un ejemplo de como declararlo. hace ya un tiempo en el palacio de computacion pase un curso basico de administracion en linux de una semana de duración, donde cogimos en un laboratorio 3 computadoras, las instalamos desde cero con debian 4 (dns-apache, correo-openfire y un firewall)y recreamos un escenario virtual de una red x donde existia un nodo central y varios subnodos y se configuro de tal forma que los subnodos interactuaban con el nodo central en todos los servicios implementados, incluso aún conservo la documentacion digital para la configuracion de los dns tanto en el nodo central como en los subnodos, fué algo muy instructivo a la vez novedoso y me sirvió de base . entonces pudieramos decir que la solucion del problema esta en el nodo central donde deben declararce los server provinciales¿? si es asi contactaré con el admin nacional y le preguntaré. ok hermano, gracias de todas formas. - Mensaje original - De: "Arian Molina Aguilera" Para: gutl-l@listas.jovenclub.cu Enviados: Viernes, 12 de Julio 2019 7:37:02 Asunto: [Gutl-l] Re: creando escenario virtual del dns para que entre servidores openfire puedan conectarse El 12/7/19 a las 9:03, SAD escribió: > Arian. > supongamos que estoy en una vpn para todas los nodos provinciales donde el > servidor central con su dns tiene esta ip:192.168.10.2/24 y cuando uno le > pregunta por jabber.comones.cu el me responde y los demas nodos son por > ejemplo el mio 192.168.10.130 masq:255.255.255.248, como pudiera configurar > mi server para que viera y resolviera a otros server que estan en el rango de > la vpn. > le pregunto porque yo puedo resolver hacia el nodo central y cuando intento > resolver hacia otro servidor desde el mio que está en 192.168.10.130 , este > no me resuelve, ejemplo si pregunto por: > dig @granma.comones.cu y este servidor tiene la ip:192.168.10.122 con > masq:255.255.255.248 > > me seria de gran utilidad que me ayudara si es posible. > el server de granma.comones.cu yo lo monté y este tambien resuelve > jabber.comones.cu y el firewall no esta configurado, yo comparto una carpeta > en granma y en stgo la veo y viceversa. mas adelante le daré la respectiva > seguridad. > ¿existe la posibilidad de que granma.comones.cu resuelva a stgo.comones.cu > sin tener que pasar por comones.cu? > > * > eso no tiene nada que ver. tu openfire funciona,. pues bien ahora solo > queda resolver el dns, y comunicarse con el otro sitio de la otra zona. > Para eso deben tener un servidor central en el nodo, con todas las zonas de domino de su vpn, es decir los subdominios, estás zonas podrían ser de tipo esclava o forward. si son de tipo esclava, todos los subnodos, deben tener configurado su servidor de dns con su respectiva zona como master, y estas replicar al servidor del nodos central donde funciona un servidos con la zonas slaves, igualmente si son configuradas de tipo forward, cada servidor de los subnodos mantienen como master su zona, pero el servidor del nodo reenviaría la solicitud de resolución a dichos servidores una vez que hagan una consulta, y no se necesitaría replicar las zonas al nodo central. Me va entendiendo. Otro caso sería que cada servidor de dns en su vpn, conociera cual es la zona de los demás dominios, entonces configuraría este forward en cada uno para consultar por el resto de los dominios de la vpn que no son conocidas por el servidor del nodo central. Esto daría respuesta a su pregunta. ¿existe la posibilidad de que granma.comones.cu resuelva a stgo.comones.cu sin tener que pasar por comones.cu? Solo tendría configurar su respectivo forward para desde granma.comones.cu resolver stgo.comones.cu y viceversa. -- Arian Molina Aguilera Administrador de Redes y Servicios Telemáticos Linux Usuario Registrado #392892 Telfs: +53(7)696-7510 ext 236 jabber: linuxc...@teknik.io Brascuba Cigarrillos S.A. La Habana. Cuba. “Nunca consideres el estudio como una obligación, sino como una oportunidad para penetrar en el bello y maravilloso mundo del saber. Albert Einstein” ___ Gutl-l mailing list -- gutl-l@listas.jovenclub.cu To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu -- EMPRESA AGROPECUARIA MILITAR SANTIAGO DE CUBA Direccion Empresa: direcc...@scuba.uam.cu Comunicaciones Informatica: comunicacio...@scuba.uam.cu telefonos: Puesto Mando 22609724-22609314-22609320 ext 101 Comunicaciones 22609702 ___ Gutl-l mailing list -- gutl-l@listas.jovenclub.cu To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu
[Gutl-l] Re: creando escenario virtual del dns para que entre servidores openfire puedan conectarse
El 12/7/19 a las 9:03, SAD escribió: > Arian. > supongamos que estoy en una vpn para todas los nodos provinciales donde el > servidor central con su dns tiene esta ip:192.168.10.2/24 y cuando uno le > pregunta por jabber.comones.cu el me responde y los demas nodos son por > ejemplo el mio 192.168.10.130 masq:255.255.255.248, como pudiera configurar > mi server para que viera y resolviera a otros server que estan en el rango de > la vpn. > le pregunto porque yo puedo resolver hacia el nodo central y cuando intento > resolver hacia otro servidor desde el mio que está en 192.168.10.130 , este > no me resuelve, ejemplo si pregunto por: > dig @granma.comones.cu y este servidor tiene la ip:192.168.10.122 con > masq:255.255.255.248 > > me seria de gran utilidad que me ayudara si es posible. > el server de granma.comones.cu yo lo monté y este tambien resuelve > jabber.comones.cu y el firewall no esta configurado, yo comparto una carpeta > en granma y en stgo la veo y viceversa. mas adelante le daré la respectiva > seguridad. > ¿existe la posibilidad de que granma.comones.cu resuelva a stgo.comones.cu > sin tener que pasar por comones.cu? > > * > eso no tiene nada que ver. tu openfire funciona,. pues bien ahora solo > queda resolver el dns, y comunicarse con el otro sitio de la otra zona. > Para eso deben tener un servidor central en el nodo, con todas las zonas de domino de su vpn, es decir los subdominios, estás zonas podrían ser de tipo esclava o forward. si son de tipo esclava, todos los subnodos, deben tener configurado su servidor de dns con su respectiva zona como master, y estas replicar al servidor del nodos central donde funciona un servidos con la zonas slaves, igualmente si son configuradas de tipo forward, cada servidor de los subnodos mantienen como master su zona, pero el servidor del nodo reenviaría la solicitud de resolución a dichos servidores una vez que hagan una consulta, y no se necesitaría replicar las zonas al nodo central. Me va entendiendo. Otro caso sería que cada servidor de dns en su vpn, conociera cual es la zona de los demás dominios, entonces configuraría este forward en cada uno para consultar por el resto de los dominios de la vpn que no son conocidas por el servidor del nodo central. Esto daría respuesta a su pregunta. ¿existe la posibilidad de que granma.comones.cu resuelva a stgo.comones.cu sin tener que pasar por comones.cu? Solo tendría configurar su respectivo forward para desde granma.comones.cu resolver stgo.comones.cu y viceversa. -- Arian Molina Aguilera Administrador de Redes y Servicios Telemáticos Linux Usuario Registrado #392892 Telfs: +53(7)696-7510 ext 236 jabber: linuxc...@teknik.io Brascuba Cigarrillos S.A. La Habana. Cuba. “Nunca consideres el estudio como una obligación, sino como una oportunidad para penetrar en el bello y maravilloso mundo del saber. Albert Einstein” signature.asc Description: OpenPGP digital signature ___ Gutl-l mailing list -- gutl-l@listas.jovenclub.cu To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu
