This Support Article describes how to enable Access to the server over SSH per hosting subscription. Enabling this option will allow access to the folders and files for the subscription over a secure connection, SFTP (SSH File Transfer Protocol) and SSH client such as PuTTY.

This process is only possible for Conetix clients with a Virtual Private Server (VPS)

Instructions

1. Login to Plesk for your VPS.
2. On the left-hand side of your VPS, go to Subscriptions:
   
3. From the list of Subscriptions click on the Domain that you want to allow SSH access for.
   
4. In the subscription settings we want to go to Hosting & DNS, then Hosting:
   
5. A side panel will appear and in the list of settings, scroll down to the SSH access option:
   
6. Change the SSH access Type from the default Forbidden to /bin/bash (chrooted):
   
7. Click Save on the bottom left of the side panel:
   

Using the default FTP user account, you can now access the server over SSH port 22.

At times you may need to provide your clients with direct access to their Plesk subscriptions so they're able to self manage some aspects of their hosting This article takes you through providing a clients access to their specific Plesk subscription.

Instructions

1. Log into your Plesk Server as the Administrator:
   
2. On the left hand side, click Customers:
   
3. Search for your customer in the search box to the right:
   
4. Your customer will now be shown.
5. Click the customer name to enter the account details window:
   
6. To supply your client a password click "Change Login Info" on the right:
   
7. Generate a new password for the user by clicking "Generate": (You can view this password by clicking "Show")
   
8. Once the password is generated, click "OK" and the password change will save.
9. You can now pass on the client's username and password along with your VPS link which will allow them to log in with the above created details:
   (username can be found per below screenshot)
   
   Using the above information you have created will allow the client full access to their subscription and only their subscription.

The Magento eCommerce Shopping cart contains a logging facility to record visitor interactions with your store. However most store owners use Google Analytics to get metrics on the performance of their store so the inbuilt logging is forgotten about and left enabled, slowly over time the store database grows and performance may degrade due to writing log information.

Using SSH access there is a command line tool to both report the status of internal logs and the ability to clean them up.

1. Log into your VPS and navigate to your Magento installation directory.

2. Change into the "shell" directory and run the shell command "ls", you should get the following output:

# ls
abstract.php  compiler.php  indexer.php  log.php
#

We can run the log.php script to get a status of the logs kept.

3. Run the "status" command as shown below:

# php -f log.php status
-----------------------------------+------------+------------+------------+
Table Name                         | Rows       | Data Size  | Index Size |
-----------------------------------+------------+------------+------------+
log_customer                       | 5          | 16.38Kb    | 16.38Kb    |
log_visitor                        | 978.04K    | 77.19Mb    | 0 b        |
log_visitor_info                   | 1.02M      | 133.87Mb   | 0 b        |
log_url                            | 1.11M      | 50.94Mb    | 47.32Mb    |
log_url_info                       | 1.12M      | 189.51Mb   | 0 b        |
log_quote                          | 12         | 16.38Kb    | 0 b        |
report_viewed_product_index        | 72.02K     | 3.69Mb     | 11.09Mb    |
report_compared_product_index      | 651        | 81.92Kb    | 212.99Kb   |
report_event                       | 81.61K     | 4.73Mb     | 8.99Mb     |
catalog_compare_item               | 111        | 16.38Kb    | 81.92Kb    |
-----------------------------------+------------+------------+------------+
Total                              | 4.38M      | 460.06Mb   | 67.72Mb    |
-----------------------------------+------------+------------+------------+

Some of the log tables contain over a million rows! The "log_url" table also has an index file, so each visit requires it to read and process the 47M index to add another entry. We can clearly save some database space which will make our backup smaller and site more responsive by cleaning the log entries out of the database.

Run the following command (it may take a while to run):

# php -f log.php clean 
Log cleaned

# php -f log.php status
-----------------------------------+------------+------------+------------+
Table Name                         | Rows       | Data Size  | Index Size |
-----------------------------------+------------+------------+------------+
log_customer                       | 5          | 16.38Kb    | 16.38Kb    |
log_visitor                        | 270.15K    | 24.18Mb    | 0 b        |
log_visitor_info                   | 247.49K    | 35.73Mb    | 0 b        |
log_url                            | 324.66K    | 16.79Mb    | 17.86Mb    |
log_url_info                       | 320.23K    | 58.82Mb    | 0 b        |
log_quote                          | 3          | 16.38Kb    | 0 b        |
report_viewed_product_index        | 20.31K     | 3.69Mb     | 11.09Mb    |
report_compared_product_index      | 743        | 49.15Kb    | 81.92Kb    |
report_event                       | 22.92K     | 2.11Mb     | 6.47Mb     |
catalog_compare_item               | 1          | 16.38Kb    | 81.92Kb    |
-----------------------------------+------------+------------+------------+
Total                              | 1.21M      | 141.43Mb   | 35.60Mb    |
-----------------------------------+------------+------------+------------+
#

The script has now removed over 75% of the logging rows, it is suggested you run this every few months or turn off logging in the relevant System Administration menu.

In most hosting environments, your entire virtual instance is mounted on a single drive of maybe 10-20GB in size. In self hosted or VPS solutions additional disks are often available and are usually mounted with default parameters. The default parameters commonly used when mounting a file system include the writing of the last access times to the file system for every file accessed, this is of little use on a production server and can be safely disabled.

If at all possible, turn off the atime and diratime parameters in /etc/fstab using the noatime and noadirtime flags on all relevant file systems. This will reduce writes to the file system when a file is accessed.

