Board index Installation Database error after installing SSL

Having trouble installing serendipity?
NeilW
Regular
 
Posts: 50
Joined: Sat Jun 20, 2015 6:56 am

Postby NeilW » Tue Mar 07, 2017 2:42 pm

Hi,

I have just moved my site to SSL and have all my pages working fine and are secure after changing all the links to 'https:' from 'http:'.

My blogs also worked fine up to this time, except once the move to SSL the pages were not rendering correctly and like the other pages on my site did start rendering correctly once I updated all the links to 'https:'.

I have had embedded pages in my blog and was using the 'clean-blog' theme. (Which no longer seems available in themes list).

But then after going into the blog admin, without even making any changes, I get the following serendipity error: "unable to connect to database - exiting" on exiting.

I have tried to restore from back-ups that were done before the move to SSL but they immediately have the above error, even though the blogs were working fine at the time of the backup.

I have also deleted one of the installations and done a fresh installation, but again, as soon as I try to configure the blog, by the ‘indexFile’ serendipity-option point to the ‘wrapper.php’ file, I again get the error.

I thought that there may be something with the 'clean-blog' theme that may not be compatible with s9y 5.5, so I did another clean install and just kept the standard 2k11 theme but that also got the same error as soon as I used the ‘indexFile’ serendipity-option to point to the ‘wrapper.php’ file.

So everything I try still brings the serendipity error: "unable to connect to database - exiting". I have been doing this non-stop for 12 hours today and it is driving me crazy.

Could someone please advise how I can get my blogs up and running again without this constant error?

I am starting to wonder if I need to change or delete something in the blog .htaccess file?

Any thoughts would be greatly appreciated.

- Neil

User avatar
onli
Regular
 
Posts: 2055
Joined: Tue Sep 09, 2008 10:04 pm

Postby onli » Wed Mar 08, 2017 12:52 am

Sorry to state the obvious, but: Are you sure the database is up and running? Persistent database connection error is likely to mean that it just went down, with no link to s9y.

NeilW
Regular
 
Posts: 50
Joined: Sat Jun 20, 2015 6:56 am

Postby NeilW » Thu Mar 09, 2017 11:28 am

Hi Onli, great to hear from you again and trust that all is going well for you.

I started a nice informative reply to you yesterday, finished it off tonite, went to save it and got kicked out because I was no longer logged in and lost the lot!! :cry: :cry: Seems I can't win a trick at the moment, but here we go again...

I have been trying everything I can think of to get over the problem, ensuring the permissions are correct, doing fresh installations, cloning the old ones (which worked fine before the move to ssl) and am still getting the same issue.

So in answer to your question I am not sure how I could not be connected to the DB when I have just done a fresh install, or cloned another and am able to both view the page and go into the admin area, do a maintenance check, (which comes up OK), log out successfully, log in again and do another maintenance check, (which still comes up OK), etc., etc., but as soon as I make one small change in the admin area (and it can be something simple such as deleting the last letter from the blog name, or adding another letter to it and update and save it (successfully) I get the error immediately when I try to log out.

Here are two installations.

This one is a clone from my previously installation with the links all updated to 'https:' and rendering fine. (Even confirming that the page is 'secure'): https://mybusiness-mylife.com/global/pr/blog.php

And this one is a brand new vanilla flavoured installation that remains totally untouched: https://mybusiness-mylife.com/s9y/.

Now I could go into both of the admin areas for these blog pages, and as said above - do maintenance checks, (which come up OK), log out successfully, log in again and do more maintenance checks, (which still come up OK), etc., etc., but as soon as I make one small change in the admin area they will immediately bomb on log-out with the serendipity error: "unable to connect to database - exiting" on exiting.

I have done all of the cloning and installing through Softaculous as supplied by my web host, but as you know, I have not had any previous issues with that.

The only thing that looks a bit weird is the path to the directory. The URL's are fine, but the directly path has two "//" in font of instead of "/" - as in "/home/mysite/public_html//s9y", so I am not sure if that creates the error, or not.

I certainly did not put an "/" in front of the directory name when installing, it just comes up that way - and as mentioned above, the URL only shows one "/".

I was able to edit the directory path and update it through Softaculous to show only the one "/", but the error still happened after logging into the admin area, making a small change, and logging out again.

So I am totally baffled here as to what on earth is going on and why I am continually getting the error.

Obviously I am not able to do any work on my blog while this persists, and I also seem to have lost my previous entries because the back-up's don't restore properly either.

So any help would be really appreciated. (You will probably remember my site when you see it again) :wink: :wink:

Thanks again,

- Neil

User avatar
onli
Regular
 
Posts: 2055
Joined: Tue Sep 09, 2008 10:04 pm

Postby onli » Thu Mar 09, 2017 1:35 pm

Sure, I remember :)

Okay, that makes it a bit clearer. You describe that everything works till you go into the configuration and save, right? We had that problem a few times, and normally the fault lies with the autocomplete function in the browser, which inserts a wrong password into the database password field. There are various methods in place to prevent that, but maybe that's not enough here.

