I have a squid proxy logging access logs to a file and syslog-ng reading those logs and based on squid's action it sets a severity - either info or notice - and forwards that as a syslog message to a NetXMS server. The problem is that the NetXMS server receives the messages like this:

1 2024-04-17T11:13:11+02:00 vvsrv-proxy1 1713345191.357 - - [meta sequenceId="5336"]     69 10.30.108.14 TCP_TUNNEL/200 3530 CONNECT api.github.com:443 - HIER_DIRECT/140.82.121.5 -

(The empty line isn't a formatting error.) I'd like to forward the lines as-is from the file to NetXMS, so like this:

1713345191.357 69 10.30.108.14 TCP_TUNNEL/200 3530 CONNECT api.github.com:443 - HIER_DIRECT/140.82.121.5 -

The current syslog-ng config (excluding the default parts):

source s_squid {
    file ("/var/log/squid/access.log");
};

filter f_squid_denied {
        message ("TCP_DENIED");
};

destination d_squid {
        syslog ("10.0.0.254" transport("udp") port(514) template("${MSG}"));
};

log {
    source (s_squid);
    filter (f_squid_denied);
    rewrite { set_severity("notice"); };
    destination (d_squid);
};

log {
    source (s_squid);                                                                          
    rewrite { set_severity("info"); };
    destination (d_squid);                                                                   
};

Version info:

syslog-ng 4 (4.1.1)
Config version: 4.0

When I tried to solve it myself I found that incorrect syslog headers from the source can cause the relaying syslog-ng server to add it's own header, but in my case the source is a local file. I also tried to switch to the legacy network driver - instead of syslog - but it was still the same.

When I used rsyslog to just forward syslogs to NetXMS it didn't have any extra data, so NetXMS is parsing and handling syslog messages as it should.

Update #1

After some digging in NetXMS source I found out from the date parsing method that it can only parse RFC 3164 syslog messages. After reading the syslog-ng docs about using the legacy protocol I tried the following:

destination d_squid {
        network ("10.0.0.254" transport(udp) port(514));
};

But it still uses the new RFC 5424 format.

Update #2

I was using service syslog-ng reload and that wasn't sufficient, after restarting the service it started using the BSD syslog format. After some tuning my destination now look like this:

destination d_squid {                                                               
        network ("10.0.0.254" transport(udp) port(514) flags(no-multi-line) template(": ${MSG}"));
};

I didn't change any other part of the config, but now all log entries have Notice severity instead of entries containing the TCP_DENIED substring.

I have a GitLab instance running in docker. GitLab works fine however I can't access GitLab Pages.

The setup

Overview

           +------------+
Request+-->+ Cloudflare |
           +-----+------+
                 |
                 v       +---------+
               Nginx+--->+Docker   |
                         |  +------+
                         |  |GitLab|
                         +---------+

The problem is that Nginx can't pass the request to the GitLab Pages server (note that GitLab it self works).
Nginx error log entry

[error] 14932#14932: *30505 connect() failed (111: Connection refused) while connecting to upstream, [...]

Docker

image: gitlab/gitlab-ce
version: 13.7.1 (latest)
ip: 172.17.0.7 (dynamic)
published ports:
    172.17.0.1:8080 -> 80
    172.17.0.1:8090 -> 8090

Nginx

Server entry for Pages

server {
        listen 80 default_server;
        listen 443 default_server;
        server_name _;
        
        location / {
                proxy_pass      http://172.17.0.1:8090;
        }
}

GitLab

grep -v '^#|^$' gitlab.rb¹

nginx['listen_port'] = 80
nginx['listen_https'] = false
pages_external_url "http://pages.example.com/"
gitlab_pages['enable'] = true
gitlab_pages['external_http'] = []
gitlab_pages['listen_proxy'] = "localhost:8090"
gitlab_pages['inplace_chroot'] = true
gitlab_pages['metrics_address'] = ":9235"
pages_nginx['enable'] = true
pages_nginx['listen_https'] = false
pages_nginx['redirect_http_to_https'] = false

Also tried with the absolute minimum config, only defining pages_external_url and gitlab_pages['enable'].

Tracing down the problem

1. Request to pages.example.com failed with 502 (Bad Gateway) from CF
2. Checked Nginx log, found the above mentioned log entry
3. Made multiple requests from the host to the container
   1. # curl 172.17.0.1:8090 -> curl: (7) Failed to connect to 172.17.0.1 port 8090: Connection refused
   2. # curl 172.17.0.7:8090 -> curl: (7) Failed to connect to 172.17.0.7 port 8090: Connection refused
4. Made a request from the container
   # curl localhost:8090 -> 404 error page

From this I assume that something is blocking incomming traffic for 8090 (GitLab Pages), but requests to 80 (GitLab) are completed successfully. I spent a couple of days googling this issue but I couldn't find anything.