Implementation    

The addition of the two flags is made to the entries in the /etc/fstab file related to physical disks. The command line in your /etc/fstab file would look something like:

/var/www ext4 defaults,grpquota,noatime,nodiratime,data=ordered 0 0

This change will result in a tiny improvement in performance but every bit counts!

Copying your existing MySQL database is quite a simple task, in fact you can do it in a single command! There are plenty of times when you want to take a copy of an existing database so that you leave your original database untouched. For example, if you want to run different databases for your production and development environments then you can copy the existing database to test making changes. 

Note: This assumes that you're copying the database onto the same server.

Instructions

1. Run the "mysqldump" program and pipe it directly back into "mysql":

   mysqldump --user=<username> --password=<password> <existingdatabase> | mysql --user=<username> --password=<password> <newdatabasename>

2. That's it!

CentOS is removing support for CentOS 8 due to their shift to only supporting the CentOS Stream project. This means that all existing CentOS 8 systems will require a transition to a different Operating System (OS) in order to receive bug fixes and security updates beyond December 2021.

CentOS itself is a binary compatible, repackaged version of Red Hat Enterprise (RHEL) source code but without the Red Hat support. New projects have popped up to replace CentOS 8, which are:

• AlmaLinux (from the CloudLinux team)
• Rocky Linux (from the original CentOS founders)
• Virtuozzo Linux (from our virtualisation stack provider, Virtuozzo)

The Conetix team have been evaluating the use of each and all of these variants over the last few months. While the distributions are nearly identical, we also need to ensure all vendors (such as Plesk) have ensured and guaranteed long term support as well. This evaluation process has identified AlmaLinux as the preferred distribution.

Conversion of existing systems is currently underway. Due to the volume of servers to convert, we’re unable to give individual ETA’s on when this will be completed. As of February 2022, approximately 50% of all systems have been converted.

Frequently Asked Questions

This process details how you can restart your VPS in your Conetix account. A reboot may be required where your server has stopped responding and the Plesk emergency access was unable to resolve the issue.

If you are unsure on whether your VPS requires a reboot, please get in touch with Conetix support at support@conetix.com.au, or give us a call on 1300 789 260.

You can access Plesk’s repair kit by following the steps in the below article
https://testing.conetix.com.au/support/plesk-emergency-access-via-the-repair-kit

Instructions

1. Login to the Conetix Control Panel.
   
2. Select Services on the left hand menu and then select My Services.
   
   
   
3. Navigate to the desired VPS and select Manage Product.
   
   
   
4. Click Restart to initiate the reboot.
   
   
   
5. Once you are notified that the service has been restarted successfully, test the functionality of services on the VPS .
   

If after a few minutes, services have not come back online, please get in touch with our support team for further assistance.
https://testing.conetix.com.au/support/

You may have a requirement to disable KernelCare Automatic updates, the following describes how you do it.

Instructions

1. Edit file /etc/sysconfig/kcare/kcare.conf 

   Set AUTO_UPDATE=False 

    

If you require assistance please contact Conetix support on 1300 789 260 or email support@conetix.com.au

Conetix is a Cloudlinux and KernelCare Distributor if you require a Cloudlinux license click here, if you require a KernelCare License click here. If you wish to take advantage of Plesk 12.5 + Cloudlinux Bundle click here.

While initial views of the Linux memory statistics may suggest the system has run out of memory, the reality is that Linux uses any free RAM available as a disk cache and buffering for network services. By caching files from disk, this provides a boost to performance of the overall server since accessing a file from memory is significantly faster than from a hard drive. When applications require more memory, the Linux kernel automatically frees the memory allocated to the cache and provides it to the applications.

Here’s an example memory output:

CT-0000-bash-4.1# free -m
             total       used       free     shared    buffers     cached
Mem:          2048       1871        176          0          0        842
-/+ buffers/cache:       1029       1018
Swap:            0          0          0

This system has a total of 2048MB and has listed and a total of 1871MB used. If you look at the top line only it would appear that the system only has 176MB free! Don’t panic though, the actual amount of memory available to your applications is the combination of the free memory (176MB) and the cached memory (842MB). So, for this particular server there’s actually 1018MB of memory available for your applications.

Certificate Transparency is an extension of the current SSL issuance and monitoring system to provide publicly auditable logs from Certificate Authorities (CA's) so that the detection of mistakenly issued or maliciously acquired occurrences can be easily detected.

In Google Chrome, you will see a message like "SSL certificate does not have public audit records". For example, a certificate currently issued by RapidSSL will look like this:

This does NOT indicate that there is an issue with the certificate or website. As indicated by the green lock, this is still a valid certificate which has been served correctly by the website.
 

Full Certificate Transparency Support

To provide full support for Certificate Transparency, this will require both support on the server and via the CA. At present (April 2014), for almost all hosting services this isn't supported by the server. The changes to the required packages (OpenSSL) is currently scheduled for version 1.0.2, however this may be subject to change. There's no guarantee that this will be backported to current Red Hat / CentOS releases, which means it would have to come from a third party repository.

As the certificates are still valid without this support, Conetix recommends waiting until there is full support by all CA's and also by standard system packages. The extra transparency will provide additional security assurance for SSL's going forward to provide further assurance that the SSL certificate is correct.

Further Reading

Official Site: https://www.certificate-transparency.org/

Current RFC (Experimental): https://tools.ietf.org/html/rfc6962

Google Group Discussion: https://groups.google.com/forum/#!forum/certificate-transparency