Database backup system bugs

A bug was found in the database backup system. This has been resolved. The bug was an issue with the backup system not properly removing old backups when it came to the database backups. HTML backups were being removed correctly though.

As a result of more coding the database backup system now supports sending the backup file to the correct website which the database is used for. For those using multiple sites and/or multiple databases.

Crons are here

While there is still no control panel yet. The system now supports schedules crons. These crons can be set at a min interval of 5 minutes and are easily modified. So once the control panel is in place it will be easy to implement it into the panel.

Currently I have already setup the crons manually that were needed for some clients. If you need any crons setup for now just send me an email.

Note: These crons have a low priority in order to keep the server running smoothly. (nice commanded)

PHP CLI added, crons to come soon

PHP has been added to the shells. There was a bug with the mysql side of this that didn’t let PHP load the mysql extensions. Now that that is fixed PHP can properly be used through the command line for each user.

With this being fixed cron jobs will be the second thing on my list to implement into the control panel.

Heart bleed bug

A friend just pointed me to this: http://www.theepochtimes.com/n3/609175-heart-bleed-bug-imperils-web-encryption-putting-passwords-credit-cards-at-risk/ which in turn turned me to this: http://heartbleed.com/

Basically OpenSSL for 2 years had a major flaw in it which allows hackers to obtain 64 kilobytes of data from the server where OpenSSL was installed and being used. I rushed onto the server and checked the OpenSSL for it’s version number. While I will not specifically state what version the servers are running for security measures I will say that the service is NOT running OpenSSL versions which were vulnerable.

However after using a test site (http://filippo.io/Heartbleed/) on a client’s server I found that even though 1.0.0 was not supoused to be affect (their version was 1.0.0c) they were vulnerable. I would strongly urge ANYONE to either run their update program (centos/rhel: “yum -y update openssl”) or manually install 1.0.1g as soon as possible. Then broadcast to your account holders to change their passwords.

Keep in mind OpenSSL 1.0.0c was released in December of 2010. Which means if 1.0.0c was vulnerable this bug has been around for 3 1/2 years.


 

Excerpt from http://heartbleed.com/

 

What versions of the OpenSSL are affected?

Status of different versions:

  • OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
  • OpenSSL 1.0.1g is NOT vulnerable
  • OpenSSL 1.0.0 branch is NOT vulnerable
  • OpenSSL 0.9.8 branch is NOT vulnerable

Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.


Commands to update your own dedicated server:

Just in case the above command doesn’t clean up here is the clean up command:

In case you’re having issues with “openssl version” still showing you your old version and are using StorMan use the following commands:

If not using StorMan and still having issues of the old version being reported try:

To test your openssl version use the below command:

 Also keep in mind you will want to re-key your SSL Certificates if your server had a known issue. As someone could be sitting on your private key just waiting to use it.

Invoices

Currently the Panel is being developed the first feature to be added to it will be the ability to view your invoices. So March’s invoice will be the last one sent out manually. From there on the system will be developed to automatically generate the invoices and they will be available via the panel.

Note: This does not mean there won’t be an invoice for April. Just means it may be late and it won’t be sent out.