> -----Original Message-----
> From: GRIDPP2: Deployment and support of SRM and local storage
> On 2 July 2010 14:57, Ewan MacMahon <[log in to unmask]>
> wrote:
> >
> > Which of user banning and fast drain needs a schema change, and why?
>
> User banning will need a schema change.
> Originally, it was planned to make this schema change at the same time
> as the schema change for quotas, but if people wanted user banning
> "early", this would add one to the schema changes needed.
> AFAIK, the change is simply to extend the current dpns user table with
> a column for "is the dn mapped to this banned" or similar.
>
Yuck. That's just plain nasty, and certainly not worth a schema change
over. The authorisation decisions should be made by calling out to
something else to make the decision at the time a user makes a request.
In the short term that 'something' could be nothing more complicated
than a script that looks through a list of banned DNs, but putting it
in the db is just wrong on every level. It should never happen, never
mind 'early'.
> Incidentally, re: ARGUS - any "early" user banning implementation
> would be a by-hand administered system. The originally planned
> user-banning system would, instead, be integrated into ARGUS support
> as you desire.
>
Right, at which point the schema change for the short term hack would
be redundant.
> So, the choice is really:
>
> fast dpm-drain (and ARGUS-integrated user banning with a single schema
> change later)
>
> manual user banning (and fast dpm-drain later)
>
So, option 'A' sounds actually useful in the short term and tasteful
design in the long term, and option 'B' sounds like deferring the
useful thing in favour of replacing an existing awkward hack with
a new and different awkward hack, AND going through a schema change
for the privilege.
So, in a nutshell - fast drain please.
Ewan
|