Does Gitlab EE Have Audit Logs for "git clone", and "git pull" commands? - gitlab

The audit events page of gitlab says that I can find "Project repository was downloaded" action in Project > Settings > Audit Events.
So I tried running git clone http://gitlab.example.com/testauditlog.git to download one of my projects. But then I can't find anything related to the download in the audit events. Why does this happen?
The only logs belonging to git clone I found is in /var/log/gitlab/nginx/gitlab_access.log
172.17.0.1 - - [03/Jan/2020:03:28:56 +0000] "GET /testauditlog.git/info/refs?service=git-upload-pack HTTP/1.1" 200 254 "" "git/2.21.0 (Apple Git-122.2)"
172.17.0.1 - - [03/Jan/2020:03:28:56 +0000] "POST /testauditlog.git/git-upload-pack HTTP/1.1" 200 949 "" "git/2.21.0 (Apple Git-122.2)"
But this log doesn't say which account cloned the repository. So it is not that useful for the compliance team in my company.
I used gitlab/gitlab-ee at dockerhub with a 30-day evaluation license to try the audit events feature of gitlab.

Related

Is it possible to add nginx cache hash to the log?

I have an nginx cache server with a simple basic config, nothing special.
nginx version: openresty/1.13.6.1
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.4)
built with OpenSSL 1.0.2k 26 Jan 2017
TLS SNI support enabled
log:
172.18.0.1 HIT -- - - 0.000 - - [06/Apr/2022:17:33:00 +0000] "HEAD /custom/xxxx/image/product/12.jpg HTTP/2.0" 200 0 "-" "curl/7.68.0" "-"
This file cache version is stored under custom folder /tmp/cache1.
What i want, is display the cache hash in the log file.
Eg. the cache hash for this file is:
/tmp/cache1/a/0/e6920f37af6df573815a02933c7f480a
And what i want to see:
172.18.0.1 HIT -- - - 0.000 - - [06/Apr/2022:17:33:00 +0000] "HEAD /custom/xxxx/image/product/12.jpg HTTP/2.0" | e6920f37af6df573815a02933c7f480a | 200 0 "-" "curl/7.68.0" "-"
Is it possible? Have any built-in variable to display this hash in the log files?

How to report a bug of GoogleBot?

