:: Re: [devuan-dev] Status of my actio…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: KatolaZ
Fecha:  
A: devuan-dev
Asunto: Re: [devuan-dev] Status of my action points
On Tue, Aug 01, 2017 at 06:03:03PM +0200, Jaromil wrote:
> On Mon, 31 Jul 2017, Daniel Reurich wrote:
>
> > Sure... but we don't appear to have any on the new server yet....
> > Better bug jaromil about getting that block of 16
>
> there is a 16th block on the new server and an extra ip on the old,
> but the extra ip on the old does not ping.
>
> do you have any idea what is happening?
>
> also can you or others outline what are the blockers to proceed with
> an installation of the new server, keeping in mind if should be
> incrementally tooled, rather than overcommitting to an effort on which
> we cannot follow up within the current time costraints.
>


In this respect, I have already setup the VM for amprolla3 and for the
mirror server. parazyd has already installed amprolla3 on that VM, and
we might be ready to test the rsync server soon (I am very busy with a
thing at work that I must finish by tomorrow morning, but after that I
am on it).

However, I am stuck again.

The first reason is the problem with the FO IP mentioned by jaromil
above. I am sure this can be solved soon. I simply tried to assign the
failover IP to one of the vms (replicating the same configuration we
have for the gitlab machine, modulo the actual FO IP), but it does not
ping. There might be something wrong but I can't see it.

The second reason is more fundamental. I had the impression that we
wanted to have a dmz where to put vms for external services, so that
all the public IPs could be routed by a VM acting as a
firewall. However, Centurion_Dan now seems convinced that the physical
machine should do the routing (and the firewalling).

I think this is not a good idea, and I am not sure about how this
plays with ganeti failover procedures. I guess that having two
identical fw VMs (one on each ganeti node) would be the best option,
since upon failover we would simply need to route the external IPs to
the mac of the new master, and everything will be already working. If
instead we go for managing routing on the physical machine, we need to
setup all the fw rules on the new master node, which might be a bit of
a burden.

Since we are now again blocked on this point, I think we must clarify
these issues and proceed as soon as possible.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[     "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[       @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[     @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]