Every hour one MariaDB version 10.4 database stops responding and I see this output in the log file:

Feb  9 10:00:02 maria55 mysqld: 2023-02-09 10:00:02 0x7f72547a5700  InnoDB: Assertion failure in file /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.4.13/storage/innobase/btr/btr0cur.cc line 7940
Feb  9 10:00:02 maria55 mysqld: InnoDB: Failing assertion: space_id == page_get_space_id(page)
Feb  9 10:00:02 maria55 mysqld: InnoDB: We intentionally generate a memory trap.
Feb  9 10:00:02 maria55 mysqld: InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
Feb  9 10:00:02 maria55 mysqld: InnoDB: If you get repeated assertion failures or crashes, even
Feb  9 10:00:02 maria55 mysqld: InnoDB: immediately after the mysqld startup, there may be
Feb  9 10:00:02 maria55 mysqld: InnoDB: corruption in the InnoDB tablespace. Please refer to
Feb  9 10:00:02 maria55 mysqld: InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
Feb  9 10:00:02 maria55 mysqld: InnoDB: about forcing recovery.

The server is running Kopano and although I can't find any prominent CRONs that cause this problem exactly on the hour, I fully suspect Kopano has some maintenance routines every hour triggering the crash.

The advice about corruption in InnoDB sounds legitimate, but I don't know how to do that the links are not clear.

For now we did a mysqlcheck kopano and database checks works 100%

Googling further doesn't really show anything.

I'm at a loss what to try next.

My one idea is to upgrade the database to see if any 'bugs' might be squashed, but when we did a dump to the same disk, this happened:

mysqldump --single-transaction --routines kopano -r kopanodb.sql

mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table 'lob' at row: 166961

Now I have a secondary problem in that I can't make a backup. The total size of the database is 80GB!

My idea was to upgrade MariaDB but now I am scared things go catastrophically wrong and I won't have a good backup.

My other idea was to maybe stop the MariaDB service and then copy /var/lib/mysql to a temporary location, all 80 GB, and then at least maybe this will be an okay backup.

Any other ideas or tips?

I found excellent rewrite rules and a PHP script that works with Apache to count the number of downloads for certain file types. I need this converted to be NGINX friendly. The Apache rewrite rules are:

RewriteEngine on    
RewriteRule ^(.*).(rar|zip|pdf)$ http://xy.com/downloads/download.php?file=$1.$2 [R,L]    

The download script is here.

I'm trying to do the same with NGINX:

When any pdf file is downloaded, the script must intercept the download so that I can keep track of it. I want to keep track of two things, the amount of times it's been downloaded, and the IP address of the download.

The closest I got to was this:

location / {
   rewrite ^(.*).(rar|zip|pdf)$ /track-downloads.php?file=$1 break;
}

But the rule doesn't work, it doesn't get called. Also note sure about the location tag.

I found some other tips on rewrite rule conversion on NGINX's blog, here, but those conversions are the rather simplistic mainstream ones.

I've googled this to death. The problem with googling phrases like "execute custom php script when downloading PDF file nginx" is that so many hits are returned with regards to PHP not working properly and wanting to download instead of serve files.

Any help or direction would be greatly appreciated. Just as a side note, but two NGINX environments are Laravel Valet and the Virtualmin control panel.

I have a great working version of DRBD across two Debian Stretch servers which I created by following this awesome guide: https://www.howtoforge.com/setting-up-network-raid1-with-drbd-on-debian-squeeze-p2/

But after each reboot I have to redo a number of things to get it into a working state again.

Here is what I see when it's working, before reboot:

root@server1:~# cat /proc/drbd version: 8.4.7 (api:1/proto:86-101) srcversion: AC50E9301653907249B740E 0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----- ns:8 nr:0 dw:4 dr:1209 al:1 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

On server 2:

root@server2:~# cat /proc/drbd version: 8.4.7 (api:1/proto:86-101) srcversion: AC50E9301653907249B740E 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----- ns:0 nr:8 dw:8 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

On server 1:

root@server1:~# mount ... /dev/drbd0 on /var/www type ext3 (rw,relatime,data=ordered)

And here is what I see after reboot. All is working but mounting, service start, and primary/secondary configurations is lost. I've tried to add drbd to the start by doing this:

update-rc.d drbd defaults

on both servers this doesn't seem to work. DRBD simply doesn't start but manually doing /etc/init.d/drdb start works fine on both servers.

