All Questions(server)

We have configured the BBR settings on all our RHEL 8.6 machines as follows: (according to Red Hat's documentation [https://access.redhat.com/solutions/3713681]). The goal is to assess whether the BBR configuration provides any network improvements. If not, we plan to revert to the default Cubic settings

sysctl -w net.ipv4.tcp_congestion_control=bbr
echo "net.ipv4.tcp_congestion_control = bbr" >> /etc/sysctl.conf
modprobe tcp_bbr

in order to revert the changes I wrote the following steps

sysctl -w net.ipv4.tcp_congestion_control=cubic
delete from /etc/sysctl.conf the line with net.ipv4.tcp_congestion_control = bbr

but I am not sure how to revert the changes about modprobe tcp_bbr

do we need just do:

modprobe tcp_cubic

or

rmmod tcp_bbr
rmmod: ERROR: Module tcp_bbr is in use

or else ?

I'm running two services (backend and api) on the same port inside Docker. However, whenever I send requests, NGINX routes all requests to the backend service, and I cannot access the api service properly.

I suspect it's a problem with my NGINX configuration.

Here are my files:

docker-compose.yml

version: '3.8'

services:
  backend:
    build:
      context: .
      dockerfile: ./backend/Dockerfile.dev
    volumes:
      - ./backend:/var/www/html/backend
    environment:
      - APP_ENV=development
    networks:
      - bysooq-network
    expose:
      - 9000
    env_file:
      - .env

  api:
    build:
      context: .
      dockerfile: ./api/Dockerfile.dev
    volumes:
      - ./api:/var/www/html/api
    environment:
      - APP_ENV=development
    networks:
      - bysooq-network
    expose:
      - 9000
    env_file:
      - .env

  postgres:
    image: postgres:13
    restart: always
    volumes:
      - ~/bysooq-data/postgres:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: xxx
      POSTGRES_USER: xx
      POSTGRES_PASSWORD: xxx
    networks:
      - bysooq-network

  redis:
    image: redis:latest
    ports:
      - "6380:6379"
    restart: always
    networks:
      - bysooq-network

  nginx:
    image: nginx:latest
    volumes:
      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf
      - ./api:/var/www/html/api
      - ./backend:/var/www/html/backend
    ports:
      - 80:80
    depends_on:
      - backend
      - api
    networks:
      - bysooq-network

networks:
  bysooq-network:
    driver: bridge

nginx default.conf

nginx

server {
    listen 80;
    server_name localhost;
    client_max_body_size 100M;
    index index.php;

    # API Service - Must come first with strict matching
    location ~ ^/api(/.*)?$ {
        root /var/www/html/api/web;
        try_files $1 $1/ /index.php$is_args$args;

        location ~ \.php$ {
            fastcgi_pass api:9000;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root/index.php;
            fastcgi_param REQUEST_URI $1$is_args$args;
        }
    }

    # Backend Service
    location / {
        root /var/www/html/backend/web;
        try_files $uri $uri/ /index.php$is_args$args;

        location ~ \.php$ {
            fastcgi_pass backend:9000;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        }
    }
}

What I expect:

Requests to /api/* should go to the api service.

Other requests should go to the backend service.

What happens:

All requests (even /api/...) are handled by the backend.

Question: How can I correctly configure NGINX to route /api/* requests to the API service and other requests to the backend service?

Thanks in advance!

I searched everywhere online, and all sources seem to suggest that it's a DNS resolution issue. However, DNS resolve fine on my machine, and whois queries to other TLDs (e.g. .com) doesn't have this issue.

I also tried on several different machines, giving the same result.

Mon 04-28 03:49 OVH root ~
> whois google.com | head
   Domain Name: GOOGLE.COM
   Registry Domain ID: 2138514_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.markmonitor.com
   Registrar URL: http://www.markmonitor.com
   Updated Date: 2019-09-09T15:39:04Z
   Creation Date: 1997-09-15T04:00:00Z
   Registry Expiry Date: 2028-09-14T04:00:00Z
   Registrar: MarkMonitor Inc.
   Registrar IANA ID: 292
   Registrar Abuse Contact Email: [email protected]

Mon 04-28 03:49 OVH root ~
> whois icann.org | head
This domain is protected by the Registry Lock service. If you are the registrant and wish to take action on this lock, please contact your registrar.

Domain Name: icann.org
Registry Domain ID: 628dbbcb4edc464b9401cbadea0a08b2-LROR
Registrar WHOIS Server: http://whois.cscglobal.com
Registrar URL: http://www.cscglobal.com/global/web/csc/digital-brand
Updated Date: 2025-01-31T20:19:44Z
Creation Date: 1998-09-14T04:00:00Z
Registry Expiry Date: 2028-12-07T17:04:26Z
Registrar: CSC Corporate Domains, Inc.

Mon 04-28 03:49 OVH root ~
> whois nic.app | head
getaddrinfo(whois.nic.app): Name or service not known

My Wireguard setup suddenly stopped working yesterday after no config or key changes. For troubleshooting, I've stripped it down to its simplest config. A client on my network should connect to a server running on a VPS.

Server ("outpost") config:

outpost:~# cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <outpost-privkey>
Address = 10.5.0.1/16
MTU = 1440
ListenPort = 51820

[Peer]
PublicKey = <rp-pubkey>
AllowedIPs = 10.5.0.2/32
PersistentKeepAlive = 13

Client ("rp") config:

rp:~# cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <rp-privkey>
Address = 10.5.0.2/16
MTU = 1440

[Peer]
PublicKey = <outpost-pubkey>
Endpoint = <outpost-ip>:51820
AllowedIPs = 10.5.0.1/32
PersistentKeepAlive = 23

Using dmesg and tcpdump I can observe repeated attempts at handshake initiation are sent from the client:

rp:~# dmesg -wT
...
[Fri Apr 25 23:45:18 2025] wireguard: wg0: Sending handshake initiation to peer 1 (<outpost-ip>:51820)

rp:~# tcpdump -n -vvv -i ens18 udp port 51820
...
23:45:19.115710 IP (tos 0x88, ttl 64, id 34886, offset 0, flags [none], proto UDP (17), length 176)
    <rp-ip>.48825 > <outpost-ip>.51820: [bad udp cksum 0x825d -> 0x3db4!] UDP, length 148

The server receives the packet:

outpost:~# tcpdump -n -vvv -i enp0s6 udp port 51820
...
23:45:19.129033 IP (tos 0x8, ttl 55, id 34886, offset 0, flags [none], proto UDP (17), length 176)
    <rp-ip>.46567 > <outpost-rp>.51820: [udp sum ok] UDP, length 148

But Wireguard on the server shows no indication that it received anything.

outpost:~# wg
interface: wg0
  public key: <outpost-pubkey>
  private key: (hidden)
  listening port: 51820

peer: <rp-pubkey>
  allowed ips: 10.5.0.2/32
  persistent keepalive: every 13 seconds

The server regularly attempts to send handshake initiation of its own:

outpost:~# dmesg -wT
[Fri Apr 25 23:46:45 2025] wireguard: wg0: Sending handshake initiation to peer 1 ((einval))

But as the server has no knowledge of the client's (dynamic) public IP, this handshake initiation does not appear on either server or client using tcpdump.

Both machines use the same NTP server (ntp.ubuntu.com) and are synchronized correctly. My MTU of 1440 is optimized for my setup, and the behaviour does not change without this line. I've also regenerated the server/client keys multiple times with no changes in behaviour.

iptables are set correctly on server/client:

# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
...

UFW is not installed.

Any suggestions are appreciated.

I am installing Solr 9.6.1 on Unix by follwing this link and I am able to start the service through below command

service solr start

But I am not able to start the service through systemctl. On executing systemctl start solr gives below message

Job for solr.service failed because the control process exited with error code.
See "systemctl status solr.service" and "journalctl -xeu solr.service" for details.

Executing systemctl status solr gives below message

× solr.service - Apache SOLR
     Loaded: loaded (/etc/systemd/system/solr.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Fri 2025-04-25 02:54:41 EDT; 1min 19s ago
    Process: 5298 ExecStart=/opt/solr/bin/solr start -noprompt (code=exited, status=1/FAILURE)
        CPU: 89ms
 
systemd[1]: solr.service: Scheduled restart job, restart counter is at 5.
systemd[1]: Stopped Apache SOLR.
systemd[1]: solr.service: Start request repeated too quickly.
systemd[1]: solr.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Apache SOLR.

Below is the content of /etc/systemd/system/solr.service

[Unit]
Description=Apache SOLR
After=syslog.target network.target remote-fs.target nss-lookup.target
 
[Service]
Type=forking
PIDFile=/var/solr/solr-8983.pid
Environment=SOLR_INCLUDE=/etc/sysconfig/solr
ExecStart=/opt/solr/bin/solr start -noprompt
ExecStop=/opt/solr/bin/solr stop -noprompt
ExecReload=/bin/kill -s HUP $MAINPID
Restart=on-failure
User=solr
PrivateTmp=true
TimeoutSec=180s
LimitNOFILE=65000
LimitNPROC=65000
 
[Install]
WantedBy=multi-user.target