Hello,
Thanks everyone for the migration, it worked well on my server (Proxmox VM, ~10 users).
I had to manually remove a file used by a previous OnlyOffice installation :
rm /etc/nginx/conf.d/ds.conf
Then run :
sudo apt install --fix-broken
Anf then the migration again.
Congratulations ! Big up for you @Aleks
Have a nice day (or night 
)
LancĆ© la migration hier soir, en 2h cāĆ©tait pliĆ© : pas une erreur, tout fonctionne au poil.
Bravo Ć toute lāĆ©quipe YNH cāest du beau boulot !
Erratum 
: en local tout va pour le mieux mais Ć distance lāinterface admin est trĆØs instable et me rĆ©pĆØte āUne instance est dĆ©jĆ en cours dāexĆ©cution, merci dāattendre sa fin avant dāen lancer une autre.ā quand je veux accĆ©der Ć la liste des services ou au diagnostic par exemple. De plus, la version nāapparaĆ®t pas dans le coin infĆ©rieur droit, la commande yunohost --version me renvoie :
yunohost: repo: stable version: 4.0.8 yunohost-admin: repo: stable version: 4.0.4 moulinette: repo: stable version: 4.0.3 ssowat: repo: stable version: 4.0.4.1
Edit 2 : en SSH je lui demande yunohost service status pour essayer de voir ce qui coince et Ƨa mouline et ne renvoie rienā¦
Same issue for me after restoring backup from serverA (with lasted yunohost version) to serverB
After forcing an upgrade with YNH_FORCE_UPGRADE=1 yunohost app upgrade agendav -u https://github.com/YunoHost-apps/agendav_ynh
All the apps are now running
Before the upgrade
# ls /var/run/php/ -l
total 4
srw-rw---- 1 www-data www-data 0 Oct 20 19:42 php7.0-fpm-agendav.sock
srw-rw---- 1 www-data www-data 0 Oct 20 19:42 php7.0-fpm-dokuwiki__2.sock
srw-rw---- 1 www-data www-data 0 Oct 20 19:42 php7.0-fpm-freshrss.sock
srw-rw---- 1 www-data www-data 0 Oct 20 19:42 php7.0-fpm-kanboard.sock
srw-rw---- 1 www-data www-data 0 Oct 20 19:42 php7.0-fpm-wallabag2.sock
srw-rw---- 1 www-data www-data 0 Oct 20 19:42 php7.3-fpm-ampache.sock
srw-rw---- 1 www-data www-data 0 Oct 20 19:42 php7.3-fpm-baikal.sock
srw-rw---- 1 www-data www-data 0 Oct 20 19:42 php7.3-fpm-dokuwiki.sock
srw-rw---- 1 www-data www-data 0 Oct 20 19:42 php7.3-fpm-nextcloud.sock
-rw-r--r-- 1 root root 3 Oct 20 19:42 php7.3-fpm.pid
srw-rw---- 1 www-data www-data 0 Oct 20 19:42 php7.3-fpm-roundcube.sock
srw-rw---- 1 www-data www-data 0 Oct 20 19:42 php7.3-fpm.sock
#
After
# ls /var/run/php/ -1
php7.3-fpm-agendav.sock
php7.3-fpm-ampache.sock
php7.3-fpm-baikal.sock
php7.3-fpm-dokuwiki__2.sock
php7.3-fpm-dokuwiki.sock
php7.3-fpm-freshrss.sock
php7.3-fpm-kanboard.sock
php7.3-fpm-nextcloud.sock
php7.3-fpm.pid
php7.3-fpm-roundcube.sock
php7.3-fpm.sock
php7.3-fpm-wallabag2.sock
PS: transmission is not listed as restore failed (I took the log but didnāt dig into it. I can reinstall it quickly)
ping @ericg who could be interested too
Hello !
For information, this release is available for docker, with delay 
and with an hard work 
! Donāt hesitate to give me feedbacks
I also remind : āWarning, all links ars changed ! Like domainelibre/yunohost3 became domainelibre/yunohostā
Edit: fix links
I have a VPS running YunoHost 3.7.1.3 on Debian 9. It has Nextcloud 18.02, Rainloop and Borg. I need to move it to another VPS. What would be the recommended order of operations to migrate it?
Or is there a better or smoother process if I installed Debian 10 and Yunohost 4.0 and then tried to restore the backup from 3.8.5/Debian 9?
Or, should I just upgrade the existing YH to 4.0/Debian 10, then migrate to the new VPS on parity with YH 4.0/Debian 10?
Thanks
I think you can try this yes, that should work smoothly if you only have a handful of well-known apps. Ideally make sure to upgrade them to their latest version before the backup.
c.f. also the doc about ārestore an archive instead of the postinstallā : YunoHost ā¢ index (though doing the postinstall then the restore should also work anyway)
Thanks for the reply.
I went and upgraded both servers to Debian 10/Yuno 4.0 and then migrated. It went fairly welly, having to patch up some nextcloud and php stuff.
The remaining issue is getting borg working again. When yunohost starts or if I restart the service, Iāll get the flurry of emails that first backup is starting. The service runs, then stops. Borg base doesnāt report any activity, nload doesnāt report any significant traffic, and top doesnāt show anything using much CPU for it to be backing up anything.
But it doesnāt seem to immediately know the service is dead and stop. The webGUI is currently chomping away after I told it to start borg. The log is greyed out and I canāt copy it at the moment. āyunohost service log borgā from the command line hasnāt returned and itās been a while.
It looks like /home/admin/.ssh didnāt get migrated over, so I manually did that before starting borg the last time. I was thinking it was just failing when trying to contact borgbase repo, but something else is going wrong and not properly error/failing out.
I thought I recall there being a known issue or at least someone else ran into this borg issue after upgrading to Debian 10/YH4 (or a full system restore), but havenāt found that post yet to see whether it was related or not.
IIRC, I did have to modify some borgbase scripts initially to get it working, so Iāll let it chill for a bit and if it doesnāt return on its own, Iāll compare all the borgbase config and notes I have to see if I can spot an issue. The previous server was backing up to borgbase nightly without issue for over a year (AFAIK).
Regards
Edit: Like a minute later, webGUI went 504 gateway timeout and log window had:
-- Logs begin at Sun 2020-11-29 16:38:42 PST, end at Sun 2020-11-29 20:27:31 PST. --
Nov 29 19:11:45 backup-with-borg[5546]: conf_ssowat: Success
Nov 29 19:11:45 backup-with-borg[5546]: conf_xmpp: Success
Nov 29 19:11:45 backup-with-borg[5546]: conf_ynh_certs: Success
Nov 29 19:11:45 backup-with-borg[5546]: conf_ynh_currenthost: Success
Nov 29 19:11:45 backup-with-borg[5546]: conf_ynh_firewall: Success
Nov 29 19:11:45 backup-with-borg[5546]: size: 976900
Nov 29 19:11:47 backup-with-borg[5546]: Creating a backup archive from the collected files...
Nov 29 19:11:48 backup-with-borg[5546]: Backup created
Nov 29 19:11:48 backup-with-borg[5546]: name: auto_data
Nov 29 19:11:48 backup-with-borg[5546]: results:
Nov 29 19:11:48 backup-with-borg[5546]: apps:
Nov 29 19:11:48 backup-with-borg[5546]: system:
Nov 29 19:11:48 backup-with-borg[5546]: data_home: Success
Nov 29 19:11:48 backup-with-borg[5546]: data_mail: Success
Nov 29 19:11:48 backup-with-borg[5546]: size: 39949025
Nov 29 19:11:49 backup-with-borg[5546]: Collecting files to be backed up for borg...
Nov 29 19:11:50 backup-with-borg[5546]: Creating a backup archive from the collected files...
Nov 29 19:11:51 backup-with-borg[5546]: Backup created
Nov 29 19:11:51 backup-with-borg[5546]: name: auto_borg
Nov 29 19:11:51 backup-with-borg[5546]: results:
Nov 29 19:11:51 backup-with-borg[5546]: apps:
Nov 29 19:11:51 backup-with-borg[5546]: borg: Success
Nov 29 19:11:51 backup-with-borg[5546]: system:
Nov 29 19:11:51 backup-with-borg[5546]: size: 96300
Nov 29 19:11:51 backup-with-borg[5546]: Collecting files to be backed up for nextcloud...
Nov 29 19:11:55 backup-with-borg[5546]: Loading installation settings...
Nov 29 19:11:55 backup-with-borg[5546]: Declaring files to be backed up...
Nov 29 19:11:56 backup-with-borg[5546]: Backing up the MySQL database...
Nov 29 19:12:00 backup-with-borg[5546]: Backing up data directory...
Nov 29 19:12:08 backup-with-borg[5546]: Creating a backup archive from the collected files...
Nov 29 19:12:11 backup-with-borg[5546]: Backup created
Nov 29 19:12:11 backup-with-borg[5546]: name: auto_nextcloud
Nov 29 19:12:11 backup-with-borg[5546]: results:
Nov 29 19:12:11 backup-with-borg[5546]: apps:
Nov 29 19:12:11 backup-with-borg[5546]: nextcloud: Success
Nov 29 19:12:11 backup-with-borg[5546]: system:
Nov 29 19:12:11 backup-with-borg[5546]: size: 74595296054
Nov 29 19:12:12 backup-with-borg[5546]: Collecting files to be backed up for rainloop...
Nov 29 19:12:12 backup-with-borg[5546]: Loading installation settings...
Nov 29 19:12:12 backup-with-borg[5546]: Declaring files to be backed up...
Nov 29 19:12:14 backup-with-borg[5546]: Creating a backup archive from the collected files...
Nov 29 19:12:16 backup-with-borg[5546]: Backup created
Nov 29 19:12:16 backup-with-borg[5546]: name: auto_rainloop
Nov 29 19:12:16 backup-with-borg[5546]: results:
Nov 29 19:12:16 backup-with-borg[5546]: apps:
Nov 29 19:12:16 backup-with-borg[5546]: rainloop: Success
Nov 29 19:12:16 backup-with-borg[5546]: system:
Nov 29 19:12:16 backup-with-borg[5546]: size: 46991852
Nov 29 19:12:16 systemd[1]: borg.service: Succeeded.
-- Subject: Unit succeeded
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit borg.service has successfully entered the 'dead' state.
Nov 29 19:12:16 systemd[1]: Started Run backup borg.
-- Subject: A start job for unit borg.service has finished successfully
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit borg.service has finished successfully.
--
-- The job identifier is 501.A small bug fix released in Yunohost 4.0.8.3 :
Thanks to frju365 
!
After upgrading to Yuno 4 from 3.8.5, Iāve noticed that the borg backup name for nextcloud changed:
Before:
auto_conf_29_11_20_00:00
auto_data_29_11_20_00:01
auto_borg_29_11_20_00:01
auto_rainloop_29_11_20_00:04
auto_nextcloud_data_29_11_20_00:07
After:
auto_conf_01_12_20_03:44
auto_data_01_12_20_03:45
auto_borg_01_12_20_03:45
auto_nextcloud_01_12_20_03:46
When I list the files of both nextcloud files above, I see files in the data dir and appears the same contents (all the data), which is good. It would jive with the instructions from the recent tutorial (and added to the README as a restore example) where the data was extracted and then the nextcloud app from the same auto_nextcloud_timestamp (without the data).
I initially set this up nearly two years ago, and I was thinking that maybe I should have been seeing two nextcloud backups, one with just the app and one with just the data. Itās simpler to have both in one backup, so Iām hoping Iām just remembering that wrong.
So Iām just trying to find out what caused the nextcloud backup name change and to confirm that the same data is still being backed up and will be OK if needing to restore from it in the future. Anyone know where this change would have occurred?
Thanks
After an upgrade that was performed I get the following error. Even if i retry to upgrade I still get the openssl package as availabe for upgradeā¦What can i do?
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
openssl
The following packages have been kept back:
Calculating upgradeā¦
Reading state informationā¦
Building dependency treeā¦
Reading package listsā¦
apt install openssl
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:The following packages have unmet dependencies:
yunohost : Conflicts: openssl (>= 1.1.1g) but 1.1.1g-1+0~20200421.17+debian10~1.gbpf6902f is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
apt install openssl=1.1.1d-0+deb10u3 --allow-downgrades
I got thisā¦
sudo apt install openssl=1.1.1d-0+deb10u3 --allow-downgrades
Reading package listsā¦ Done
Building dependency tree
Reading state informationā¦ Done
openssl is already the newest version (1.1.1d-0+deb10u3).
openssl set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
and still it shows as available upgrade
Does the diagnosis shows anything in particular ?
Some system packages should be downgraded Some packages were inadvertendly installed from a third-party repository called Sury. The Yunohost team improved the strategy that handle these packages, but it's expected that some setups that installed PHP7.3 apps while still on Stretch have some remaining inconsistencies. To fix this situation, you should try running the following command: apt install --allow-downgrades libssl1.1=1.1.1d-0+deb10u3 libssl-dev=1.1.1d-0+deb10u3
Should I do this?
Yup
Well this is turning into a loop. I downgraded those packages, then i run the system update and of course they were shown again together of course with the openssl issue, did the upgrade and the openssl error remained and is still shown as an upgrade to be madeā¦
Does the diagnosis says anything elseā¦
Apart from some closed ports and things Iāve tweaked the newest error is this:
Configuration file /etc/apt/preferences.d/extra_php_version appears to have been manually modified.
This is probably OK if you know what you're doing! YunoHost will stop updating this file automatically... But beware that YunoHost upgrades could contain important recommended changes. If you want to, you can inspect the differences with yunohost tools regen-conf apt --dry-run --with-diff and force the reset to the recommended configuration with yunohost tools regen-conf apt --force
Which appeared if I remember when i installed Firefly iii earlier this dayā¦