Wednesday, January 29, 2014
Force Postfix to read/use your hosts file
By default postfix use DNS to resolv names, if by any chance you need postfix to use your hosts file, you will need to configure the smtp_host_lookup option to you main.cf.
Postfix : 451 Error in processing Number of messages exceeds maximum per connection
If you have deferred mails with the following reason :
You might have an issue with your default_destination_recipient_limit option which is set to 50 by default.
In my case it was a bit more complicated, I had a custom transport for this destination (@hsbc.fr) with the destination_recipient_limit set to 5 and even with a setting of 2, I still had the same error coming from their servers...
The solution was to turn off on demand smtp connection caching, which is activated by default.
The postfix documentation says :
"Temporarily enable SMTP connection caching while a destination has a high volume of mail in the active queue. With SMTP connection caching, a connection is not closed immediately after completion of a mail transaction. Instead, the connection is kept open for up to $smtp_connection_cache_time_limit seconds. This allows connections to be reused for other deliveries, and can improve mail delivery performance."
http://www.postfix.org/postconf.5.html#smtp_connection_cache_on_demand
"high volume of mail" is unfortunately not specified. In my case, I had to send about 6K mails, the destination_recipient_limit was effective for this destination but Postfix reused the same SMTP connection which triggered HDBC mailserver limit.
Conclusion :
You can either disable SMTP connection caching globally in main.cf :
Or by smtp transport in master.cf (NOT TESTED) :
Hope that helps !
451 Error in processing Number of messages exceeds maximum per connection
You might have an issue with your default_destination_recipient_limit option which is set to 50 by default.
In my case it was a bit more complicated, I had a custom transport for this destination (@hsbc.fr) with the destination_recipient_limit set to 5 and even with a setting of 2, I still had the same error coming from their servers...
The solution was to turn off on demand smtp connection caching, which is activated by default.
The postfix documentation says :
"Temporarily enable SMTP connection caching while a destination has a high volume of mail in the active queue. With SMTP connection caching, a connection is not closed immediately after completion of a mail transaction. Instead, the connection is kept open for up to $smtp_connection_cache_time_limit seconds. This allows connections to be reused for other deliveries, and can improve mail delivery performance."
http://www.postfix.org/postconf.5.html#smtp_connection_cache_on_demand
"high volume of mail" is unfortunately not specified. In my case, I had to send about 6K mails, the destination_recipient_limit was effective for this destination but Postfix reused the same SMTP connection which triggered HDBC mailserver limit.
Conclusion :
You can either disable SMTP connection caching globally in main.cf :
smtp_connection_cache_on_demand = no
Or by smtp transport in master.cf (NOT TESTED) :
smtpslow unix - - n - - smtp
...
...
-o destination_recipient_limit=5
-o smtp_connection_cache_on_demand=off
Hope that helps !
Friday, October 11, 2013
Easy way to find your public IP in scripts or CLI
There is a lot of online tools that gives your public IP but most of them are either not accepting cli User-Agent or they require nasty parsing with AWK,grep,sed,etc
Best way to get your public IP address is to use ifconfig.me which only returns the IP; simple and efficient.
Another cool way is to query the opendns servers :
Best way to get your public IP address is to use ifconfig.me which only returns the IP; simple and efficient.
$ curl http://ifconfig.me
Another cool way is to query the opendns servers :
This method is pretty fast but requires the dig command (part of the bind-utils package).$ dig+shortmyip.opendns.com @resolver1.opendns.com
Dell Firmware update fails with "mktemp: too many templates"
If you have the following error while updating a Dell server firmware (BIOS, RAID, etc) via Linux binary (*.BIN) :
Then check the binary's filename for specials characters, in my case Chrome added a "(1)" at the end of the filename. Remove it, restart the update process and you're good to go !
mktemp: too many templates
Then check the binary's filename for specials characters, in my case Chrome added a "(1)" at the end of the filename. Remove it, restart the update process and you're good to go !
Linux server sends SYNACK packet only after receiving 8 SYN
Got a really weird issue recently, in some rare case (mostly Mac and Mobile phone clients), the connection to a linux server was really really slow (about 12s).
The issue was not only impacting Apache but all TCP services like SSH, hence it was not a particular service issue/misconfiguration.
The Chrome console on a MacBook Pro showed that the initial connection took about 10s, on the other hand a Win7 client in the same LAN had no problem at all.
After some digging on the client and server side, I found out that the client needs to send 8 SYN packets before the server replies with a SYNACK which explain why the connexion is so slow. Once the SYNACK is send back to the client, the communication speed is back to normal.
One hour headache later, it turn out that I enabled some Sysctl TCP tunning values that somehow introduced the issue.
I disabled the net.ipv4.tcp_tw_recycle and net.ipv4.tcp_tw_reuse features and everything went back to normal.
I think the problem comes from the net.ipv4.tcp_tw_reuse option, but as the issue impacted a production service (and is really hard to reproduce) I didn't try to re-enable tcp_tw_recycle.
Some posts advice to disable window scaling, I strongly disencourage this as it would result in poor network performances.
Hope that helps !
Below the tcpdump output that shows the 8 client's SYN packets before the SYNACK is sent back. Test was performed on SSH service as you can see, the TCP handshake took 10 secondes.
The issue was not only impacting Apache but all TCP services like SSH, hence it was not a particular service issue/misconfiguration.
The Chrome console on a MacBook Pro showed that the initial connection took about 10s, on the other hand a Win7 client in the same LAN had no problem at all.
After some digging on the client and server side, I found out that the client needs to send 8 SYN packets before the server replies with a SYNACK which explain why the connexion is so slow. Once the SYNACK is send back to the client, the communication speed is back to normal.
One hour headache later, it turn out that I enabled some Sysctl TCP tunning values that somehow introduced the issue.
I disabled the net.ipv4.tcp_tw_recycle and net.ipv4.tcp_tw_reuse features and everything went back to normal.
I think the problem comes from the net.ipv4.tcp_tw_reuse option, but as the issue impacted a production service (and is really hard to reproduce) I didn't try to re-enable tcp_tw_recycle.
Some posts advice to disable window scaling, I strongly disencourage this as it would result in poor network performances.
Hope that helps !
Below the tcpdump output that shows the 8 client's SYN packets before the SYNACK is sent back. Test was performed on SSH service as you can see, the TCP handshake took 10 secondes.
# SYN 1
15:57:26.303076 IP (tos 0x0, ttl 53, id 9488, offset 0, flags [DF], proto TCP (6), length 64)
client_ip.49316 > server_ip.ssh: Flags [S], cksum 0xdf5f (correct), seq 2356956535, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 835124724 ecr 0,sackOK,eol], length 0
# SYN 2
15:57:27.306416 IP (tos 0x0, ttl 53, id 37141, offset 0, flags [DF], proto TCP (6), length 64)
client_ip.49316 > server_ip.ssh: Flags [S], cksum 0xdb71 (correct), seq 2356956535, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 835125730 ecr 0,sackOK,eol], length 0
15:57:28.315804 IP (tos 0x0, ttl 53, id 2415, offset 0, flags [DF], proto TCP (6), length 64)
# SYN 3
client_ip.49316 > server_ip.ssh: Flags [S], cksum 0xd785 (correct), seq 2356956535, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 835126734 ecr 0,sackOK,eol], length 0
15:57:29.330233 IP (tos 0x0, ttl 53, id 62758, offset 0, flags [DF], proto TCP (6), length 64)
# SYN 4
client_ip.49316 > server_ip.ssh: Flags [S], cksum 0xd398 (correct), seq 2356956535, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 835127739 ecr 0,sackOK,eol], length 0
15:57:30.335779 IP (tos 0x0, ttl 53, id 29003, offset 0, flags [DF], proto TCP (6), length 64)
# SYN 5
client_ip.49316 > server_ip.ssh: Flags [S], cksum 0xcfa9 (correct), seq 2356956535, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 835128746 ecr 0,sackOK,eol], length 0
15:57:31.345254 IP (tos 0x0, ttl 53, id 5246, offset 0, flags [DF], proto TCP (6), length 64)
# SYN 6
client_ip.49316 > server_ip.ssh: Flags [S], cksum 0xcbba (correct), seq 2356956535, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 835129753 ecr 0,sackOK,eol], length 0
15:57:33.382242 IP (tos 0x0, ttl 53, id 5958, offset 0, flags [DF], proto TCP (6), length 64)
# SYN 7
client_ip.49316 > server_ip.ssh: Flags [S], cksum 0xc3dc (correct), seq 2356956535, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 835131767 ecr 0,sackOK,eol], length 0
15:57:37.881881 IP (tos 0x0, ttl 53, id 21274, offset 0, flags [DF], proto TCP (6), length 48)
# SYN 8
client_ip.49316 > server_ip.ssh: Flags [S], cksum 0x5c3d (correct), seq 2356956535, win 65535, options [mss 1460,sackOK,eol], length 0
15:57:37.881907 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 48)
# SYNACK (at last !!!)
server_ip.ssh > client_ip.49316: Flags [S.], cksum 0x7a12 (correct), seq 3228952474, ack 2356956536, win 14600, options [mss 1460,nop,nop,sackOK], length 0
15:57:37.885362 IP (tos 0x0, ttl 53, id 62772, offset 0, flags [DF], proto TCP (6), length 40)
# ACK
client_ip.49316 > server_ip.ssh: Flags [.], cksum 0xdfde (correct), seq 1, ack 1, win 65535, length 0
Wednesday, October 9, 2013
Juniper JunOS transfer on commit fails
I had quite a surprise when I discover that my transfer on commit stopped working on my SRX firewall.
The error in the logfile was :
Not really explicit...
Turn out that /cf/var/ was full, it needs at least some free MB to work properly, that sound weird as the config file only requires several KB.
The configuration is indeed copied to /cf/var/transfer/config/ before being transferred over the network. If /cf/var/ is full then the configuration cannot be copied and the transfer process finds nothing to send hence the error message above.
If you have the same error, cleanup some old logfiles and maybe decrease the amount of data you're logging.
For any other errors, I recommend this post which explains all the other issues you may have with transfer on commit.
http://www.net-gyver.com/?p=655
Hope that helps !
The error in the logfile was :
ACCT_XFER_FAILED: Error transferring /var/transfer/config/*
Not really explicit...
Turn out that /cf/var/ was full, it needs at least some free MB to work properly, that sound weird as the config file only requires several KB.
The configuration is indeed copied to /cf/var/transfer/config/ before being transferred over the network. If /cf/var/ is full then the configuration cannot be copied and the transfer process finds nothing to send hence the error message above.
If you have the same error, cleanup some old logfiles and maybe decrease the amount of data you're logging.
For any other errors, I recommend this post which explains all the other issues you may have with transfer on commit.
http://www.net-gyver.com/?p=655
Hope that helps !
Monday, September 2, 2013
Squirrel Mail crash with "PHP Fatal error: Call to undefined function sqimap_run_literal_command()"
I have encountered a bug on Squirrel Mail (version 1.4.8-21), the client's credentials are accepted but the page is then stucked on "webmail/src/redirect.php"
On the Apache side, I noticed the following PHP error :
After some debugging, I found out that Squirrel Mail does NOT properly handle specials characters; In this case I had an accent in the user password.
I reseted the user's password and everything went back to normal.
Hope that helps !
On the Apache side, I noticed the following PHP error :
PHP Fatal error: Call to undefined function sqimap_run_literal_command() in /usr/share/squirrelmail/functions/imap_general.php on line 518
After some debugging, I found out that Squirrel Mail does NOT properly handle specials characters; In this case I had an accent in the user password.
I reseted the user's password and everything went back to normal.
Hope that helps !
Subscribe to:
Posts (Atom)