Unable to connect GitLab with Mailgun - gitlab

I am unable to send emails in GitLab, I am using the service Mailgun, below my settings:
sudo vim /etc/gitlab/gitlab.rb
Settings:
gitlab_rails['gitlab_email_from'] = "username#domain.com"
gitlab_rails['gitlab_email_reply_to'] = "username#domain.com"
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.mailgun.org"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_authentication'] = "plain"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_user_name'] = "username#domain.com"
gitlab_rails['smtp_password'] = "secret"
gitlab_rails['smtp_domain'] = "domain.com"
Reconfigure and restart:
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
Does anyone have any idea how to solve this? Thanks.

All new accounts of DigitalOcean has a lock for sending emails. To remove the blockade is necessary open a ticket and request the unlock.
To curb a recent increase in abuse and SPAM, we have an initial SMTP block on new accounts created in certain contexts.
By DigitalOcean.

Related

Using docker registry of gitlab, which is installed as docker-container

I have installed a GitLab in a docker container, that works very well.
Now, I would like to use the integrated docker-registry of GitLab.
Now, I tried, adding in gitlab.rb:
registry_external_url 'https://gitlab.team-f.de'
registry_nginx['enable'] = true
registry_nginx['redirect_http_to_https'] = false
registry_nginx['listen_https'] = false
registry_nginx['listen_port'] = 5005
Going into the container I can connect to port 5000 and 5005, but those ports do not get exposed!
How can I do this? TIA!
Using a reverse-proxy, I need an extra subdomain for my gitlab-docker-registry.
gitlab.mydomain.com
registry.gitlab.mydomain.com
Then I configured in docker-compose.yml:
registry_external_url 'https://registry.gitlab.mydomain.com'
registry_nginx['enable'] = true
registry_nginx['listen_https'] = false
registry_nginx['listen_port'] = 5005
registry_nginx['redirect_http_to_https'] = false
Now, it works fine. :)

"NOAUTH Authentication required" Gitlab error with Azure cache for Redis

I have created an Azure cache for Redis and I am trying to use it as external redis for Gitlab.
My gitlab.rb is this:
#external_url "https://ci.example.com"
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate'] = "/etc/gitlab/ssl/ci.example.com.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/ci.example.com.key"
### The duration in seconds to keep backups before they are allowed to be deleted
gitlab_rails['backup_keep_time'] = 604800
### External postgres settings
postgresql['enable'] = false
gitlab_rails['db_adapter'] = "postgresql"
gitlab_rails['db_encoding'] = "unicode"
gitlab_rails['db_database'] = "cisomething"
# username string for AWS
# gitlab_rails['db_username'] = "gitlab"
# username string for Azure
gitlab_rails['db_username'] = "gitlab#ci-something.postgres.database.azure.com"
gitlab_rails['db_password'] = "really long password"
gitlab_rails['db_host'] = "ci-something.postgres.database.azure.com"
gitlab_rails['db_port'] = 5432
gitlab_rails['auto_migrate'] = false
### External redis settings
redis['enable'] = false
gitlab_rails['redis_host'] = "ci.redis.cache.windows.net"
gitlab_rails['redis_port'] = 6379
gitlab_rails['redis_password'] = "azure-redis-primary-access-key"
### Whitelist VPC cidr for access to health checks
gitlab_rails['monitoring_whitelist'] = ['XX.XXX.X.X/24']
### Default Theme
gitlab_rails['gitlab_default_theme'] = 2
### Enable or disable automatic database migrations
gitlab_rails['auto_migrate'] = false
### GitLab email server settings
... other settings here
I can connect to Redis with redis-cli
redis-cli -h ci.redis.cache.windows.net -p 6379 -a azure-redis-primary-access-key
and execute commands.
When I execute gitlab-ctl tail I see this error:
==> /var/log/gitlab/gitlab-workhorse/current <==
{"error":"keywatcher: pubsub receive: NOAUTH Authentication required.","level":"error","msg":"unknown error","time":"2020-02-21T10:26:08Z"}
{"address":"ci.redis.cache.windows.net","level":"info","msg":"redis: dialing","scheme":"redis","time":"2020-02-21T10:26:08Z"}
{"error":"keywatcher: pubsub receive: NOAUTH Authentication required.","level":"error","msg":"unknown error","time":"2020-02-21T10:26:08Z"}
{"address":"ci.redis.cache.windows.net","level":"info","msg":"redis: dialing","scheme":"redis","time":"2020-02-21T10:26:08Z"}
{"error":"keywatcher: pubsub receive: NOAUTH Authentication required.","level":"error","msg":"unknown error","time":"2020-02-21T10:26:08Z"}
{"address":"ci.redis.cache.windows.net","level":"info","msg":"redis: dialing","scheme":"redis","time":"2020-02-21T10:26:08Z"}
{"error":"keywatcher: pubsub receive: NOAUTH Authentication required.","level":"error","msg":"unknown error","time":"2020-02-21T10:26:08Z"}
{"address":"ci.redis.cache.windows.net","level":"info","msg":"redis: dialing","scheme":"redis","time":"2020-02-21T10:26:08Z"}
I searched the internet but I cannot find something to resolve this.
System information
System: Ubuntu 16.04
Current User: git
Using RVM: no
Ruby Version: 2.6.5p114
Gem Version: 2.7.10
Bundler Version:1.17.3
Rake Version: 12.3.3
Redis Version: 5.0.7
Git Version: 2.24.1
Sidekiq Version:5.2.7
GitLab information
Version: 12.7.6
Revision: 61654d25b20
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: PostgreSQL
DB Version: 9.5.20,
So, I figured it out.
For future reference here it goes.
gitlab.rb
### External redis settings
redis['enable'] = false
gitlab_rails['redis_host'] = "ci.redis.cache.windows.net"
gitlab_rails['redis_port'] = 6380
gitlab_rails['redis_password'] = "azure-primary-access-key"
gitlab_rails['redis_ssl'] = true
Azure Cache for Redis configuration [Azure portal]
Final note:
When deploying the Gitlab VM, check the logs with gitlab-ctl tail. If you see the redis default port to be 6379 means that Sidekiq has old configuration, which as I observed is not updated with gitlab-ctl reconfigure. Delete the VM and redeploy it.

Haskell stack connection timeout

I have installed stack on WSL Ubuntu using WSL2 on Windows 10. The installation completed successfully, but when I test stack with
stack path --local-bin
I get the following error message:
Writing implicit global project config file to:
/home/jdgallag/.stack /global-project/stack.yaml
Note: You can change snapshot via the resolver field there.
HttpExceptionRequest Request {
host = "s3.amazonaws.com"
port = 443
secure = True
requestHeaders = [("Accept","application/json"),("User-Agent","The Haskell Stack")]
path = "/haddock.stackage.org/snapshots.json"
queryString = ""
method = "GET"
proxy = Nothing
rawBody = False
redirectCount = 10
responseTimeout = ResponseTimeoutDefault
requestVersion = HTTP/1.1
}
ConnectionTimeout
I have seen some other posts about issues like this one, but none that are resolved, and they are older. Also, I am not on a proxy, this is my personal computer, and I turned the firewall completely off. That said, when I attempt this over a vpn connection I get a different error. Could it be an ssl/https issue since WSL2 is technically a different IP address from Windows, and so the connection is being blocked on the amazon side?
For the record when attempting the command on a VPN, the error I get is
Writing implicit global project config file to:
/home/jdgallag/.stack/global-project/stack.yaml
Note: You can change the snapshot via the resolver field there.
HttpExceptionRequest Request {
host = "s3.amazonaws.com"
port = 443
secure = True
requestHeaders = [("Accept","application/json"),("User-Agent","The Haskell Stack")]
path = "/haddock.stackage.org/snapshots.json"
queryString = ""
method = "GET"
proxy = Nothing
rawBody = False
redirectCount = 10
responseTimeout = ResponseTimeoutDefault
requestVersion = HTTP/1.1
}
(InternalException (HandshakeFailed Error_EOF))
Update
Reverting to WSL-1 "solves" the problem, so the issue is something specific to WSL-2. I replicated the problem with a fresh install of Windows on a separate machine, but haven't found a way around the issue yet.
I have wls2 ubuntu 20.02 installed on my pc
fixed this problem with changing the contents of /etc/resolv.conf
cd /etc
sudo *your favorite editor* resolv.conf
added Google DNS servers as
nameserver 8.8.8.8
nameserver 8.8.4.4
this fixed stack not working for me.

kinit: Failed to store credentials: Bad format in credentials cache (filename: /tmp/krb5cc_651) while getting initial credentials

I have been trying to do kinit from client machine to KDC server to authenticate client
kinit -kt host.keytab -p host/mydomain.com#REALM.COM
but I am getting below error
kinit: Failed to store credentials: Bad format in credentials cache
(filename: /tmp/krb5cc_651) while getting initial credentials
I have checked permission /tmp dir. I do have write permission.
the same kinit command works on the machine where KDC is installed.
both machines are in public domain
krb5.conf
dns_lookup_realm = false
default_realm = REALM.COM
# default_ccache_name = KEYRING:persistent:%{uid}
rdns = false
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
preauth = false
udp_preference_limit = 1
Please help me. what is going wrong?? (I have changed realm name and domain name here)
it was OS (openVOS stratus machine) specific which is returning end of file while trying to read cache file very first time. actually, the cache file would not have anything very first time in the cache file. So I have to take care of the same in Kerberos source code.

Can't Enable Google Login (omniauth) on GitLab CE

I am having an issue enabling Google authentication with my GitLab install. I followed this guide to add enable Google authentication (the interface changed a bit, but I was able to generate the tokens I need with contacts & Google+ api access for my domain). When I go to my GitLab login URL, no providers are showing up. I also enabled Omniauth. Here is the relevant snippet from my Gitlab.rb:
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = false
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_providers'] = [
{
"name" => "google_oauth2",
"app_id" => "not-showing",
"app_secret" => "not-showing",
"args" => { "access_type" => "offline", "approval_prompt" => '' }
}
]
I am inclined, however, to think it is an issue with Omniauth itself because in my GitLab admin dashboard, it doesn't show the green "on" icon next to it:
I'm running the server on Ubuntu 14.04.
Any insights into this would be greatly appreciated.
You need to reconfigure and restart gitlab after making those changes.
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
Change this line:
...
gitlab_rails['omniauth_allow_single_sign_on'] = ['google_oauth2']
...
Then run:
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Resources