Forums | Mahara Community
Support
/
Could not generate a new SSL key
23 April 2017, 17:45
I'm migrating a Mahara 15.04.2 installation to a Mahara 16.10.2 installation on a different server, same debian8 os. I've performed the update, and it was successful. I moved the data directory over.
I get this error when running the 16.10.2 code and attempt to load an administration page:
example.us: Site unavailable
The environment where example.us is running is misconfigured and this is causing problems. You probably need to contact a server administrator to get this fixed. Details, if any, follow:
Could not generate a new SSL key. Are you sure that both openssl and the PHP module for openssl are installed on this machine?
In addition to that error, any user page that does manage to load (several do), takes several minutes to load (5-10).
If I change back to the 15.04.2 code I don't get any errors and the pages load at a normal speed.
I'm not sure why I need to generate an SSL key, as I'm using letsencrypt for ssl. I do see that the config table in mysql currently has a key stored, which doesn't seem to interfere with the older installation.
Anyway, this is unfortunate and I would like to upgrade to 16.10.2. Can anyone point me toward a solution?
TIA
24 April 2017, 9:36
Hi Gary,
Did you check if you have openssl and the requisite PHP module installed on the new server?
Cheers
Kristina
24 April 2017, 10:59
Hi Kristina
I do have openssl installed and my research tells me that debian8 php packages include openssl support.
Gary
02 May 2017, 10:16
Hi Gary,
This behaviour can happen if PHP can't find the openssl.cnf file
Ususally these are present at (in Ubuntu)
/etc/ssl/openssl.cnf
/usr/lib/ssl/openssl.cnf
Or the location can be set via the
$cfg->opensslcnf value in config.php
Try setting the path to the file via
$cfg->opensslcnf = '/actual/path/to/file';
to see if that helps
Cheers
Robert
02 May 2017, 16:46
Thanks for the idea, Robert.
I've just upgraded to 17.04 successfully. I'm still having the same issue I had with 16.10 even after I took your suggestion and set the path to openssl.cnf in the config.php file.
In addition 17.04 won't allow me to login. Perhaps I should try a fresh install or just stay with 15.04? Until now, I've never had any problems with mahara, it's really quite fustrating.
If I use port 80 in my VH and an http:// address then the speed issue is gone, pages load very fast.
Gary
03 May 2017, 16:59
Hello Gary,
Please give it a go with a fresh install. It might have been something small that is causing you problems. You don't want to stay with Mahara 15.04 as it doesn't contain all the new features we implemented since. :-)
Maybe you should also look into using Memcache for sessions? See https://bugs.launchpad.net/mahara/+bug/785469/comments/1 for a patch. Robert might have some more ideas, but since we don't have access to your hosting environment, troubleshooting might be slow going via the forum.
Cheers
Kristina
04 May 2017, 16:57
Well I could give you access to the fresh install, but unfortunately it never seems to work. The installation page loads and I click on <Install> , the message <Performing Installation> appears and then afterward whatever link I click on or if I re-enter the url the browser just returns to the <install> page.
I've done fresh unpacks of the code base, drop and create a new db and user, granted and flushed privileges and created a fresh data directory .... several times as a group.
So, I must be doing the same thing wrong everytime and just don't see it. Got any ideas?
TIA, Gary
Here's the output:
Performing installation...
Component or plugin | From version | To version | Information |
---|---|---|---|
core | Not installed | 17.04.0 | |
firstcoredata | |||
localpreinst | |||
artefact.annotation | Not installed | 1.0.0 | |
artefact.plans | Not installed | 0.0.1 | |
artefact.internal | Not installed | 1.3.0 | |
artefact.file | Not installed | 1.2.7 | |
artefact.resume | Not installed | 1.0.3 | |
artefact.blog | Not installed | 1.2.0 | |
artefact.comment | Not installed | 1.0.1 | |
auth.webservice | Not installed | 2.0.2 | |
auth.ldap | Not installed | 1.1.0 | |
auth.xmlrpc | Not installed | 1.0.0 | |
auth.browserid | Not installed | 0.0.0 | |
auth.saml | Not installed | 1.2.0 | |
auth.imap | Not installed | 1.2.0 | |
auth.none | Not installed | 1.0.0 | |
auth.internal | Not installed | 1.0.0 | |
notification.email | Not installed | 1.0.0 | |
notification.emaildigest | Not installed | 1.0.1 | |
notification.internal | Not installed | 1.0.3 | |
search.elasticsearch | Not installed | 1.0.4 | |
search.internal | Not installed | 1.0.0 | |
module.framework | Not installed | 1.0.3 | |
module.mobileapi | Not installed | 1.0.0 | |
module.multirecipientnotification | Not installed | 1.0.2 | |
module.lti | Not installed | 1.0.0 | |
blocktype.file/filedownload | Not installed | 1.0.1 | |
blocktype.annotation/annotation | Not installed | 1.0.0 | |
blocktype.file/html | Not installed | 1.0.1 | |
blocktype.file/image | Not installed | 1.0.3 | |
blocktype.internal/textbox | Not installed | 2.0.1 | |
blocktype.plans/plans | Not installed | 1.0.1 | |
blocktype.internal/profileinfo | Not installed | 1.0.1 | |
blocktype.blog/blog | Not installed | 1.0.1 | |
blocktype.resume/entireresume | Not installed | 1.0.1 | |
blocktype.comment/comment | Not installed | 1.0.1 | |
blocktype.blog/taggedposts | Not installed | 1.1.1 | |
blocktype.file/gallery | Not installed | 2.0.1 | |
blocktype.file/internalmedia | Not installed | 1.0.1 | |
blocktype.file/folder | Not installed | 1.0.2 | |
blocktype.resume/resumefield | Not installed | 1.0.1 | |
blocktype.blog/recentposts | Not installed | 1.0.1 | |
blocktype.internal/socialprofile | Not installed | 1.0.1 | |
blocktype.externalvideo | Not installed | 1.1.0 | |
blocktype.file/pdf | Not installed | 1.0.2 | |
blocktype.blog/blogpost | Not installed | 1.0.1 | |
blocktype.externalfeed | Not installed | 1.0.6 | |
blocktype.myviews | Not installed | 1.0.2 | |
blocktype.myfriends | Not installed | 1.0.1 | |
blocktype.watchlist | Not installed | 1.1.0 | |
blocktype.groupviews | Not installed | 1.0.3 | |
blocktype.groupmembers | Not installed | 1.0.1 | |
blocktype.openbadgedisplayer | Not installed | 1.0.5 | |
blocktype.recentforumposts | Not installed | 1.0.1 | |
blocktype.navigation | Not installed | 1.0.1 | |
blocktype.wall | Not installed | 1.2.0 | |
blocktype.newviews | Not installed | 1.0.2 | |
blocktype.inbox | Not installed | 1.0.1 | |
blocktype.creativecommons | Not installed | 1.0.1 | |
blocktype.googleapps | Not installed | 1.0.9 | |
blocktype.mygroups | Not installed | 1.0.1 | |
blocktype.groupinfo | Not installed | 1.0.0 | |
blocktype.text | Not installed | 1.0.3 | |
interaction.forum | Not installed | 1.2.2 | |
grouptype.standard | Not installed | 1.0.0 | |
grouptype.course | Not installed | 1.0.0 | |
import.leap | Not installed | 0.1 | |
import.file | Not installed | 0.1 | |
export.html | Not installed | 0.1 | |
export.leap | Not installed | 0.1 | |
lastcoredata | |||
localpostinst |
08 May 2017, 13:34
I switched to the cli installation method.
The install went ok, I was able to login and do all the normal things.
However, I'm still stuck with not being able to use https. Http works fine. I'm using a fixed domain name dedicated to mahara, like "http://myhost.org" (no path after that). What's the normal way for people to use https with mahara? The config.php file says:
/**
* wwwroot: The base URL of your Mahara installation.
*
* (Normally, this is automatically detected. If it doesn't work for you then try specifying it here.)
*/
// Example:
// $cfg->wwwroot = 'https://myhost.com/mahara/';
If I don't put a wwwroot in mahara won't load, and I can't use https. My server is using letsencrypt and I haven't had any issues with https for my other domains. Is there a problem with not having the "/mahara/" at the end of the url?
Also, is there a way to import my old data into the new mahara, even for just one user?
TIA,
Gary
09 May 2017, 9:56
Hi Gary,
If you've installed the site via http first then there might be a setting in the database config table for http.
Try doing the search:
SELECT * FROM config WHERE field = 'wwwroot';
And update value as needed.
You should be fine to run Mahara with just a domain name set, eg https://example.com/
To import old data into the new Mahara you can either (easy way) export users via Leap2A and then import them into new Mahara. This will migrate user data across - but will lose group/institution data.
The harder way would be to make a migration script that connects to both databases, old and new, and read from one a write to the other.
Cheers
Robert
14 May 2017, 9:05
First I would like to thank both of you for taking the time to help me with this installation. Mahara is now working perfectly. It really is a top notch web application.
I'd like to include some notes as to what I think were the main problems/solutions for the sake of possible future users that might experience similar issues. I'm not certain that my conclusions are accurate, but it's the best I can offer. I was upgrading from v15 to v17.04. I used a new installation of 17.04 for testing and comparison, but ended up staying with the upgrade.
The problem as stated in the title of this post could have been related to the config table in the mahara miriadb. There were many extra rows in that table that were not part of a default installation of version 17.04. My solution was to remove all values from fields that did not exist in a standard 17.04 installation. These included fields containing ssl snakeoil certs from previous mahara installations.
The speed problem that was causing my pages to take 5+ minutes to load was solved by coping the letsencrypt cert enabling apache configuration lines to the mahara virtual host as well as in the default ssl virtualhost. I can't explain why it needs to be in both, but it works.
Once again, thank you for helping.
- «Previous page
- 1
- 2
- »Next page