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
--
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