Julien's questions

I'm facing a strange problem when I try to load a big iptables set of rules on a LXC container (it's working fine on a virtual machine).

The container is running Linux Debian 12 bookworm.

I'm able to configure the rules and save them with:

 /usr/sbin/netfilter-persistent save

However, if I try to load them, I get this error message ( the file is 694 chars length)

$ sudo  iptables-restore < /etc/iptables/rules.v4
sendmsg() failed: Message too long
iptables-restore: line 692 failed: Message too long.

What's weird is that if I add the verbose mode it is working fine

$ sudo  iptables-restore -v < /etc/iptables/rules.v4 && echo ok
(...)
# Completed on Fri Sep 15 08:57:48 2023
ok

However, if I try to load a big file (33750 lines), I'm always getting the "Message too long" error, in verbose mode or not.

All the loading tests are working fine on a virtual machine (same os).

So I'm wondering if there is a line limit or memory limit somewhere in LXC ? I have tried to play with limits.conf but it didn't change anything yet.

Any idea ?

EDIT Here are more information to reproduce this behavior:

Kernel version:

Linux xxxxxx 6.2.16-10-pve #1 SMP PREEMPT_DYNAMIC PMX 6.2.16-10 (2023-08-18T11:42Z) x86_64 GNU/Linux

Some packages version (guest container):

ii  iptables                            1.8.9-2                                 amd64        administration tools for packet filtering and NAT
ii  iptables-persistent                 1.0.20                                  all          boot-time loader for netfilter rules, iptables plugin
ii  libip4tc2:amd64                     1.8.9-2                                 amd64        netfilter libip4tc library
ii  libip6tc2:amd64                     1.8.9-2                                 amd64        netfilter libip6tc library
ii  libnetfilter-conntrack3:amd64       1.0.9-3                                 amd64        Netfilter netlink-conntrack library
ii  libxtables12:amd64                  1.8.9-2                                 amd64        netfilter xtables library
ii  netfilter-persistent                1.0.20                                  all          boot-time loader for netfilter configuration

host packages:

ii  lxc-pve                              5.0.2-4                             amd64        Linux containers userspace tools
ii  lxcfs                                5.0.3-pve3                          amd64        LXC userspace filesystem
ii  pve-lxc-syscalld                     1.3.0                               amd64        PVE LXC syscall daemon

The little ruleset is :

# Generated by iptables-save v1.8.9 (nf_tables) on Fri Sep 15 08:57:48 2023
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:block_spam2 - [0:0]
:block_spam1 - [0:0]
:block_spam3 - [0:0]
:incoming_net - [0:0]
:sensitive_daemons - [0:0]
-A INPUT -j block_spam1
-A INPUT -j block_spam2
-A INPUT -j block_spam3
-A INPUT -j sensitive_daemons
-A INPUT -j incoming_net
-A INPUT -j sensitive_daemons
-A block_spam2 -s 1.0.1.0/24 -j DROP
-A block_spam2 -s 84.22.192.0/19 -j DROP
-A block_spam1 -s 103.39.156.0/22 -j DROP
-A block_spam1 -s 5.255.220.0/22 -j DROP
-A block_spam3 -s 87.245.234.136/32 -j DROP
-A block_spam3 -s 217.199.224.0/19 -j DROP
[...] 675 lines here : block_spam[1-3] with a uniq ip address [...]
-A incoming_net -d 192.168.1.248/29 -p tcp -m tcp --dport 80 -j ACCEPT
-A incoming_net -d 192.168.1.248/29 -p tcp -m tcp --dport 443 -j ACCEPT
-A incoming_net -d 192.168.1.248/29 -p tcp -j DROP
-A sensitive_daemons -s 192.168.1.248/29 -p tcp -m tcp --dport 22 -j DROP
-A sensitive_daemons -s 192.168.1.0/24 -d 192.168.1.24/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A sensitive_daemons -p tcp -m tcp --dport 22 -j DROP
COMMIT
# Completed on Fri Sep 15 08:57:48 2023

I'm facing a strange behavior on varnish 6, and I would need some advices to find out what's wrong. This occures on empty POST/PUT requests.

Everything is working well on recipe platform but fails on production plateform with error :

transfer closed with outstanding read data remaining

Here is the detailed tests :