Over the last days, Google Bot tries to read one URL of our main site over and over again, leading to a DDOS attack :) Our website got very slow because of the massive requests of the Google Crawler.
Here an excerpt for the curious ones (or if a Google engineers reads this post):
66.249.76.54 - - [27/May/2019:06:31:23 +0200] "GET /235432/~plot~+4x%5E2%3B+4%2Ax%5E2+++4%2A%281/32%29%2Ax+-+15%2A%281/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/323274/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/tag/594749/323274/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/323274/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/235432/tag/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/594749/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/323274/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/user/impressum HTTP/1.0" 200 32603
66.249.76.54 - - [27/May/2019:06:31:23 +0200] "GET /235432/~plot~+4x%5E2%3B+4%2Ax%5E2+++4%2A%281/32%29%2Ax+-+15%2A%281/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/235432/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/323274/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/323274/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/235432/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/235432/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/403551/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/403551/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/tag/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/594749/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/323274/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/bestusers HTTP/1.0" 200 32603
66.249.76.55 - - [27/May/2019:06:31:23 +0200] "GET /235432/tag/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/154807/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/594749/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/594749/403551/tag/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/403551/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/schreibregeln HTTP/1.0" 200 32603
66.249.76.54 - - [27/May/2019:06:31:23 +0200] "GET /235432/~plot~+4x%5E2%3B+4%2Ax%5E2+++4%2A%281/32%29%2Ax+-+15%2A%281/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/154807/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/323274/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/403551/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/tag/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/403551/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/235432/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/594749/tag/chat HTTP/1.0" 200 32603
Or here (see the different IPs, so there are several bots):
66.249.76.54 - - [27/May/2019:09:24:42 +0200] "GET /235432/~plot~+4x%5E2%3B+4%2Ax%5E2+++4%2A%281/386961/~plot~+4x%5E2%3B+4%2Ax%5E2+++4%2A%281/32%29%2Ax+-+15%2A%281/403551/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/594749/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/594749/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/235432/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/user/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/594749/user/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/punkte HTTP/1.0" 200 32587
66.249.76.55 - - [27/May/2019:09:24:42 +0200] "GET /235432/~plot~+4x%5E2%3B+4%2Ax%5E2+++4%2A%281/32%29%2Ax+-+15%2A%281/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/403551/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/235432/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/user/403551/agb HTTP/1.0" 200 32587
66.249.76.56 - - [27/May/2019:09:24:42 +0200] "GET /235432/~plot~+4x%5E2%3B+4%2Ax%5E2+++4%2A%281/32%29%2Ax+-+15%2A%281/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/323274/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/235432/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/594749/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/594749/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/user/154807/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/235432/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/594749/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/403551/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/403551/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/qa-theme/lounge/js/lounge.min.js?v=2019-01-17 HTTP/1.0" 200 32587
66.249.76.55 - - [27/May/2019:09:24:42 +0200] "GET /235432/~plot~+4x%5E2%3B+4%2Ax%5E2+++4%2A%281/32%29%2Ax+-+15%2A%281/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/235432/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/tag/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/235432/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/594749/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/235432/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/luckentext-zum-thema-extrema-funktionenschar-ft-x-1-2-tx-2-2-t HTTP/1.0" 200 32587
66.249.76.58 - - [27/May/2019:09:24:42 +0200] "GET /235432/~plot~+4x%5E2%3B+4%2Ax%5E2+++4%2A%281/32%29%2Ax+-+15%2A%281/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/235432/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/235432/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/323274/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/323274/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/tag/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/323274/user/Lu HTTP/1.0" 200 32587
66.249.76.57 - - [27/May/2019:09:24:42 +0200] "GET /235432/~plot~+4x%5E2%3B+4%2Ax%5E2+++4%2A%281/32%29%2Ax+-+15%2A%281/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/235432/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/154807/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/323274/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/235432/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/32)*x%20-%2015*(1/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/tag/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/user/user/tag/tag/~plot~%204x%5E2;%204*x%5E2%20+%204*(1/badges HTTP/1.0" 200 32587
The false link that was leading to this problem:
~plot~ 4x^2; 4*x^2 + 4*(1/32)*x - 15*(1/32)^2; x; [[0.1]]~plot~
Where can I report a bug of GoogleBot?
There seems to be no official way how to report a bug.
Here is the link to report a crawling bug of Google Bot:
https://www.google.com/webmasters/tools/googlebot-report
Report a problem with how Googlebot crawls your site.
You can report problems only for domain-level properties (for example, "www.example.com/")
The rate at which Google crawls your page depends on many factors:
The URLs we already know about
Links from other web pages (within your site and on other sites)
URLs listed in your Sitemap.
For most sites, Googlebot shouldn't access your site more than once every few seconds on average.
Probably the report link was not easy to find since you need a Google Webmaster account and can apparently only report your own websites.

Gitlab: pushes registering with repo, but pipelines not running and projects dashbaord 'last updated' is not changed

