Problem phenomenon:

Gitlab has been running stably for more than a year. Today, a small partner in the R & D department came to say that his gitlab couldn’t be accessed. After a while, several other partners gave the same feedback to check their error reports. It was 403 Forbidden. Strangely, my visit was normal

Troubleshooting process

First, go to the server and check that all services are normal. Check the gitlab CTL logs. It is found that an IP 172.17.2.254 access is denied, and this IP is the gateway of the wireless network segment. I immediately understood that all the students who can’t use the wireless Internet can’t use it as long as they have passed 2.254. Continue to check the log. There is a Xiaoxiao user who has failed to log in several times, and then it’s all forbidden. It seems that gitlab has an explosion-proof mechanism. Check the configuration document gitlab.yml. Sure enough, there is a rack_The configuration of attack is shown in the figure below:

Solution

Enter redis and delete the IP address of the wall. The command is as follows:

/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket keys ‘*’ | grep ‘rack::attack’ | xargs /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket DEL

[root@localhost gitlab]# /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket keys '*' | grep 'rack::attack' | xargs /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket DEL
(integer) 1
[root@localhost gitlab]# 
##Execute this command Use a wireless connection to gitlab to restore the computer to normal.