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

[Sylvain Beucler]

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