How to upgrade Akeneo PIM on Bitnami VM?

Keywords: Akeneo - Virtual Machines - How to - Upgrade
Description:
I thought it will be documented process, or am I blind? I can’t find how to upgrade or at least how to apply Akeneo patch on VM. I’m currently running Bitnami WM with Akeneo Stack 3.2.60 and wanted to apply patch to latest 3.2 version and also plan the upgrade to 4.0. There is no word about it on https://docs.bitnami.com/virtual-machine/apps/akeneo/.I also tried Akeneo steps, but that doesn’t wok with Bitnami VM. Can someone shed light on it please?

Hi @braun.botnet,

Can you tell me which guide and which exact steps you followed?

Regards,
Michiel

Hi @michiel,
Here is the guide from Akeneo which is very simple - Just run the composer command and then restart php-fpm and few additional steps. But already on composer I found Fatal Error. Or actually 2.

  1. problem waas in memory_limit of PHP settings in /opt/bitnami/php/etc/php.ini which has been set originally to 512MB. I was increasing it first to 1GB, then 2GB and Filnally to 4GB and then it started working. So the command for composer should be rather something like:
    php -d memory_limit=4G /opt/bitnami/php/bin/composer --prefer-dist update
    to avoid setting such huge memory limit for normal operation of PHP. This goes on Akeneo weak documentation anyway. Eventually I overcome this… by modifying the ini file, because that command with php with parameter didn’t worked either, so I started as written in Akeneon documentation:
    composer --prefer-dist update

  2. problem appeared immediately after with dependencies:
    response from composer:
    Loading composer repositories with package information
    Warning from https://repo.packagist.org: You are using an outdated version of Composer. Composer 2 is now available and you should upgrade. See https:
    //getcomposer.org/2
    Updating dependencies (including require-dev)
    Your requirements could not be resolved to an installable set of packages.

    Problem 1
    - This package requires php 7.2.* but your PHP version (7.3.19) does not satisfy that requirement.
    Problem 2
    - akeneo/pim-community-dev v3.2.82 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.81 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.80 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.79 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.78 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.77 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.76 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.75 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.74 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.73 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.72 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.71 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.70 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.69 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.68 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.67 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.66 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.65 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.64 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.63 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.62 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.61 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.60 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - akeneo/pim-community-dev v3.2.60 requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.
    - Installation request for akeneo/pim-community-dev ~3.2.60 -> satisfiable by akeneo/pim-community-dev[v3.2.60, v3.2.61, v3.2.62, v3.2.63, v3.2.64
    , v3.2.65, v3.2.66, v3.2.67, v3.2.68, v3.2.69, v3.2.70, v3.2.71, v3.2.72, v3.2.73, v3.2.74, v3.2.75, v3.2.76, v3.2.77, v3.2.78, v3.2.79, v3.2.80, v3.2
    .81, v3.2.82].

As suggested in doc. i tried to update json file from the version I need to apply patch. I found one on github:
https://raw.githubusercontent.com/akeneo/pim-community-standard/3.2/composer.json

And of course the problem still remains, because the requirement of PHP 7.2 is still present, the response from compose lokked like this though:

Loading composer repositories with package information
Warning from https://repo.packagist.org: You are using an outdated version of Composer. Composer 2 is now available and you should upgrade. See https:
//getcomposer.org/2
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - This package requires php 7.2.* but your PHP version (7.3.19) does not satisfy that requirement.
  Problem 2
    - Installation request for akeneo/pim-community-dev 3.2.x-dev@dev -> satisfiable by akeneo/pim-community-dev[3.2.x-dev].
    - akeneo/pim-community-dev 3.2.x-dev requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.

I tried to put required vesion 7.3 in the json file. But still it complains about it:

Loading composer repositories with package information
Warning from https://repo.packagist.org: You are using an outdated version of Composer. Composer 2 is now available and you should upgrade. See https:
//getcomposer.org/2
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

Problem 1
- Installation request for akeneo/pim-community-dev 3.2.x-dev@dev -> satisfiable by akeneo/pim-community-dev[3.2.x-dev].
- akeneo/pim-community-dev 3.2.x-dev requires php 7.2.* -> your PHP version (7.3.19) does not satisfy that requirement.

I’m surprised that on Bitnami VM is actually PHP 7.3 present, even though any version af Akeneo 3.2 requires and accepts only version 7.2. How could be that? I was clearly expected version 7.2 since Akeneo 3.2 requires that.
Should I somehow install PHP 7.2 separately? Or do I need some customized composer.json from Bitnami which would make more sense for me.

In that case I woul like also consider Major version update. First to 4.0, but this seems to be much more complex. There are some System requirement to fullfill first. Like Upgrade MySQL, ElasticSearch (PHP ist already on 7.3). I don’t know how to do that exactly since the Bitnami Installation is self-contained.

I’m really missing documentation on this topic from Bitnami

Hi @braun.botnet,

A colleague from another team will update this thread with further information.

Regards,
Michiel

Hi @braun.botnet

If you take a look to our changelog, see:

You’ll find that PHP was bumped to 7.3.15 in the Bitnami Akeneo Stack Version 3.2.44-0.

As you mentioned, Akeneo 3.2 requires PHP 7.2, and it’s not until 4.x that it fully supports PHP 7.3, see:

I can’t guarantee the reasons why it was bumped to PHP 7.3, but it’s very likely that our system bumped it automatically, launched the battery of tests and found no issues using PHP 7.3.

You can try to create a ZIP with the content of /opt/bitnami/apps/akeneo in your current VM. Then, install a second VM using the Bitnami Akeneo Stack 4.0.83 stack (that already includes all the updated components). After that, replace the new VM’s /opt/bitnami/apps/akeneo directory with the files in the ZIP you created. Finally, you’ll have to follow the steps described at the guide below

You’ll also have to backup the database and restore it in the new VM, find detailed instructions in the link below:

You can download the Bitnami Akeneo Stack 4.0.83 OVA from the link below:

Best regards,

Juan Ariza

Hi jariza,

Thank you for your response. That make sesne.

I’m trying to do it just now and I’m stucked in the section “MySQL and ES Credentials Access” in where I can’t find MySQL credentials for Akeneo App. Although, I do have MySQL root access, but obviously I wont use it for Akeneo. After deployment of Bitnami Akeneo Stack there is no .env file in /opt/bitnami/apps/akeneo/htdocs which normally holds these. Where is the Akeneo MySQL credential on Bitnami, so I can keep the concept? Of course I can login as root to MySQL and alter it, then provide own .env file and I hope it will work.

Hi @braun.botnet

After deployment of Bitnami Akeneo Stack there is no .env file in /opt/bitnami/apps/akeneo/htdocs which normally holds these

That’s deploying Akeno using the 4.0.83 OVA, right? The .env should be included in the ZIP file i recommended you to create with the content of /opt/bitnami/apps/akeneo from the “old” VM. So, when you replace the new VM’s /opt/bitnami/apps/akeneo content with what you have in the ZIP file, it should be there.

Where is the Akeneo MySQL credential on Bitnami, so I can keep the concept? Of course I can login as root to MySQL and alter it, then provide own .env file and I hope it will work.

Once you backup/restore the MariaDB database (you can use the root credentials for this), you should be able to connect to the database using the “old” database credentials. I mean, the ones available in the .env file you have in the ZIP file.

Best regards,

Juan Ariza

Hi @jariza

Yes, I transferred the whole folder of /opt/bitnami/apps/akeneo using rsync with -avz options to shorten the data transfer time. Otherwise I would have to do few steps more which takes too much time. But interesting thing is that on the original old server is not the file .env present. Just that .env.dist. That’s whay I asked how is Bitnami Stack configured. I’ve read the documntation, and there it’s possible to use System Variables to populate main configuration. But I didn’t found it. So Bitnami doesn’t use that file in their image by default. I tried to use locate build the index database and then this is all what could be found on original server:

bitnami@debian:~$ locate .env
/opt/bitnami/apps/akeneo/htdocs/.env.dist
/opt/bitnami/apps/akeneo/htdocs/vendor/akeneo/pim-community-dev/.env.dist

At the end I could go arund it by providing new .env file, resetting passord of original SQL user and save it all in the new .env file back. But I’m still interrested how this is done by Bitnami, so I can do it properly next time. Not looking for workarounds.

Now I’m almost done, since all other steps are done by Akeneo upgrade manual, not having Error messages during the upgrade procedure, but the configuration of Apache is incorrect, I believe. I was looking for the Virtual Directory Configuration of Akeneo and found it broken in to multiple files. The reason why I was doing it, was that the page didn’t worked correctly. I got error 500 webserver response. Then I corrected permissions on FS, but still 500 errors. Regarding upgrade manual by Akeneo I’m assuning the problem is in the change of DocumentRoot and the change of entry point. See the “UPGRADED VIRTUAL HOST CONFIGURATION” Section in the “Upgrade from 3.2 to 4.0”. So I modifiled:

/opt/bitnami/apps/akeneo/conf/httpd-prefix.conf
/opt/bitnami/apps/akeneo/conf/httpd-app.conf
/opt/bitnami/apps/akeneo/conf/htaccess.conf

and replaced paths from /opt/bitnami/apps/akeneo/htdocs/web to /opt/bitnami/apps/akeneo/htdocs/public and changed the the app.php to index.php. But that’s not enough. Still having the issue. At the moment in the Apache error log I can see too many redirect message.
I tking I will deploy one more clean image of Bitnami Akeneo 4.0 and compare untouched Apache configuration files. I believe like that I can localize the problem. Do you have better idea?

I got it. That was the right direction. I had to deploy clean OVA of Akeneo Stack 4.0.83 again to get clean working instance with config and then I found lot more differences in the configuration files of Apache. Mainly in httpd-app.conf and htaccess.conf. So the easiest way would be to:
rsync --exclude={'conf/*.conf'} /opt/bitnami/apps/akeneo <destination>
just exclude all .conf files in the /opt/bitnami/apps/akeneo and if any changes needed, then work on files from version 4.0.

Hi @braun.botnet

Sorry for the late response.

You’re 100% right, the Apache configuration shouldn’t be migrated from the old VM to new one. As you said, you can skip the Apache configuration file under the /opt/bitnami/apps/akeneo/conf directory on this migration.

and replaced paths from /opt/bitnami/apps/akeneo/htdocs/web to /opt/bitnami/apps/akeneo/htdocs/public and changed the the app.php to index.php.

Nice trick! Thanks for sharing it, that’ll be super useful for other users facing the same problem that use this thread as reference.


Did you finally get everything working in the new VM? Were you also able to restore the database backup?

Best regards,

Juan Ariza

Hi @jariza
No Problem. I took obviously even more time to answer. I had to postpone project, but eventuelly I was able to do it on test environmet first and then also on Production. Everything working. I was facing some other issues, creating DB Dump and then recover it from file was the easy part.

Everytime I did anything with files through console or composer through bitnami user, then I had to correct filesystem permissions for daemon user. Otherwise there were 500’s error on web. This is just an hint. Most of them could be isolated through apache error log file:
/opt/bitnami/apache2/logs/error_log

Hi @braun.botnet

Thanks for sharing your insights!

Everytime I did anything with files through console or composer through bitnami user, then I had to correct filesystem permissions for daemon user.

I guess that an alternative would be using sudo su to perform some of these actions as “daemon” user. In any case, you’re right and it’s likely that you’ll have to revert the ownership/permission configuration to be more restricted after these actions.

Best regards,

Juan Ariza

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.