Also I'm unsure if I can just add the DRBD volumes to fstab because surely it won't work if the DRBD service isn't even started? I've read about using _netdev in fstab but various combinations of fstab entries didn't work out.

Finally I also have to set the primary and secondary status of DRBD every time I restart and then remount the volume manually.

So this is how I am getting it working after reboot:

On server 1:

root@server1:/etc# /etc/init.d/drbd status ● drbd.service - LSB: Control DRBD resources. Loaded: loaded (/etc/init.d/drbd; generated; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-sysv-generator(8)

root@server1:/etc# /etc/init.d/drbd start [ ok ] Starting drbd (via systemctl): drbd.service. root@jmtest1:/etc# cat /proc/drbd version: 8.4.7 (api:1/proto:86-101) srcversion: AC50E9301653907249B740E 0: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r----- ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

root@server1:/etc# drbdadm primary r0

root@server1:/etc# cat /proc/drbd version: 8.4.7 (api:1/proto:86-101) srcversion: AC50E9301653907249B740E 0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----- ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

On server 2:

root@server2:~# /etc/init.d/drbd status ● drbd.service - LSB: Control DRBD resources. Loaded: loaded (/etc/init.d/drbd; generated; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-sysv-generator(8)

root@server2:~# /etc/init.d/drbd start [ ok ] Starting drbd (via systemctl): drbd.service.

root@server2:~# cat /proc/drbd version: 8.4.7 (api:1/proto:86-101) srcversion: AC50E9301653907249B740E 0: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r----- ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

root@server2:~# drbdadm secondary r0

root@server2:~# cat /proc/drbd version: 8.4.7 (api:1/proto:86-101) srcversion: AC50E9301653907249B740E 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----- ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Some fstab entries that I tried:

/dev/drbd0 /var/www ext3 _netdev 0 2 UUID=042cc2e395b2b32 /var/www ext3 none,noauto 0 0

Not sure if you're supposed to use the UUID or just /dev/drbd0

I have these questions as to why it's not starting:

1. What FSTAB entries are supposed to be there?
2. Why does update-rc.d drbd defaults not work?
3. Why do I have to reset primary and secondary on both servers after each restart?

I am struggling with this error after an Elastix upgrade:

exit: 1 [FATAL] Unable to connect to Asterisk Manager from /var/lib/asterisk/bin/retrieve_conf, aborting

From what I can see the manager is running:

[root@elastix3 asterisk]# telnet localhost 5038
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
Asterisk Call Manager/1.1

By all indications the various Astersik Management Portal passwords should match up, in the /etc/amportal.conf, /etc/asterisk/manager.conf, and possibly in the GUI.

Selective output of /etc/amportal.conf:

AMPDBHOST=localhost
AMPDBENGINE=mysql
AMPDBUSER=asteriskuser
AMPDBPASS=My_Secret
AMPENGINE=asterisk
AMPMGRUSER=admin
AMPMGRPASS=My_Secret

Selective output of /etc/asterisk/manager.conf

[admin]
secret = My_Secret
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.0,192.168.20.0/255.255.255.0

Image of Password Update success

When I access FreePBX directly I also have an indication that there is no communication, see this screenshot:

But it's not correct, because Asterisk is online and working.

I would like some ideas on what to try next as I am at a complete loss. With regards to the botched upgrade, I have logged a separate Server Fault post here:

In summary when I did the upgrade Yum succeeded apart from a few packages.

Another anomaly of the upgrade is that I had to run amportal a ma install module_name for many different modules (one would have expected this to happen automatically).

Fixing the GUI is a priority but at least for now I suspect all is not lost because I think doing this command reloads the config in the command line: amportal module_admin reload

I upgraded a year old vanilla Elastix box using yum update and yum upgrade.

Almost 400 packages updated but a few of them failed, including asterisk. At present the switchboard is working but I can't apply updated configuration from the GUI. The error produced is

exit: 1 [FATAL] Unable to connect to Asterisk Manager from /var/lib/asterisk/bin/retrieve_conf, aborting

I researched various topics on how to get the Asterisk Management interface username and password synched, but to not avail. So now I'm thinking that I can isolate the problem further if I can at least get YUM to complete as it should. The errors produced by YUM update are:

--> Finished Dependency Resolution
2009020507:asterisk-11.5.0-0.x86_64 from elastix-beta has depsolving problems
  --> Missing Dependency: libgsmat.so.2.0.7()(64bit) is needed by package 2009020507:asterisk-11.5.0-0.x86_64 (elastix-beta)
2009020507:asterisk-11.5.0-0.x86_64 from elastix-beta has depsolving problems
  --> Missing Dependency: libwat.so.1.0.24()(64bit) is needed by package 2009020507:asterisk-11.5.0-0.x86_64 (elastix-beta)
Error: Missing Dependency: libgsmat.so.2.0.7()(64bit) is needed by package 2009020507:asterisk-11.5.0-0.x86_64 (elastix-beta)
Error: Missing Dependency: libwat.so.1.0.24()(64bit) is needed by package 2009020507:asterisk-11.5.0-0.x86_64 (elastix-beta)
 You could try using --skip-broken to work around the problem
 You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest

I tried all the remedies mentioned, including --skip-broken, package-cleanup --problems, package-cleanup --dupes, and rpm -Va --nofiles --nodigest but none of this worked.

The only bit of research led me to this Elastix "bug" related to libss7 and spandsp which is resolved by saying that the EPEL package supplied version should be updated to the newest version. I don't know how to do this or if it would help. http://bugs.elastix.org/view.php?id=1753

Our Elastix came with these repos:

[root@elastix3 yum.repos.d]# ls
CentOS-Base.repo       CentOS-Debuginfo.repo  commercial-addons.repo  epel-testing.repo
CentOS-Base.repo.back  CentOS-Media.repo      elastix.repo            pgdg-91-centos.repo
CentOS-Base.repo.test  CentOS-Vault.repo      epel.repo

When I do yum list I notice some oddities, for example it appears asterisk is installed and also present in another repo:

[root@elastix3 yum.repos.d]# yum list | grep asterisk
asterisk.x86_64                        2009020507:1.8.20.0-0      installed     
...
asterisk.x86_64                        2009020507:11.5.0-0        elastix-beta  

The output for libss7, libgsmat, and libwat:

[root@elastix3 yum.repos.d]# yum list | egrep -i "libss7|libgsmat|libwat"
libgsmat.x86_64                        2.0.3-0                    installed     
libwat.x86_64                          1.0.23-0                   installed     
libss7.i386                            1.0.1-3.el5                epel          
libss7.x86_64                          1.0.1-3.el5                epel          

So I'm guessing between all these repos I have a dependency mess and I don't know where to begin solving it.

The complete output from YUM is:

[root@elastix3 ~]# yum upgrade
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * addons: ftp.wa.co.za
 * base: ftp.wa.co.za
 * commercial-addons: elastix.kisiek.net
 * elastix-base: elastix.kisiek.net
 * elastix-beta: elastix.kisiek.net
 * elastix-extras: elastix.kisiek.net
 * epel: ftp.wa.co.za
 * extras: ftp.wa.co.za
 * updates: ftp.wa.co.za
Excluding Packages from CentOS-5 - Addons
Finished
Excluding Packages from CentOS-5 - Base
Finished
Excluding Packages from CentOS-5 - Extras
Finished
Excluding Packages from CentOS-5 - Updates
Finished
Setting up Upgrade Process
Resolving Dependencies
--> Running transaction check
---> Package asterisk.x86_64 2009020507:11.5.0-0 set to be updated
--> Processing Dependency: libwat.so.1.0.24()(64bit) for package: asterisk
--> Processing Dependency: libgsmat.so.2.0.7()(64bit) for package: asterisk
--> Processing Dependency: libss7.so.1()(64bit) for package: asterisk
---> Package asterisk-addons.x86_64 2009020507:11.5.0-0 set to be updated
---> Package asterisk-devel.x86_64 2009020507:11.5.0-0 set to be updated
---> Package asterisk-sounds-es.x86_64 2009020507:11.5.0-0 set to be updated
---> Package asterisk-sounds-fr.x86_64 2009020507:11.5.0-0 set to be updated
--> Running transaction check
---> Package asterisk.x86_64 2009020507:11.5.0-0 set to be updated
--> Processing Dependency: libwat.so.1.0.24()(64bit) for package: asterisk
--> Processing Dependency: libgsmat.so.2.0.7()(64bit) for package: asterisk
---> Package libss7.x86_64 0:1.0.1-3.el5 set to be updated
--> Finished Dependency Resolution
2009020507:asterisk-11.5.0-0.x86_64 from elastix-beta has depsolving problems
  --> Missing Dependency: libgsmat.so.2.0.7()(64bit) is needed by package 2009020507:asterisk-11.5.0-0.x86_64 (elastix-beta)
