[Savannah-hackers-public] Re: [gnu.org #249111] project.nongnu.org webpages - issue with cvs.nongnu.org

[Sylvain Beucler via RT]

Hello,

http://cvs.nongnu.org/
fails with a 404 error:
---
Not Found
The requested URL /cvs/cvs.html was not found on this server.

Apache/1.3.31 Server at www.nongnu.org Port 80
---

http://archway.nongnu.org still works.

To support my point that volunteer and hired people's job can be
efficiently complementary, that's something I could have checked,
fixed and/or tested with week-end :)

-- 
Sylvain


On Wed, Aug 17, 2005 at 12:50:59AM +0200, Sylvain Beucler wrote:
> On Mon, Aug 15, 2005 at 10:23:41AM -0400, Justin Baugh via RT wrote:
> > > What are the drawbacks of wildcards DNS entries? As far as I saw
> > > specified entries are always prioritary.
> > 
> > They're generally thought to being prone to abuse by spammers, however: 
> 
> Would you mind telling me more about this? We're not providing
> wildcard MX records, and I don't see the advantage abusing
> non_existent.nongnu.org over abusing www.nongnu.org :/
> 
> > > Btw, that's what is apparently used at SourceForge:
> > > http://qsdfqsdfqsdfqsdf.sourceforge.net/
> > 
> > I've gone ahead and set up this wildcard entry. I'd still like to
> > consider doing this in a different way (below).
> > 
> > > Hmm, that means communicating that list from Savannah to nongnu.org.
> > > 
> > > The way Savane shares data between machines is to offer limited access
> > > to the database, but Jim was not a fan of MySQL remote TCP
> > > access. What's your point on this?
> > 
> > I'm not a fan of it unless there's a very compelling reason to do so.
> 
> Well as I said the SourceForge (and clones) model rely on sharing a
> central database containing user and project information among
> distinct systems. Thinking differently will bring work to maintain
> patches against Savane.
> 
> What is the difference between your proposal and accessing the DB?
> Theoretically, both run a service at Savannah, both use SSL and client
> authentication via public key, both can be configured to prevent root
> access (to the DB or to the system). MySQL is actually even a less
> privileged process.
> 
> 
> > > Usually when we develop new feature we try to do so in reusable ways
> > > that could be integrated in Savane, so please don't suggest something
> > > too much awkard ;) Aside from that I'm open to suggestions. The other
> > > way that comes to mind would be to offer a web service at nongnu.org
> > > to put the project list.
> > 
> > The way I might do this is to have an SSH key which can only run a
> > script on Savannah for the purpose of dumping out a list of projects.
> > Then that script could write out a new zone file, if necessary, and
> > reload bind. Sound reasonable?
> 
> Hmmm, I like sharing the DB for its simplicity and its integration in
> the model described above, and the notion of webservice for its
> real-time and system-load-reducing potential (keeping in mind we
> create around 1 project per day).
> 
> This solution offers neither advantages :/ So I'd rather work on one
> of the two I originaly proposed.
> 
> 
> Btw, I just realize that you actually already have the list on
> gnu.org: it's /path/to/www.nongnu.org/*. The drawback is that the list
> currently doesn't know about project deletion or webpage
> desactivation, which doesn't look much of a problem for the webpage
> replication process.
> 
> 
> To answer your other question, 'unix_group_name' in table 'groups' is
> indeed the one to look at, with status 'A', group type (type) allowing
> webpage (currently all, though that _might_ change), group
> configuration allowing webpages as well (use_homepage), with a project
> page at www.nongnu.org/* (which excludes GNU projects and projects
> that use another host for their webpages) :)
> 
> This might be simplified in a first step ;)
> 
> -- 
> Sylvain