Showing 14 Result(s)

Plesk “The component was not installed” for all services.

This is a really small blog post, but it’s an issue I wanted to share – so hopefully anyone who comes across this issue themselves can avoid the mistake I made!

Basically, we noticed that one of our older Plesk servers seemed to have lost basic functionality like editing DNS zones, or accessing PHPMyAdmin or Webmail.

When going to Tools & Settings > Server Components we noticed that next to all the services (components), there was the message “The component was not installed“.

Interestingly, when accessing the server via SSH, the servers were installed, and functioning correct (websites were accessible, DNS was querying etc).

Sadly, I jumped straight to the wrong conclusion, and thought that a recent automatic update of Plesk had failed, and that the PSA services had been corrupted. I was wrong.

I ran the Plesk bootstrapper. If anyone is familiar with this, you’ll understand the pain I was going through. Two hours later, and the issue was not resolved. What do you try next?

Well, after the bootstrapper failed to fix the issue, I just tried running “yum update” to see if there were any package updates etc.

BOOM! There it was!

Thread died in Berkeley DB library
DB_RUNRECOVERY: Fatal error, run database recovery

Great! That’s a really easy fix.

rm -f /var/lib/rpm/__*
rpm --rebuilddb
yum clean all

Now, check back in Plesk, and all functionality and the Server Components list will be fixed!

R1Soft : GC overhead limit exceeded

I encountered this issue on the R1Soft Web Interface last week, which I had to open a support ticket for with R1Soft’s brilliant support.

r1soft

When trying to run tasks like a backup, run, or restore I would encounter the error messages as seen above.

The error was down to the maximum amount of memory which was assigned to the Java Heap and PermGen. After contacting R1Soft’s support, I was pointed to a config file where you can adjust the java heap and permgen values.

To increase the java heap:

# Edit /usr/sbin/r1soft/conf/server.conf

  1. Locate the following line at the top: “compute.maxmemory=true” and change it to… “compute.maxmemory=false
  2. Locate the following line: “#maxmemory=” and remove the hash symbol. Set it to use 8192 (in MB). It should now read… “maxmemory=8192
  3. Save the server.conf file.

# Now restart the CDP Server Service.

  1. /etc/init.d/cdp-server stop
  2. /etc/init.d/cdp-server restart

 

To increase the PermGen Space:

# Edit /usr/sbin/r1soft/conf/server.conf

  1. Locate the following line “additional.10=-XX:MaxPermSize=256m” and change it to… “additional.10=-XX:MaxPermSize=1024m
  2. Save the server.conf file.

# Now restart the CDP Server Service

  1. /etc/init.d/cdp-server stop
  2. /etc/init.d/cdp-server restart

NGINX SSL Ciphers

With browsers such as Google Chrome and Mozilla Firefox forcing websites to use better ciphers, along with websites such as PayPal no longer support older versions of TLS it’s time to update your NGINX installations with the latest version of OpenSSL (TLS 1.2+) and set some decent ciphers.

I’m finding the following cipher set are passing tests such as SSL Labs and CryptoReport – this could change in the future.

ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA;

Add those to your NGINX configuration files (usually in /etc/nginx/conf.d/ on CentOS), and restart NGINX.

Please be aware at the time of writing this article, the ciphers in the list were passing SSL tests, however as these requirements change and new exploits are released, this may change. I’ll try to update the blog with any such changes.

At the time of writing, the ciphers were secure against the following vulnerabilities:

  • Poodle (TLS)
  • Poodle (SSLv3)
  • FREAK
  • BEAST
  • CRIME

OpenVZ IO Limits

OpenVZ has had IO limits for years, but I’ve never really had opportunity to implement them, especially with SSD disks becoming cheaper and the standard.

However in some cases implementing IO Limits on your OpenVZ VMs can be a good practice. Especially on Database servers (High usage MySQL/MariaDB) or Mail servers (Exim on cPanel can be an IO hog at times).

Depending on your disks, and how many OpenVZ containers live on your host, you may wish to adjust the following to better suited values.

vzctl set 100 --iolimit 10M --save

10MB/s seems to be the perfect value for my requirements. It doesn’t over limit IO usage, but if a VM is behaving badly, it limits the impact on the other VMs. IO Limiting effects both read and write, and there is also an option to allow bursts of up to 3x.

Requirements:

  • Kernel Version: 2.6.32-042stab084.3 or higher
  • VZCTL Version: 4.6 or higher

Further information can be found on the OpenVZ Wiki.