I went thru the installation of GitLab CE on Ubuntu 18.04. I logged in using root. Then changed the root login to to something different. The Letsencrypt cert was obtained. I made the necessary changes per the web interface. The GitLab account is there but I am unable to access the account from my server.
I simply want to properly uninstall every bit of GitLab CE on Ubuntu 18.04.
@Tristan, thank you sir. After GitLab is completely uninstalled and my system is up and running, I hope there are persons that will assist in getting GitLab properly working on my system. I have gone thru the voluminous gitlab.rb, too. It is reminiscent of a VMS sysgen file.
The server runs Apache 2.4 and is a reverse proxy to applications. The other applications have been configured and work. I have tried various suggestions to configure an Apache virtual host for Gitlab and tweaked gitlab.rb.
The goal is to get my system up, running and to document the process of configuring apache virtual hosts for running Gitlab so it can be shared with others.
Unless you have another suggestion, starting from scratch may be the best solution.
Thanks for listening.
I really need your help. I have removed gitlab from my system. Now I cannot get Apache to start: systemctl restart httpd.
journalctl -xn produces the following:
– The result is failed.
Jan 10 19:32:20 Sire systemd[1]: Unit httpd.service entered failed state.
Jan 10 19:32:21 Sire sshd[8167]: Failed password for root from 218.92.1.169 port 30713 ssh2
Jan 10 19:32:22 Sire sshd[8167]: pam_succeed_if(sshd:auth): requirement “uid >= 1000” not met by user “root”
Jan 10 19:32:24 Sire sshd[8167]: Failed password for root from 218.92.1.169 port 30713 ssh2
Jan 10 19:32:25 Sire sshd[8167]: pam_succeed_if(sshd:auth): requirement “uid >= 1000” not met by user “root”
After whois 218.92.1.169 and dropping the above ip address, Now I get the following:
Jan 10 20:13:06 Sire systemd[1]: Unit httpd.service entered failed state.
Jan 10 20:13:47 Sire named[5943]: client myIPADDRESS#50921 (157.33.254.189.in-addr.arpa): view outside: query (cache) ‘157.33.254.189.in-addr.arpa/PTR/IN’ denied
Jan 10 20:13:48 Sire named[5943]: client myIPADDRESS#47609 (customer-189-254-33-157-sta.uninet-ide.com.mx): view outside: query (cache) 'customer-189-254-33-157-sta.uninet-ide.com
Jan 10 20:13:48 Sire sshd[8820]: reverse mapping checking getaddrinfo for customer-189-254-33-157-sta.uninet-ide.com.mx [189.254.33.157] failed - POSSIBLE BREAK-IN ATTEMPT!
Jan 10 20:13:48 Sire sshd[8820]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=189.254.33.157 user=root
Jan 10 20:13:48 Sire sshd[8820]: pam_succeed_if(sshd:auth): requirement “uid >= 1000” not met by user “root”
Jan 10 20:13:50 Sire sshd[8820]: Failed password for root from 189.254.33.157 port 44649 ssh2
Jan 10 20:13:50 Sire sshd[8820]: Received disconnect from 189.254.33.157: 11: Normal Shutdown, Thank you for playing [preauth]
My system is down. It appears pam is complaining. I there a way to remove any keys GitLab added to my system?
That seems like a very bad idea. We generally don’t use a “root” account at all on Ubuntu. You should use sudo, which temporarily gives you root privilege without needing a root account. I don’t think you can blame GitLab here.
You haven’t said how you installed Gitlab (there are at least three ways I know of: omnibus, source, and docker), so it’s not possible to know what has broken things.
Your current error messages are saying that you are trying to login via SSH asroot. That is generally forbidden. It can be overridden, but I’m not going to help you shoot yourself in the foot by digging up the method (which I haven’t needed in 20+ years of administering Linux systems). Login as yourself, then use sudo. I don’t think those messages are related to the systemd error starting Apache, but they could be.
You say “my system is down”, but only show us a system that’s up. Do you really mean that Apache is down? Then login as yourself–that is, the user who initially installed Ubuntu, or another user who is either in the sudo group or the /etc/sudoers file–and try to restart Apache with: sudo systemctl restart httpd
And another thing… httpd is not the name of the standard Ubuntu Apache daemon (the Ubuntu service has been apache2.service for as long as Ubuntu has used systemd, and the daemon has been apache2 since they stopped shipping version 1.X), so not only don’t we know how you installed GitLab, we don’t know how you installed Apache, either.
Thank @auspex. There was no attempt to blame GitLab. I have both Fedora and Ubuntu. Fedora’s apache damon is httpd.
The need to uninstall GitLab CE was a fresh start. The reverse proxy is Fedora (httpd). Behind the reverse proxy is an Ubuntu (apache2) subdomain with CE installed. After uninstalling GitLab attempts to restart the reverse proxy failed. The Fedora reverse proxy was rebooted and came up fine. With the fresh start the reverse proxy was configured to communicate with the subdomain. The on the subdomain was hosting CE was configured.
At the CE new pass word screen a pass word was entered. Then I was able to proceed setting up CE from the fresh start.
I’m sorry, but you’re not providing us with any usable information, then. You installed Gitlab on your Ubuntu system, but were getting errors from your Fedora system. The GitLab install couldn’t have caused the problems on the Fedora machine. And nobody here could possibly have helped you with your problem, because you forgot to even mention that the errors were coming from a completely different machine. Please, if you want help, you really need to give us as much information as possible.
There is not a problem. There is nothing to apologize for or about. The software was removed and Fedora would not boot. After Fedora was reboot everything is fine. There is another gentleman that was not very happy with GitLab. I am not him.
After removing Gitlab and rebooting both systems, everything is fine. GitLab CE is installed on Ubuntu behind the Fedora reverse proxy. The next step is to install a runner on a separate Ubuntu server behind the Fedora reverse proxy.
Someone there could have helped. However, it was not the lack of information that prevented them. It was the lack of interest in customers/users/clients. Anyone in this forum has seen detailed posts that have gone unanswered for very long times, even years, including the gentlemen that ranted to get Gitlab removed.
It is not helpful to lecture people on what they should have asked, provided or said, after the fact. Actually helping is not having everything perfectly laid out, but asking a question to solicit what one needs to know in order to help.