2009020507:asterisk-11.5.0-0.x86_64 from elastix-beta has depsolving problems
  --> Missing Dependency: libwat.so.1.0.24()(64bit) is needed by package 2009020507:asterisk-11.5.0-0.x86_64 (elastix-beta)
Error: Missing Dependency: libgsmat.so.2.0.7()(64bit) is needed by package 2009020507:asterisk-11.5.0-0.x86_64 (elastix-beta)
Error: Missing Dependency: libwat.so.1.0.24()(64bit) is needed by package 2009020507:asterisk-11.5.0-0.x86_64 (elastix-beta)
 You could try using --skip-broken to work around the problem
 You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest

Please assist! Although there is a workaround to apply the updated configuration from the command line I would really know that I've got a perfectly updated system.

We have a client with 6 sites using IPsec. Every now and again, possibly once a week, sometimes once a month, data just stops flowing from the remote Fortigate VPN server to the local MikroTik IPsec VPN client.

In order to demonstrate the symptoms of the problem I have attached a diagram. On the diagram Installed SAs tab you will notice a source IP address x.x.186.50 trying to communicate with x.x.7.3 but 0 current bytes. x.x.186.50 is the client's remote Fortigate IPsec server, and x.x.7.73 is a MikroTik based IPsec endpoint. It appears data from the remote side to us is not always flowing.

Phase 1 and 2 are always established but traffic always refuses to flow from the remote side to us.

We tried various things over time, such as rebooting, setting clocks, dabbling with configuration, rechecking and rechecking configuration but it appears the problem is entirely random. And sometimes random things fixes it. At one stage I had a theory that if the tunnel is initiated from their side it works, but fiddling with "Send Initial Contact" has not made any difference.

We've had many chats to the client about this but they have many more international IPsec VPNs and only our MikroTik configuration is failing.

Fortigate log:

http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=11654

Looking at Fortigate's knowledgebase it appears SPIs don't agree and DPD would make a difference. But I have tried every single combination of DPD on this side without avail. I would like to enable DPD on the other side but I cannot due to change control and also because the client is saying it's working on all the other sites exactly configuration the same. EDIT DPD was enabled

Local VPN client diagram showing no traffic flow:

I have included a log file showing continuous loops of "received a valid R-U-THERE, ACK sent" MikroTik log file:

echo: ipsec,debug,packet 84 bytes from x.x.7.183[500] to x.x.186.50[500]

echo: ipsec,debug,packet sockname x.x.7.183[500]

echo: ipsec,debug,packet send packet from x.x.7.183[500]

echo: ipsec,debug,packet send packet to x.x.186.50[500]

echo: ipsec,debug,packet src4 x.x.7.183[500]

echo: ipsec,debug,packet dst4 x.x.186.50[500]

echo: ipsec,debug,packet 1 times of 84 bytes message will be sent to x.x.186.50[500]

echo: ipsec,debug,packet 62dcfc38 78ca950b 119e7a34 83711b25 08100501 bc29fe11 00000054 fa115faf

echo: ipsec,debug,packet cd5023fe f8e261f5 ef8c0231 038144a1 b859c80b 456c8e1a 075f6be3 53ec3979

echo: ipsec,debug,packet 6526e5a0 7bdb1c58 e5714988 471da760 2e644cf8

echo: ipsec,debug,packet sendto Information notify.

echo: ipsec,debug,packet received a valid R-U-THERE, ACK sent

I've received various suggesions from IPsec experts and MikroTik themselves implying that the problem is at the remote side. However the situation is greatly compounded that 5 other sites are working and that the client's firewall is under change control. The setup also always worked for many years, so they claim it cannot be a configuration error on their side. This suggestion seems plausible but I cannot implement due to change control. I may only change the client side:

Make sure the IPSec responder has both passive=yes and send-initial-contact=no set.

This did not work.

EDIT 9 Dec 2013

I am pasting additional screenshots with the Fortigate configuration and what we believe are the Quick Mode selectors on the Mikrotik side.

