Beta-testing phase for YunoHost 3.0 on Debian Stretch

Announcements
,
122

Chez moi fail2ban fonctionne correctement.

Par contre j’ai le même état “exited” sur postfix et le firewall : les processus sont vivants mais affichés “exited” (voir les échanges du 30 mai dans ce thread). Je n’ai pas de piste de résolution pour l’instant. Ma réponse ne fait pas avancer la chose à part te dire que tu n’es pas le seul :frowning:

Et j’ai aussi ton erreur ‘whoami_s’ :

WARNING moulinette.authenticator.ldap is_authenticated - Error during ldap authentication process: ‘NoneType’ object has no attribute ‘whoami_s’
123

Bonjour,

J’ai voulu faire un essai yunohost 3.0, mais ça a planté. Voici ce qu’on m’annonce dans l’interface admin :

Action

GET /diagnosis
{“locale”:“en”}

Traceback

Traceback (most recent call last):
File “/usr/lib/python2.7/dist-packages/moulinette/interfaces/api.py”, line 406, in process
ret = self.actionsmap.process(arguments, timeout=30, route=_route)
File “/usr/lib/python2.7/dist-packages/moulinette/actionsmap.py”, line 498, in process
return func(**arguments)
File “/usr/lib/moulinette/yunohost/tools.py”, line 605, in tools_diagnosis
services = service_status()
File “/usr/lib/moulinette/yunohost/service.py”, line 228, in service_status
status = _get_service_information_from_systemd(name)
File “/usr/lib/moulinette/yunohost/service.py”, line 265, in _get_service_information_from_systemd
service_path = manager.GetUnit(service + “.service”)
File “/usr/lib/python2.7/dist-packages/dbus/proxies.py”, line 70, in call
return self._proxy_method(*args, **keywords)
File “/usr/lib/python2.7/dist-packages/dbus/proxies.py”, line 145, in call
**keywords)
File “/usr/lib/python2.7/dist-packages/dbus/connection.py”, line 651, in call_blocking
message, timeout)
DBusException: org.freedesktop.systemd1.NoSuchUnit: Unit mopidy.service not loaded.

Du coup, on j’imagine que ça vient de mopidy (qui était désinstallé). J’ai essayée d’installer/désinstaller mais rien n’y fait.
Dans l’interface, Services n’est pas accessible. En ssh, il n’y a pas de mopidy (service --status-all). Toujours en ssh, apt-get update ne fonctionne plus :frowning: :

W: GPG error: http://http.debian.net jessie-backports InRelease: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010

Je n’aurai pas dû essayer mopidy, une application aussi peu mise à jour, mais j’aimerai quelque chose d’un peu plus moderne que Ampache ! (J’avoue que le passage à la beta 3.0 était motivée pour essayer funkwhale.)

Voilà, si vous avez une idée, je suis preneur :slight_smile:

PS : j’adore ce que vous faite

124

Hello !

J’imagine que tu pars donc d’une instance en 2.7.x ?

Si oui, est-ce que tu peux mettre à jour et retenter ? (J’ai mergé quelques fix)

Si tu as toujours des problèmes avec mopidy, je pense qu’il faut que tu ouvres le fichier /etc/yunohost/services.yml et que tu enlève un bloc qui devrait commencer par mopidy: (ou un truc du genre)

A propos des backports, ils devraient être commenté automatiquement pendant la migration à Stretch je pense. Sinon il faut trouver le fichier qui va bien avec grep jessie-backports /etc/apt/, l’ouvrir et commenter la ligne qui va bien en rajoutant un # devant.

125

Oui, ça c’est la théorie, et comme dit le proverbe :

En théorie, la théorie et la pratique sont identiques. En pratique, c’est différent.

:stuck_out_tongue:

J’imagine que dans ton cas, il reste un bout de cron job qui essaye de log-rotationner les logs de php5. On dirait qu’il y a effectivement un fichier /etc/logrotate.d/php5-fpm qui peut causer ça … est-ce que tu confirmes que tu as ce fichier ? Je peux potentiellement rajouter un fix qui supprime ce fichier.

126

Coucou,

C’est super : durant mes recherches préliminaires j’avais bien vu /etc/yunohost/services.yml (bloc mopidy) et le jessy-backports, mais je n’avais pas osé toucher !
Maintenant, l’interface service de yunohost est bien débloquée, ainsi que apt-get update.

Comme il est tard, et que j’ai besoin que mon serveur tourne (j’attends quelques fichiers de gens), je re-ferai un test pour la beta un peu plus tard. (Oui, je partais bien de 2.7.13)

Merci bien et bonne nuit :slight_smile:

