Bug 1614

Ouch! Xavier asked me to point the download1 DNS entry to another server since the real one has been down for a few days. That other server (of mine) has all of the files and the same FTP path, but seems to lack some configuration :
 * The http virtualhost for those paths doesn't exist (I'll create it now)
 * The rsync modules for mirroring don't exist (I'll check and try to create those too)

Seems to work OK now. Thanks!

*** Bug 1613 has been marked as a duplicate of this bug. ***

(In reply to comment #1)
> Ouch! Xavier asked me to point the download1 DNS entry to another server since
> the real one has been down for a few days. 

I could ssh into the real one earlier today; could somebody confirm it's up and running properly and switch the dns back? Or give me ssh access to the temporary server? 

Without a solutions like those I can't push new packages and thus not fix bug 1618 :-/

I can access the servers now, it looks like it's fixed.

I'm confused... the server I've pointed download1 to is actually accessing the exact same tree of files than most of the other servers/services, of which plague itself. So anything pushed should be available immediately.

Also, 193.28.235.60 is the "normal" download1 and is still not answering ping or http...

(In reply to comment #6)
> I'm confused... the server I've pointed download1 to is actually accessing the
> exact same tree of files than most of the other servers/services, of which
> plague itself. So anything pushed should be available immediately.
 
Now I'm confused...

"Pushed" in the past meant: A local, private master tree on se03 is populated with the push scrpts and then rsynced to download1.rpmfusion.org; all the other mirrors and the public got the content from there.

Your words would make sense if what's available via download1.rpmfusion.org right now is the content that can be found in a subdirectory on the machine se03 (e.g. the one that was normally rsynced out when ready). Is that the case?

> Also, 193.28.235.60 is the "normal" download1 and is still not answering ping
> or http...

I'll ask Pix what's up. 

(In reply to comment #7)
> Your words would make sense if what's available via download1.rpmfusion.org
> right now is the content that can be found in a subdirectory on the machine
> se03 (e.g. the one that was normally rsynced out when ready). Is that the case?

That should be the case : The http service serving "download1" temporarily is running on the machine which is the nfs server for se03. I've also enabled an rsync service there, with a public "rpmfusion" module pointing to /var/ftp/pub/rpmfusion since I got a report from a mirror which was unable to sync following the DNS change.

I thought I mentioned it somewhere in Bugzilla already, but can't find it right now. So here it is again: 

The original download1.rpmfusion.org from Pix is online again since weeks; someone should decide if we switch back or if we use both servers in the future to improve reliability and spread the load the load a bit.

Aha, good to know! Especially since the server to which I had pointed download1 is on an obsolete platform, where I'm trying to lower every little bit of bandwidth usage in order to kill it off at some point :-)

I've pointed download1 back to the 193.28.235.60 address. The other server is still available in case of problems, and I'll make sure it stays like that at least until another one is ready to take over.

Great :) But is my repo sync'd ? or i should mirror from the Matthias' host ?

(In reply to comment #11)
> Great :) But is my repo sync'd ?
Yes, it is.

If your server/repo is like before, then all should be fine : On my end nothing
was changed for the temporary situation regarding rsync and server config, only
the name was pointed to the main existing file server where the buildsys was
already storing all the files and other servers syncing from.