I setup gitlab on Centos 6x . Webserver : nginx .
I installed my gitlab follow link .
And i have a problem : when i push my project on client to gitlab#mydomain.com , system ask password :
git push -u origin master
git#gitlab.mydomain.com's password:
Then i show config file of my project on client :
cat ../.git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[branch "master"]
[remote "origin"]
url = git#gitlab.mydomain.com:myusename/myproject.git
fetch = +refs/heads/*:refs/remotes/origin/*
System showed log When i check :
bundle exec rake gitlab:check RAILS_ENV=production
/usr/local/lib/ruby/gems/2.0.0/gems/bundler-1.3.5/lib/bundler/runtime.rb:216: warning: Insecure world writable dir /usr/bin in PATH, mode 040777
/usr/local/lib/ruby/gems/2.0.0/gems/bundler-1.3.5/lib/bundler/runtime.rb:216: warning: Insecure world writable dir /usr/bin in PATH, mode 040777
Checking Environment ...
..
..
I want to turn off the password requirement .
Some body help me , thanks a lot .
I assume you have checked you public keys are valid and installed on client and server/gitlab and that ssh is working with public keys for another user on that machine.
Have you checked file permissions on the git users ~/.ssh directory (should be 700) and ~/.ssh/authorised_keys (600).
Also is selinux enabled? You may have an issue with security contexts - see https://serverfault.com/a/564824/204206
Related
I have a locally hosted version of bitbucket, and a github account. I want to be able to connect to both easily. I tried this .gitconfig version, does not work seamlessly. What Am I missing? What should I put under user in both systems?
#Github (default)
Host gh
HostName github.com
User ?
IdentityFile ~/.ssh/id.pub
#Bitbucket (secondary)
Host bb
HostName stash.company.com
User ?
IdentityFile ~/.ssh/id.pub
In your local repo, a "remote" is defined to tell git what repository to go to when doing things like push and pull.
The default name is "origin".
So we enter commands like "git pull origin main"
The command "git remote -v" will show the "remotes you have defined, like this:
git remote -v
origin git#github.com:/.git (fetch)
origin git#github.com:/.git (push)
You can define another remote to point to a different remote repo:
git remote add
So if you add a remote and call it bborigin then
git pull bborigin main
would pull the main branch on remote bborigin
(I do not know if you will need special steps to set up authentication on the different remotes)
First, you need to put that in ~/.ssh/config
That means you can:
test your authentication with ssh -Tv gh or ssh -Tv bb
use those Host entries in SSH URLs with
git clone gh:me/myGitHubRepository
git clone bb:me/myBitBucketRepository
Second, a typical global .gitconfig (in $HOME\.gitconfig) would look like:
[alias]
st = status
lg2 = log --graph --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(bold white)- %an%C(reset)' --abbrev-commit
lg = !"git lg2"
br = branch
[user]
name = You
email = your#email.com
[core]
autocrlf = false
safecrlf = false
commitGraph = true
quotepath = false
longpaths = true
[rebase]
autostash = true
autosquash = true
[pull]
rebase = true
[protocol]
version = 2
[gc]
writeCommitGraph = true
[credential "helperselector"]
selected = manager-core
[credential]
helper = manager-core
manager = manager-core
[init]
defaultBranch = main
This assumes you have downloaded and installed GCM (Git Credential Manager), the credential manager which helps caching your credentials (username/password) for HTTPS URL.
Not mandatory in your case, though, if you stick to SSH URLs.
RESUME
When I push from my local workspace to the target repo in GitLab on my remote VPS, I want GitLab run a script and ask a beta repo on the same VPS to git checkout and pull in order to check my changes.
Current configurations
Gitlab configurations
Suppose you already have a project in your admin area, you just need to get it's relative path
Admin area > Projects
Select your project
Get the path in the project profil (hashed for this case)
Create a new directory in this location called custom_hooks.
sudo su
cd /var/opt/gitlab/git-data/repositories/hashed/path/of/project
mkdir custom_hooks
Inside the new custom_hooks directory, create a file with a name matching the hook type. For a post-receive hook the file name should be post-receive with no extension.
cd custom_hooks
nano post-receive
Write the code to make the server hook function as expected. Hooks can be in any language. Ensure the ‘shebang’ at the top properly reflects the language type. In that case the script code used is :
#!/bin/sh
unset GIT_INDEX_FILE
cd /var/repo/beta.git && git checkout master && git up # --[see the note 2 below]
Make the hook file executable and make sure it’s owned by Git.
chmod +x post-receive
Note 1 :
You can find more informations about git hooks here : GitLab Documentation : Server hooks
VPS configurations
Create new alias with #RichardHansen recommandations
git config --global alias.up '!git remote update -p; git merge --ff-only #{u}'
Note 2 :
During my researches, I've found an interesting answer about git pull on the forum.
I've decided to follow that advice and I made an alias named git up.
What is important is that :
it works with all (non-ancient) versions of Git,
it fetches all upstream branches (not just the branch you're currently working on), and;
it cleans out old origin/* branches that no longer exist upstream.
You can find more informations about "In what cases could git pull be harmful ?" here :
Link to answer
Create a directory for git repos only and access it to process Hooks configurations
# Create a repo for the project in apache area
mkdir /var/www/beta
# Create the git repo only folder
cd /var
mkdir repo && cd repo
# Create git repo and init
mkdir beta.git && cd beta.git
git init --bare # --bare means that our folder will have no source files, just the version control.
# Add gitlab remote
git remote add gitlab
# Accessing hooks folder to create script
cd hooks
cat > pre-receive
# On the blank line, write this script then 'ctrl + d' to save and press enter to exit
#!/bin/sh
unset GIT_INDEX_FILE
git --work-tree=/var/www/beta --git-dir=/var/repo/beta.git checkout -f
# Make the file executable
chmod +x post-receive
Note 3 :
'git-dir' is the path to the git repository. With 'work-tree', we can define a different path to where the files will actually be transferred to.
The 'post-receive' hook will be looked into every time a push is completed and will set the path where the files will be transferred to /var/www/beta in that case.
Local Workspace configurations
# Create in your workspace a folder to hold the project
cd /path/to/workspace
mkdir project && cd project
# Initialize git and add gitlab remote
git init
git remote add gitlab ssh://user#mydomain.com/gitlab/path/of/project
# Create an index.html file and send the initial commit
nano index.html
# copy this into the file then 'ctrl + x' then 'y' then 'enter' to save
<html>
<head>
<title>Welcome to Beta domain!</title>
</head>
<body>
<h1>Success! The beta virtual host is working!</h1>
</body>
</html>
# prepare the changes and then send the commit
git status
git add index.html
git commit -m "chore: add index.html :tada: :rocket:"
git push gitlab master
EXPECTED RESULTS
The expected result of this process is that when the git push gitlab master is done, the hook inside the gitlab hashed directory of the project, run a script who make something like this :
# Access the beta.git directory
cd /var/repo/beta.git
# Run command for updating repo
git checkout master && git up
# If we access the beta folder in apache area we should see index.html
cd /var/www/beta
ls
--index.html
ACTUAL RESULTS
No result.
ERROR MESSAGES
No error messages.
REQUEST
How can I set up a process like this one ?
There is something in my process I did not take in consideration ?
I created a repo in gitlab and set the user.name in a global way.
When I try to push my project, after inserting my password, I get the following error:
fatal: 'user/test.git' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
My .git/config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git#gitlab.domain.tld:user/test.git
fetch = +refs/heads/*:refs/remotes/origin/*
output from "git remote -v:
origin git#gitlab.domain.tld:user/test.git (fetch)
origin git#gitlab.domain.tld:user/test.git (push)
What could be the problem?
Try using this:
git push https://username:password#gitlab.com/user/test.git
I've seen some issues in the newer versions of git that give me trouble when I don't specify the username and password every time. I'm sure there's a way around it but I haven't figured it out yet. Git recommends rolling back to older versions, but I'm sure there is a less drastic way.
In Settings you want to add with
git push https://yourusername:yourpassword#gitlab.com/user/test.git
I'm on a fresh install of Linux Mint.
I'm getting the following error when trying to push from any repository:
error: Malformed value for push.default: simple
error: Must be one of nothing, matching, tracking or current.
fatal: bad config file line 8 in /home/leng/.gitconfig
fatal: Could not read from remote repository.
This is very odd, because I definitely have a version that supports the simple push behavior.
The output of git --version is git version 1.8.3.2.
The contents of ~/.gitconfig:
[user]
name = My Name
email = MyEmail#website.com
[color]
ui = true
[push]
default = simple
Here's where it gets creepy.
If I change the behavior to matching (or to nothing, tracking, or current, for that matter), then attempt to push, I get the same exact error message. How is that possible? Is it caching the config somehow? I've even tried rebooting. I've even tried purging GIT completely from the system (and deleting ~/.gitconfig) then reinstalling it.
If I delete the [push] section completely from the .gitconfig file (or if I delete the file entirely), then try to push, then I get this:
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:
git config --global push.default matching
To squelch this message and adopt the new behavior now, use:
git config --global push.default simple
See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
'current' instead of 'simple' if you sometimes use older versions of Git)
error: Malformed value for push.default: simple
error: Must be one of nothing, matching, tracking or current.
fatal: bad config file line 8 in /home/leng/.gitconfig
fatal: Could not read from remote repository.
...so it appears to be both acknowledging that I haven't chosen a pushing behavior, but then also saying that I've chosen an unsupported behavior. What on earth is going on here?
I even get the error if I delete ~/.gitconfig completely.
Can anyone help me out with this witchcraft?
Thanks!
EDIT:
Here is a .git/config file requested:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = ssh://{my remote repo}
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
Okay, so I fixed it, but the method is absolute witchcraft.
I tried to isolate the problem by purging GIT, deleting the config file, reinstalling GIT, then creating a local bare repository, then cloning it, then attempting to push from there. Pretty much like this:
sudo apt-get purge git-core
rm -f ~/.gitconfig
sudo apt-get install git-core
cd /git
mkdir foo
cd foo
git init --bare
cd /var/www
git clone /git/foo
cd foo
touch blah.txt
git add -A
git config --global user.name "Name"
git config --global user.email "user#email.com"
git commit -m "Blah"
git push
...same exact error message, no change there. (Still some serious witchcraft.)
Then, I deleted one of my repositories that doesn't have a local origin (it connects to its origin via SSH) and cloned the repository anew after deleting it (with a fresh git clone ssh://... command).
I got an error from the clone command:
remote: Malformed value for push.default: simple
remote: Must be one of nothing, matching, tracking or current.
Ah ha! Now it says remote instead of error. So the remote doesn't support this behavior. (That doesn't explain why the error persists on local-only repositories with local origins, then, though.)
So I then SSH'ed into the remote server and updated the git-core there to the latest version, re-attempted to clone the repository from my local machine, and it worked.
Now, I can finally git push. Insanely, this also fixed it so I can git push from the entirely local /var/www/foo to the also entirely local /git/foo (the local origin bare repository). SSH'ing into this remote server and updating it somehow - WITCHCRAFT - fixed my local machine's error.
Why on earth the entirely local repos care about an entirely different machine's GIT version is... beyond me. How utterly, utterly insane.
I had the same error message on git push.
For me it turned out that the remote user's git was an older version (1.7.2.5),
and I had recently updated the remote ~/.gitconfig to include:
[push]
default = simple
The solution was to remove this setting from the remote's configuration.
Since it seems other people are having this issue, and I found a solution HERE, I thought I'd post the solution that worked for me.
IN SHORT:
The solution I found was at this page. Evidently the best solution is to upgrade to a newer version of Git (if possible). That was not an option for me, however. From a local machine, I typed the following command:
git config -–global push.default upstream
This got rid of the Malformed value for push.default: simple error I had been getting. I'm not entirely sure what upstream does, however.
MY CONTEXT (for comparison): I had an empty (bare) repository on a remote computer, and I had a few repositories on a couple "local" workstations. I pull from the remote repository, do some work, and then push my work to the remote repository. Pushing/pulling was accomplished via SSH. Most of the time, while working on a local machine, pushing/pulling would result in the error described above.
In short, before the fix, I had the following ~/.gitconfig file on the remote machine:
[user]
name = Foo Bar
email = FooBarPerson#email.com
[diff]
external = /Users/foobar/bin/git-diff-cmd.sh
[color]
diff = auto
status = auto
branch = auto
[push]
default = simple
After entering in the above command, my ~/.gitconfig file on the remote machine changed to:
[user]
name = Foo Bar
email = FooBarPerson#email.com
[diff]
external = /Users/foobar/bin/git-diff-cmd.sh
[color]
diff = auto
status = auto
branch = auto
[push]
default = upstream
Version information:
Remote machine (repository location): 1.9.4
My laptop: 1.8.5.2 (Apple Git-48)
Other computer I work on: 1.7.7.4
Here's another site that may be useful to some people:
http://www.lorrin.org/blog/2011/10/03/argumentless-git-pull-and-git-push/comment-page-1/
I just setup git on my linux server and configured SSH - I want to create private repository to work with my friends. When I'm pulling or cloning that repo everything works fine (LAN), but when my friend tries pull or clone it (over Internet),
git hangs at:
remote: Compressing objects: x
where x is always lower than 17%.
What's wrong with it or how could I fix it?
PS: I not using gitosis, I initialized that remote repo with: git --bare init.
Thanks in advance.
Update:
The results commands:
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
symlinks = false
ignorecase = true
hideDotFiles = dotGitOnly
[remote "origin"]
url = ssh://git#server:port/~/repo_name.git
fetch = +refs/heads/*:refs/remotes/origin/*
$ git fetch -v
Enter passphare for key '/c/Users/dev/.ssh/id_rsa':
remote: Counting objects: 76, done.
remote: Compressing objects: 21% (12/55)
However, when my friend got ZIP with sources and he pushed it, everything worked fine.
So he is able to push. I added an empty file and pushed it, he successfully downloaded (pulled) it.
Get your friend to try:
git fetch -v
If that doesn't give you the answer then get him to do this:
cat .git/config
If your server is secure then update your question to include the output of that command. If it's not secure then change the IP and other identifying details to a fake IP and fake details, but try not to alter anything else as you may end up providing misleading info.
Edit based on update:
The url should start with "ssh://" not "ssh/". Although I'm about to go double check that.
If Git push/pull freeze using a config that previously worked, try restarting the computer.
It sounds strange yet I have experienced this on Windows and Linux.
I had the same problem until I went into my Ethernet adapter settings and changed the Jumbo Packet size from 1514 bytes to 9014 bytes.