Let me re-iterate that I don't think it's a configuration problem. I speculate it's a timing problem whereby side A or side B tries to send information too aggressively making the negotiation of the information (e.g. the SPI) out of sync.

EDIT 11 Dec 2013

Sadly I have to give up on this issue. Happily everything is working. Why it's working is still a mystery, but to further illustrate what we did I post another image inline.

We fixed it by:

1. Turning off PPPoE at client.
2. Installing completely new router (Router B) and tested at Border. It worked at Border.
3. Switching off new router B at border. AND THEN, WITHOUT MAKING A SINGLE CHANGE, the client's end-point Router A started working. So just adding a duplicate router at the border and taking this router offline again made the original router work.

So add this fix to the list of things we've done:

1. Reboot. That worked once.
2. Create new tunnel with new IP. That worked once but only once. After changing IP back client endpoint came live again.
3. Change time servers.
4. Fiddle with every possible setting.
5. Wait. Once, after a day, it just came right. This time, even after days, nothing came right.

So I postulate that there is an incompatibility on either Fortigate or MikroTik side which only happens at very random situations. The only things we haven't been able to try is upgrade firmware on Fortigate. Maybe there is hidden corrupt configuration value or timing issue invisible to configurer.

I further speculate that the issue is caused by timing issues causing SPI mismatch. And my guess is the Fortigate doesn't want to "forget" about the old SPI, as if DPD is not working. It just happens randomly and from what I can tell only when endpoint A is Fortigate and endpoint B is MikroTik. The constant aggressive attempts at trying to re-establish the connection "holds" on to old SPI values.

I'll add to this post when it happens again.

EDIT 12 Dec 2013

As expected it happened again. As you may recall we have 6 MikroTik client IPsec end-point routers configured exactly the same connecting to one Fortigate server. The latest incident was again to a random router, not the one I posted here about originally. Considering the last fix where we installed this duplicate router, I took this shortcut:

1. Disable Router A, the router that does not want to receive packets from Fortigate any more.
2. Copy Router A's IPsec configuration to a temporary router closer to the border of our network.
3. Immediately disable the newly created configuration.
4. Re-enable Router A.
5. Automagically it just starts working.

Looking at @mbrownnyc comment I believe that we are having an issue with Fortigate not forgetting stale SPIs even though DPD is on. I will investigate our client's firmware and post it.

Here is a new diagram, much like the last, but just showing my "fix":

I am working with a compromised Ubuntu 8.04 Plesk 9.5.4 server. It seems that a script on the server is continuously doing reverse lookups to random IPs on the Internet.

I first spotted it during by using top and then noticed flashes of this coming up continuously: sh -c host -W 1 '198.204.241.10'

I wrote a this script to interrogate ps every 1 second to see how frequently this script happens:

#!/bin/bash
while :
do
    ps -ef | egrep -i "sh -c host"
    sleep 1
done

The results are that this script runs often, every few seconds:

www-data 17762  8332  1 10:07 ?        00:00:00 sh -c host -W 1 '59.58.139.134'
www-data 17772  8332  1 10:07 ?        00:00:00 sh -c host -W 1 '59.58.139.134'
www-data 17879 17869  0 10:07 ?        00:00:00 sh -c host -W 1 '198.204.241.10'
www-data 17879 17869  1 10:07 ?        00:00:00 sh -c host -W 1 '198.204.241.10'
www-data 17879 17869  0 10:07 ?        00:00:00 sh -c host -W 1 '198.204.241.10'
root     18031 17756  0 10:07 pts/2    00:00:00 egrep -i sh -c host
www-data 18078 16704  0 10:07 ?        00:00:00 sh -c host -W 1 '59.58.139.134'
www-data 18125 17996  0 10:07 ?        00:00:00 sh -c host -W 1 '91.124.51.65'
root     18131 17756  0 10:07 pts/2    00:00:00 egrep -i sh -c host
www-data 18137 17869  0 10:07 ?        00:00:00 sh -c host -W 1 '198.204.241.10'
www-data 18137 17869  1 10:07 ?        00:00:00 sh -c host -W 1 '198.204.241.10'

My theory is if I can see who is launching the sh process or form where it's launched I can isolate the problem further.

Can somebody please guide me using netstat or ps to identify from where sh is being run?

