I am pretty new in Git and I am installing a centralized GIT repository on a Linux server following this tutorial: http://toroid.org/git-central-repo-howto
It show these 2 first steps:
$ git init --bare --shared foo.git
Initialized empty shared Git repository in /git/foo.git/
$ chgrp -R dev foo.git
So basically the first command:
git init --bare --shared foo.git
I think that it means that I am creating a new empty foo repository (is foo the name of the created repository?).
From what I have understand the --bare option means that this repository is not associated to a working tree. Why?
Reading this documentation: https://git-scm.com/docs/git-init I can understand that --shared means that this repository is to be shared amongst several users. This allows users belonging to the same group to push into that repository.
But what users? Users of what?
The second statement is:
chgrp -R dev foo.git
From what I have understand it set the foo.git directory (my repository) and all its content to the dev group.
The problem is performing this command I obtain this error message in my shell:
XXX#YYY:~$ chgrp -R dev foo.git
chgrp: invalid group: ‘dev’
I am not so into Linux but I think that it means that the dev group doesn't exit on my server. Why have I to associate this repository folder (and its content) to a group? How can I solve this issue?
Re-read manual:
The easy way to give people read-write access to it (repository) is to
add all the relevant users to one group (say dev), and give that group
ownership of the repository
and
The --shared option sets the permissions on everything in the
repository to group-writable.
ssh:// access-type to repo assumed. I.e. user belongs to local group, all members of which have RW rigths in the repository on FS-level
I'm quite new to GIT myself, but I think you just need to create linux group "dev" beforehand, or use an already existing group. You can add users of the linux server into that group. The users of the group could later clone/pull from/push to your repository.
Link about managing groups:
https://wiki.archlinux.org/index.php/users_and_groups
Related
We have a scenario in which single server is running, which is getting data from the network span.
Every developer should work on their machine locally but the data to work on is only available in the server. how can I get the data to be replicated into each developers machine so that once they have completed development on their local machine, developers can push it to a GIT in the server.
PS: The network span data is constantly written to the server (data is in size of 100s of GB's).
What we have tried so far:
So we created a GIT server in the server we were getting the data on. But once a developer log in using his username then he creates a new branch in a directory. This works fine until another developer logs into the server with his username and switches to another branch in the same directory which will cause all the developers branch to the new one. which is not what we were expecting.
Probabily this question should go to https://serverfault.com/, but, anyway...
The git advantage is to have local and remotre repositories, so, in the server, you should have "only" the remote repositories, and they should be cloned in localmachines.
to work with that paradigm, or with the one you are asking for, you need a umask of 007 (depending on your distribution edit /etc/login.defs and change there)
You should have diferent groups for the diferent kind of shared projects, and a user to "own all the repositories", for example, git-adm ).
With all the prerequisites, you create with that user the base folder for all the repositories:
sudo -i
mkdir /srv/git
chown git-adm:gitgrp /srv/git
chmod g+s /srv/git
exit
The last line in the "sticky bite", wich allows to mantain the group (and avoid the problems you previously stated), so, in order to cerate a repository should be something like:
sudo su - git-adm
mkdir /srv/git/<group>/<repoName>.git
cd /srv/git/<group>/<repoName>.git
git init --bare
exit
And thats all: if the folder /srv/git/<group>/ we owned for a diferent group, then it'll keep the group.
Here is a problem.
I create a new repository with
mkdir -p repositories/project.git
cd repositories/project.git
git init --bare --shared=all
The repository is at shared local folder. UMASK is 022.
Later on, folks in my team are able to clone the project and push a few changes.
However, soon they come across this issue when they try to do 'git push'.
error: unable to write sha1 filename ./objects/3c/c2f933427a4215d3237a0c3b874a4ff16725: Permission denied
To myaccountname#nameofthecomputer:/repositories/project.git
! [remote rejected] master -> master (unable to migrate objects to permanent storage)
error: failed to push some refs to 'myaccountname#nameofthecomputer:/repositories/project.git'
The problem is obviously in the way git creates some internal files/objects, because if I do:
sudo chmod -R 777 project.git
the problem is temporarily gone.
What am I doing wrong?
git init --shared=all makes the repository readable by all users, but not writable by all users. Making any directory writable by all users (without using the sticky bit) is generally a colossal security risk, so Git doesn't provide that as an option.
If you want people to all be able to write to a Git repository this way, then places them all in a single group, say git. Change the main repository and all of its subdirectories to have that group, and make each directory setgid. That means that each directory and file that's created will have the group git. Since with --shared=all, Git will make all files and directories writable by that group, users should be able to push normally to the repository.
Note that the umask is not relevant here, since Git will adjust the permissions to honor the setting you specified.
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.
I use a mercurial repository for global configuration. The system config files are linked to /opt/config which is a hg repo owned by root.
I d like all users to be able to update settings from repo i.e. to call hg pull -u in /opt/config
I tried to create the following script
# -rwsr-x--x 1 root users 343 Mar 15 14:10 /bin/update_config
#! /bin/bash
cd /opt/config
hg pull -u
(Pay attention, the s-bit is set) . In this case, hg does not read the settings from /root/.hgrc which contain the HTTP login parameter (user cannot does not know the parameters)
even if I do export HOME=/root the hgrc file is not read.
How should I change my script to make it possible?
EDIT
It seems to be a general permission problem. I use sles11. The line touch /root/bla does not work in this script, why?
Mercurial being a distributed versioning system, it seems to me that you are not using it correctly. If users are required to modify the repository, every user should handle its own repository and then configure it to push into your desired location (/opt/config). Hence, the mercurial workflow will handle the merge problems. If they are only consumers of the repository, you should either 1) create a cron entry to update it automatically or 2) use a continuous integration system like Jenkins or TeamCity that will automatically update the repository when something is pushed to it.
If you still want to realize what you asked, you should look into the sudo command for this purpose. Make the /opt/config ownership to a new passwordless user, configure sudo to allow the switch to this user without password and make the configuration only in ~theuser/.hgrc . This will make it easier to maintain (only a single .hgrc to handle).
I have this problem when i try to push in git:
error: insufficient permission for adding an object to repository database ./objects
fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To ssh://<repo url>/<repo dir>
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'ssh://<repo url>/<repo dir>'
I've had this before sporadically and we've always had to solve it by each user sshing to the repo and setting group permissions on all the files therein with
chmod -R g+w *
This was never a satisfactory solution and now it's bitten us in the arse as one of the guys is away and no-one knows his repo user's password. So, i'm trying to solve it properly.
The error seems to occur when someone tries to push up a change that will alter a repo dir that is owned by another user (hence setting the group write option above). I've done a bit of googling around this and have found a couple of solutions being discussed (neither of which worked for me)
1) make sure that the group that the repo dirs are shared with is each users' primary group (i believe that is the case already: each user has only one group so that must be their primary group, right?)
2) git repo core.sharedRepository setting, as detailed here: Git: Can't push from one computer
I changed this but it didn't make any difference. Do i need to reload the config or something to actually effect the change?
Here's what my repo config looks like atm:
[core]
repositoryformatversion = 0
filemode = true
bare = true
sharedRepository = all
[receive]
denyNonFastForwards = True
Grateful for any advice or suggestions!
max
I had this error for two weeks, and the majority of the solutions stated 'chmod -R' as the the answer, unfortunately for me my git repos (local / remote / shared - with team) were all on Windows OS, and even though chmod -Rv showed all the files changed to 'rwxrwxrwx', a subsequent 'ls -l' still showed all files as 'rwxr-xr-x' and the error repeated itself. I eventually saw this solution by Ariejan de Vroom. It worked and we were all able to pull and push again.
On both local (the local that is having trouble pushing) and remote repos, run the following commands:
$ git fsck
$ git prune
$ git repack
$ git fsck
On a side note, I tried using Windows' native file permissions / ACL and even resorted to elevating the problem user to Administrator, but none of that seemed to help. Not sure if the environment is important, but it may help someone with a similar setup - problem team member and remote (Windows Server 2008 R2 Standard), my local (Windows 7 VM).
A simpler way to do this is to add a post-receive script which runs the chmod command
after every push to the 'hub' repo on the server. Add the following line to hooks/post-receive inside your git folder on the server:
chmod -Rf u+w /path/to/git/repo/objects
It is a permission error. The way that was most appropriate and secure for me was adding users to a supplementary group that the repo. is owned by (or vice versa):
groupadd git
chgrp -R git .git
chgrp -R git ./
usermod -G -a git $(whoami)
In case anyone else is stuck with this: it just means the write
permissions are wrong in the repo that you’re pushing to. Go and chmod
-R it so that the user you’re accessing the git server with has write access.
For me, this error occurred when I was out of space on my remote.
I just needed to read the rest of the error message:
error: file write error (No space left on device)
fatal: unable to write sha1 file
error: unpack failed: unpack-objects abnormal exit
For the permission error using git repository on AWS instance, I successfully solved it by creating a group, and assigning it to the repository folder recursively(-R), and give the written right to this group, and then assign the default aws instance user(ec2-user or ubuntu) to this group.
1. Create a goup name share_group or something else
sudo groupadd share_group
2. change the repository folder from 'root' group to 'share_group'
sudo chgrp -R share_group /path/to/your/repository
3. add the write authority to share_group
sudo chmod -R g+w /path/to/your/repository
4. The last step is to assign current user--default user when login (by default ec2 is 'ec2-user', user of ubuntu instance is 'ubuntu' in ubuntu on aws) to share_group. I am using ubuntu insance on aws, so my default user is ubuntu.
sudo usermod -a -G share_group ubuntu
By the way, to see the ownership of the folder or file just type:
ls -l /path/to/your/repository
'
Output:
drwxr-x--x 2 root shared_group
(explanation please see:https://wiki.archlinux.org/index.php/File_permissions_and_attributes).
After step 3, you will see
drwx--x--x 2 root root
changed to
drwxr-x--x 2 root share_group
In this case, I did not assign user 'ubuntu' to root group, for the consideration of security. You can just try to assign you default user to root according to step 4 (just skip the first 3 steps
In another way, tried the solution by :
chmod -Rf u+w /path/to/git/repo/objects
It did not work for me, I think it should be the reason that my repository folder belong to the root user, not to Ubuntu user, and 'git' by default use the default user(ec2-user or Ubuntu user. You can try to change the user and test it.
Finally, below code definitely work for me, but 777 is not good for security
sudo chmod -R 777 /path/to/your/repo
I use gitosis for managing this kind of stuff. Gitosis has a single user (usually called "git") that owns all the repositories, and it uses public-key-based access control to each repo. It might not suit your setup but is probably worth checking out (no pun intended).
This problem can also occur after Ubuntu upgrades that require a reboot.
If the file /var/run/reboot-required exists, do or schedule a restart.
I was getting similar error and please see below how I resolved it.
My directory structure:
/opt/git/project.git
and git user is git
$ cd /opt/git/project.git
$ sudo chown -R git:git .
chown with -R option recursively changes the ownership and and group (since i typed git:git in above command) of the current directory. chown -R is necessary since git changes many files inside your git directory when you push to the repository.
I was having trouble with this too, thinking my remote gitolite-admin was corrupted or something wrong.
My setup is Mac OS X (10.6.6) laptop with remote Ubuntu 10 server with gitolite.
It turned out that the problem was with my local checkout of gitolite-admin.
Despite the "unpack failed" error, it turned out the the problem was local.
I figured this out by checking it out again as gitolite-admin2, making a change, and the pushing.
Voila! It worked!
For what it worth, I had the same problem over my own VPS and it was caused by my low hard disk space on VPS. Confirmed by df -h command and after i cleaned up my VPS' hard disk; the problem was gone.
Cheers.
Where I work we have been using this method on all of our repositories for a few years without any problems (except when we create a new repository and forget to set it up this way):
Set 'sharedRepository = true' in the config file's '[core]' section.
Change the group id of the repository to a group shared by all users who are allowed to push to it:
chgrp -R shared_group /git/our_repos
chmod -R g+w /git/our_repos
Set the setgid bit on all directories in the repository so that new files/directories keep the same group:
find /git/our_repos -type d -exec chmod g+s {} +
Add this line to the pre-receive hook in the repository to ensure new file permissions allow group read/write:
umask 007
For me its a permissions issue:
On the git server run this command on the repo directory
sudo chmod -R 777 theDirectory/
A git configuration mistake can also product this error. I give my students and example of configuration like this:
git config --global user.name "John Doe"
git config --global user.email johndoe#example.com
One of my students was getting the unpacker error. Other students were fine, but I still did a double check on the git server's permissions and to be sure the student was in proper group.
Finally, I had the student do a git log and saw that he had John Doe for his configuration, but his branch was his own name.
Setting up his configuration properly eliminated the error .
I had similar problem like this before:
! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'https://mywebsite.com/my-git-directory.git'
In my case, I have checked wrong directory ownership with ls -l. I change the directory owner to www-data to solve the problem like this:
sudo chown -R www-data:www-data my-git-directory.git/
But in this case I not use SSH method, I use HTTP method.
Maybe when we make sure the directory owner is correct, it can solve the problem.