This is a fresh install on Ubuntu 16.04.
I have been able to change the port and edit the "/etc/gitlab/gitlab.rb" file.
changes;
external_url 'http://superawesomedomain.com:2345'
nginx['listen_port'] = 2345
nginx['proxy_set_headers'] = {
"Host" => "$http_host",
"X-Real-IP" => "$remote_addr",
"X-Forwarded-For" => "$proxy_add_x_forwarded_for",
"X-Forwarded-Proto" => "https",
"X-Forwarded-Ssl" => "on"
}
When I try to access Gitlab from the browser, I get a 502 error "Whoops, GitLab is taking too much time to respond."
And this in the logs:
==> /var/log/gitlab/nginx/gitlab_error.log <== 2016/05/04 00:43:53 [error] 1599#0: *14 connect() to
unix:/var/opt/gitlab/gitlab-workhorse/socket failed (111: Connection
refused) while connecting to upstream, client: xxx.xxx.xxx.xxx, server:
superawesomedomain.com, request: "GET /favicon.ico HTTP/1.1", upstream:
"http://unix:/var/opt/gitlab/gitlab-workhorse/socket:/favicon.ico",
host: "superawesomedomain.com:2345", referrer:
"http://superawesomedomain.com:2345/"
The only ports configured behind NAT to work on this machine are; 2345 and 8080.
What am I missing? Ultimately I would prefer that it be https://superawesomedomain.com:2345/
I was able to get this working by using the IP of the server instead of the URL in the config:
external_url 'http://192.168.0.20:2345'
After doing that, GitLab was accessible from the //superawesomedomain.com:2345/ address. I am not sure why this worked, but it seems this is the only way to get it working with NAT and forwarded ports.
Related
The compilation is complete in all logs but am retrieving this error message:
"http://127.0.0.1:8080/", host: "172.31.30.177"
2022/12/01 21:42:06 [error] 32487#32487: *55 connect() failed (111: Connection refused) while connecting to upstream, client: 172.31.42.14, server: , request: "GET /.env HTTP/1.1", upstream: "http://127.0.0.1:8080/.env", host: "54.242.94.106"
Along with in my environment I am getting this response as well:
Environment health has transitioned from Degraded to Severe. 100.0 % of the requests are failing with HTTP 5xx. ELB processes are not healthy on all instances. Initialization completed 86 seconds ago and took 2 minutes. ELB health is failing or not available for all instances. Impaired services on all instances.
I am trying to host the server on aws and this is my server:
const express = require('express')
const server = express()
const PORT = process.env.PORT
const cors = require('cors')
const pizzaRouter = require('./api/pizza/pizza-router')
const toppingsRouter = require('./api/toppings/toppings-router')
server.use(express.json())
server.use(cors())
server.use('/api/pizza',pizzaRouter)
server.use('/api/toppings',toppingsRouter)
server.get('/', (req,res) => res.json({message:'This better work'}))
server.listen( PORT, () => {
console.log(`Server listening on PORT ${PORT} `)
})
// I did not assign the PORT env to any number as it has not worked for any i have assigned so far(443, 5000)
We have a self-managed gitlab instance running in docker container and an external url set as: https://subdomain.domain.com:50080
I’ve put gitlab_kas[‘enable’] = true in the docker-compose file in “GITLAB_OMNIBUS_CONFIG: |” and try to add the agent with helm in “Connect a Kubernetes cluster”, but the kasAddress does not contain the 50080 port:
–set config.kasAddress=wss://subdomain.domain.com:/-/kubernetes-agent/
and the agent pod gives this error:
{“level”:“error”,“time”:“2022-09-07T07:32:50.899Z”,“msg”:“Error handling a connection”,“mod_name”:“reverse_tunnel”,“error”:“Connect(): rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing failed to WebSocket dial: failed to send handshake request: Get \"https://subdomain.domain.com/-/kubernetes-agent/\\\”: context deadline exceeded""}
If I add the port manually to the kasAddress in the helm command the gitlab-kas/current log gives this error:
2022-09-07_07:44:01.55475 {“level”:“error”,“time”:“2022-09-07T07:44:01.553Z”,“msg”:“AgentInfo()”,“correlation_id”:“01GCBE78S0SX2BA5B48M3813W4”,“grpc_service”:“gitlab.agent.reverse_tunnel.rpc.ReverseTunnel”,“grpc_method”:“Connect”,“error”:“Get "https://subdomain.domain.com:50080/api/v4/internal/kubernetes/agent_info\”: dial tcp PUBLIC_IP:50080: i/o timeout"}
I've changed the external_url to use the default 443 port for https but the same i/o timeout error is found in the kas log
The problem was upstream on the mikrotik router. I needed a masquerade nat rule for the srcnat chain. In other words, the gitlab was not able to reach itself on the public IP
I'm new at consul and I try to setup a server-client environment. I have started my server with the following command and configuration:
consul.exe agent -ui -config-dir=P:\Consule\config
The config file looks the following ("P:\Consule\config\server.json")
{
"bootstrap": false,
"server": true,
"datacenter": "MyServices",
"data_dir": "P:\\Consule\\data",
"log_level": "INFO"
}
Output when I start consul from commandline with above command:
==> Starting Consul agent...
==> Consul agent running!
Version: 'v0.8.3'
Node ID: '1a244456-e725-44be-0549-33603ea7087d'
Node name: 'MYCOMPUTERNAMEA'
Datacenter: 'myservices'
Server: true (bootstrap: false)
Client Addr: 127.0.0.1 (HTTP: 8500, HTTPS: -1, DNS: 8600)
Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302)
Gossip encrypt: false, RPC-TLS: false, TLS-Incoming: false
Atlas: <disabled>
Now, at another computer in my domain I try to run an consul client with follwoing commandline and config-file:
consul.exe agent -config-dir C:\Consul -bind=127.0.0.1
Config file ("C:\Consul\client.json")
{
"server": false,
"datacenter": "MyServices",
"data_dir": "C:\\TEMP",
"log_level": "INFO",
"start_join": ["MYCOMPUTERNAMEA"]
}
But I always get follwing output/error message:
==> Starting Consul agent...
==> Joining cluster...
==> 1 error(s) occurred:
* Failed to join <IP_OF_MYCOMPUTERNAMEA>: dial tcp <IP_OF_MYCOMPUTERNAMEA>:8301: connectex: No connection could be made because the target machine actively refused it.
Does anyone know what I'm doing wrong?
Thanks and best regards
I suppose, the reason is that your server is available only for 127.0.0.1 ip-address, which is localhost ip and available only from the same server. This can be seen here:
Client Addr: 127.0.0.1 (HTTP: 8500, HTTPS: -1, DNS: 8600)
Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302)
You have to configure your server, to make it listening all network interfaces or some specific interface, which have to be available from other server.
Try to run it with the client and advertise options set to 0.0.0.0 (or some specific ip). Read about it here and here.
And you might have to delete -bind=127.0.0.1 from the client configuration, since it might be available from the server too.
I am using the mongo-express.
Installed on AWS EC2, it was started.
$ node app
Mongo Express server listening on port 8081 at localhost
Database connected
Connecting to db...
Database db connected
However, it is not possible to connect from the browser to port 8081.
I can download the index.html of the mongo-express using wget command on ec2.
$ wget http://admin:pass#localhost:8081
--2016-02-22 02:22:25-- http://admin:*password*#localhost:8081/
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:8081... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Authentication selected: Basic realm="Authorization Required"
Reusing existing connection to localhost:8081.
HTTP request sent, awaiting response... 200 OK
Length: 9319 (9.1K) [text/html]
Saving to: ?index.html?
index.html 0%[ ] 0 --.-KB/s GET / 200 218.468 ms - 9319
index.html 100%[===================>] 9.10K --.-KB/s in 0.04s
2016-02-22 02:22:26 (236 KB/s) - ?index.html? saved [9319/9319]
By the way, port 8081 in the security group of ec2 is open to my IP.
The following settings of config.js is, was the cause
site: { // baseUrl: the URL that mongo express will be located at - Remember to add the forward slash at the stard and end!
baseUrl: '/',
cookieKeyName: 'mongo-express',
cookieSecret: process.env.ME_CONFIG_SITE_COOKIESECRET || 'cookiesecret',
host: process.env.VCAP_APP_HOST || 'localhost',
port: process.env.VCAP_APP_PORT || 8081,
requestSizeLimit: process.env.ME_CONFIG_REQUEST_SIZE || '50mb',
sessionSecret: process.env.ME_CONFIG_SITE_SESSIONSECRET || 'sessionsecret',
sslCert: process.env.ME_CONFIG_SITE_SSL_CRT_PATH || '',
sslEnabled: process.env.ME_CONFIG_SITE_SSL_ENABLED || false,
sslKey: process.env.ME_CONFIG_SITE_SSL_KEY_PATH || '',
},
The value of the host is changed to "0.0.0.0", now to be able to connect from browser to the mongo-express.
In my case, I've got the issue because I wanted to expose my container on another port (4301).
But the express was still listening on 8081.
To fix it, had to specify indeed VCAP_APP_HOST and VCAP_APP_PORT.
And you can directly specify it on the run cmd like:
docker run --network YOUR_NETWORK --name YOUR_MONGO_EXPRESS_CONTAINER_NAME -e ME_CONFIG_MONGODB_SERVER=YOUR_MONGO_SERVER_IP -e VCAP_APP_HOST=0.0.0.0 -e VCAP_APP_PORT=4301 -p 4301:4301 mongo-express
As a test, I have a local bind instance running:
>netstat -ant | grep LISTEN
tcp 0 0 10.72.186.23:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
...
>nslookup mysubdomain.example.com 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: mysubdomain.example.com
Address: nn.nn.nn.251
Name: mysubdomain.example.com
Address: nn.nn.nn.249
Name: mysubdomain.example.com
Address: nn.nn.nn.201
Name: mysubdomain.example.com
Address: nn.nn.nn.138
I'm running haproxy 1.6.2 on the same host, with a resolvers section:
resolvers dns
nameserver dns1 127.0.0.1:53
nameserver dns2 10.72.186.23:53
hold valid 10s
It doesn't reject the resolvers section, but doesn't seem to be using it, either. It doesn't show in the stats page, and attempting to add this service command:
server mysubdomain-dev mysubdomain.example.com
causes this error:
>service haproxy restart
* Restarting haproxy haproxy
[ALERT] 322/171813 (10166) : parsing [/etc/haproxy/haproxy.cfg:77] : 'server mysubdomain-dev' : invalid address: 'mysubdomain.example.com' in 'mysubdomain.example.com'
[ALERT] 322/165300 (29751) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg
[ALERT] 322/165300 (29751) : Fatal errors found in configuration.
The haproxy doc https://cbonte.github.io/haproxy-dconv/configuration-1.6.html indicates this should work.
server <name> <address>[:[port]] [param*]
...
<address> is the IPv4 or IPv6 address of the server. Alternatively, a
resolvable hostname is supported, but this name will be resolved
during start-up. Address "0.0.0.0" or "*" has a special meaning.
Is there some other piece that needs to be added to the haproxy.cfg that activates the resolvers section?
When HAProxy first starts, it attempts to resolve the hostnames of any servers in all the backends to fill the server structures. During this first startup phase, HAProxy uses the OS resolver, i.e. generally the servers defined in your /etc/resolv.conf file.
Only later, when the server's IP addresses are updated during checks, HAProxy uses its internal resolver configuration and its internal DNS resolver.
From your error description, it now seems as if your host itself can not resolve the mysubdomain.example.com hostname. HAProxy will only be able to start if it can resolve the hostnames without an explicit named nameserver. This can be verified with e.g.
dig mysubdomain.example.com
might be you are not specifying the resolvers to use for that server
server mysubdomain-dev mysubdomain.example.com ->
server mysubdomain-dev mysubdomain.example.com resolvers dns