$ curl -v -X PUT --data "" "http://<prod-varnish-server>:81/"
* Expire in 0 ms for 6 (transfer 0x55ee8ab12f50)
*   Trying 10.10.10.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55ee8ab12f50)
* Connected to 10.10.10.10 (10.10.10.10) port 81 (#0)
> PUT / HTTP/1.1
> Host: ************
> User-Agent: curl/7.64.0
> Accept: */*
> Content-Length: 0
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200 OK
< Date: Tue, 29 Sep 2020 08:21:55 GMT
< Server: Apache
< Vary: cookie,authorization,Accept-Encoding
< Content-Type: text/html; charset=UTF-8
< X-Backend: web1
< X-ttl: 0.000
< X-Varnish: 463
< Age: 0
< Via: 1.1 varnish (Varnish/6.1)
< X-Debug-Served-By: front_nodes
< X-Debug-varnishHost: frd825p103fel.itc.integra.fr
< X-Debug-User-Hash:
< X-Debug-Cache-Control: public, s-maxage=86400
< X-Cache: MISS
< Cache-Control: public
< Accept-Ranges: bytes
< Transfer-Encoding: chunked
< Connection: keep-alive
<
* transfer closed with outstanding read data remaining
* Closing connection 0


$ curl -v -X PUT --data "" "http://<prod-apache-backend>:82/"
* Expire in 0 ms for 6 (transfer 0x55b5beda8f50)
*   Trying 10.10.10.11...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b5beda8f50)
* Connected to 10.10.10.11 (10.10.10.11) port 82 (#0)
> PUT / HTTP/1.1
> Host: ************
> User-Agent: curl/7.64.0
> Accept: */*
> Content-Length: 0
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200 OK
< Date: Tue, 29 Sep 2020 08:22:29 GMT
< Server: Apache
< Cache-Control: public, s-maxage=86400
< Vary: cookie,authorization,Accept-Encoding
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
<
 ... html code data


$ curl -v -X PUT --data "" "http://<rec-varnish-server>:81/"
*   Trying 10.10.10.10...
* TCP_NODELAY set
* Connected to 10.10.10.10 (10.10.10.10) port 81 (#0)
> PUT / HTTP/1.1
> Host: ************
> User-Agent: curl/7.52.1
> Accept: */*
> Content-Length: 0
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200 OK
< Date: Tue, 29 Sep 2020 08:25:45 GMT
< Server: Apache
< Vary: cookie,authorization,Accept-Encoding
< Content-Type: text/html; charset=UTF-8
< X-Backend: web2
< X-ttl: 0.000
< X-Varnish: 32777
< Age: 0
< Via: 1.1 varnish (Varnish/6.0)
< X-Debug-Served-By: front_nodes
< X-Debug-varnishHost: INTEZPUBCACHE.itc.integra.fr
< X-Debug-User-Hash:
< X-Debug-Cache-Control: public, s-maxage=86400
< X-Cache: MISS
< Cache-Control: public
< Accept-Ranges: bytes
< Transfer-Encoding: chunked
< Connection: keep-alive
<
 ... html code data
* Curl_http_done: called premature == 0
* Connection #0 to host 127.0.0.1 left intact

On production environment :

• varnishd (varnish-6.1.1 revision efc2f6c1536cf2272e471f5cff5f145239b19460)
• curl 7.64.0 (x86_64-pc-linux-gnu) libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3

On recipe environment :

• varnishd (varnish-6.0.6 revision 29a1a8243dbef3d973aec28dc90403188c1dc8e7)
• curl 7.52.1 (x86_64-pc-linux-gnu) libcurl/7.52.1 OpenSSL/1.0.2q zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3

Thank you

I'm facing a strange behavior on phpmyadmin + redis php session cache. Here is my php-fpm pool configuration :

php_value[session.save_handler] = redis
php_value[session.save_path]    = "tcp://127.0.0.1:6379"

This configurations works fine for a simple php script :

<?php
//simple counter to test sessions. should increment on each page reload.
session_start();


$count = isset($_SESSION['count']) ? $_SESSION['count'] : 1;

echo $count;

echo "<br>";

$_SESSION['count'] = ++$count;


$username = $_SESSION['username'];
if(isset($_SESSION['logged']) && $_SESSION['logged']=='yes') {
    echo "$username";
}   

$_SESSION['username']='Teddy';
$_SESSION['logged']='yes';



?>

I see the increment and the Teddy message.

But when I try to access to phpmyadmin through 'http://myserver/phpmyadmin' I always get the authentication page, even after successfull login, I'm always redirected to that login page...

If I switch to path sessions :

php_value[session.save_handler] = files
php_value[session.save_path]    = /var/www/vhost/sessions

Everything works well (my php script and phpmyadmin).

I would like to know if somebody experienced a similar issue and if there is a fix ? Could this be a limitation of phpmyadmin ?

I'm runing on Linux Debian 8.6 + phpmyadmin 4.2.12-2 + php5-fpm 5.6.24 + redis-server 3.2.4-1.

My vhost is configured this way :

Alias /webops /usr/share/phpmyadmin
...


<FilesMatch "(^$|\.php$)">
        SetHandler "proxy:unix:///var/run/php-fpm/vhost.sock|fcgi://vhost/"
</FilesMatch>

<Proxy fcgi://vhost/$1 >
</Proxy>

RewriteCond %{REQUEST_FILENAME} .php$
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_URI} !-f
RewriteRule (.*) - [H=text/html]
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

Thank you Bests Julien

I'm facing a strange issue on joomla and would need help to solve it :

The frontoffice side is working fine but when trying to log in backoffice, I get a HTTP 503 Error :

[Wed Jul 29 17:41:02.023862 2015] [proxy_fcgi:error] [pid 32285] (70007)The timeout specified has expired: [client <client IP>:55665] AH01075: Error dispatching request to :, referer: http://my-website/administrator/index.php

http://my-website/administrator/index.php is the backoffice login page. I can access to it before login but I get the 503 error after login with successfull credentials :

Access before login :

GET http://my-website/administrator/index.php HTTP/1.1
=> HTTP/1.0 200 OK

On succcessfull login, there is a first redirection and then the 503 :

POST http://pmy-website/administrator/index.php HTTP/1.1
Host: my-website
...
=> HTTP/1.0 303 See Other
Date: Thu, 30 Jul 2015 09:23:57 GMT
Server: Apache
Location: http://my-website/administrator/index.php
...

GET http://my-website/administrator/index.php HTTP/1.1
Host: my-website
Referer: http://my-website/administrator/index.php
Cookie: 3f74c53723c2b649b1df9afa77de6e27=tung6luvahdj9v39cdlqmv4kh3
...
=> HTTP/1.0 503 Service Unavailable
...

A clue : After the 503 error page, I can paste a URL with the section to open. It works ! For example :

http://my-website/administrator/index.php?option=com_config

The only unavailable URL is index.php without parameter... So I believe that could be an URL Rewriting issue...

My config : Centos 6.6 / joomla v3.3.1 / php 5.4.16 / - apache v2.4.6 + php-fpm.

Thank you in advance if you could help me. Bests Julien

I'm facing a strange ipv6 behavior and I don't know how to solve it because I'm not familiar with ipv6. Maybe this behavior is normal. I hope that you will help me. ( I'm running under debian 6.0.9 with a custom kernel 3.2.58 )

machine A is "2a00:7d30:edf6:100::1" wants to ping machine B, which is "2a00:7d30:edf6:100::10". Both are on the same segment.

machine A asks for the address of machine B and I don't understand why machine B gives its global scope address instead of the local scope one ?

10:59:02.082785 IP6 2a00:7d30:edf6:100::1 > ff02::1:ff00:10: ICMP6, neighbor solicitation, who has 2a00:7d30:edf6:100::10, length 32

10:59:02.082821 IP6 2a00:7d30:edf6:100::10 > 2a00:7d30:edf6:100::1: ICMP6, neighbor advertisement, tgt is 2a00:7d30:edf6:100::10, length 32

after that machine A pings the global scope address of machine B and it works fine :

10:59:02.082927 IP6 2a00:7d30:edf6:100::1 > 2a00:7d30:edf6:100::10: ICMP6, echo request, seq 1, length 64

10:59:02.082960 IP6 2a00:7d30:edf6:100::10 > 2a00:7d30:edf6:100::1: ICMP6, echo reply, seq 1, length 64

Thank you for you help best regards Julien