I'm having massive issues right now trying to get a gitolite hook to go.
I've put the file in .gitolite/hooks/common/ and I have ran the gitolite setup, and when I push to a repo, nothing happens.
I have checked the permissions 755 on the file. It's owned by git. I'm fully stumped.
So far I like gitolite, however so far for me, hooks are killing me.
Try to modify the hook as published by Gitolite in your ~/repositories/yourRepo/hooks, in order to:
simplify it
have a simple echo in it
make it non-blocking
That way, you will make sure if the issue actually comes from that hook or not.
Also don't hesitate to upgrade your gitolite version to the latest one.
The OP mike tries the VREF route and finds out that:
turns out the issue was in my config file where I call the hook.
We have a group called devs and admins: I needed to make sure I was referencing the right group.
Related
I'm currently in the process of moving a gitolite (3) installation between two
servers. Thankfully, this process is pretty well
documented on the main
project website. However, my repositories makes pretty active use of
git-annex which stores data in various
remotes as well as on the server itself.
Now, I'm not an expert on git-annex, but I know it works a bit differently from
"regular" git, so is there anything one should keep in mind when moving this
kind of installation or does it work just as outlined in the gitolite
documentation above?
After quite a bit of research, I couldn't find any details on how this should
done on a git-annex enabled repository so I decided to simply try it
out. Apparently, the steps as they are written work just fine, even for
git-annex content. That said, be cautious as you're moving stuff. Once the new
server is ready to take over, make sure the old one is disabled, I don't think
the git-annex likes to find 2 identical remotes.
As a minor anecdote: I accidently forgot to chown/chmod the repositories but
re-running step 6 and onwards without any issues what-so-ever.
I wanted to checkout an older commit to my working directory to mess around with something so I did the following command in the root of my repo:
git checkout 2aa2c5 .
But nothing happened, the # prompt simply came back. I did the command a few more times, but nothing seemed to happen. I then did:
git status
Which showed that I was still on master. I then did:
git checkout master
As I wasn't sure what was happening and just wanted to get back to where I was. It came back with Already on master
However now my website is not accessible, every single file now seems to have the permission 644? I am really not sure what has happened? It looks like although my original attempt to checkout a commit didn't do anything, it has messed with my file permissions, and/or file ownership.
UPDATE: I don't think it is the permission that is the problem. I think the problem is that all the files have changed to root for the owner and group? I was logged in as root when I did the checkout, will that have caused this?
I am new to git and Linux file permission in general, if anyone could shed some light on this I would really appreciate it.
Thanks
Permissions and ownership are really critical for web servers. If you get this wrong, the wrong people (= crackers) can read or modify your files. So make sure you understand what you're doing.
As a rule of thumb, never work as root. One silly mistake (like a flacky mouse that cut&pastes too much) can cost you the work of many hours.
In your case, it seems that the ownership of the files was changed. To fix this, you will have to delete all the files (as root; be careful - if you make a mistake, a lot more that you might ever want will be gone!)
Try to keep the Git repo (i.e. delete everything except for the .git folder) but I fear that running git as root has already messed with some permissions in that folder as well.
So your best bet might be to delete the whole tree (including the .git folder) and clone it again with the correct user.
Related:
http://www.linux.org/threads/file-permissions-chmod.4094/
http://www.linuxquestions.org/linux/answers/Security/Quick_and_Dirty_Guide_to_Linux_File_Permissions
Is it possible to have multiple git users logged as the same Linux user?
What I would like is that multiple admins can login as root, make a git pull to a directory assigned to them, and then git push, but so we still can see who made which changes in the git log?
Each one of your users can clone the repo for his own. That repository would have his config.user and config.email according to the person using it, and they all pull and push to the same "central" repo.
Anyway, they are all root, so there's not much to do about preventing one of this admins to commit as another one. But if they aren't evil, you can do this.
gitosis can surely help to access control the repository, too, if needed.
Personally I would say that the correct mechanism to make sure that you can track changes in this sort of case would be not to have root as a permitted username for your repository. They would all have to commit with their individual user names by logging in as themselves.
In general nobody should be logged in as root other than very briefly while performing a specific task such as installing a new package - not all of the time while developing so anything you do to make such practices unrewarding is good.
It would be safer to manage that kind of access control with an authorization layer like gitolite, instead of relying on system account.
That way, you are controlling who can pull what.
Although that wouldn't control the "where" part (where the users would pull those repos to)
I searched through Google, forums and JGit user guide but couldn't find how to connect to a distant repository with the API.
Anyone has an example or just an idea on how to do that?
Thanks for your help.
Currently, JGit 2.0.0-SNAPSHOT does only offer
org.eclipse.jgit.storage.file.FileRepository
org.eclipse.jgit.storage.dfs.InMemoryRepository
concrete Repository classes, meaning that since org.eclipse.jgit.api.Git takes a Repository, it is not possible to work remotely. Since Git by itself is not designed to operate remotely in the way I think you mean, I doubt we will see such a feature any time soon.
MORE ON THAT:
Consequently, you will need to clone locally. You do that by issuing
Git.cloneRepository()
.setURI(myRemoteURIString)
.setDirectory(new File(myLocalPathString))
.call();
However, for reasons of consistency in Git you should clone a bare repository only, so a non-bare repository in a remote location, while not technically, is practically inaccessible.
I am not sure I understand the question since Git is made for accessing other repositories, this is what is meant by "Git is distributed".
If you want to connect to ONE distant repository, then yeah you should clone it.
I don't know if that is what you are looking for, but you can also use multiple remotes. Adding one more is done with Git using git remote add <remote_name> <remote_uri>. As for Jgit, I unfortunately can't remember the code to do it simply, but you can figure this out.
At least it's possible by modifying the configuration, calling getConfig() from a Repository object and then calling setString(...) on it - don't forget to save the configuration in the end. But before modifying the configuration, I think you should first get to know more about Git and JGit.
I recommend you to read more about it, and play a bit with your repository. Take a look at this article : http://caiustheory.com/adding-a-remote-to-existing-git-repo .
Another one that will help you down the road is How do I do the equivalent of “git remote update” with jgit?
Maybe someone else knows exactly which commands to run and can help.
I have an application using some template files and some developers wich are producing them.
The best way I found to mantain templates is to install git over gitolite and creates an hook to automatically checkout templates on update, in the right folders.
Well, everything on setup is up and running fine, but I have a security question.
Templates are used by a small application running with a user called runtime, with runtime group.
Gitolite uses another user/group usually git:git to manage repositories.
In the hook I must check out files into a runtime user folder and obviously it does not work.
I think about changing git group to the same of runtime, but I really don't know if there are security troubles in this solutions or there are no reasons to worry.
I'm not a security experts, but I know here is full :)
Thank's a lot, David.
It sounds to me like you don't actually want to run the checkout of the files from the hook, you just want the hook to trigger them. The checkout really wants to be run as the runtime user?
I can think of a couple of ways to do this, none of them sound amazing:
Set-up a passwordless ssh key for the git user, so it can run ssh runtime#localhost ~runtime/doUpdates.sh, and said script does the fetch and checkout.
Set-up limited sudo for the git user so it can run sudo -u runtime ~runtime/doUpdates.sh.
Set-up limited sudo for the git user so it can chown runtime:runtime -R the result of its checkout actions.
And a couple of even worse ones. :)