Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure consistent hostname logging behavior in nginx logs #897

Closed
cotosso opened this issue Nov 11, 2024 · 3 comments
Closed

Ensure consistent hostname logging behavior in nginx logs #897

cotosso opened this issue Nov 11, 2024 · 3 comments
Assignees
Labels
verified All test cases were verified successfully

Comments

@cotosso
Copy link
Contributor

cotosso commented Nov 11, 2024

Currently, the log format used by nginx differs from other logs, as it writes the hostname twice, causing inconsistency and visual misalignment with the rest of the log entries. This behavior can be seen in the following examples:

Expected Behavior (similar to other logs):

Nov 11 14:07:18 NSec8-VM-davidem nethsecurity-api[4929]: nethsecurity_api 2024/11/11 14:07:18 middleware.go:199: [INFO][AUTH] refresh response success for user root

Current Nginx Behavior:

Nov 11 14:07:18 NSec8-VM-davidem nsec8-vm-davidem nginx: 192.168.56.1 - - [11/Nov/2024:14:07:18 +0000] "GET /api/refresh HTTP/1.1" 200 254 "https://192.168.56.104:9090/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36"

Explanation and Purpose

  • WHY: The discrepancy in logging format creates inconsistency when viewing logs from multiple daemons. This may lead to confusion during log analysis, troubleshooting, and system auditing, especially in environments where uniformity across logs is essential.
  • PURPOSE: Ensuring that Nginx logs follow the same logging format as other daemons would promote uniformity, making it easier to parse and visually inspect logs.

Proposed Solution

Modify the nginx log format to prevent the hostname from being written twice.

Components

NethSecurity version: 8-23.05.5-ns.1.3.0

@cotosso
Copy link
Contributor Author

cotosso commented Nov 11, 2024

This needs to be fixed for both port 443 and 9090.

For port 443 it should be enough to use this fix:

uci set nginx._lan.access_log='syslog:server=unix:/dev/log,nohostname'
uci commit nginx

For port 9090 this should fix it:

root@NSec8-VM-davidem:~# diff -u /etc/nginx/conf.d/ns-ui.conf.ori /etc/nginx/conf.d/ns-ui.conf
--- /etc/nginx/conf.d/ns-ui.conf.ori    2024-10-03 11:26:06.000000000 +0000
+++ /etc/nginx/conf.d/ns-ui.conf        2024-10-31 15:01:08.168405068 +0000
@@ -6,8 +6,8 @@
        ssl_certificate_key /etc/nginx/conf.d/_lan.key;
        ssl_session_cache shared:SSL:32k;
        ssl_session_timeout 64m;
-       error_log syslog:server=unix:/dev/log;
-       access_log syslog:server=unix:/dev/log;
+       error_log syslog:server=unix:/dev/log,nohostname;
+       access_log syslog:server=unix:/dev/log,nohostname;

        # enable NS UI
        location / {

if you want to try it you 'll need also to restart the service:

/etc/init.d/nginx restart

@Tbaile
Copy link
Contributor

Tbaile commented Nov 14, 2024

Image: 23.05.5-ns.1.3.0-41-g7436b45

Try the new image, ensure configuration is set correctly.
Try to update a regular installation with the new one, check that the values get updated.

@Tbaile Tbaile added the testing Packages are available from testing repositories label Nov 14, 2024
@Tbaile Tbaile moved this from ToDo 🕐 to Testing in NethSecurity Nov 14, 2024
@Tbaile Tbaile assigned cotosso and unassigned Tbaile Nov 14, 2024
@cotosso
Copy link
Contributor Author

cotosso commented Nov 18, 2024

tested on port 9090 and 443 it works as expected:

Nov 18 20:18:42 NethSec.localdomain nginx: 192.168.56.1 - - [18/Nov/2024:20:18:42 +0000] "POST /api/ubus/call HTTP/1.1" 200 323 "https://192.168.56.104:9090/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36"

@cotosso cotosso added verified All test cases were verified successfully and removed testing Packages are available from testing repositories labels Nov 18, 2024
@nethbot nethbot moved this from Testing to Verified in NethSecurity Nov 18, 2024
@github-project-automation github-project-automation bot moved this from Verified to Done ✅ in NethSecurity Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
verified All test cases were verified successfully
Projects
Archived in project
Development

No branches or pull requests

3 participants