Upgrade or Reinstall

Hi there,

I love the performance and robustness of seafile, but I never had the guts to do an upgrade (“never change a running system”), as I’m using it daily. I’m on

Ubuntu 14.04
Seafile 4.2.2

Now, Ubuntu trusty is going down soon, so I have to try at least. What’s the best way to do it?

  • do-release-upgrade (14.0.4 -> 16.04 or even 18.04 )
  • cross fingers and try to upgrade Seafile from 4.2.2 -> 6.x.x

Or the other way round? Or something else?
Thanks and best regards,
Felix

Doing a release upgrade and updating Seafile afterwards should work without issues. Just make sure to run the upgrade scripts in the correct order and to not miss one.

If you want to be safe, you can do a backup before (seafile install dir, seafile-data (if not included) and seafile database dumps unless sqlite is used).

Seafile updates are very easy to do. No crossing fingers necessary, even if you mess up. I’ve been using it since version 3 and the only time I messed one up is when I accidentally skipped a script. So, I simply went back through the scripts in order again, even after messing up, and Seafile started working again. Seafile updates from ver 4 to ver 6 won’t monkey around with your libraries since those haven’t changed since ver 3, so your libraries will remain intact. Still, though, I would do a backup prior to making any change to anything. It’s just good practice, and backups should be a part of your routine anyway since anything can go wrong with a computer, such as a hard drive failure.

OS updates, though, have always been more tricky.

My advice is to update Seafile going through all the scripts. Once you have verified that Seafile is working properly, then I would consider updating Ubuntu.

Thanks for the kind words :slight_smile:

Updates worked - kind of… no error messages and I followed the upgrade notes, but now seafile is messed up - or apache, I’m not sure. System is now Ubuntu server 16.04 and Seafile 6.2.5.
I fiddled a bit arround, and I got to the point, that the (new) seafile login page is displayed, when I enter

https://

I enter my credentials and get this as a result:

**Page unavailable**
Sorry, but the requested page is unavailable due to a server hiccup.
Our engineers have been notified, so check back later.

Any ideas where to look?
Thanks for the help!

Have a look at seahub_django_request.log

Just did - here are the last entries:

2018-06-22 07:28:17,716 [ERROR] django.request:256 handle_uncaught_exception Internal Server Error: /accounts/login/
Traceback (most recent call last):
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/core/handlers/base.py", line 132, in get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/utils/decorators.py", line 110, in _wrapped_view
response = view_func(request, *args, **kwargs)
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/views/decorators/cache.py", line 57, in _wrapped_view_func
response = view_func(request, *args, **kwargs)
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/seahub/auth/views.py", line 113, in login
if form.is_valid():
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/forms/forms.py", line 184, in is_valid
return self.is_bound and not self.errors
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/forms/forms.py", line 176, in errors
self.full_clean()
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/forms/forms.py", line 393, in full_clean
self._clean_form()
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/forms/forms.py", line 417, in _clean_form
cleaned_data = self.clean()
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/seahub/auth/forms.py", line 66, in clean
username = self.get_username_by_login(login)
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/seahub/auth/forms.py", line 46, in get_username_by_login
username = Profile.objects.get_username_by_login_id(login)
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/seahub/profile/models.py", line 93, in get_username_by_login_id
return super(ProfileManager, self).get(login_id=login_id).user
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/models/manager.py", line 127, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/models/query.py", line 328, in get
num = len(clone)
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/models/query.py", line 144, in __len__
self._fetch_all()
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/models/query.py", line 965, in _fetch_all
self._result_cache = list(self.iterator())
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/models/query.py", line 238, in iterator
results = compiler.execute_sql()
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/models/sql/compiler.py", line 840, in execute_sql
cursor.execute(sql, params)
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/utils.py", line 98, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
  File "/home/seafile/cloud/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/backends/mysql/base.py", line 124, in execute
return self.cursor.execute(query, args)
  File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 226, in execute
self.errorhandler(self, exc, value)
  File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
raise errorvalue
OperationalError: (1054, "Unknown column 'profile_profile.list_in_address_book' in 'field list'")

Found this thread: https://forum.seafile.com/t/moved-seafile-to-new-server-getting-unhandled-exception/4221/2

I think I did all the upgrade steps - but I’m not sure about “minor-upgrade.sh”. Should I run this one as well?

This is eating up so much time… is it possible to do a reinstall, using the same database? I’m using Apache and MySQL.

Have you run all upgrade scripts? You’ve to run them one by one.

upgrade_4.2_4.3.sh
upgrade_4.3_4.4.sh
upgrade_4.4_5.0.sh
upgrade_5.0_5.1.sh
upgrade_5.1_6.0.sh
upgrade_6.0_6.1.sh
upgrade_6.1_6.2.sh

Yup. Though I can’t confirm that, as I don’t find it in the bash-history. (I was on the VM and connected via ssh). What would happen if I accidently skipped one step?

You have to run the minor script to get 6.2.5. If you still got it and it even don’t works, do the upgrades another time.

Some SQL tables will not be updated. Looks like the column above should be added in upgrade_6.1_6.2.sh. You can try to run it again.

It could also help to clean the cache by either restarting memcached or removing the file cache (it’s documented somewhere in the manual where the file cache is located).

After running a major upgrade running minor upgrade is not required (but doing so does never harm - as long as you run it from the directory with the version you want to use)

Thanks for your efforts - I killed the server and reinstalled. Now everything works fine - except ssh over letsencryt.

I didn’t know that, thought I have to