Resolved Unable to modify "/usr/share/psa-roundcube/config/config.inc.php"

[learning_curve]

As the thread title says really but we can't We suspect this MAY be linked back to the MySql / Maria DB setup...

We want to ensure that if/when on the rare occasions that Roundcube is used, it's via https only. Post_#6 in that previous thread clearly explains how to do this. However, in our case, the suggested file: /usr/share/psa-roundcube/config/config.inc.php already exists (it was created on the 1st day we started with Plesk) and it contains the following content:

<?php
// Copyright 1999-2016. Parallels IP Holdings GmbH. All Rights Reserved.
$config = array();
$config['db_dsnw'] = 'mysql://roundcube:uSoz9567Jl3qHYx@localhost/roundcubemail';

We initially assumed that adding the extra coding required to achieve the Roundcube https only requirement, in this file, would not be an issue and it isn't, but trying to enable the new file is....
With the new file in place, it's impossible to login to any e-mail account via Roundcube (e-mail elsewhere is unaffected) and a standard error note is provided. Restoring the original file then means that everything in Roundcube goes back to normal.

Internal Server Error

Removing this mysql line from this file leaving only the additional code is not an option obviously, as another expected standard error is produced:

Database Error: Connection Failed!
Unable to connect to the database!
Please contact your server-administrator.

If we try adding the required code in the system file: /usr/share/psa-roundcube/config/defaults.inc.php this isn't an option either as another standard error is produced:

Configuration Error
defaults.inc.php was not found.
Please read the INSTALL instructions!

So... in each case above, changing either of these files results in no access to Roundcube.

Due to the existing mysql reference in the /usr/share/psa-roundcube/config/config.inc.php file and because this was created on the day we started with Plesk, which we then switched over to a Plesk supported version of MariaDB (currently > MariaDB 10.1.28) within a couple of days, having never used the default supplied mysql at all (our own specific setup choice and no sites were made until this was 100% functionally checked and complete), we now wonder if this is causing the issue?

For extra details:

# sudo service mysql status
ERROR! MySQL is not running, but lock file (/var/lock/subsys/mysql) exists
# sudo service mariadb status
ERROR! MySQL is not running, but lock file (/var/lock/subsys/mysql) exists

This note:

ERROR! MySQL is not running, but lock file (/var/lock/subsys/mysql) exists

is common but we're assuming in our case, this is because MariaDB is active not MySQL hence the mysql > mariadb link too

So in more detail:

systemctl status mysql
● mysql.service - LSB: start and stop MySQL
   Loaded: loaded (/etc/rc.d/init.d/mysql; bad; vendor preset: disabled)
   Active: active (exited) since Fri 2017-10-27 03:53:51 BST; 1h 29min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 989 ExecStart=/etc/rc.d/init.d/mysql start (code=exited, status=0/SUCCESS)
   Memory: 0B

Oct 27 03:53:46 *.* systemd[1]: Starting LSB: start and stop MySQL...
Oct 27 03:53:48 *.* mysql[989]: Starting MySQL.171027 03:53:48 mysqld_safe Logging to '/var/log/mariadb/mariadb.log'.
Oct 27 03:53:48 *.* mysql[989]: 171027 03:53:48 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
Oct 27 03:53:51 *.* mysql[989]: .. SUCCESS!
Oct 27 03:53:51 *.* systemd[1]: Started LSB: start and stop MySQL

# top |grep mysql
 1197 mysql     20   0  803572 153168  11528 S   0.3  3.8   0:01.32 mysqld                                   
 1197 mysql     20   0  803572 153168  11528 S   0.3  3.8   0:01.33 mysqld

systemctl status mariadb
● mariadb.service - MariaDB database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/mariadb.service.d
           └─migrated-from-my.cnf-settings.conf
   Active: active (running) since Fri 2017-10-27 03:53:50 BST; 1h 32min ago
  Process: 2071 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 1035 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
  Process: 998 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
 Main PID: 1197 (mysqld)
   Status: "Taking your SQL requests now..."
   Memory: 210.7M
   CGroup: /system.slice/mariadb.service
           └─1197 /usr/sbin/mysqld