I might get many suggestions that the OS is out of date and so the Plesk, but please bear in mind there are some very concrete reasons why this server is running legacy software. My question is aimed at a advanced Linux systems administrators who have in depth experience with security compromises and using netstat and ps to get to the bottom of it.

UPDATE 26 Oct 14:01 SAST

The command grep -lr 'sh -c host' left in the comments left by @ramruma helped me to quickly find the corresponding website running the script. As it turns out the server is not compromised. What is instead happening is there is a forum in that location produced by Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC that does a reverse lookup every time someone accesses the board.

It also turns out that the forum is unmaintained and severely spammed and why we initially thought it's compromised is because many of the reverse lookups pointed to foreign IPs known for spamming. Goodness only knows how a website can execute this command, but for the time being I am going to close the issue as harmless.

With regards to the blanket replies I received about "restore from backup" I came to ServerFault to help isolate the issue and I made it clear in my initial request. Sometimes restoring from backup is impractical or even impossible. It's better to figure out the issue or find the compromise in case it might arise in the future.

We have two Linux CentOS hosts, A and B.

A = 19x.2xx.6.4 (/24)
B = 19x.2xx.7.4 (/24)

Both these hosts are on the same physical switch. The reason why they are on different logical networks is because in the future they will be on separate physical networks.

A can ping B, and from A you can SSH to B.

You can also TRACEROUTE from A to B, in this case it goes through router C (19x.1x.8.1).

You cannot NMAP from A to B and various other important network utilities fail when connecting from A to B. The general effect is the same as a time-out.

The router in has aliases on the Cisco as such:

interface FastEthernet0/0
 ip address 19x.2xx.6.1 255.255.255.0 secondary
 ip address 19x.2xx.7.1 255.255.255.0 secondary
 ip address 19x.1x.8.1 255.255.255.192

I am at a loss how to fix this problem. Please assist.

We have an Asterisk 1.8.7.0 (the Elastix derivative) switchboard.

Every since a month ago, seemingly out of the blue, the switchboard does not recognise DTMF tones any more from mobile phones.

• Testing the switchboard using 7777 works.
• Testing the switchboard from a normal phones works.
• Testing the switchboard from a mobile phone fails.

Looking at the log file I can't see anything. I used 'asterisk -rvvvv' and 'tail -f /var/log/asterisk/full' to see the live output and scan the logs. I guess I don't see anything because it's simply not recognising the DTMF tones.

I did brief research and found an old setting for SIP phones, 'rfc2833compensate=yes', and tried adding this to 'sip_general_custom.conf'. After that I did 'core restart when convenient' but that didn't make any difference.

Could anyone give me some additional troubleshooting steps?

Edit 10 July 2012:

Since posting this we have further isolated the problem. The mobiles affected are:

• Blackberry
• iPhone
• Android Ice Cream (Samsung Galaxy S II)

The following phones are not affected:

• Android Gingerbread (Samsung Galaxy S II, Samsung Tab)
• Normal land lines

Additional information:

We have an IVR, press '1' for technical support, press '2' for sales. If you know the extension of the person you would like to dial, press it now.

Before, you could press '1' at any time. Now, you have to wait till the very end before pressing '1'. If you wait, this works with all phones.

Our Plesk Linux Ubuntu 64-bit mail server has extremely high load and we don't know how to isolate it. The load was okay will two weeks ago but in the last two weeks it's seriously deteriorated.

The mail server has been running for years and we have had sporadic performance issues. Normally we reduce the load by turning off all SPAM checks until the problem is sorted (which sometimes resolves itself).

Currently we have turned of real time block lists, SPF checking and we have attempted to turn off SpamAssassin.

1. No matter what we do the SpamAssassin check box stays ticked in the GUI. Out of desperation we have done /etc/init.d/psa-spamassassin stop. For years we haven't been able to do SpamAssassin because it kills the server. We would like to use it but performance is more important for now.

2. We cannot turn off Greylisting. The moment we turn off Greylisting our help desk is inandated with calls. Out of desperation we investigated truncating the Greylisting database which is now 2.5 GB big but we abandoned this after noticing turning of Greylisting doesn't improve the performance at all.

3. We have no anti-virus. It's just more load and Dr. Web never really worked that well for us. But we'll try that if it will make a difference.

4. We have implemented Postfix Anvil. This seems to have made the situation worse so we disabled it. We’re not sure if this is the case.

5. Our current mail server is configured to forward all SMTP to a relay server. We did so to reduce the load. This helped a lot because outgoing queues are generally empty.