Did you already check the file serendipity_config_local.inc.php on your webserver? It contains the database settings. Are those correct?

NeilW
Regular
 
Posts: 50
Joined: Sat Jun 20, 2015 6:56 am

Postby NeilW » Fri Mar 10, 2017 2:11 am

That's an interesting question about the password and the serendipity_config_local.inc.php file.

I am still going through it, but have found something interesting that I thought I would quickly bounce off you.

When I look at my old installations (before I moved to ssl), their serendipity_config_local.inc.php files show the actual password in plain text. For example, if I had entered something like 'password123' it is 'password123' that shows as the $serendipity['dbPass']. (Even now, after moving to ssl, those passwords remain in plain text and as initially entered.)

But in the clones and newer installations the $serendipity['dbPass'] look to be either encrypted or corrupted. These passwords take the form of 'F6pnc[G!14' or [email protected]@46PX', etc. which are not the real passwords I had set up.

So now I am wondering if, after the move to ssl, the passwords should be encrypted in the serendipity_config_local.inc.php file?

Or, if even after the move to ssl, should the password be shown in plain text as originally set up?

At the moment, it appears that I have both.

If they should be in plain text, then the issue I have seems to be fairly straight forward ( yeah, I know, there is no such thing :P ).

But if that is also the case, why did my original installations that have plain text passwords in the serendipity_config_local.inc.php file crash?

If they are supposed to be encrypted, why are my new installations crashing? (Although, I understand what you are saying about the auto correct changing it, but how can you tell if it is encrypted?).

Interesting and frustrating stuff. :roll:

NeilW
Regular
 
Posts: 50
Joined: Sat Jun 20, 2015 6:56 am

Postby NeilW » Fri Mar 10, 2017 4:23 am

*** UPDATE ***

OK, so I am still learning here a little, so please bear with me.

It turns out that the passwords that I thought were encrypted actually are the database passwords that were created on installation by the installation software.

So they do agree in the new installations. (Which still doesn't explain why I have the issues in the new installations and clones).

The plain text passwords in the old installations were somehow wrong, they were the admin passwords, not the database passwords. That was what was leading me to think that the database passwords in the serendipity_config_local.inc.php files were perhaps encrypted.

I have no idea how that happened, because the installations with those passwords were previously working fine and I certainly did not edit the serendipity_config_local.inc.php files.

So far, I have gone into one of the old installations, and changed the password in the serendipity_config_local.inc.php file to the real database password. - No shocks there, the old database now opens OK and I have been in and out the admin area without issues. (I have not dared change anything, as yet, but).

Now please note that the old installations are still version 2.0.1, whereas the new installations and clones are 2.0.5. (Therein could lay another issue).

I had 4 blogs and database in my initial installation. One now seems to work but needs testing. One needs the database password changed in the serendipity_config_local.inc.php file to the correct password. One had the correct password and was the one that I was cloning the others from, but I was not game enough to make any changes in it to see if it was going to crash. So they are all the 2.0.1 versions that I have. The forth database was built off that clone and upgraded to 2.0.5.

So I am now going to see if I can resurrect things back to the original four databases at version 2.0.1.

If I can get them working again without crashes, then we can start worrying about what is happening with 2.0.5.

Stay tuned... :lol: :lol:

NeilW
Regular
 
Posts: 50
Joined: Sat Jun 20, 2015 6:56 am

Postby NeilW » Fri Mar 10, 2017 7:23 am

:cry: :cry: :cry:

It all sounded like a plan, but no matter what I try to do it continually crash's and burns.

I have just one 'working' blog left which is one of the old 2.0.1 ones and it is the only one where I was able to fully update the path in the admin file to "https:" without it crashing.

As soon as I tried that on the second 'working' blog it too crashed.

I say 'working' with the first blog, because I was at least able to add "https:" to the links in the admin area and the theme. Plus I edited a blog post, and all that saved fine.

With the current issues, heaven knows what would happen if I actually tried to create a new entry - I just want to risk the outcome.

I tried to clone that working blog and it all looked ok, until I made the change to the blog name in the admin area - just one tiny little word, and it crashed.

I have been working on this all week for 12-16 hours a day and am totally deflated and exhausted.

sy9 seems so fragile and temperamental. :? :?

Here is hoping that you can come up with a solution, because I have come to the end.

Thank you.

User avatar
onli
Regular
 
Posts: 2055
Joined: Tue Sep 09, 2008 10:04 pm

Postby onli » Fri Mar 10, 2017 12:19 pm

I will play the old wise men: You need to take a break. If you stare on a problem like this for 12-16h there is no chance in hell you will solve it.

We actually know a bit more now. You ran into the browser auto-completion bug of 2.0.1, that is what changed your database password to the admin password.

You need to do one thing, and that with proper backups:

1. Take a working blog. Does not matter whether it is 2.0.1 or 2.0.5. Look how the serendipity_config_local.inc.php looks like.
2. In the configuration: Change the url to https://
3. If it works: End, all is good.
4. If it does not: Look at the serendipitipy_config_local.inc.php. Does it still have the correct database settings?
5. If not: Change them
6. If the blog still crashes with a database error, then you know now that there is another issue in play. I would like to see the webserver error output of that crash then.

NeilW
Regular
 
Posts: 50
Joined: Sat Jun 20, 2015 6:56 am

Postby NeilW » Sat Mar 11, 2017 1:12 am

Thank you wise old man. :lol: :lol:

I have had a good night's sleep and feel a lot better.

I must have been so close with that second 'working' blog that crashed after I changed the path to 'https:'

As you suggested above, I went back into the serendipitipy_config_local.inc.php and yep, the database password had changed back again to the admin password.

So I re-set it to the database password again and was able to get back into the blog page and admin pages and make a few more little changes without crashing out.

I still have to upgrade 2 of the 3 blogs to 2.0.5 and then get the one on the public pages working again by either cloning and/or following the steps I have taken to get the others working.

I am still perplexed as to why the new installations kept crashing though. I probably did about 20 of them over the past week, they were all version 2.0.5 so should not have had the 'bug' and they all crashed when I tried to change the blog name in the config. :?

But from what you say above, I take it that you would think that this should now get me past the problem and back to normal?
Last edited by NeilW on Sat Mar 11, 2017 1:18 am, edited 1 time in total.

User avatar
onli
Regular
 
Posts: 2055
Joined: Tue Sep 09, 2008 10:04 pm

Postby onli » Sat Mar 11, 2017 1:16 am

Yes. I think your whole problem was your browser setting the wrong database password, which you did not see (not surprising, it is hidden by default) and then there was chaos. We pushed some patches for that in recent versions, and I think that was before 2.1. Those work for me, I really assume they will work for you, upgrading to 2.0.5 should prevent this from happening again (at least till browser get a bit more stupid again).

NeilW
Regular
 
Posts: 50
Joined: Sat Jun 20, 2015 6:56 am

Postby NeilW » Sat Mar 11, 2017 1:26 am

Thanks mate, there are a few beers waiting here for you if you want to come and get them. :P :P

But with all the new installations crashing, I would guess that the bug still exists in 2.0.5.

At least if it happens again, I know the first place to look. I didn't think that I had manually changed the password so I'm glad to know too that I have not gone {fully} crazy yet and the browser did it.

Thanks so much again for your help and have a great weekend.

User avatar
onli
Regular
 
Posts: 2055
Joined: Tue Sep 09, 2008 10:04 pm

Postby onli » Sat Mar 11, 2017 1:32 am

Thanks :)

It is possible I mixed it up and the fixes are actually in 2.1. That should be released soon as well.

NeilW
Regular
 
Posts: 50
Joined: Sat Jun 20, 2015 6:56 am

Postby NeilW » Sat Mar 11, 2017 1:41 am

I will definitely keep an eye out for 2.1 and upgrade immediately, as it seems like the problem does persist in 2.0.5 whenever the configuration page is opened and saved.

(Just for the record, I am using a Mac and Safari)

Thanks again

NeilW
Regular
 
Posts: 50
Joined: Sat Jun 20, 2015 6:56 am

Postby NeilW » Sat Mar 11, 2017 3:58 am

*** ISSUE SOLVED ***

Just a quick tag and summary for anyone who may have this issue in the future and, as I was, be a bit slower to pick up the terminology with 'auto-completion' as used above.

The term 'auto-completion', to me, means an instance where you have entered a text area and begin to type text and the browser or app pre-empts the word and 'auto-completes' it.

In reality, what seems to be happening here is not 'auto-completion' because the password text field does not need to be entered to be changed.

What I would term it is 'auto-fill' where the browser actually 'auto-fills' any open password field with a previously saved password relating to the page.

In this case, the browser has remembered the administration page password on logging in and 'auto-fills' the open database password field on the configuration page and overwrites it with the remembered administration password, so that when you make a change anywhere on the configuration page and save it, you are inadvertently saving the password change - thus causing the password mismatch and the page error on exit.

You cannot go back into the administration page and correct the password or open the blog page while this mismatch continues to exists.

However, you can go into the serendipitipy_config_local.inc.php file and change the password there, (which will now be the administration page password) back to the database password and save it.

This will fix the problem.

Hope this helps.

NeilW
Regular
 
Posts: 50
Joined: Sat Jun 20, 2015 6:56 am

Postby NeilW » Mon Jun 05, 2017 5:00 am

Glad it helped! :lol:

There is a more recent version 2.1.1 that has been released and I would think that from the comments by Onli above, the problem should have been addressed with it. But I do not see anything specific in the release notes.



Return to Installation

Who is online

Users browsing this forum: No registered users and 2 guests