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.
v/r,
neal
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html