the solutions is below
Log into your WordPress Admin account.
Go to ‘Miscellaneous’ Settings options from the ‘Settings’ menu.
In the Miscellaneous Settings put wp-content/uploads in the “Store uploads in this folder” text box.
Save the Changes by hitting the “Save Changes” button and you are done.
Thank you.
first you need to make sure that ionCube already installed, you just run this command to verify if
installed php -v
if ionCube installed then you need to follow the below commands
cd /usr/local/cpanel/whostmgr/docroot/cgi
wget -N http://www.softaculous.com/ins/addon_softaculous.php
chmod 755 addon_softaculous.php
Now go to : WHM > Plugins (Add-Ons on older versions than 11) > Softaculous – Instant Installs
then few seconds and will see the installation already done successfully
Thank you
if you got suhosin issue, to increase the value , ,, the solutions is below
suhosin.post.max_vars = 4000
max_input_vars = 4000
suhosin.request.max_vars = 4000
post_max_size = 8M
then restart httpd
How to change mail server ip address in PLESK ?
Ans :
If primary mail server ip address is blocked in any spam checker sites ( eg BARRACUDA,SORBS-SPAM etc) then there is only one solution, that is change the mail server ip address on the server.
You can easily change the mail server ip address in cpanel by using /etc/mailips file. The same as in PLESK you can also change the outgoing mail server ip address by using “/var/qmail/control/smtproutes” file.
1) first check the domain name which is hosted on the server by using following file
cat /var/qmail/control/rcpthosts
domain1.com
domain2.com
domain3.com
domain4.com
domain5.com
2) By default the “/var/qmail/control/smtproutes” file is not present on PLESK server, you need to create it.
vi /var/qmail/control/smtproutes
3) Then add the new ip address in the following format.
domain1.com:192.168.0.2
domain2.com:192.168.0.2
4) Save the file and restart qmail
/etc/init.d/qmail restart
Note: Please replace the “192.168.0.2” to original ip address and the “domain.com” equal the original domain name
Simply change both of these options below to “On”, and then click the “Save” button in Tweak Settings area.
Allow Remote Domains [?]
Allow unregistered domains [?]
Reference
http://forums.cpanel.net/f34/addon-domain-problems-190192.html
The other day I helped a client deal with a SYN flood denial of service attack. This article describes the symptoms, diagnosis and solution from a Linux server point of view.
Definition
A SYN flood attack exploits one of the properties of the TCP/IP protocol: by sending SYN requests, and then never following up with an ACK, this leaves the server using one network “slot” and waiting for the other side for some time. Doing this many times ties up network resources and the server becomes unresponsive.
Symptom: web site visitor
The symptom to an end user, a web site visitor, is that a site takes a long time to load, or loads some elements of a page but not others. The general impression is that the site is slow or down.
Symptom: on the server
From a server administrator perspective, you will not see high CPU utilization, nor memory utilization. The server will be lightly loaded when this happens.
In order to check whether your server is under a SYN flood attack, you use the wget command times how much it takes for your site to load, from the same box (to eliminate the network as a cause).
For a normal site, you get something like this instantly:
$ time wget -O /dev/null www.example.com
Resolving www.example.com… 1.1.1.1
Connecting to www.example.com|1.1.1.1|:80… connected.
HTTP request sent, awaiting response… 200 OK
…
real 0m0.018s
The request takes just 18 milliseconds, which is quite normal for a well configured server.
Compare that to when a SYN flood attack was active:
$ time wget -O /dev/null www.example.com
Resolving www.example.com… 1.1.1.1
Connecting to www.example.com|1.1.1.1|:80… connected.
And this is where things hang for a long time … The server takes a very long time to open a network socket.
Then after a long time, you would get this:
HTTP request sent, awaiting response… 200 OK
…
real 0m45.002s
Ouch! 45 millisconds for the home page to load locally!
This can vary from a few seconds, to several minutes, and running it several times will give different results, but all or most of them will be over 1 or 2 seconds.
Diagnosis
Then when you look at netstat’s output, you find that there are lots of connections in the SYN_RECV state:
netstat -tuna | grep :80 | grep SYN_RECV
The output will look like this:
tcp 0 0 1.1.1.1:80 70.56.83.204:1609 SYN_RECV
tcp 0 0 1.1.1.1:80 2.2.2.2:1723 SYN_RECV
tcp 0 0 1.1.1.1:80 209.112.192.126:4988 SYN_RECV
tcp 0 0 1.1.1.1:80 2.2.2.2:1724 SYN_RECV
tcp 0 0 1.1.1.1:80 2.2.2.2:1727 SYN_RECV
tcp 0 0 1.1.1.1:80 2.2.2.2:1733 SYN_RECV
tcp 0 0 1.1.1.1:80 24.158.121.0:3337 SYN_RECV
tcp 0 0 1.1.1.1:80 2.2.2.2:1753 SYN_RECV
tcp 0 0 1.1.1.1:80 2.2.2.2:1811 SYN_RECV
tcp 0 0 1.1.1.1:80 2.2.2.2:1821 SYN_RECV
tcp 0 0 1.1.1.1:80 2.2.2.2:1831 SYN_RECV
tcp 0 0 1.1.1.1:80 24.7.27.61:52142 SYN_RECV
tcp 0 0 1.1.1.1:80 207.118.0.58:50819 SYN_RECV
tcp 0 0 1.1.1.1:80 115.64.40.38:52865 SYN_RECV
You will see a lot of SYN requests from the same addresses. Do not bother with tracing what this address is, because it is easily faked, and the attacker is probably using fake addresses.
Solution
So, how do you solve this?
The solution varies, but the best one is to enable SYN cookies on your load balancer or the server itself.
To enable that on a current Linux kernel, you enter the following command:
sysctl -w net.ipv4.tcp_syncookies=1
And then add the following line to the /etc/sysctl.conf file to make make it persist across reboots:
net.ipv4.tcp_syncookies = 1
You may optionally want to increase the size of the SYN backlog queue as well, from a default of 1024, to 2048, using the following command:
sysctl -w net.ipv4.tcp_max_syn_backlog=2048
And you add this to /etc/sysctl.conf:
net.ipv4.tcp_max_syn_backlog = 2048
Results
After you do the above, SYN Flood attacks will continue, but it will not affect the server negatively. You will see a message like this in your logs:
[1116377.589736] possible SYN flooding on port 80. Sending cookies.
[1116439.567828] possible SYN flooding on port 80. Sending cookies.
[1116500.631623] possible SYN flooding on port 80. Sending cookies.
But there will be no ill effect from it …
And there you have it, attackers will still send SYN requests, but the server will remain responsive …
Resources
For more reading on this issue, check the following links:
RFC 4987: TCP SYN Flooding Attacks and Common Mitigations
http://www.securityfocus.com/infocus/1729
http://www.iss.net/security_center/advice/Exploits/TCP/SYN_flood/default.htm
http://www.usenix.org/events/sec01/invitedtalks/oliver.pdf, dated, and hence doesn’t cover SYN cookies, but describes the problem well.
http://www.networkcomputing.com/unixworld/security/004/004.txt.html, dated as well.
First a new entry will need to be created in xinetd for the alternate port:
cd /etc/xinetd.d
cp smtp_psa smtp_psa_p26
Next the entry that was just created needs to be modified:
vi smtp_psa_p26
Make the first line say “service smtp_p26” and save the file.
Next edit the services for the system to include the newly created one:
vi /etc/services
smtp_p26 26/tcp mail
smtp_p26 26/udp mail
After editing this, just restart xinetd and the server should be listening on port 26. A quick way to verify the changes took effect can be done using this command:
netstat -lpn|grep 26
NOTE: Don’t forget to make sure port 26 is open in the firewall. A walk through on how to do this can be found here: http://www.liquidweb.com/kb/apf-firewall/
The cause for the problem can either be because that the MX DNS record for the domain zone of destination recipient (local host) is wrong, or because (most likely reason anyway) that during the verify sender and recipient condition in RCPT ACL phase, the example.com is not recognized as a local domain, nor is the remote host allowed to relay.
To solve the issue, check whether the domain MX record in DNS name servers to verify that it’s pointing to the correct mail server. If MX record is correct, ensure that the destination domain is properly designated as the local-domain to allow Sendmail or Exim to know that they suppose to receive the mail without querying DNS again. To do so, insert the affected domain to the server’s domain lists into the following config file, depending on your flavor of Linux or Windows OS, and which MTA you’re using.
/etc/localdomains (Exim)
/etc/mail/local-host-names (Sendmail)
Reference
http://www.mydigitallife.info/lowest-number-mx-record-points-to-local-host-rejected-rcpt-error/
Applies to: SmarterMail 8.x
A system administrator may need to move SmarterMail to a different server because they are moving to a more powerful server or changing hosting companies and need to move to their servers.
Before starting the move process, add new MX records to your domains in DNS for the new server and allow 24-48 hours for the records to propagate through the Internet. Doing so will help ensure that you do not lose any mail. SmarterTools also recommends ensuring your license key can be activated again before beginning the migration process. This information can be found in the account management area of the SmarterTools Portal.
Follow this steps to migrate a SmarterMail installation to a different server:
Install SmarterMail on the new server and follow the instructions for setting up IIS if you plan on using it instead of the SmarterMail Web server.
Stop the SmarterMail Service on both servers
Copy the following files and folders from your old server to your new one:
C:\program files\smartertools\smartermail\service\mailconfig.xml
C:\program files\smartertools\smartermail\service\domainlist.xml
C:\program files\smartertools\smartermail\service\greylistbypass.xml
C:\program files\smartertools\smartermail\service\greylist.dat
C:\SmarterMail\Domains
Start the SmarterMail service on the new server.
Log in and re-activate the software on the new server.
If you change the path to your domains, you would need to edit your domainList.xml file accordingly to reflect the new paths.
If your DNS servers change, update the corresponding setting in SmarterMail and restart the SmarterMail Service (or reboot the server) to make the change effective.
NOTE: These steps assume that the domain data is stored in the default C:\SmarterMail\Domains directory and that the product is installed in the default location.
Reference http://portal.smartertools.com/KB/a1461/migrate-smartermail-to-a-different-server.aspx
Following commands can delete all mails from your qmail mail server queue.
qmailctl stop
find /var/qmail/queue/mess -type f -exec rm {} \;
find /var/qmail/queue/info -type f -exec rm {} \;
find /var/qmail/queue/local -type f -exec rm {} \;
find /var/qmail/queue/intd -type f -exec rm {} \;
find /var/qmail/queue/todo -type f -exec rm {} \;
find /var/qmail/queue/remote -type f -exec rm {} \;
qmailctl start
Do this when even you get time 🙂