Gitlab error “fatal: The remote end hung up unexpectedly” Again
Category : How-to
I previously wrote in this blog post about how to fix an error with Gitlab. The error was presented when using the git push command with a remote repository that uses the Gitlabs HTTP protocol and not the SSH protocol.
The following error was presented in the Git client when using the git push command:
git push -u origin master Counting objects: 556, done. Delta compression using up to 8 threads. Compressing objects: 100% (539/539), done. efrror: RPC failed; result=22, HTTP code = 413367.00 KiB/s atal: The remote end hung up unexpectedly Writing objects: 100% (556/556), 1.45 MiB | 367.00 KiB/s, done. Total 556 (delta 282), reused 0 (delta 0) fatal: The remote end hung up unexpectedly Everything up-to-date
It seems that the issue is Nginx, Gitlab’s HTTP server, is not configured to receive large amounts of data. We need to specify the attribute client_max_body_size in Gitlab’s Nginx configuration file and specify the maximum amount of data Nginx will accept.
Open the configuration file and find the line location @gitlab.
vi /etc/nginx/sites-available/gitlab
Add the client_max_body_size attribute and specify the size value to use.
client_max_body_size 20M
The M stands for megabyte – you can also use G for gigabytes.
If the size of your git push ever exceeds the above value, you will have to either increase the size further or reduce your git commit sizes.
Your completed /etc/nginx/sites-available/gitlab file should look like the below example which has a 20MB upload limit.
upstream gitlab {
server unix:/home/git/gitlab/tmp/sockets/gitlab.socket;
}
server {
listen *:80 default_server; # e.g., listen 192.168.1.1:80; In most cases *:80 is a good idea
server_name YOUR_SERVER_FQDN; # e.g., server_name source.example.com;
server_tokens off; # don't show the version number, a security best practice
root /home/git/gitlab/public;
# Increase this if you want to upload large attachments
# Or if you want to accept large git objects over http
client_max_body_size 20m;
# individual nginx logs for this gitlab vhost
access_log /var/log/nginx/gitlab_access.log;
error_log /var/log/nginx/gitlab_error.log;
location / {
# serve static files from defined root folder;.
# @gitlab is a named location for the upstream fallback, see below
try_files $uri $uri/index.html $uri.html @gitlab;
}
# if a file, which is not found in the root folder is requested,
# then the proxy pass the request to the upsteam (gitlab unicorn)
location @gitlab {
proxy_read_timeout 300; # Some requests take more than 30 seconds.
proxy_connect_timeout 300; # Some requests take more than 30 seconds.
proxy_redirect off;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://gitlab;
}
error_page 502 /502.html;
}
Ceph is an open source storage platform which is designed for modern storage needs. Ceph is scalable to the exabyte level and designed to have no single points of failure making it ideal for applications which require highly available flexible storage.
The rest of this tutorial will assume that you have three nodes which are all clustered into a single Proxmox cluster. I will refer to three host names which are all resolvable via my LAN DNS server; prox1, prox2 and prox3 which are all on the jamescoyle.net domain. The image to the left is what is displayed in the Proxmox web GUI and details all three nodes in a single Proxmox cluster. Each of these nodes has two disks configured; one which Proxmox is installed onto and provides a small ‘local’ storage device which is displayed in the image to the left and one which is going to be used for the Ceph storage. The below output shows the storage available, which is exactly the same on each host. /dev/vda is the root partition containing the Proxmox install and /dev/vdb is an untouched partition which will be used for Ceph.
