Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manual update from 3.1.6 to 3.2.8-fixed prompts for user recreation #164

Closed
nebulade opened this issue Jan 4, 2019 · 6 comments
Closed

Manual update from 3.1.6 to 3.2.8-fixed prompts for user recreation #164

nebulade opened this issue Jan 4, 2019 · 6 comments

Comments

@nebulade
Copy link

@nebulade nebulade commented Jan 4, 2019

We are trying to provide an update for the Lychee Cloudron app. The current version is 3.1.6 and the new version will be 3.2.8-fixed. Since this is for Cloudron, the built-in updater is disabled, since on Cloudron apps run on a read-only filesystem. For reference, our app packaging code can be found at https://git.cloudron.io/cloudron/lychee-app

The issue is, that after putting the new release assets in place, visiting the lychee installation will prompt for creating a new user, despite the pre-updated instance already had one. What I can see so far is, that the username and password fields in the settings table are empty after the update. Is there any manual step which needs to be performed when just swapping out the code for update? Thanks a lot for any pointers.

@ildyria

This comment has been minimized.

Copy link
Contributor

@ildyria ildyria commented Jan 5, 2019

No. In theory the update should only be run once. This is done by:

if (Database::setVersion($connection, 'update_030208')===false) Response::error('Could not update version of database!');

and:

private static function update($connection, $dbName) {
  // Check dependencies
  Validator::required(isset($connection, $dbName), __METHOD__);

  // Get current version
  $query  = self::prepare($connection, "SELECT * FROM ? WHERE `key` = 'version'", array(LYCHEE_TABLE_SETTINGS));
  $result = self::execute($connection, $query, __METHOD__, __LINE__);
  if ($result===false) return false;

  // Extract current version
  $current = $result->fetch_object()->value;

  // For each update
  $list_versions =  scandir(__DIR__ . '/../database');
  for($i = 0; $i < count($list_versions) ; $i++)
  {
    if( $list_versions[$i] != '.' && $list_versions[$i] != '..' && substr($list_versions[$i],-4) != '.sql')
    {
      // Only update when newer version available
      if (substr($list_versions[$i],0,-4) <= $current) continue;

      // Load update
      include(__DIR__ . '/../database/'.$list_versions[$i]);
    }
  }
  return true;
}

You can check that the value of version in the database is indeed correct.
However if you run all the updates, then yes some fields are cleared.
e.g. : https://github.com/LycheeOrg/Lychee/blob/master/php/database/update_030000.php

@nebulade

This comment has been minimized.

Copy link
Author

@nebulade nebulade commented Jan 7, 2019

Thanks for the response, looks like the update_030000.php is exactly what I was looking for to debug further. Have to check why it is running, despite updating from 3.1.6 only.

@nebulade

This comment has been minimized.

Copy link
Author

@nebulade nebulade commented Jan 10, 2019

Hm ok, so what I can see is, that after initial installation the version field in the settings table contains 030102 while after applying the update by putting the new release files in-place, the update scripts run and the version field yields update_030208 (including that update_ prefix suddenly). Now looking at the logic when to apply which db migration script, it very much seems like https://github.com/LycheeOrg/Lychee/blob/master/php/Modules/Database.php#L289 will make it apply all migrations at that point. Is this a bug or do I miss some manual update steps here?

Note that if I run the following mysql command prior to applying the update, it all goes well:

update lychee_settings set value="update_030102" where `key`="version";

Does this mean the missing update_ prefix was the error from the start and the initial installation had an issue? Thanks again for any pointers.

@ildyria

This comment has been minimized.

Copy link
Contributor

@ildyria ildyria commented Jan 10, 2019

that after initial installation the version field in the settings table contains 030102

Nicely spotted. Indeed, it should be update_030102 and yes, I believe this was an error from the start. But as it is something that was consistent in term of behavior with an "installation" process I believe this error was never spotted.

@nebulade

This comment has been minimized.

Copy link
Author

@nebulade nebulade commented Jan 14, 2019

We have pushed an update to the cloudron lychee package, which contains some patch code for this. So I'm closing it. Thanks for all the help!

@nebulade nebulade closed this Jan 14, 2019
ildyria added a commit that referenced this issue Jan 14, 2019
@ildyria

This comment has been minimized.

Copy link
Contributor

@ildyria ildyria commented Jan 14, 2019

@nebulade I just pushed a change that should fix your problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.