See it the data is there

#echo  'select * from eximstats.sends limit 2;' | mysql
mailtime        msgid   email   processed       user    size    ip      auth    host    localsender     domain  spamscore
2014-12-09 21:38:11     1XyZyR-0004j1-5K        santa_2014@domain.com 0       -remote-        7134    37.48.84.200    localdelivery   domain.com    1               3.1
2014-12-03 05:19:07     1Xw9pe-0003aq-8b        mobileco@domain2.com    0       mobileco        3256    127.0.0.1       localuser       localhost       1     domain2.com  2.1

If data does exist (you can also check the other tables: defers, failures, smtp in the same way). If you get no data than for some reason data is not making it from exim into the database.

Check if an upgrade has failed.

On CentOS:

# yum install php-soap

If you get this error:

# yum install php-soap
Loaded plugins: fastestmirror, priorities, security
Setting up Install Process
Loading mirror speeds from cached hostfile
 * base: mirrors.usc.edu
 * extras: centos.sonn.com
 * updates: centos-distro.cavecreek.net
Resolving Dependencies
--> Running transaction check
---> Package php-soap.x86_64 0:5.3.3-40.el6_6 will be installed
--> Processing Dependency: php-common(x86-64) = 5.3.3-40.el6_6 for package: php-soap-5.3.3-40.el6_6.x86_64
--> Finished Dependency Resolution
Error: Package: php-soap-5.3.3-40.el6_6.x86_64 (updates)
           Requires: php-common(x86-64) = 5.3.3-40.el6_6
           Installed: php-common-5.4.19-25.el6.art.x86_64 (@atomic)
               php-common(x86-64) = 5.4.19-25.el6.art
           Available: php-common-5.3.3-38.el6.x86_64 (base)
               php-common(x86-64) = 5.3.3-38.el6
           Available: php-common-5.3.3-40.el6_6.x86_64 (updates)
               php-common(x86-64) = 5.3.3-40.el6_6
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

yum.repos.d]# php -v
PHP 5.4.19 (cli) (built: Aug 27 2013 18:40:41)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
    with the ionCube PHP Loader v4.6.0, Copyright (c) 2002-2014, by ionCube Ltd.
[root@69-64-67-20 yum.repos.d]# yum list available | grep soap
glite-lbjp-common-gsoap-plugin.i686        3.2.12-1.el6                  epel
glite-lbjp-common-gsoap-plugin.x86_64      3.2.12-1.el6                  epel
glite-lbjp-common-gsoap-plugin-devel.i686  3.2.12-1.el6                  epel
glite-lbjp-common-gsoap-plugin-devel.x86_64
gsoap.i686                                 2.7.16-4.el6                  epel
gsoap.x86_64                               2.7.16-4.el6                  epel
gsoap-devel.i686                           2.7.16-4.el6                  epel
gsoap-devel.x86_64                         2.7.16-4.el6                  epel
php-soap.x86_64                            5.3.3-40.el6_6                updates
python-soaplib.noarch                      0.8.1-4.el6                   epel
qtsoap.i686                                2.7-3.el6                     epel
qtsoap.x86_64                              2.7-3.el6                     epel
qtsoap-devel.i686                          2.7-3.el6                     epel
qtsoap-devel.x86_64                        2.7-3.el6                     epel
[root@69-64-67-20 yum.repos.d]# yum list available | grep soap
glite-lbjp-common-gsoap-plugin.i686        3.2.12-1.el6                  epel
glite-lbjp-common-gsoap-plugin.x86_64      3.2.12-1.el6                  epel
glite-lbjp-common-gsoap-plugin-devel.i686  3.2.12-1.el6                  epel
glite-lbjp-common-gsoap-plugin-devel.x86_64
gsoap.i686                                 2.7.16-4.el6                  epel
gsoap.x86_64                               2.7.16-4.el6                  epel
gsoap-devel.i686                           2.7.16-4.el6                  epel
gsoap-devel.x86_64                         2.7.16-4.el6                  epel
php-soap.x86_64                            5.3.3-40.el6_6                updates
python-soaplib.noarch                      0.8.1-4.el6                   epel
qtsoap.i686                                2.7-3.el6                     epel
qtsoap.x86_64                              2.7-3.el6                     epel
qtsoap-devel.i686                          2.7-3.el6                     epel
qtsoap-devel.x86_64                        2.7-3.el6                     epel

Checking the repos, I had to enable the atomic repo /etc/yum.repos.d/atomic.repo

Then the installtion would work with the update:

Installing:
php-soap x86_64 5.4.39-45.el6.art atomic 223 k
Updating for dependencies:
php x86_64 5.4.39-45.el6.art atomic 2.7 M
php-cli x86_64 5.4.39-45.el6.art atomic 2.6 M
php-common x86_64 5.4.39-45.el6.art atomic 935 k
php-gd x86_64 5.4.39-45.el6.art atomic 144 k
php-imap x86_64 5.4.39-45.el6.art atomic 80 k
php-mbstring x86_64 5.4.39-45.el6.art atomic 945 k
php-mysql x86_64 5.4.39-45.el6.art atomic 136 k
php-pdo x86_64 5.4.39-45.el6.art atomic 121 k
php-xml x86_64 5.4.39-45.el6.art atomic 172 k

Verify:

# php - | grep soap
soap
soap.wsdl_cache => 1 => 1
soap.wsdl_cache_dir => /tmp => /tmp
soap.wsdl_cache_enabled => 1 => 1
soap.wsdl_cache_limit => 5 => 5

Now restart apache

# service httpd restart

HTTP Strict Transport Security (HSTS) is an opt-in browser security mechanism that lets web site owners declare “Encrypted Communications Only”.

Strict-Transport-Security HTTP header instructs browsers to only communicate with the domain over SSL/TLS for a set period of time (the max-age). HSTS only goes into effect after a browser receives a valid header from the domain. HSTS is to ensure unencrypted communication is not allowed on your domain or site to mitigate attacks such as SSL-stripping.

The HSTS Header


Strict-Transport-Security: max-age:31536000; includeSubDomains 

The max-age parameter value is in seconds; 31536000 seconds equals 365 days. Notice how the above also uses includeSubDomains. This optional parameter informs the browser to force secure communication to the site’s subdomains as well.

Browsers must receive the Strict-Transport-Security header over an HTTPS connection with the domain; HSTS headers over HTTP are not recognized as valid.

Threat Mitigation
HSTS mitigates the following threats.

1. HTTP request to an HTTPS site
For example:
1. User wants to visit SecureSite.com
2. User types SecureSite.com into the address bar
3. Browser automatically appends “http://” making the following request: http://SecureSite.com
4. Server responds with 301 (permanent redirect) to the following location: https://SecureSite.com
5. Browser makes request to above URL

The above scenario allows for a man-in-the-middle attack as a result of the unintentional HTTP request to SecureSite.com. An attacker can leverage a tool such as ssltrip to transparently hijack the HTTP request prior to the 301 redirect. HSTS eliminates this attack window as long as the user previously accessed SecureSite.com over HTTPS and obtained the HSTS header.

Even with HSTS enabled, a user’s initial request to SecureSite.com would remain unprotected from attacks. As a result, both Chrome and Mozilla introduced HSTS preload lists. If SecureSite.com is on Chrome’s HSTS preload list, a freshly installed Chrome browser will only allow secure connections to that site, even if the user never accessed it before.

2. Insecure link referencing an HSTS enabled site

For example:

1. Forum.com includes a link to http://SecureSite.com
2. HSTS will automatically convert the link to HTTPS for the HSTS-enabled site
3. Invalid Certificate
The following would be considered invalid certificates:
– Self-signed and/or untrusted CA signed certificate
– Expired
– Wrong name specified
– …

HSTS displays an error message as shown below. In addition, it will NOT allow the user to override the error message, thus preventing a potential attack by ensuring the victim does not accept the bad certificate.

Enabling HSTS
You can enable HSTS in Apache with mod headers and the following line in your configuration:


<IfModule mod_headers.c>
# this domain should only be contacted in HTTPS for the next 6 months
Header add Strict-Transport-Security "max-age=15768000"
</IfModule> 

Afterwards, restart Apache and test the configuration change:


# curl -si nvisium.com | grep ^Strict
Strict-Transport-Security: max-age=31536000 

In Nginx, update nginx.conf:


# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains"; 

In Rails, HSTS can be enabled with the following:


# config.force_ssl = true 

HSTS Preload Lists
Chrome
Code repository:
https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json

Add your site using using the following:
https://hstspreload.appspot.com

Firefox
Code repository:
http://dxr.mozilla.org/mozillacentral/source/security/manager/boot/src/nsSTSPreloadList.inc

Firefox does not maintain their own list; instead, they use a subset of Google’s. Firefox only accepts sites on Google’s preload list that have a max-age greater than or equal to 18 weeks (10886400 seconds). See https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ for more information.

Testing HSTS
– Leverage an intercepting proxy (e.g. Burp) or browser tools (e.g. Chrome DevTools / Firefox Developer Tools) to examine server responses

– In Chrome, type the below to determine if a host is in your STS cache
chrome://net-internals/#hsts

– In Firefox, you can use the Strict Transport Security Detector add-on to see if the site supports HSTS (https://addons.mozilla.org/en-US/firefox/addon/strict-transport-security-d/)

Source: http://blog.nvisium.com/2014/04/is-your-site-hsts-enabled.html

Recently, I had to find a connection script for mysql as the clients programmer had gone away. I knew the database username and here is the grep command that found it.

# cd /var/www/vhosts/domain.com/httpdocs
# grep -r 'database username' *

* Where database username is the actulay database username in the plesk database

To change the root password for your Dedicated Server:

Log into WHM.
Click the Server Configuration icon on the home screen.
From the Server Configuration menu, click Change Root Password.
In the New Password field, enter the desired new password.
In the Confirm New Password field, retype the new password.

Before you begin installing the signature, you will need to see the hidden files and file extensions.

Go to your File Explorer (Windows key + E)
Select your hard drive (C:/ for most users)
Click on the Organize drop-down box
Click on the Folder and Search options tab
In the folder options, select the View tab, and make sure Show hidden files is selected, and uncheck Hid extensions for known file types
Now that this is done, we can get working on installing your signature.

Open File Explorer (Windows Key + E)
Go to Your Username/AppData/Roaming/Microsoft/Signatures/<.li>
Paste your .HTML signature in the Signatures file.
Rename the file by changing the extension from .HTML to .HTM
Open Outlook 2013 and go to FILE
Go to Options
Click on the Mail Tab and then on the Signatures button
You should see your signature in the list of Select signatures to edit box. The name of your signature will be your file’s name. Also, in the Edit signature box, your signature may not display properly. Do not worry, this is perfectly normal. Do not make any alterations. Make sure that you choose your signature in the New Message and Replies/Forwards
CONGRATULATIONS! Your signature is now installed!
– See more at: http://myhtmlsignature.com/installing-your-email-signature-in-outlook-2013/#sthash.Qj5eXA4I.dpuf

edit /etc/my.cnf to show the following…

[mysqld]
port = 3306
# bind-address = 10.10.0.1
# skip-networking
....

Where,

* bind-address : local IP address to bind to. If you wish mysql listen on all IPs, don’t use this option.

* skip-networking : Don’t listen for TCP/IP connections at all. All interaction with mysqld must be made via Unix sockets. This option is highly recommended for systems where only local requests are allowed. Since you need to allow remote connection this line should be removed from file or put it in comment state.

Restart MySQL.

# service mysqld restart

Now you should grant access to remote IP address, login to Mysql:

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` mysql

For example if you want to allow access to database called ‘foo’ for user ‘bar’ and remote IP 192.168.0.1(The IP you are connecting from) then you need to type following commands at “mysql” prompt:

mysql> GRANT ALL ON foo.* TO bar@'192.168.0.1' IDENTIFIED BY 'PASSWORD';

If you want to grant remote access for all databases to any IP:


mysql> GRANT ALL PRIVILEGES ON *.* TO 'USERNAME'@'%' IDENTIFIED BY 'PASSWORD' WITH GRANT OPTION;

Be sure to check that Iptables is set up with the info to allow the remote connection

# iptables -A INPUT -i eth0 -p tcp -m tcp --dport 3306 -j ACCEPT

To add to an existing database:

Other sources:
http://www.cyberciti.biz/tips/how-do-i-enable-remote-access-to-mysql-database-server.html

nano /var/lib/mysql/server.com.err


141212 17:26:27 [ERROR] Plugin 'InnoDB' init function returned error.
141212 17:26:27 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed 

There are two solutions to this particular problem:

1. Restore the my.cnf file to its original state, with an innodb_log_file_size equal to the actual size of the existing InnoDB log files.

2. Rename or move both the ./ib_logfile0 and ./ib_logfile1 files, and then start the MySQL server.
The ./ib_logfile0 and ./ib_logfile1 files are located in the InnoDB data directory (usually /var/lib/mysql). Both files must be moved or renamed for the above procedure to work. When starting MySQL, new InnoDB log files of the appropriate size will be created.

The original InnoDB log files only need to be kept as long as they may be needed for data recovery. If the MySQL server successfully starts after the above procedure, and all data is intact, the original InnoDB log files can be discarded.

There are two files that matter:


# /var/www/vhosts/default/htdocs/index.html
# /var/www/vhosts/.skel/0/httpdocs/index.html

Also, if present:


# /var/www/vhosts/default/httpsdocs/index.html
# /var/www/vhosts/.skel/0/httpsdocs/index.html

Windows Plesk files are in similar locations — C:\inetpub\vhosts\ instead of /var/www/vhosts

Edit index.html after backing up.