Re: git-archive and tar options

[Neal Kreitzinger <nkreitzinger@gmail.com>]

On 7/20/2011 9:13 PM, Neal Kreitzinger wrote:
> On 7/19/2011 12:56 PM, René Scharfe wrote:
>> Am 19.07.2011 02:12, schrieb Neal Kreitzinger:
>>> On 7/18/2011 3:50 PM, René Scharfe wrote:
>>>> Am 18.07.2011 20:13, schrieb Neal Kreitzinger:
>>>>> However, the permissions also need to change to 777 and tar
>>>>> --mode would not effect this in combination with --catenation
>>>>> or -x. Is there a way I can change the permissions without
>>>>> having to untar->chmod->retar, and without having to use a
>>>>> non-bare repo as an intermediary?
>>>> You can use the configuration setting tar.umask to affect the
>>>> permissions of the archive entries. Set it to 0 to pass the
>>>> permission bits from the repo unchanged.
>>>>
>>> The permissions in my repo are 775 and 664 and I want to change
>>> them to 777.
>> Git doesn't store all permission bits. If a file is marked as
>> executable then you get 777, otherwise 666 -- minus the umask,
>> which is 0002 by default. So in order to achive rwx permissions for
>> all in the archive, you need to A) mark the files as executable in
>> the repository and B) set tar.umask to 0 to get allow the world to
>> write.
>>
>> However, what's the reason for requiring this lack of access
>> control? Why o+w?
> tar.umask worked. Thank you for explaining how the permissions work
> in this context. I now see that 775 and 664 would work for the apache
>  component and for executing our binaries. Thanks for pointing this
> out. However, another element of our application is a proprietary
> runtime that runs on top of linux and runs our core binaries. This
> allows us to store our binaries in git and deploy them directly on
> the customer server from git (via git-archive). That runtime needs
> o+w in order to update the 'last run date' in the binary which is
> critical to our troubleshooting in the field. o+w is needed because
> the user's runtime instance runs with user permissions when executed
> from a linux command line terminal and our users are not setup in the
> same group as the binaries. Therefore, with tar.umask = 0000 I can
> deploy 777 and 666 permissions and everything will work.
>
> I suppose I could write a script to change the tar.umask entry to
> 0000 only when running git-archive for the binary portion, and use
> tar.umask 0002 when extracting the other portions. I could also
> change our setup to put the users and the runmodules in the same
> group and use tar.umask 0002 across the board. These would be more
> correct than the chmod 777 shotgun that we currently use to blast
> away our permissions problems.
>
> git-archive is a "quick" solution to our immediate deployment needs.
>  Eventually, I plan on using git on the source and target machines as
> the core mechanism to "promote to production" (ie. deploy to customer
>  servers). It looks like others are using git for deployment also. In
> my previous shops which used other VCS's on minicomputers and
> mainframes, "promote to production" meant the universal run path for
> all users (and especially for productional data transactions) on that
> central machine. In my current shop (my first linux shop) we have
> multiple concurrent versions of production on a multitude of
> productional machines and even concurrently on an individual
> productional machine in some cases. The main reason we chose git is
> because it is the only VCS that can handle this.
>
Actually, the apache user (web interface) also needs to be able to
update the binaries with 'last run date'. In this context the o+w allows
this, also.  I don't know enough about apache and permissions to try and 
add apache to the same group as the binaries at this point.

-neal