Don’t forget to stop Seafile Server before the upgrade (i.e: service seafile-server stop or, another example: service seahub stop && service seafile stop)
Don’t forget to change the directory rights of Seafile after unpacking it (i.e: chown -R seafile:nogroup seafile-server-6.1.1 or, another example: sudo chown -R seafile:seafile seafile-server-6.1.1 )
Don’t forget to apply the upgrade script/s according your start release && with the properly user which in normal case should be seafile (i.e change to seafile user: su - seafile -s /bin/bash or, another example: sudo su seafile)
Important Edit (29.07.2017): Please install pyhton-requests module dependence and update Pillow to 4.1.1;
To install python-requests:
apt-get install python-requests
To check Pillow version:
pip list --format=columns | grep -i pillow
upgrade Pillow until last version:
pip install --upgrade Pillow
Some users need to install libjpeg-dev as well:
apt-get install libjpeg-dev
Important: Please check maybe this issue in the Seafile Forum for further unexpected behaviours and suggested troubleshooting
Once again, thanks to the developers and Seafile Community
Thx again for building this
Will be cool if you found time and could share your steps for building (in short), i tried it but evrytime i do there are some errors or it didnt produce right versions (for this i got seahub 6.1.1, but other components are 6.0.1), even the packaging script didnt work with that…btw., i followed wiki instructions…
@jobenvil could we recommend users to also backup their database before upgrading? This allows easy restore in cases where something goes wrong during the upgrade.
sure @shoeper ! I will add your suggestion in next announcement. Do you have some idea what kind of recommendation or link to attach to the suggestion? Do we have a official backup, to point out, as well?
You can send me your suggestions by PN, if you like.
I agree, this is a good idea. I’m not hundred percent sure if there are cases where that is not wanted. Possibly there could be a switch to disable the backup or it could be one to enable the “feature” but I’ve got the impression that those needing it most would miss the option.
If that is wanted, this could possibly implemented by the community as well. We are only talking about databases, not data, are we? That should be an easy approach like:
Creating script backup.sh
should stop seahub and seafile services if sqlite is used
backups the databases depending on the used database, the seafile doc already mentions how to backup them
should let the user pass an argument for the desired path, e.g. ./backup.sh -d /tmp/seafilebackup
Change the update scripts
let the user decide whether he wants a backup before upgrade or not by using arguments, like ./upgradeXXXXX.sh -b
for the backup case the upgrade.sh script has to be called, maybe with a default argument for the backup output
After that the docs could be changed to mention the -b option for backuping before upgrading.
That’s basically how it works. The passwords would have to be read from the Seafile configs (I think there are three different configs with different credentials).
Please remember:
