Bitnami Magento 3.3.3 on Ubuntu 18.04.3 LTS

Keywords: Magento - AWS - How to - Upgrade
Description:
Is there an estimated release date for the Updated Bitnami Magento Lighsail blueprint?
If not, is there a path process you can suggest in steps for the upgrading of the current blueprint by the user before/after the current blueprint is configured? I know that the directory structure of your blueprints is a Bitnami are consistent and was not sure if manually upgrading Ubuntu or Magento would end up complicating things.
Thanks!

Hi @RStack,

Thank you for notifying us about this. The Lightsail team is in charge of updating the solutions and we already sent the new version to them. I’ll ask them for more information to know the status of those solutions.

If you want to use the latest version of the Bitnami solution, you can launch a new instance with the old version of Magento and run the following commands to stop that old version (and remove all the data) and install the latest one

sudo /opt/bitnami/ctlscript.sh stop
sudo rm -rf /opt/bitnami
cd /tmp
curl -LJO "https://downloads.bitnami.com/files/stacks/magento/2.3.3-1/bitnami-magento-2.3.3-1-linux-x64-installer.run
chmod +x ./bitnami-magento-2.3.3-1-linux-x64-installer.run
sudo ./bitnami-magento-2.3.3-1-linux-x64-installer.run

Happy to help!


Was my answer helpful? Click on :heart:

Hi Jota,
Thats Great!!!
Thank you

Any chance I could upgrade Ubuntu to 18.04.3 LTS, after downloading, but Prior to running your newer Magento 3.3.3 installers?
I tried with Magento 2.3.2 stack (and all services stopped), but was unable afterwords to connect SSH (as it warned that I might not be able to during the installation process, so I told it to keep my original SSH configuration files)… it appeared in lightsail metrics as if it was running (cpu activity) but I could not connect, so I restored a snapshot.
I am thinking I might have to modify/replace the current SSH configuration file to match that of a currently running 18.04.3 LTS machine, so that if/when the uprade process reaches that point, and if it prompts me to replace or keep current configuration, that it would work this time… and allow me connect. Do you have any stacks using Ubuntu 18.04 LTS or are you moving to Debian 9 ?
Thanks!
Roger
Thanks
Roger

Hello

Just to clarify. Did you find any issue running Jota’s commands?

I can not provide you with an ETA for migrating the AMIs from Ubuntu 16 to Ubuntu 18.
According to https://wiki.ubuntu.com/Releases the EOL of Ubuntu 16 is April 2024, which is not a short-term priority.

You could launch an Ubuntu 18 machine from AWS and follow the same steps on that machine in order to install Magento.

We already offer Debian 9 instances (e.g. ami-04cccf453082901fb)

I hope it helps

Hi , followed instructions, had to get pid of memcache to Kill it to free the Default port that Setup showed as default for 3.3.3. Set new admin user password. Rebooted and the machine is up (but can’t get a Magento http page using my public IP) but I am unable to use the ctlscript.sh status , even after locating it in the new opt/magento-3.3.3-1-1 directory, and the current permissions show :-rwxr-xr-x 1 root root 46318 ctlscript.sh. ( Apache Error Log doesn’t seem to be complaining about too much except https not being configured.)
I assume I may need to do some mass permission changes?

Thanks

Hi @RStack,

If the IP of the machine changed when you rebooted the instance, you need to configure Magento with that new IP. We have a tool that takes care of that, can you check this guide?

https://docs.bitnami.com/installer/faq/linux-faq/configuration/understand-bnconfig/

You will basically need to run this command

sudo /opt/magento-3.3.3-1/apps/magento/bnconfig --machine_hostname NEW_IP

Happy to help!


Was my answer helpful? Click on :heart:

Good Morning Jota,
I rebooted, but I didn’t Stop the instance, so under normal conditions I wouldn’t think it would change on a lightsail instance. checking ifconfig eth0 on the instance of which I am able to SSH connect to shows the private IP as matching the IP within the bitnami@ip-xxx-xxx-xxx:~$ Terminal prompt of the Amazon Console connected SSH. The Putty SSH connection works as well and substitutes my Private IP in the bitnami@ip-xxx-xxx-xxx:~$ to my current Public IP. Is there a commad I can use to inquire as to the current machine_hostname different from the processes above before I bnconfig tool?

Hi @RStack,

This is not about the console or the SSH connection, this is about Magento and its configuration. It’s probably configured to use another IP (not the one you currently have). That tool changes the information in the database based on the IP/domain you set when running it. That means that you will need to set the IP/domain you use to access the application when running the tool.

Hi Joda,
I never configured, set, ran, initialized, or created a new user with magento… Before, or after going to 3.3.3-1.
If there were any values in a configuration file, they would have been the default values after spinning up the lighsail instance. I was always able to enter my Amazon assigned public IP into a browser and get the luma screen with 2.3.2, but never went further than that. After going to 3.3.3-1, and rebooting, none of the services start according to bnhelper tool. Even after manually starting the services, when I try to browse to my Public IP, i get http://127.0.0.1/index.php/ “This site can’t be reached127.0.0.1 refused to connect.”

Hi @RStack,

We include some scripts that take care of configuring the application every time the IP changes. The problem with that is that you are not using a “default” instance, you took an old one and installed the latest version using the installer so the scripts do not work now.

It’s redirecting you to 127.0.0.1 because the application has that information. Please run this command to set the proper IP in the database (if you restart the server in the future, you will need to do the same)

sudo /opt/magento-3.3.3-1/apps/magento/bnconfig --machine_hostname PUBLIC_IP_OF_YOUR_INSTANCE_HERE

Happy to help!


Was my answer helpful? Click on :heart:

Hi jota,
I applied my current public ip and I am able to get the Luma start page.

  1. I had to use bnhelper-tools to start all the stack services, is there a way we can change the original Script that started them automatically to show the new location of the apps?
  2. is the /opt/bitnami directory that was re-created need to exist? I imagine the directories are being remade due to a boot script that referred to the 4 Files being re-created:

Thanks

Hi @RStack,

We have this guide in our documentation

https://docs.bitnami.com/installer/faq/linux-faq/administration/autostart-linux/

This directory is not recreated automatically. Did you run the stop and remove commands I share above?

sudo /opt/bitnami/ctlscript.sh stop
sudo rm -rf /opt/bitnami

Thanks

As far as I can remember, Yes. this would have been on 11/1/19
What confirms to me would be the fact that there are no other files in any of the branch folders of bitnami/ except the ones I had noted. So maybe it is possible that the opt/bitnami branch could not be removed because the Proxy.php and Cache files were not ‘disconnected’ with the “sudo /opt/bitnami/ctlscript.sh stop” ?
Should I try the two command lines again? stop / rm , then reboot and take a look?

Hi @RStack,

Maybe there was a running process that was editing those files at that time and that’s why they were not removed. You can run the commands again without problems.

Can you also remove the cronjobs related to /opt/bitnami? (check the root and bitnami crontab)

sudo crontab -e
crontab -e

Thanks

Ran two scripts again, /opt/bitnami is no longer present.
Could not find cron job tab in root, and is no opt/bitnami directory anymore.
Not sure how to delete/modify the information below… or where it might be now.
~$ systemctl status cron
cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2019-11-08 16:44:13 UTC; 2min 20s ago
Docs: man:cron(8)
Main PID: 1206 (cron)
Tasks: 1
Memory: 356.0K
CPU: 22ms
CGroup: /system.slice/cron.service
└─1206 /usr/sbin/cron -f

Nov 08 16:46:01 ip-172-26-12-98 CRON[1480]: (daemon) CMD (/opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/bin/magento
Nov 08 16:46:01 ip-172-26-12-98 CRON[1478]: pam_unix(cron:session): session opened for user daemon by (uid=0)
Nov 08 16:46:01 ip-172-26-12-98 CRON[1477]: (CRON) info (No MTA installed, discarding output)
Nov 08 16:46:01 ip-172-26-12-98 CRON[1477]: pam_unix(cron:session): session closed for user daemon
Nov 08 16:46:01 ip-172-26-12-98 CRON[1481]: (daemon) CMD (/opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/update/cron.
Nov 08 16:46:01 ip-172-26-12-98 CRON[1478]: (CRON) info (No MTA installed, discarding output)
Nov 08 16:46:01 ip-172-26-12-98 CRON[1479]: pam_unix(cron:session): session opened for user daemon by (uid=0)
Nov 08 16:46:01 ip-172-26-12-98 CRON[1482]: (daemon) CMD (/opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/bin/magento
Nov 08 16:46:01 ip-172-26-12-98 CRON[1479]: (CRON) info (No MTA installed, discarding output)
Nov 08 16:46:01 ip-172-26-12-98 CRON[1479]: pam_unix(cron:session): session closed for user daemon

Hi @RStack,

The cron job is configured to run php commands in the /opt/bitnami directory. That’s not a problem anymore because the folder doesn’t exist. Can you check both cron files (the one for the root user and the one for bitnami)? You said that the root’s one doesn’t have any information but what about the other one?

sudo crontab -e
crontab -e

Regards

When I enter both/either of the commands they come back with something different each time:

“/tmp/crontab.Aw8ENt” 0L, 0C
“/tmp/crontab.4iNfqV” 0L, 0C
“/tmp/crontab.rsGdJ5” 0L, 0C

When I enter both/either of the commands they come back with something different each time:

“/tmp/crontab.Aw8ENt” 0L, 0C
“/tmp/crontab.4iNfqV” 0L, 0C
“/tmp/crontab.rsGdJ5” 0L, 0C

Ok @RStack,

That means that there is not anything in the files. That’s why it’s trying to create a new temporary file to use it to create the real one later.

Hi Jota,
Ok, so all cronjobs have been deleted.
So back to automatically starting on System Boot. You had indicated to follow guidelines in the documentation link: https://docs.bitnami.com/installer/faq/linux-faq/administration/autostart-linux/

When checking the existing etc/init.d I can see the earlier ‘bitnami’ script that started applications in the opt/bitnami/ environment. So I would guess that I would need to delete this original script and replace with the copy of the script from /opt/magento-2.3.3-1 ctlscript.sh as detailed in the Link you had previously provided?

For a cleaner overall result, could you see any disadvantage in my Spinning up a new Ubuntu 18.04LTS OS Only Lightsail instance and then installing the latest Linux bitnami-magento-2.3.3-3-linux-x64-installer.run using the same instructions you had provided (with the exception of the removal of the older/previous magento stack since it wouldn’t be there in the first place)? I Guess this was one of davidg’s suggestions on 11/01/19 but I hadn’t entirely understood the benefits of doing it that way until possibly now.

Thanks