1 Like
127

for some reason this happen on clear install

systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/lib/systemd/system/postfix.service; enabled; vendor preset: enabled)
   Active: active (exited) since Tue 2018-06-05 23:29:05 GMT; 50s ago
  Process: 3973 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 3973 (code=exited, status=0/SUCCESS)


systemctl status yunohost-firewall 
● yunohost-firewall.service - YunoHost Firewall
   Loaded: loaded (/lib/systemd/system/yunohost-firewall.service; enabled; vendor preset: enabled)
   Active: active (exited) since Tue 2018-06-05 23:24:06 GMT; 8min ago
 Main PID: 536 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/yunohost-firewall.service
128

Are you referring to the status “exited” ? As discussed previously in this thread, this is perfectly normal, it just relates to the way this service works. Imho the relevant piece of information is the “active” part.

1 Like
129

Bonjour @Aleks ,

J’ai bien les 2 fichiers dans /etc/logrotate.d/ :

/etc/logrotate.d/php5-fpm
et
/etc/logrotate.d/php7.0-fpm

Avec pour chacun d’eux des références dans /var/log/ du type :

/var/log/php5-fpm.log
/var/log/php5-fpm.log.1
/var/log/php5-fpm.log.2.gz
/var/log/php5-fpm.log.3.gz
…
/var/log/php7.0-fpm.log
…

Si tu peux rajouter un fix alors c’est super :slight_smile:

Sinon, est-ce que je peux sans crainte supprimer le logrorate php5-fpm et ses logs dans /var/log/ ?

ppr

130

Je pense, ouip :wink:

131

@Aleks ,

J’ai fait

rm /etc/logrotate.d/php5-fpm
rm /var/log/php5-fpm*

Merci,
ppr

1 Like
132

Hello,

I also did the migration :

Just some informations :

  • After the migration openvpn didn’t work. To fix that I did that :
sed -i "s/CapabilityBoundingSet=CAP_IPC_LOCK CAP_N/#CapabilityBoundingSet=CAP_IPC_LOCK CAP_N/g" /lib/systemd/system/openvpn@.service
sed -i "s/LimitNPROC=10/#LimitNPROC=10/g" /lib/systemd/system/openvpn@.service
systemctl daemon-reload

I don’t know if it’s really a good practice to do this but in all case worked.

  • To be sure that the migration process wasn’t interrupted, I launched it in tmux. But I was not a really good idea. Suddenly tmux was kill for un unknown reason. But apt continued his work. So I just left apt doing his work and monitored his work by ps -elf and tail -f /var/log/dpkg.log. When his work was finished I have just relaunch the command : yunohost tools migrations migrate to finish the migration.

  • After the migration I ned to upgrade synapse to use the prebuild package for stretch (only for ARM) which is actually in the branch v0.31.0.

133

Hi

I have setup an internetcube image (just dd + full-upgrade), and then add testing branch and full-upgrade again.