Oct 27 03:53:50 *.* mysqld[1197]: 2017-10-27  3:53:50 139836898035968 [Note] InnoDB:  Percona XtraDB (http://www.per...1272324
Oct 27 03:53:50 *.* mysqld[1197]: 2017-10-27  3:53:50 139836119836416 [Note] InnoDB: Dumping buffer pool(s) not yet started
Oct 27 03:53:50 *.* mysqld[1197]: 2017-10-27  3:53:50 139836898035968 [Note] Plugin 'FEEDBACK' is disabled.
Oct 27 03:53:50 *.* mysqld[1197]: 2017-10-27  3:53:50 139836898035968 [Note] Server socket created on IP: '127.0.0.1'.
Oct 27 03:53:50 *.* mysqld[1197]: 2017-10-27  3:53:50 139836898035968 [ERROR] Missing system table mysql.roles_mappi...eate it
Oct 27 03:53:50 *.* mysqld[1197]: 2017-10-27  3:53:50 139836897614592 [Warning] Failed to load slave replication sta...t exist
Oct 27 03:53:50 *.* mysqld[1197]: 2017-10-27  3:53:50 139836898035968 [Note] /usr/sbin/mysqld: ready for connections.
Oct 27 03:53:50 *.* mysqld[1197]: Version: '10.1.28-MariaDB'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MariaDB Server
Oct 27 03:53:50 *.* systemd[1]: Started MariaDB database server.
Oct 27 03:53:51 *.* mysqld[1197]: 2017-10-27 03:53:51 7f2e50973b00 InnoDB: Error: Table "mysql"."innodb_table_stats"... found.
Hint: Some lines were ellipsized, use -l to show in full.

What we want to do is re-specify Roundcube, but it looks like we may need to resolve this item first...
There are no current issues or faults on any live sites setup as it is, but all suggestions / guidance welcome

 

[UFHH01]

Hi learning_curve,

it's kind of a pitty, that you missed to scroll further in the above mentioned thread, as you could have found there a link to the official Plesk Knowledge - Base, with another global resolution:

=> How to redirect webmail HTTP to HTTPS?​

 

[learning_curve]

it's kind of a pitty, that you missed to scroll further in the above mentioned thread, as you could have found there a link to the official Plesk Knowledge - Base, with another global resolution: => How to redirect webmail HTTP to HTTPS?

"He who assumes is lost"
Nope, we had read ALL that thread and we didn't miss that suggestion at all.
We didn't see anything wrong with the post you had made is the reality. Makes perfect sense.
Yes we can try the Plesk option too if/when we want to, but the mysql / mariadb question that has now been raised (and which is possibly related ) we will still need to understand fully beforehand anyway now

 

[learning_curve]

Today's update. We've used Solution 1 > Global Resolution by Plesk which does exactly what it says it will; that's changing http to https i.e. no other changes are made using this method. If you are wanting to make other addditional changes to roundcube security (like we are e.g. TCP port for IMAP and SMTP Port ** etc) then Post_#6 by @UFHH01 still appears to be a very logical, sensible way to apply these changes we think. That, then brings us back to the mysql / mariadb question again and one which we wouldn't have immediatey seen, had we not followed this thread orginally! We should be able to modify/change either /usr/share/psa-roundcube/config/config.inc.php and /usr/share/psa-roundcube/config/defaults.inc.php or both, without any issues, but we can't (yet) as explained in our opening post. We can clearly see and access the user roundcube initially via https:/*.*:8443/plesk/server/db/ and then via *.*:8443/domains/databases/phpMyAdmin/sql.php?server=1&db=mysql&table=user&pos=0&token=*.* no problem, but as to what's needed next to solve this access issue, we are obviously unsure. When used, the modified versions of both of those files have exactly the same name / same access rights etc as the currently, fully functional original files, but they will not work. Why this is happening, is the answer we want to figure out now...

** Part of the longer term plan to close TCP Port 25 permanently

 

[learning_curve]

Well that was an interesting experience...

Using Roundcube only via https and not http was the easy part to achieve, as we posted earlier. The resolution of everything after that... as per our name in this forum, was indeed a definite learning curve!

A large amount of reading on the interaction between Roundcube / Postfix / Dovecot and then the same again, but this time between MySQL / MariaDB etc means we can close this thread, because we've solved our original question ourselves thankfully. We'll post more questions, but on different subjects as we proceeed...