Resolved 12.0 to onyx upgrade - problem with login

[Tempest]

Hi,

I ran the auto upgrade from 12.0 to onyx, it seemed to have completed fine, more or less.

The websites are running fine (or even better - faster), ftp's work fine etc., however, I cannot log in to the pesk panel at all.

Has anyone experienced anything like it?

Many thanks,
Peter

 

[IgorG]

What exact error do you have when you try login to plesk with https://domain.name:8443 ?

Have you tried to fix it with

# plesk repair installation

?

 

[Bitpalast]

Maybe sw-cp-server is not running?
# service sw-cp-server restart

 

[Tempest]

Thank you for the clues.

When I go to :8443 page, nothing shows up, as if the domain did not exist.
I tried rebooting the server but no joy.

So it looks like the plesk does not work, however since the upgrade I keep receiving admin emails from plesk about updates:
"Package Update Manager notification
The following package updates are available:
- accountsservice 0.6.35-0ubuntu7.3 from Ubuntu for trusty-updates by Ubuntu repo (currently installed version: 0.6.35-0ubuntu7.1 from now repo)
(and here goes a long list of the packages)
You can update these packages in System Updates: https://xxx:8443/admin/pum"

However, if I click on this link, nothing shows up ("Problem loading page, unable to connect).




As for your other suggestions, how would I do
# plesk repair installation
or
# service sw-cp-server restart
?

 

[Bitpalast]

As for your other suggestions, how would I do
# plesk repair installation
or
# service sw-cp-server restart
?

You cannot reach the Plesk GUI, because most likely Plesk web server is not running.
You must login via SSH to your Linux console, then switch to superuser (# su) then enter the commands. The "#" is a prompt sign only quoted to clarify that the command is a command to enter on the console. Do not include that in the command.

 

[Tempest]

Thank you for that Peter.

There was an error during the repair and the sw-cp restart didn't succeed. Here's a final screenshot.

 

[Bitpalast]

Check the ssl_ciphers line in /etc/sw-cp-server/conf.d/ssl.conf and remove the duplicate line. If there are different entries, keep the one with the most entries. Then try restarting sw-cp-server again.

 

[Tempest]

there are only three lines in the file. couldn't find any duplicates in my understanding.
could you advise on how that line should look like, please?

 

[Bitpalast]

Please run
# grep -R ssl_ciphers /etc/sw-cp-server/*
to identify the file where the other ssl_ciphers directive is listed. It is probably in /etc/sw-cp-server/config. The /etc/sw-cp-server/conf.d/ssl.conf is included in the config file, so if there is an ssl_ciphers directive in the config file, one of the two is too many. The line from your screenshot is correct, so if you find the same line or similar in the /config file or elsewhere, you can safely remove that. It is still a good idea to make a backup of a file that you edit, before apply changes.

 

[Tempest]

the only other ssl_ciphers line was found in /pci-compliance.conf file, and this one does have more entries.
In the previous post you advised to remove the one with less entries, does this mean it's better to leave the in /pci-compliance.conf as it is, and remove the ssl_ciphers line in ssl.conf?

 

[Bitpalast]

Basically, yes, but also no. If the pci-compliance.conf file is present, an "add-on" configuration was done, because that file is not standard. It is an enhanced security measure. Personally, I'd probably rather revert back to the default to get the server up and running again, then think about enhancing security later. The default setup is "secure", it is just not "perfectly secure".

You can try either way. Maybe you would simply want to copy the pci-compliance.conf into a backup (outside the directory!) and remove the pci-compliance.conf file. Then check whether sw-cp-server can be started.

 

[Tempest]

woo hoo!
it worked! thank you so much for help and patience!