6. We are running in an Expand configuration. The mail server has about 12 000 accounts of which maybe half are active.

We have read through this document: http://www.postfix.org/STRESS_README.html but there are too many settings and we don’t know which ones to choose.

Please assist urgently. We need advice on how to fix this problem before all our clients abandon is.

The only clue we have is that there are 100s of these processes:

30 13205 1 0 13:18 ? 00:00:00 /usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10027 before-queue 30
13207 1 0 11:38 ? 00:00:00 /usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10027 before-queue 30
13208 1 0 13:18 ? 00:00:00 /usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10026 before-remote 30
13209 1 0 11:38 ? 00:00:00 /usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10026 before-remote 30
13213 1 0 13:18 ? 00:00:00 /usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10027 before-queue

We want to do this:

Internet<->MikroTik in Bridge Mode with Firewall Filter<->Hosted Server

1. The primary objective is to allow RDP and FTP in from the outside but block everything else from the outside. From the inside everything must go out.

2. The problem we are running into is we add these rules and blocking outside to inside is working, but now the hosted server cannot access anything to the outside. The return TCP/IP from the outside is not port 3389 or port 80, but random.

/interface bridge filter> pr

Flags: X - disabled, I - invalid, D - dynamic 0 ;;; Accept ICMP for PING chain=forward action=accept mac-protocol=ip dst-address=196.x.x.x/32 ip-protocol=icmp

1 ;;; Accept FTP Transfer Port chain=forward action=accept mac-protocol=ip dst-address=196.x.x.x/32 dst-port=20 ip-protocol=tcp

2 ;;; Accept FTP Control Port chain=forward action=accept mac-protocol=ip dst-address=196.x.x.x/32 dst-port=21 ip-protocol=tcp

3 ;;; Accept RDP chain=forward action=accept mac-protocol=ip dst-address=196.x.x.x/32 dst-port=3389 ip-protocol=tcp

4 ;;; Log everything that is about to get dropped chain=forward action=log mac-protocol=ip dst-address=196.x.x.x/32 ip-protocol=tcp log-prefix="firewall_drop"

5 ;;; Drop everything chain=forward action=drop mac-protocol=ip dst-address=196.x.x.x/32 ip-protocol=tcp

Just FYI bridge is set to use firewall and connection tracking is on.

We have a Plesk 9.5.4 server with 2423 domains and according to SELECT * FROM psa about 8811 e-mail accounts.

When we do a backup it takes about three days and the backup file is about 65 GB big.

We need a long term strategy for disaster recovery to solve this problem of long restores. If I restore a 65 GB file that takes three days my clients would leave me in droves. What can I do?

I would like to turn off this warning Postfix warning:

Apr 4 19:03:54 cm postfix/smtpd[7456]: warning: x1.208.40.68: hostname x1-208-40-68.mxxx.net verification failed: Name or service not known

The reason why I want to turn off this warning is I get 80 messages every minute on this mail server and my egrep command is picking up too much information. I would rather Postfix not report this warning so that I can focus on the important warning generated from systems elsewhere.

Egrep command:

tail -f /usr/local/psa/var/log/maillog | egrep -i "unable|failed|refused|error|warning"

From what I understand from this post, the warning appears because there is no proper reverse (PTR) record for this host. See here:

http://kolab.org/pipermail/kolab-users/2010-July/011771.html

Using Webmin I find setting under SMTP Authentication And Encryption, "Reject clients with no reverse hostname". This appears to be a matching setting in case I actually wanted to reject those clients. Could someone confirm? Again, my aim is not to reject these clients. I just want to turn off the warnings.

In my postfix log I have the following when I send e-mail from a PHP based web site:

Feb 11 11:52:04 cp5 postfix/qmgr[6007]: 93C6E79C4D1: from=|[email protected]|, size=3266, nrcpt=1 (queue active)

(I substituted | for smaller-than / greater-than signs.)

The problem with the above is that I need to control the "FROM:" address. I know I can control the "@domain.com" address by modifying the "mydomain" in Postfix main.cf file and I had to do that in order to stop e-mail from bouncing in the first place. The problems is now people are reply to "[email protected]" and I don't want that.

This is a Plesk 9.5 server which as far as I know runs a stock standard Postfix installation. I would like advice on how to fix this problem in my PHP script.