I had a gitolite pre-g2 repository I am attempting to get going on g3.
I copied over the entire repositories folder, and started with a clean g3 conf file, and removed all the gl-perms files to have a clean slate. I am trying to get a couple repos up and running with per-repo permissions.
Specifically I have my admin access keys and can clone and push the repo. This is defined the gitolite.conf as:
#admin = nikolaj
repo #all
RW+ = #admin
Then for the individual repo, I made sure my name (nikolaj) was in the gl-creator file, and removed the old gl-perms file.
I then try to run
ssh git#myserver perms my/repo
and I get
FATAL: sorry you are not authorised
Any help on how I can go about debugging this is greatly appreciated!
Make sure you followed the migration guide and did preset your gitolite.rc file
If you don't preset the rc (in this case, by commenting out the 'ssh-authkeys' line) before running gitolite setup, your ~/.ssh/authorized_keys file will get clobbered.
In your case, you did get a new gitolite.rc file, but still check if your ~/.ssh/authorized_keys is still intact (with a forced-command using nikolaj as parameter)
Related
I have a big problem and I can't understand this topic. I have a server with a website. I created a repository there with git init. Than I made a git add * to add all files from my server to the repository. Than I made a commit to commit all files to the repository.
Than I cloned it with git clone ssh://username#mysite.com/wordpress/.git to my local client.
All worked fine and I got a copy from my project. No I changed something on my local version and made a commit with a push. I looked in FileZilla but the content in the file don't changed. In the other direction when I changed something on the sever and pulled it to the local copy I saw the changes. Do you know why the changes which I made on the local copy are not visible on my sever?
Thank you for your help!
You need to push changes to a central repository that both your local machine and server can pull from (or add them as remotes for each other). A service such as GitHub works nicely for this. Here are instructions for a full workflow that works well for this. Updated instructions can be found in this gist. This workflow uses hooks to do the heavy lifting so that updates to your server are automated.
Using Git to Manage a Live Web Site
Overview
As a freelancer, I build a lot of web sites. That's a lot of code changes to track. Thankfully, a Git-enabled workflow with proper branching makes short work of project tracking. I can easily see development features in branches as well as a snapshot of the sites' production code. A nice addition to that workflow is that ability to use Git to push updates to any of the various sites I work on while committing changes.
You'll need to have Git installed on your development machines as well as on the server or servers where you wish to host your website. This process can even be adapted to work with multiple servers such as mirrors behind a load balancer.
Setting up Passwordless SSH Access
The process for updating a live web server relies on the use of post hooks within the Git environment. Since this is fully automated, there is no opportunity to enter login credentials while establishing the SSH connection to the remote server. To work around this, we are going to set up passwordless SSH access. To begin, you will need to SSH into your server.
ssh user#hostname
Next, you'll need to make sure you have a ~/.ssh in your user's home directory. If not, go ahead and create one now.
mkdir ~/.ssh
On Mac and Linux, you can harness the power of terminal to do both in one go.
if [ ! -d ~/.ssh ]; then mkdir ~/.ssh; fi
Next you'll need to generate a public SSH key if you don't already have one. List the files in your ~/.ssh directory to check.
ls -al ~/.ssh
The file you're looking for is usually named similarly to id_rsa.pub. If you're not sure, you can generate a new one. The command below will create an SSH key using the provided email as a label.
ssh-keygen -t rsa -b 4096 -C "your_email#example.com"
You'll probably want to keep all of the default settings. This will should create a file named id_rsa in the ~/.ssh directory created earlier.
When prompted, be sure to provide a secure SSH passphrase.
If you had to create an SSH key, you'll need to configure the ssh-agent program to use it.
ssh-add ~/.ssh/id_rsa
If you know what you are doing, you can use an existing SSH key in your ~/.ssh directory by providing the private key file to ssh-agent.
If you're still not sure what's going on, you should two files in your ~/.ssh directory that correspond to the private and public key files. Typically, the public key will be a file by the same name with a .pub extension added. An example would be a private key file named id_rsa and a public key file named id_rsa.pub.
Once you have generated an SSH key on your local machine, it's time to put the matching shared key file on the server.
ssh user#hostname 'cat >> ~/.ssh/authorized_keys' < ~/.ssh/id_rsa.pub
This will add your public key to the authorized keys on the remote server. This process can be repeated from each development machine to add as many authorized keys as necessary to the server. You'll know you did it correctly when you close your connection and reconnect without being prompted for a password.
Configuring the Remote Server Repository
The machine you intend to use as a live production server needs to have a Git repository that can write to an appropriate web-accessible directory. The Git metadata (the .git directory) does not need to be in a web-accessible location. Instead, it can be anywhere that is user-writeable by your SSH user.
Setting up a Bare Repository
In order to push files to your web server, you'll need to have a copy of your repository on your web server. You'll want to start by creating a bare repository to house your web site. The repository should be set up somewhere outside of your web root. We'll instruct Git where to put the actual files later. Once you decide on location for your repository, the following commands will create the bare repository.
mkdir mywebsite.git
cd mywebsite.git
git init --bare
A bare repository contains all of the Git metadata without any HEAD. Essentially, this means that your repository has a .git directory, but does not have any working files checked out. The next step is to create a Git hook that will check out those files any time you instruct it to.
If you wish to run git commands from the detached work tree, you'll need to set the environmental variable GIT_DIR to the path of mywebsite.git before running any commands.
Add a Post-Receive Hook
Create a file named post-receive in the hooks directory of your repository with the following contents.
#!/bin/sh
GIT_WORK_TREE=/path/to/webroot/of/mywebsite git checkout -f
Once you create your hook, go ahead and mark it as executable.
chmod +x hooks/post-receive
GIT_WORK_TREE allows you to instruct Git where the working directory should be for a repository. This allows you to keep the repository outside of the web root with a detached work tree in a web accessible location. Make sure the path you specify exists, Git will not create it for you.
Configuring the Local Development Machine
The local development machine will house the web site repository. Relevant files will be copied to the live server whenever you choose to push those changes. This means you should keep a working copy of the repository on your development machine. You could also employ the use of any centralized repository including cloud-based ones such as GitHub or BitBucket. Your workflow is entirely up to you. Since all changes are pushed from the local repository, this process is not affected by how you choose to handle your project.
Setting up the Working Repository
On your development machine, you should have a working Git repository. If not, you can create on in an existing project directory with the following commands.
git init
git add -A
git commit -m "Initial Commit"
Add a Remote Repository Pointing to the Web Server
Once you have a working repository, you'll need to add a remote pointing to the one you set up on your server.
git remote add live ssh://server1.example.com/home/user/mywebsite.git
Make sure the hostname and path you provide point to the server and repository you set up previously. Finally, it's time to push your current website to the live server for the first time.
git push live +master:refs/head/main
This command instructs Git to push the current main branch to the live remote. (There's no need to send any other branches.) In the future, the server will only check out from the main branch so you won't need to specify that explicitly every time.
Build Something Beautiful
Everything is ready to go. It's time to let the creative juices flow! Your workflow doesn't need to change at all. Whenever you are ready, pushing changes to the live web server is as simple as running the following command.
git push live
Setting receive.denycurrentbranch to "ignore" on the server eliminates a warning issued by recent versions of Git when you push an update to a checked-out branch on the server.
Additional Tips
Here are a few more tips and tricks that you may find useful when employing this style of workflow.
Pushing Changes to Multiple Servers
You may find the need to push to multiple servers. Perhaps you have multiple testing servers or your live site is mirrored across multiple servers behind a load balancer. In any case, pushing to multiple servers is as easy as adding more urls to the [remote "live"] section in .git/config.
[remote "live"]
url = ssh://server1.example.com/home/user/mywebsite.git
url = ssh://server2.example.com/home/user/mywebsite.git
Now issuing the command git push live will update all of the urls you've added at one time. Simple!
Ignoring Local Changes to Tracked Files
From time to time you'll find there are files you want to track in your repository but don't wish to have changed every time you update your website. A good example would be configuration files in your web site that have settings specific to the server the site is on. Pushing updates to your site would ordinarily overwrite these files with whatever version of the file lives on your development machine. Preventing this is easy. SSH into the remote server and navigate into the Git repository. Enter the following command, listing each file you wish to ignore.
git update-index --assume-unchanged <file...>
This instructs Git to ignore any changes to the specified files with any future checkouts. You can reverse this effect on one or more files any time you deem necessary.
git update-index --no-assume-unchanged <file...>
If you want to see a list of ignored files, that's easy too.
git ls-files -v | grep ^[a-z]
References
Deploy Your Website Changes Using Git
A simple Git deployment strategy for static sites
Using Git to manage a website
Ignoring Local Changes to Tracked Files in Git
pushing the code merely updates the remote repository's references.
It doesn't change the checked out working copy.
Consider that you could add a colleague's repository as a remote. If you pushed and the behaviour was that it would auto-checkout that new code, that would affect what they're working on.
It sounds like what you really want is a continuous integration tool, be it something full featured or merely an rsync triggered from a git hook.
you should only ever push to a bare repository (unless you know exactly what you are doing; and even then, you should only ever push to a bare repository).
you shouldn't clone a working copy's .git/ directory.
SOLUTION BELOW - How to use git to push to cpanel server
I finally got somewhere with setting up Git between my localhost (WAMP setup on Windows 8.1) and my Linux server (CentOS 6.6 x64 with cPanel 11.46.2).
Locally I created a bare clone: git clone --bare my_project my_project.git
NOTE: my_project is an example name, not the real name, and from this doc here: http://git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git-on-a-Server
I copied the my_project.git folder to my server's root directory /home/myuser/public_html/
so now in the root directory I have:
cgi-bin
my_project.git
This is one area I am unsure of. Do I have to do an init (using putty) on my server in the public_html directory? I read something about a bare init? I just want to push (from my PC) the website I already have under Git control, to the server. When I make a change to 1 file, push that change to the server so it's updated live with a push. The website is DONE and ready to be live. I have already manually moved back and forth for live testing on the server. My last step is to get the Git setup correctly, so any further changes I can just push them to the server without the need of FTP.
I added a remote origin: git remote add origin ssh://myuser#thedomain.com/home/myuser/public_html/my_project.git
I tried to push to it, and got "Permission denied (publickey)". I already had an id_rsa and id_rsa.pub key locally on my PC, so I copied them and renamed them to id_rsa.myname id_rsa.myname.pub (where myname is my first name). I then copied them to the .ssh folder through FTP (FTP as cpanel user, and it's the directory your dumped into, above public_html), same as /home/myuser/.ssh/ directory.
Once they where there, I added them to 'authorized_keys' using Putty logged in as the cpanel user (my private ppk) by doing:
cd .ssh
cat id_rsa.myname >> ~/.ssh/authorized_keys
cat id_rsa.myname.pub >> ~/.ssh/authorized_keys
After doing that, a push appeared to work. Because I was having a key/auth issue, I used Git Gui version, which was setup and worked fine locally. I added the origins through Git Bash though. When I did "Remote > Push" in the Gui version, I got:
Pushing to ssh://theregistrybank#theregistrybank.com/home/theregistrybank/public_html/yiire gistrybank.git
stdin: is not a tty
To ssh://myuser#thedomain.com/home/myuser/public_html/my_project.git
44ae034..0388a05 master -> master
updating local tracking ref 'refs/remotes/origin/master'
Before doing the push, the only file modified (diff from the bare clone I transferred to the server) was my .gitignore file. I added 2 more exclusions to it, and committed it locally. So I was trying to push the change in that file. After I did the push, it said "success" in green and appeared to work. However, when I check the file in FileZilla, the .gitignore file is not the updated one that I just committed locally.
I think I am close, but missed a step somewhere. I tried to be as descriptive as possible.
And putting the source on GitHub is not an option as the client does not want the source public, and does not want to pay for the private repos. I should be able to push from my local setup to the cPanel server so I don't have to transfer thousands of files every time. I actually transfer a zip file, and unzip on the server lol.
Server Info
cPanel 11.46.2 build 0
CentOS 6.6 x86_64 kvm build01
Yes, Git is setup on the server, and working, and git --version reports:git version 1.7.1
Git on my PC: git version 1.9.4.msysgit.2
Thank you in advance.
SOLUTION
Thanks to #VonC I was able to get this to work :)
You need somewhere for your git repo to sit. I created a 'git-repos' folder in '/home/cpaneluser/git-repos' to house my repos for this cpanel user.
First step is to create a bare repo: http://git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git-on-a-Server - I only followed the first step, basically created the bare repo 'my-project.git'
Before putting it on your server, rename 'my-project.git/hooks/post-receive.sample' to just 'post-receive' so it will be ran. Edit it with your editor, and add the line that #VonC gave us in his chosen answer:
#!/bin/sh
umask 0022
GIT_WORK_TREE=/home/cpaneluser/public_html GIT_DIR=/home/cpaneluser/git-repos/my-project.git git checkout -f
Note: I am using cpanel, so your path's may be different, and your umask could be different. 0022 is for 0644 file permissions. Without the umask, I was getting 500 Internal Server Errors, because the files were created with 0664 permissions instead.
Using FTP or whatever you like, copy the 'my-project.git' bare repo to your server to '/home/cpaneluser/git-repos'. Then go into 'my-project.git/hooks' and change the permissions of post-receive to have execute permissions. For me, 0744 worked fine. This was the magic sauce :)
Locally, add your remote (must be in your git project): git remote set-url origin ssh://cpaneluser#yourdomain.com/home/cpaneluser/git-repos/my-project.git
Now if you try to push now, it won't put the files in 'public_html' because the git tree (terminology?) matches and is up to date. If they are up to date, it seems to skip over executing your 'post-receive' hook. That means your bash script never ran, and it never checked out the files to your working tree.
We need to manually run the 'post-receive' bash script to create all the files of our project in the 'public_html' directory.
cd to '/home/cpaneluser/git-repos/my-project.git/hooks'
Run: ./post-receive
Boom, all your files are in 'public_html'. Now you can work locally, then push to your cpanel server as expected :)
I had a similar problem with my cPanel account, git was set up but for some reason I couldn't push to it. After a lot of head-banging I realized that the root of the problem is like you pointed out that although git is set up, the repo is empty so there's nothing for it to track.
This happens when you set up an empty repo in cPanel and then try pushing a local repo that you've already created, as opposed to cloning it first from github or your local repo (which is what happened to me because for some reason I couldn't access my github from the cPanel git interface even though I had set up a SSH key)
The simple solution that I found is to manually clone the repo using the terminal in your cPanel account
On your cPanel dashboard, under the "advanced" section, you'll find the terminal. You'll get a warning saying that you could mess up your server if you don't know what you're doing, click ok and you're in.
Now you just have to clone your repo the same way you would if you're cloning onto a local machine.
Navigate to where git was set up in your cPanel
cd repositories/<nameOfYourRepo>
And run the clone command
git clone <URLofYourGithubReop>
You'll be asked for your github username and password if it's a private repository
And that's it, you're good to go
What you have copied (my_project.git) is a bare repo, meaning one without a working tree (the actual checked out files).
Read for instance "Git workflow - Setting up a build process".
That means pushing to if won't change anything in /home/myuser/public_html/
The missing piece is a post-receive hook (in /home/myuser/public_html/my_project.git/hooks/post-receive, make sure it is executable: chmod +x), in order to checkout the repo in /home/myuser/public_html/.
#!/bin/sh
GIT_WORK_TREE=/home/myuser/public_html GIT_DIR=/home/myuser/public_html/my_project.git git checkout -f
I have two CentOS servers that are set up the same. I created a git repo on server A and pushed it to github. I then cloned the repo on server B. At first, all seemed to be in order. I could commit on either server, push to the remote, and the pull on to the other server.
The problem is that my co-workers now cannot push or pull on server B (they can run git status or commit). Strangely, this applies to ALL repos on server B, not just the one I cloned. Here is the error they see:
ERROR: Repository not found.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I checked that they are in the collaborators lists (both as owners and on the team assigned to the repo).
I also tried changing to the root user and cloning the repo again--as root I received the same error as above. The global .gitconfig does not reference my user or key, and the local .git/config files are set to use SSH (git#github.com).
What would cause this error to happen all users but one? Where else should I be looking?
Add '-v' to your git command as you run it to get more verbose output, that should tell you what's wrong.
I did resolve this issue. I found the problem by running ssh -T -vvv git#github.com which showed different keys being used for my user vs. the other users on the server. The key being used generally was not tied to a user in our github account. The fix:
Generated a new SSH key
Added key to shared user on github account
Updated .ssh/config to use the new key when accessing github.com
I am not certain how the SSH key got messed up, because it worked before. But this fixed it.
I created a simple project, committed and pushed the master branch, then protected it. After that I added a user to the project as a developer and this user was allowed to push to master.
So admin=master, user1=developer.
When I modified and pushed as user1, I was allowed to push to master. This is odd because I have a production instance that does not allow this.
I used the vagrant installation to setup a development environment.
After vagrant ssh:
cd /vagrant/gitlabhq && git pull --ff origin master
put me at commit a8b544ed770cf172b09feb6ffee14b1814b66ad4, gitlab-shell v1.5.0
cd /vagrant/gitlabhq && bundle exec foreman start -p 3000
gitlab was now up and running.
I logged in as admin#local.host
Added my "admin" key
Created project "master-protected"
in a shell, I created the repo, added a file and committed and pushed.
As "user1", I added my key, and in a shell, cloned "master-protected" which user1 has a developer role.
When I modified and pushed master, gitlab accepted the push, and the commit shows right up in gitlab. It should have denied it. In fact, when you go to the branches section, and see the master branch as being protected, it's last commit is the commit of the "user1" which only had developer permissions.
Any ideas on where I can look further to try and find out why this is happening in the development environment? It's the same for tag v5.3.0 as well, and I'm certain it does not happen in production v5.3.0.
it's funny because I was trying to replicate another bug I thought I had found with protected branches not being protected with merge requests and developer roles, but I hit a block with this one.
Sorry to bump this several moths later, but I have this same issue and I managed to solve this by checking the gitlab-shell update hook.
I have Gitlab version 5.1.0-4 and in my case, the gitlab-shell/hooks/update file should look like this:
#!/usr/bin/env /opt/gitlab-5.1.0-4/ruby/bin/ruby
# This file was placed here by GitLab. It makes sure that your pushed commits
# will be processed properly.
refname = ARGV[0]
key_id = ENV['GL_ID']
repo_path = `pwd`
require_relative '../lib/gitlab_update'
GitlabUpdate.new(repo_path, key_id, refname).exec
I hope helps someone else.
Best Regards.
Pedro Flores
This may be because the user is an admin, (A user can be admin and developer):
See:
https://github.com/gitlabhq/gitlabhq/issues/7723#issuecomment-63287902
Removing admin privileges from the user solved the problem for me.
I had the same problem, in my case the problem was a broken 'hooks' symlink in the project folder.
lrwxrwxrwx 1 git git 28 Sep 29 2015 hooks -> /home/git/gitlab-shell/hooks
Fixing the link as above fixed the issue
I have got a gitolite v2 installed on my company's server, and now I have to administrate it. Since it's really chaotic there I decided to install a new one, now it's v3. I have around 8 repositories what I want to move to the new install.
I don't need the old .rc file or any configurations, just the (working!) $GIT_HOME/repositories/*.git
What I tried: (found it while searching for solution)
copied all $GIT_OLD_HOME/repositories/*.git to $GIT_HOME/repositories/*.git (except gitolite-admin.git and testing.git)
then I updated the gitolite-admin.git/conf/gitolite.conf (by cloning and pushing back changes) with this kind of entries:
repo myrepo1
RW+ = #all
Now if I want to clone anything other than gitolite-admin or testing, it sais:
FATAL: R any myrepo1 myusername DENIED by fallthru
Few things I've checked:
ls -l $GIT_HOME -> gitolite:gitolite it's ok I guess since gitolite is the user I want to use
I did the same for all entries in the repositories directory and the permissions are the same.
I was googling for a solution however I didn't find any that fits my case. If you can help me or suggest me anything, please don't hold back :)
If you need any more details to find out the answer just tell me.
I had the same problem and upgrading did not work as it should so I used the following strategy - the bold text represents where was the step executed:
1- New: Install Gitolite (https://github.com/sitaramc/gitolite).
2- Workstation: In a new empty directory clone the gitolite-admin of the old version and rename it to gitolite-admin-old. Remove access to all users in gitolite-admin-old/conf/gitolite.conf except yourself - To disable anyone to do any change while you are migrating the repositories.
3- Workstation: Clone all repositories from the old Gitolite. git clone git#oldserver.com:repo.
4- Old: We already got what we want from the old repository. Disable old gitolite for good by adding exit 0 at the top of .gitolite.rc file.
5- Workstation: Clone gitolite-admin from the new server git clone git#newserver.com:gitolite-admin gitolite-admin-new
6- Workstation: Copy keys from the gitolite-admin-old/keydir to the gitolite-admin-new/keydir, add the repositories you want to transfer in the new gitolite-admin-new/conf/gitolite.conf with the user priviledges. add, commit and push.
7- Workstation: Push each required repository to the new server
git push --all git#newserver.com:repo
git push --tags git#newserver.com:repo
or
git push --mirror git#newserver.com:repo
8- Workstations: Change DNS or remote URL from each working repo.
Hope this helps
Make sure you have migrated your .gitolite.rc file, as described in the g2->g3 migration page
if you're migrating from g2, there are some settings that MUST be dealt with before running gitolite setup; please read the migration page and linked pages, and especially the one on "presetting the rc file"
The rc file for g3 is quite different from that of g2.
Or if you don't need the old one, as you mention, make sure the content of the default new one has appropriate values.
Make sure your new ~git/.ssh/authorized_keys file does contain a line with myusername in it.
The OP Attila Horvath confirms:
Note: nothing in any of the gitolite install/setup/etc will ever touch the data in any repository except the gitolite-admin repo. The only thing it will normally touch in normal repos is the update hook."
The last sentence just grabbed my attention, and it seems now that was the problem.
I first installed gitolite then copied there the repos, so I had to run again gitolite setup -pk mykey.pub and now it seems working!