When we push to our repository, we expect a pipeline to run. However, the pipelines have stopped starting automatically when we push.
In addition, when we try to start the pipeline manually, not all the tags and branches are showing in the dropdown list of tags and branches to choose from. When we browse the repository in Gitlab, we can see the branches and the pushed commits.
Finally, in the /dashboard/projects page, the 'last updated' date of the project is out of date, saying "yesterday" rather than "10 mins ago" (which is what shows when viewing the repository within the project.
We recently migrated server and so would expect that there is some migration issue going on here. Does anyone have any ideas where to look to solve this problem (i.e. what sub-systems could be not working/configured correctly to produce this behaviour)?
Gitlab version: 9.4.2
Run with Docker using: https://hub.docker.com/r/gitlab/gitlab-ce/
Update
I tailed the logs while pushing to the repository, what follows is a chunk of logs around that time (starting with the SSH connection for the push). Potentially the 404 around prometheus is interesting, but I'm not sure that's unexpected (we're not using it):
==> /var/log/gitlab/sshd/current <==
2017-08-01_17:05:16.86559 Accepted publickey for git from (removed) port 57680 ssh2: RSA SHA256:(removed)
==> /var/log/gitlab/gitlab-rails/production.log <==
Started POST "/api/v4/internal/allowed" for 127.0.0.1 at 2017-08-01 17:05:17 +0000
==> /var/log/gitlab/gitlab-shell/gitlab-shell.log <==
I, [2017-08-01T17:05:17.088866 #2286] INFO -- : POST http://127.0.0.1:8080/api/v4/internal/allowed 0.01170
I, [2017-08-01T17:05:17.089030 #2286] INFO -- : gitlab-shell: executing git command <git-receive-pack /var/opt/gitlab/git-data/repositories/products/preside-ext-ems.git> for user with key key-2.
==> /var/log/gitlab/sshd/current <==
2017-08-01_17:05:17.20480 Received disconnect from x.x.x.x port 57680:11: disconnected by user
2017-08-01_17:05:17.20483 Disconnected from x.x.x.x port 57680
==> /var/log/gitlab/gitlab-rails/production.log <==
Started GET "/-/metrics" for 127.0.0.1 at 2017-08-01 17:05:18 +0000
Processing by MetricsController#index as HTML
Filter chain halted as :validate_prometheus_metrics rendered or redirected
Completed 404 Not Found in 1ms (Views: 0.4ms | ActiveRecord: 0.0ms)
Started POST "/api/v4/jobs/request" for 172.17.0.1 at 2017-08-01 17:05:18 +0000
==> /var/log/gitlab/gitlab-workhorse/current <==
2017-08-01_17:05:18.16504 gitlab.mycompany.com # - - [2017-08-01 17:05:18.158505651 +0000 UTC] "POST /api/v4/jobs/request HTTP/1.1" 204 0 "" "gitlab-ci-multi-runner 9.4.1 (9-4-stable; go1.8.3; linux/amd64)" 0.006484
==> /var/log/gitlab/nginx/gitlab_access.log <==
172.17.0.1 - - [01/Aug/2017:17:05:18 +0000] "POST /api/v4/jobs/request HTTP/1.1" 204 0 "-" "gitlab-ci-multi-runner 9.4.1 (9-4-stable; go1.8.3; linux/amd64)"
==> /var/log/gitlab/gitlab-rails/production.log <==
Started POST "/api/v4/jobs/request" for 172.17.0.1 at 2017-08-01 17:05:23 +0000
==> /var/log/gitlab/gitlab-workhorse/current <==
2017-08-01_17:05:23.16534 gitlab.mycompany.com # - - [2017-08-01 17:05:23.159064793 +0000 UTC] "POST /api/v4/jobs/request HTTP/1.1" 204 0 "" "gitlab-ci-multi-runner 9.4.1 (9-4-stable; go1.8.3; linux/amd64)" 0.006235
==> /var/log/gitlab/nginx/gitlab_access.log <==
172.17.0.1 - - [01/Aug/2017:17:05:23 +0000] "POST /api/v4/jobs/request HTTP/1.1" 204 0 "-" "gitlab-ci-multi-runner 9.4.1 (9-4-stable; go1.8.3; linux/amd64)"
Not exactly an answer - but I have wiped out the server and rebuilt from scratch. Manually recreating each project and importing the repositories for each project.
A royal PITA, but everything is working as expected.
I can only guess that either something was setup on the host server that was causing issues (I did a clean install on the host to start again), or that there was something about simply copying over all our configuration and data dirs from the old server to the new server that caused issues (seems unlikely).
Not much help I'm afraid :(

Network printer doesn't accept job from Debian Linux, no errors in error_log

There is a shared printer at my workplace. We send jobs and then go to the printer and authenticate, so printer prints your documents only when you present at it. Periodically, we change domain passwords, so I also have to change it in /etc/cups/printers.conf (windows users just change domain password). So, that's how it works.
But, suddenly, it stop receive my jobs. When I send job I have no errors and have this:
sudo tail /var/log/cups/access_log
localhost - - [14/Apr/2015:12:15:14 +0300] "POST /printers/Generic-PCL-6-PCL-XL HTTP/1.1" 200 499 Create-Job successful-ok
localhost - - [14/Apr/2015:12:15:14 +0300] "POST /printers/Generic-PCL-6-PCL-XL HTTP/1.1" 200 1273674 Send-Document successful-ok
localhost - - [14/Apr/2015:12:17:59 +0300] "POST / HTTP/1.1" 200 183 Renew-Subscription successful-ok
On cups page in browser it shows state for job - "Pending since (date/time)".
It seems like job was sent successfully, but when I came to printer I've got nothing and no job in my queue. Our IT support fix problems only for Windows users and who on Linux - on their own. So, I don't know what to do and what logs I should inspect. Please, help.
Probably, some updates broke it down. But I have found another solution - I add printer not via samba, but via lp and it doesn't ask username/password:
cat /etc/cups/printers.conf
# Printer configuration file for CUPS v1.5.3
# Written by cupsd
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING
<DefaultPrinter KonicaMinolta>
UUID urn:uuid:0f60c08a-ecfb-326a-421c-86aa3519147b
Info MyCompany Office printer
Location WestCorridor
MakeModel Generic PostScript Printer Foomatic/Postscript (recommended)
DeviceURI lpd://Company_printer_server_address/lp
State Idle
StateTime 1429265417
Type 8433692
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>
If somebody can provide another solution or some explanation why it is so, I will be glad to see.
As far as debugging you can view more data in your CUPS logs if you edit your /etc/cups/cupsd.conf file, find the section "loglevel" change "info" to "debug"
Then you should restart CUPS with:
/etc/init.d/cups restart
Then your log will be in
/var/log/cups/error_log

PuppetCA not signing Certificate-Requests

I'm having a setup with MCollective 1.2.0, Puppet 2.6.4 and an
provision-agent. Most of the time this works great, but sometimes
(every 10th node or so) I experience, that signing-requests of puppet-
agents are not getting signed on the master.
In this case every request of the puppet agent to the "/production/certificate/..." fails with an HTTP-Error 404.
The problem is also hard to analyze because the logoutput is not very
detailed.
Puppet-Agent:
Jun 18 16:10:38 ip-10-242-62-183 puppet-agent[1001]: Creating a new SSL key for ...
Jun 18 16:10:38 ip-10-242-62-183 puppet-agent[1001]: Caching certificate for ca
Jun 18 16:10:41 ip-10-242-62-183 puppet-agent[1001]: Creating a new SSL certificate request for ...
Jun 18 16:10:41 ip-10-242-62-183 puppet-agent[1001]: Certificate
Request fingerprint (md5): 6A:3F:63:8A:59:2C:F6:C9:5E:56:5F:39:16:FF:19:BE
Puppet-Master:
"GET /production/certificate/a.b.c.d HTTP/1.1" 404
"GET /production/certificate_request/a.b.c.d HTTP/1.1" 404
"GET /production/certificate/a.b.c.d HTTP/1.1" 404
"GET /production/certificate/a.b.c.d HTTP/1.1" 404
"GET /production/certificate/a.b.c.d HTTP/1.1" 404
"GET /production/certificate/a.b.c.d HTTP/1.1" 404
... last message repeats endlessly
Does anyone have a glue about that?
Markus

Resources