[OpenAFS-devel] Moving Forwards

[Troy Benjegerdes]

I am attempting an import of my OpenAFS mercurial repository
(which was cloned from the openafs.org git tree) into Bitbucket

https://bitbucket.org/dahozer/openafs

It will either work, or I'll probably end up with some very interesting
conversations with Atlassian support people.

(I'm also waiting on a vos move of the original read-write volume that
is on the wrong side of a DSL connection that contains the source for
http://bitspjoule.org/hg/openafs, so I can then update it with the 
latest code from git)

I would also appreciate some opinion, at least on the mailing list, to
confirm my belief that it is perfectly acceptable under the OpenAFS 
license and IBM's trademarks for me to have a clone of the repository.

I intend to fork OpenAFS and rename it TFS (or maybe CFS.. cloud FS)
to facilitate getting a working implementation that uses AES crypto
and IPv6, which can then be submitted to afs3-std, and then eventually
incorporated under the OpenAFS trademark.



As for flag days and standards compliance... I'm already screwed on
my own cell. I upgraded one of my kdcs and left out 3des support, so
I've got a flag day to deal with anyway, and when my old backup kdc
goes down, I can't authenticate. I don't really want to downgrade, 
so it seems like a full-on fork of the code is the only 'upgrade' 
path I have.

If someone can solve this mess for me, and wants to set up a hosted
kerberos + AFS cloud storage solution, I'd happily pay a reasonable
monthly fee. Think about what a small/medium business would pay for 
this. 

At the moment, I am aware of no such service, so I'm stuck in the 
position of inventing it.



On Sun, Sep 09, 2012 at 04:55:34PM +0100, Simon Wilkinson wrote:
> 
> On 9 Sep 2012, at 15:42, Jeffrey Altman wrote:
> > OpenAFS RT and the wiki used to be much more open.   The reason they
> > were locked down years ago is because the quantity of spam and defacing
> > became overwhelming.  
> 
> I don't think this is correct. The wiki is as open as it ever was. When we were using TWiki, hosted on dementia.org, we allowed self registration, which led to lots of spam. For a while, we added an 'approval' requirement, where Derrick would enable each genuine new account. When we moved over to ikiwiki, we enabled self registration again (for those with valid OpenID accounts). This has led to an unfortunate increase in the incidence of spam, but to my knowledge, we haven't yet disabled self registration there.
> 
> Since I started contributing to OpenAFS, RT has always been locked down in terms of who can comment and manipulate tickets. We have talked on a number of occassions about relaxing access but this has always stalled on either a concrete proposal of who should have access (which I believe I have now provided - whoever wants access), and on the availability of someone to do the work to implement a self registration mechanism that is spam resistant.
> 
> > must ensure that anonymous accounts cannot be
> > used to easily generate false tickets or deface existing ones.
> 
> In terms of ticket generation, this is a red herring. Anonymous users can generate false tickets simply by mailing the openafs-bugs address. I doubt that opening the system up will lead to more spam than we already see through that conduit.
> 
> I agree that we want to avoid the defacing of existing tickets. The proposal of giving access to anyone who subscribes to openafs-devel seems like a good one, if we can make it work in practice.
> 
> If Chaskiel or Jeffrey don't have the time or inclination to help us change the configuration of rt.central.org (which might be complicated because it provides RT to other users as well), we do always have the option of hosting an OpenAFS RT on openafs.stanford.edu.
>