Basically having you try it from another directory to avoid the docker-compose executable that is in that directory (then may be able to simply remove the outdated executable).
I actually had to install it to begin with because it wasn’t in the path …
How do I install the correct version of docker without using PowerShell (I don’t know what that is).
Also,
See my post above regarding the database link. The settings in the docker-compose.yaml are used for initial docker run, but will not be used in the upgrade. The database settings need to be modified in the docker itself in the sites/default/sqlconf.php file (since you need to redirect it to the RDS backup instance).
hi,
To help out, what do you see for the following:
docker --version
and
docker-compose --version
(run them both from within the /root/openemr-devops/packages/standard/ directory)
ubuntu@ip-172-31-44-33:~$ docker --version
Docker version 17.05.0-ce, build 89658be
root@ip-172-31-44-33:/root/openemr-devops/packages/standard# docker-compose --version
docker-compose version 1.8.0, build unknown
I’m running into another issue where the new EC2 instance cannot “see” the databases. On going to the web server I get the following error:
Check that you can ping the server 5-0-2-2019-08-04.cydpnbzyq3qr.us-east-1.rds.amazonaws.com.
Which, sure enough, I cannot ping … Probably because I’m not on the correct network with the database server…
I’m also going to ask Amazon AWS support … They are usually pretty good but it takes about 24 hours to get an answer.
–RBL
When you launched Standard, CloudFormation created a VPC and several subnets and security groups. Your snapshot instance needs to share all of these things, or the OpenEMR instance won’t be able to connect to it.
Mind that I didn’t say “IP” – the snapshot will have a unique IP, but it has to be part of the VPC and subnet (to make it addressable) and it has to be part of the security groups (to make it connectable).
1 Like
I started over, making sure that I have the consistent VPC and subnets, and that seems to have launched me past that database connectivity problem for now.
The ssl configuration of the replicated EC2 image is redirecting to the secure connection … in other words it won’t allow a http connection to the replicated image and immediately redirects to my domain with a https:// and I cannot remember how to “undo” this behavior. I know there must be a .cnf or .conf file somewhere that controls the redirection of http to https (forcing a https connection).
Update — I eliminated a .htaccess file and modified all the relevant .conf and .cnf files I could find. Finally sent a message to Amazon Tech Support to help me out on this.
–Ralf
AWS Tech support helped me out on this (by reading the OpenEMR manual no less)… those folks never cease to amaze me. Anyway, it turns out that there is a ssl configuration in OpenEMR itself and somehow that must be redirecting to the secure site rather than allowing an http connection to the test system. I would need to take this out of the configuration somehow … it’s probably buried in a database table for the openEMR configuration. Rather than go that route, I decided to first take the opportunity to test the backup and restore of 5.0.1(7) to create a new 5.0.1(7) test system that I could then upgrade to 5.0.2.
Sooooo … I created a new Standard OpenEMR 5.0.1-6b (the newest available) instance and database using the AWS Marketplace subscription system that uses Cloudformation. Next, I am patching it to 5.0.1(7). Then I am going to try to restore the backup and upgrade this system as explained by Brady, above.
–Ralf
If I remember correctly there is an openemr.conf somewhere that redirects port 80 or there is a virtual host for port 80 that redirects.
I was able to modify the openemr.conf file to take out that redirect. However, there is still something else (I removed all .htdirect files also)
I assume there’s a ssl virtual host set up for ssl. Ya sure there is not another vhost conf for port 80?
Also, wouldn’t access log point you to who is doing redirect?
Yes, correct. I agree with you that this shouldn’t be so difficult.
I’m going to try the following … (helplessly retrieved from https://serverfault.com/questions/11332/troubleshooting-apache-redirects-in-production)
To log what’s going on in the mod_rewrite module you need to set RewriteLog and RewriteLogLevel:
RewriteLog /path/to/mod_rewrite.log
RewriteLogLevel 2
I killed those test instances, but I can easily re-create them. I’m going to snapshot the current AWS production web server EC2 instance and image the MySQL database/instance and re-create that particular system and take another look. I’ll show you what I modify, and what the result is so I can troubleshoot this in more detail.
–Ralf
I reverted to the original openemr.conf and ssl.conf … renamed the .htaccess file to SSLhtaccess restarted docker … and it worked on the test system webserver EC2 instance … no more undesired redirect!
Thank you!
Now I need to connect the test system to the test database instance (it is connecting to the production database initially because this is from a snapshot … need to change the configuration to connect to the MySQL database that was created from the production database image.
–Ralf
1 Like
Good deal.
I find using netcat and pings very helpful along with traceroute for these type issues.
Good luck.
1 Like
Ok. So I have an AWS EC2/RDS(MySQL) test system now thanks to substantial help from everyone above.
Now I’m trying to do the upgrade on the test system as explained by @brady.miller above …
Step 1 - DONE: sudo bash … then cd /root/openemr-devops/packages/standard/ as given by brady.
Step 2 - DONE: Modify docker-compose.yaml file
Change the image: openemr/openemr:5.0.1 line in docker-compose.yaml to:
image: openemr/openemr:5.0.2
Step 3 - DONE:
root@ip-10-0-1-179 : /root/openemr-devops/packages/standard # /root/openemr-devops/packages/standard/docker-compose up -d
Removing elegant_goldstine
Removing nervous_elion
Removing affectionate_carson
Removing epic_kalam
Removing eloquent_mcnulty
Pulling openemr (openemr/openemr:5.0.2)…
5.0.2: Pulling from openemr/openemr
050382585609: Pull complete
4d61f28ee280: Pull complete
76e61a049383: Pull complete
bf5110788d99: Pull complete
0f871c9e49bb: Pull complete
61236122513d: Pull complete
343af72d1676: Pull complete
3ab4fbedcac6: Pull complete
9af2c76c95e8: Pull complete
b8fe35ac4f01: Pull complete
553e8e64c900: Pull complete
9674cacacb05: Pull complete
9ce5ad550ce6: Pull complete
Digest: sha256:616140a6039bb381ef1efecb573e4e30aa2e207c14339818d205664235c05430
Status: Downloaded newer image for openemr/openemr:5.0.2
Recreating standard_openemr_1 …
Recreating standard_openemr_1 … done
root@ip-10-0-1-179 : /root/openemr-devops/packages/standard #openemr-development
Then
docker logs standard_openemr_1
Plan to try an upgrade from 0 to 1
Attempting upgrade
Start: Processing fsupgrade-1.sh upgrade script
Start: Upgrade to docker-version 1
Start: Ensure have all directories in default
Completed: Ensure have all directories in default
Start: Update new directory structure in default
Completed: Update new directory structure in default
Start: Clear smarty cache in default … etc. etc. (lots of information)…
……
Completed: Upgrade database for default from 5.0.1
Completed: Upgrade to docker-version 1
Completed: Processing fsupgrade-1.sh upgrade script
Completed upgrade
Setting user ‘www’ as owner of openemr/ and setting file/dir permissions to 400/500
Default file permissions and ownership set, allowing writing to specific directories
Removing remaining setup scripts
Setup scripts removed, we should be ready to go now!
Love OpenEMR? You can now support the project via the open collective:
> https://opencollective.com/openemr/donate
Starting cron daemon!
Starting apache!
AH00558: httpd: Could not reliably determine the server’s fully qualified domain name, using 172.18.0.2. Set the ‘ServerName’ directive globally to suppress this message
Looks like it worked.
Now try it out…
Seems to work well. I will test this test system out for a few days before I upgrade the production system.
Thank you, everyone!!
–Ralf
4 Likes