Thread: Moving services to a new server / IP ...

In order to deal with the DDoS attacks that have been hitting one of our
clients, we've just setup a US based server that offers DDoS filtering
(not sure how they are doing it, but apparently they've been effective in
the past) ... the server that we are moving the client to has 700GB of
available bandwidth on it, and his VM uses <30GB of it ...

First thing we're going to be doing is setting up redundant DNS on that
machine, replicated from the main server (we use bind-dlz for DNS), so in
case of problems in the future, we'll be able to relatively easily change
DNS around ...

Second thing is we're going to build a VM on the machine that we're going
to rsync a bunch of stuff over to, to offload it from the servers in
Panama ... masters will remain there, all that will be on the US server
will be mirrors ...

Dave and I just chatted, and came up with the following as easy things to
move across:

    ftp.postgresql.org (which also means I'll be able to open it up a
                            bit more for # of connections and speed)
    anoncvs.postgresql.org
    rsync.postgresql.org
        - this is where mirrors will connect to to update
                  themselves, and will itself be updated hourly
    bt.postgresql.org

Basically, those things that are not database dependent ... we had thought
about www.postgresql.org, but there are just too many database
dependencies on it ... *but* ... with DNS on that server also, if the
Panama network goes down, its a simple update on the SQL database on the
US server to change www.postgresql.org to point at rsync.postgresql.org
for the duration ...

Is there anything else that doesn't have any database dependencies that
could be easily mirrored, that we're not thinking of?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

It's rumoured that Marc G. Fournier once said:
> !
>
> rsync.postgresql.org
> - this is where mirrors will
> connect to to update

On further thought we cannot move rsync because the mirror tracking code
needs db access (as does the rsync access control stuff) :-(
Regards, Dave

On Mon, 5 Apr 2004, Dave Page wrote:

> It's rumoured that Marc G. Fournier once said:
> > !
> >
> > rsync.postgresql.org
> > - this is where mirrors will
> > connect to to update
>
> On further thought we cannot move rsync because the mirror tracking code
> needs db access (as does the rsync access control stuff) :-(

True, but all that means is that the script to do the updates just needs
to copy over the appropriate rsyncd.conf file that gets generated, no?
That is, I believe, the only part that is database driven?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

> -----Original Message-----
> From: Marc G. Fournier [mailto:scrappy@postgresql.org]
> Sent: 05 April 2004 15:14
> To: Dave Page
> Cc: scrappy@postgresql.org; pgsql-www@postgresql.org;
> pgsql-core@postgresql.org
> Subject: Re: [pgsql-www] Moving services to a new server / IP ...
>
> True, but all that means is that the script to do the updates
> just needs to copy over the appropriate rsyncd.conf file that
> gets generated, no?
> That is, I believe, the only part that is database driven?

No, there is a C prog that periodically scans the rsync logfile and sets
the last sync timestamp in the DB based on when it sees connections from
the mirrors. That's how we keep track of which mirrors are up to date.

Regards, Dave

On Mon, 5 Apr 2004, Dave Page wrote:

>
>
> > -----Original Message-----
> > From: Marc G. Fournier [mailto:scrappy@postgresql.org]
> > Sent: 05 April 2004 15:14
> > To: Dave Page
> > Cc: scrappy@postgresql.org; pgsql-www@postgresql.org;
> > pgsql-core@postgresql.org
> > Subject: Re: [pgsql-www] Moving services to a new server / IP ...
> >
> > True, but all that means is that the script to do the updates
> > just needs to copy over the appropriate rsyncd.conf file that
> > gets generated, no?
> > That is, I believe, the only part that is database driven?
>
> No, there is a C prog that periodically scans the rsync logfile and sets
> the last sync timestamp in the DB based on when it sees connections from
> the mirrors. That's how we keep track of which mirrors are up to date.

'k, and the buildsite builds a hard copy of mirror-ftp.html, correct?
ohhhh, now I understand what you are getting at ... how periodic is that
C program run?  Its something that could run remotely as long as the IP
of the remote VM is allowed to connect to the database, right?



----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

It's rumoured that Marc G. Fournier once said:
> On Mon, 5 Apr 2004, Dave Page wrote:
>
> 'k, and the buildsite builds a hard copy of mirror-ftp.html, correct?
> ohhhh, now I understand what you are getting at ... how periodic is
> that C program run?  Its something that could run remotely as long as
> the IP of the remote VM is allowed to connect to the database, right?

It runs hourly, and yes, it could run remotely. It simply runs a bunch of
update queries so there isn't a great deal of data transferred. It's in
/usr/local/rsync-mgr (or something like that) if you wanna take a look. Be
warned though, it's not nice - I take solace in the knowledge that I
wasn't responsible for it!
Regards, Dave.