The postinstall was blocked after firewall has been enable (so the regen conf force operation

grep: /etc/ldap/slapd.conf: No such file or directory
config file testing succeeded
Running in chroot, ignoring request.
Running in chroot, ignoring request.
Running in chroot, ignoring request.
Running in chroot, ignoring request.
Running in chroot, ignoring request.
Running in chroot, ignoring request.
Setting up yunohost-admin (2.7.2) ...
Setting up dh-python (1.20141111-2) ...
Setting up libwww-perl (6.08-1) ...
Processing triggers for libc-bin (2.19-18+deb8u10) ...
Processing triggers for systemd (215-17+deb8u7) ...
Running in chroot, ignoring request.
Processing triggers for dbus (1.8.22-0+deb8u1) ...
Processing triggers for resolvconf (1.76.1) ...
Running in chroot, ignoring request.
Processing triggers for php5-fpm (5.6.30+dfsg-0+deb8u1) ...
Running in chroot, ignoring request.
Running in chroot, ignoring request.
Running in chroot, ignoring request.
Running in chroot, ignoring request.
Running in chroot, ignoring request.
Processing triggers for python-support (1.0.15) ...
Processing triggers for sgml-base (1.26+nmu4) ...
[ 2017-08-30 12:22:46+00:00 ] ----- [ entering restart_services               ]
[ 2017-08-30 12:22:47+00:00 ] ----- [ entering post_install                   ]

So I have interrupted the postinstall and run myself the regen conf force operation.

Until here i a mstill in jessie (because I have not proceed to the migrate to stretch operation)

134

Yes, using the current internet cube image like this leads to a bug if you run an apt-get upgrade before running the postinstall (services.yml is not updated properly leading to a deadlock when starting the firewall :confused: ) To avoid that, you should either not upgrade the system before postinstall, or use the install-sd.sh , or somehow apply this manually : https://github.com/labriqueinternet/labriqueinter.net/blob/master/install-sd.sh#L702-L709

135

Hello,

I just made the migration on my production server with yunohost tools migrations migrate and it fails with

Erreur : La migration 3 migrate_to_stretch a échoué avec l’exception Quelque chose s’est ma passé pendant la mise à niveau principale : le système est toujours sur Jessie ?!? Pour investiguer le problème, veuillez regarder /tmp/migrate_to_stretch.log :slightly_frowning_face:…, annulation

As suggested, I tried to re-run the migration tool and it fails again :scream:

I cannot access to web administration and yunohost application still run. I can use dokuwiki and freshrss

Current state

root@yunohost:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.4 (stretch)
Release: 8
Codename: stretch
root@yunohost:~#

root@yunohost:~# yunohost --version
yunohost:
repo: now
version: 2.7.13.4
yunohost-admin:
repo: now
version: 2.7.13.1
moulinette:
repo: now
version: 2.7.13
ssowat:
repo: now
version: 2.7.12
root@yunohost:~#

migrate_to_stretch.log : Framapad mensuel

Server is a dedicated kimsufi box : Serveurs dédiés, serveurs Bare metal haute performance | Kimsufi

There has always been issue with dnsmask that I did not take care of :innocent:

Some screenshots along with the log file (I cannot go the begin of the migration process so I might have missed some issues)

Screenshot%20from%202018-06-11%2022-58-10
Screenshot%20from%202018-06-11%2022-58-101600×873 223 KB

Screenshot%20from%202018-06-11%2022-58-22
Screenshot%20from%202018-06-11%2022-58-221600×873 243 KB

Screenshot%20from%202018-06-11%2022-58-34
Screenshot%20from%202018-06-11%2022-58-341600×873 185 KB

Screenshot%20from%202018-06-11%2022-58-51
Screenshot%20from%202018-06-11%2022-58-511600×873 209 KB

Screenshot%20from%202018-06-11%2022-59-03
Screenshot%20from%202018-06-11%2022-59-031600×873 247 KB

136

Description: Debian GNU/Linux 9.4 (stretch)
Release: 8

WHY-

So debian says it’s on Stretch but still says it’s on release 8 … :expressionless:

I don’t understand why :expressionless:

If you do lsb_release -r, does it tell “8” also ?

137 
root@yunohost:~# lsb_release -r
Release:        8
root@yunohost:~#

Well …

torvalds

138

Meh I guess I’ll just parse the damn Codename: instead then :expressionless:

Thanks for spotting this and sorry on behalf of the people who implemented lsb_release :expressionless:

139

Issue identified anf fixed by Aleks Rely on /etc/os-release to get the release number.. · YunoHost/yunohost@1b55eac · GitHub

root@yunohost:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.4 (stretch)
Release: 8
Codename: stretch
root@yunohost:~# lsb_release -r
Release: 8

root@yunohost:~# cat /etc/debian_version
9.4

root@yunohost:~# cat /etc/lsb-release
DISTRIB_ID=Debian
DISTRIB_RELEASE=8
DISTRIB_CODENAME=
DISTRIB_DESCRIPTION=

root@yunohost:~# cat /etc/os-release
PRETTY_NAME=“Debian GNU/Linux 9 (stretch)”
NAME=“Debian GNU/Linux”
VERSION_ID=“9”
VERSION=“9 (stretch)”
ID=debian
HOME_URL=“https://www.debian.org/”
SUPPORT_URL=“Debian -- User Support”
BUG_REPORT_URL=“https://bugs.debian.org/”
root@yunohost:~#

1 Like
140

About my internetcube migrations. As my internetcube was ko before the migrations! I have decided to restore with stretch.

Here are my steps:

  • dd the internetcube official image
  • change passwd
  • add testing repo
  • update and full-upgrade debian package
  • reboot test
  • restore conf and data
  • reboot test
  • migrate to stretch
  • reboot test
  • yunohost service regen-conf --force
  • install vpnclient
  • restore my apps one by one
  • remount my hdd

Currently some wordpress, opensondage and my roundcube are broken. dokuwiki, my_webapp, are ok

I had not restore for now my nextcloud, my ttrss and my other my_web_app.

141

After app upgrade opensondage works, about wordpress it was probably due to a corrupted wordpress backup !!!

I had to fix some right permission on roundcube https://github.com/YunoHost-Apps/roundcube_ynh/issues/41

About nextcloud it fails https://github.com/YunoHost-Apps/nextcloud_ynh/issues/122