Mailing-List: contact repository-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: repository@apache.org
Received-SPF: pass (athena.apache.org: domain of carlossg@gmail.com designates
 64.233.166.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=Xoj5glLHeC6tezUnPTQbMHuxmZfgG3/Jh+MSMkOvzFhTFCvtcSWNdQiBbFoYMZlApUIFx9Nw8CeAOdmu3xbMYMLhGEmR7siU4LYCUwIPf6ZEHW+txNp7kHBpqEhIUGonFQHwfjHeSdJanTWOYh/93Gh1mDmLswmptv7jATB4gHI=
Message-ID: <1a5b6c410708230253s44f96aa7mefec4e91860acd65@mail.gmail.com>
Date: Thu, 23 Aug 2007 11:53:40 +0200
From: "Carlos Sanchez" <carlos@apache.org>
Sender: carlossg@gmail.com
To: repository@apache.org
Subject: Re: fix-permissions.sh and sudo
Cc: "Infrastructure Apache" <infrastructure@apache.org>
In-Reply-To: <5a75db780708221445m7d1c99e5u4ce6717559a3ed8b@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <D2124E81-3B70-49FC-B5EE-926682D32C72@visi.com>
	 <1a5b6c410708221224v4e1b5c8fgc72a42931299c1c2@mail.gmail.com>
	 <5a75db780708221445m7d1c99e5u4ce6717559a3ed8b@mail.gmail.com>

it's users misconfiguration of their deployment settings in maven

On 8/22/07, Luciano Resende <luckbr1975@gmail.com> wrote:
> Stepping back a little, what's the cause for the problem that requires
> us to have the fix-permission.sh in place ? Is this a maven bug or a
> maven misconfiguration, that does not set the right permissions when
> artifacts are deployed ?
>
> On 8/22/07, Carlos Sanchez <carlos@apache.org> wrote:
> > why then not just add it to cron?
> >
> > On 8/22/07, David Blevins <david.blevins@visi.com> wrote:
> > > I'm not sure if this is the right list for this, so feel free to move
> > > it to one or the other.
> > >
> > > I think we should sudo enable the fix-permission.sh[1] script as
> > > running this script is something a monkey could do, so why not have
> > > the monkey trying to deploy something do that work.  It pains me to
> > > have to bug Joe or someone else root enabled to do such trival things.
> > >
> > > I'm willing to put some work into this and am asking for feedback.
> > > Namely, who should be able to run this script and on which parts of
> > > the snapshot repo?
> > >
> > > IMHO, anyone should be able to run it on any part of the snapshot
> > > repo and we can just leave it on people's honor to stick to areas
> > > they know.  Alone those lines we could simply cripple the script so
> > > it can't run on org/apache preventing any mistakes -- not that there
> > > would be any real consequences to those mistakes.
> > >
> > > Most people just move the offending directory aside and deploy their
> > > stuff anyway when they find something a peer had deployed with
> > > default perms which do not allow anyone else but them to write.  Of
> > > course then someone with root has to go and clean up the "backed up"
> > > directory and as well the project looses any previously deployed snaps.
> > >
> > > Seems if we sudo enabled the fix-permissions.sh we could allow people
> > > to do what they are already doing, but more appropriately and without
> > > bugging a root.
> > >
> > > Thoughts?
> > >
> > > -David
> > >
> > > [1] /www/people.apache.org/repo/m2-snapshot-repository/fix-
> > > permissions.sh
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                              -- The Princess Bride
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride