This installation is not up to date. Currently using 4.0.2 and it should be v4.1.0-rc.2

Installation Issues
1

Checklist
[ :+1:] I have read intro post: About the Installation Issues category
[ :+1: ] I have read the tutorials, help and searched for similar issues
[ :+1: ] I provide relevant information about my server (component names and versions, etc.)
I provide a copy of my logs and healthcheck
[ ] I describe the steps I have taken to trouble shoot the problem
[ :+1: ] I describe the steps on how to reproduce the issue

I tried to update my passbolt installation on Ubuntu, it is a source code installation type. My healthcheck wrote :
This installation is not up to date. Currently using 4.0.2 and it should be v4.1.0-rc.2.
So I stopped nginx and run a standard sets of cmds to update a passbolt installation, but it seems I have still the same version.

$ git pull origin master
From GitHub - passbolt/passbolt_api: Passbolt CE Backend, a JSON API written with CakePHP

    • branch master → FETCH_HEAD*
      Already up to date.
      $ php -d allow_url_fopen=on /usr/bin/composer.phar install --no-dev -n -o
      Installing dependencies from lock file
      Verifying lock file contents can be installed on current platform.
      Nothing to install, update or remove
      Package webmozart/path-util is abandoned, you should avoid using it. Use symfony/filesystem instead.
      Generating optimized autoload files
      26 packages you are using are looking for funding.
      Use the composer fund command to find out more!
      > App\Console\Installer::postInstall
      Permissions set on /var/www/passbolt/tmp/avatars
      Permissions set on /var/www/passbolt/tmp/cache
      Permissions set on /var/www/passbolt/tmp/cache/database
      Permissions set on /var/www/passbolt/tmp/cache/models
      Permissions set on /var/www/passbolt/tmp/cache/persistent
      Permissions set on /var/www/passbolt/tmp/cache/views
      Permissions set on /var/www/passbolt/tmp/selenium
      Permissions set on /var/www/passbolt/tmp/sessions
      Permissions set on /var/www/passbolt/tmp/tests
      Permissions set on /var/www/passbolt/tmp
      Permissions set on /var/www/passbolt/logs
      No Security.salt placeholder to replace.

I have not clue what I am doing wrong. Thanks for any advice.

2

Hi @tlamik

You’ll need to start around step 4 to get migrations processed.

3

I did it, of course, but it did nothing. so I did not posted here.
Here it is:
sudo -H -u www-data bash -c “/var/www/passbolt/bin/cake passbolt migrate --backup”

 ____                  __          ____
/ __ \____  _____ ____/ /_  ____  / / /_

/ // / __ `/ / / __ / __ / / _/
/ / // ( | ) // / // / / /
// _,///./_//__/

Open source password manager for teams

Saving backup file: /var/www/passbolt/tmp/cache/database/backup_1687976255.sql
Success: the database was saved on file!

Running migration scripts.

using migration paths

  • /var/www/passbolt/config/Migrations
    using seed paths
  • /var/www/passbolt/config/Seeds
    using environment default
    using adapter mysql
    using database passbolt
    ordering by creation time

All Done. Took 0.0074s
Clearing default
Cleared default cache
Clearing cake_core
Cleared cake_core cache
Clearing cake_model
Cleared cake_model cache

sudo -H -u www-data bash -c “/var/www/passbolt/bin/cake cache clear_all”
Clearing default
Cleared default cache
Clearing cake_core
Cleared cake_core cache
Clearing cake_model
Cleared cake_model cache
systemctl start nginx

4

It looks like it might be due to this:

Screenshot_20230628-164520_Trebuchet
Screenshot_20230628-164520_Trebuchet1080×2270 183 KB

Probably will get synced with GitHub soon. @pabloelcolombiano

5

Apart from the github code not being in sync with the tags I would like to make a side note. Maybe this is clear for everyone but maybe someone finds this information useful:

Release candidates (RC) are not stable releases. While they are close to being a production release they might contain bugs. They are meant for beta testing new features.

Unless you want to beta test the RC for some reason we suggest waiting for stable releases.

In the case of a from-source installation, there is no way as of now for us to block this kind of upgrade so you need to identify that the upgrade is an RC and just wait for the stable. For installations based on packages, users would need to switch from the stable repo to the testing one which is already a conscious change.

2 Likes
6

I am not for 100% sure, but I think that healthcheck was never showing up a RC before, but maybe I am wrong. Anyway, it is good that update process do not upgrade to RC.

7

It’s because we’re were not publishing RC on github before. We’ll update the healtcheck so that it ignores the RCs in the future.

3 Likes
8

I thought this would be fixed with the 4.1.0 release, unfortunately it’s still present:

[FAIL] This installation is not up to date. Currently using 4.1.0 and it should be v4.1.1-rc.1.
9

This was planned to be featured in 4.2 only, but since we are preparing a 4.1.1 in order to fix another healthcheck, we might want to include the fix indeed.

I will post here whenever the fix is available.

1 Like
10

FYI @TheReptile the v4.1.1 has been released.

11

I just updated to 4.1.1, I can confirm the healthcheck is green again :slight_smile:

1 Like
12

Good to know, I’ll try that as well asap since my Healthcheck also shows that FAIL which is kinda disturbing my peace :laughing: