Debian 8.0 Jessie compatibility

Announcements
, ,
1

Hi,

As you may have learned, the new Debian major stable release, 8.0 (codename Jessie) has been released for a few weeks now. The old-stable version, 7.0 (codename Wheezy), is deprecated and will not be maintained anymore by next year.

Thankfully, Debian Jessie did not bring any major version changes, and thanks to @beudbeud, the current YunoHost release, 2.2, is already compatible with it. Yet, we cannot guarantee that all the Apps are perfectly functional on Jessie.

So, you will have to upgrade your system eventually, but if you decide to do it now, please let us know how it ended up with your Apps. :blush:

Upgrading from your current Debian Wheezy

First, you need to edit your /etc/apt/sources.list file, and edit all your debian lines from “wheezy” to “jessie”. The YunoHost line stays the same. The file should look like this:

deb http://http.debian.net/debian jessie main
deb http://http.debian.net/debian jessie-updates main
deb http://security.debian.org jessie/updates main
deb http://repo.yunohost.org/ stable main

Then, just run a standard dist-upgrade:

sudo apt-get update
sudo apt-get dist-upgrade

After the upgrade, OpenLDAP and Glances will stop because of some configuration changes between Wheezy and Jessie. You can correct this by running:

sudo dpkg-reconfigure yunohost-config-slapd yunohost-config-others

Now you should have a working YunoHost/Jessie server \o/

Installing YunoHost on a fresh Debian Jessie

The procedure has not changed. We upgraded the installation script so that you can install YunoHost directly on a Debian Jessie host in the same fashion. :slight_smile:

https://yunohost.org/install_on_debian

The future

We will eventually provide a script to do the upgrade part automatically from the web administration interface, but we need App testers before. Please let us know if you encounter any issue on your current Apps, most of the time the broken part is not a big deal.

With datalove <3,
  kload

4

Update done , Y with all replacement of confifuration

yunohost app fetchlist
yunohost app upgrade

Done too

But owncloud is broken

PHP est configuré pour remplir des données brutes POST. A partir de PHP 5.6, cela va générer des avis pour du code parfaitement valide.
Pour corriger ce problème, configurez always_populate_raw_post_data à -1 dans votre php.ini

Fiex by

php_value[always_populate_raw_post_data] = -1

in /etc/php5/fpm/pool.d/owncloud.conf

Denis

5

Another issue : ./yunohost/api/monitor/system?locale=fr give an 500 error.

Impossible de se connecter au serveur Glances

:smile:

# service glances status -l
● glances.service - LSB: Starts and daemonize Glances server
   Loaded: loaded (/etc/init.d/glances)
   Active: active (exited) since ven. 2015-05-29 11:14:14 CEST; 3min 28s ago
  Process: 560 ExecStart=/etc/init.d/glances start (code=exited, status=0/SUCCESS)

mai 29 11:14:14 riva glances[560]: Starting Glances server: glances Not starting glances: disabled by /etc/default/glances..

Fixed with:
cat /etc/default/glances.conf

# Default is to launch glances with '-s' option.
DAEMON_ARGS="-s"
# Change to 'true' to have glances running at startup
RUN="true"

Not sure we need both ?

6

@Shnoulle Nice catch!

I updated the update instructions for glances: reconfiguring the yunohost-config-others package does the trick, and includes this /etc/default/glances:

For PHP 5.6, I will probably integrate the always_populate_raw_post_data as soon as I can.

Thank you for this precise feedback!

7

Thanks to you for yunohost :slight_smile: .

For always_populate_raw_post_data : https://github.com/Kloadut/owncloud_ynh/pull/34/files But don’t look at “update”.

8

J’ai tenté la mise à jour.

sudo dpkg-reconfigure yunohost-config-slapd renvoi une erreur:

sudo dpkg-reconfigure yunohost-config-slapd
55771847 mdb_db_open: database "dc=yunohost,dc=org" cannot be opened: No such file or directory (2). Restore from backup!
55771847 backend_startup_one (type=mdb, suffix="dc=yunohost,dc=org"): bi_db_open failed! (2)
slap_startup failed (test would succeed using the -u switch)
[ ok ] Stopping OpenLDAP: slapd.
[ ok ] Starting OpenLDAP: slapd.

Le résultat est sans appel… Plus rien ne fonctionne hormis la connexion locale sur la machine. J’adore ces mises à jour qui se passe sans encombres…
Une idée de comment retrouver ou restaurer cette base de donnée?

9

@kload

Il ne suffit pas d’arrêter bind9

sudo service bind9 stop

Il redémarre au reboot suivant et provoque un conflit de dns. C’est la raison pour laquelle mon serveur était inaccessible via http et ssh.
Il faut, au minimum désactiver le démarrage du service!

sudo update-rc.d -f bind9 remove

En revanche, ça ne résout pas le problème de ldap, qui m’affiche sans cesse

insserv: script sudo-ldap: service sudo-ldap already provided!
10

@Maniack_Crudelis Le passage à MDB s’est visiblement mal passé… J’ai passé une journée à essayer de le résoudre chez PierreBoulet. De son côté c’était lié au fait qu’il avait beaucoup bidouillé son serveur avant de faire la mise à jour.

Finalement la situation s’est débloquée, mais je ne sais pas exactement comment. Parmis les commandes que j’ai tenté :

dpkg-reconfigure sudo-ldap
dpkg-reconfigure slapd

Dis-moi si ça t’avance…

11

Kload… Tu sais que dpkg-reconfigure slapd pose plein de questions auxquelles je n’ai pas de réponse…

Pour les premières questions je n’ai pas noté, pour les suivantes, voila la réponse. Si ça peut aider à débugger ou aider les suivants.

Faut-il autoriser le protocole LDAPv2 ? Oui
C’était la dernière question…

Il me donne ça:

  Moving old database directory to /var/backups:
  There are leftover files in /var/lib/ldap. This will probably break 
  creating the initial directory. If that's the case please move away
  stuff in there and retry the configuration.
  Creating initial configuration... mkdir: impossible de créer le répertoire « /etc/ldap/slapd.conf »: Le fichier existe

Et sudo dpkg-reconfigure yunohost-config-slapd
donne

sudo: ldap_sasl_bind_s(): Can't contact LDAP server
5578c09b mdb_db_open: database "dc=yunohost,dc=org" cannot be opened: No such file or directory (2). Restore from backup!
5578c09b backend_startup_one (type=mdb, suffix="dc=yunohost,dc=org"): bi_db_open failed! (2)
slap_startup failed (test would succeed using the -u switch)

C’est moi ou c’est pire?

12

J’ai fait la migration il n’y pas si longtemps.
Et j’ai eut le meme genre de soucis que toi concernant le LDAP

c’est à dire

insserv: script sudo-ldap: service sudo-ldap already provided!
et le

sudo: ldap_sasl_bind_s(): Can’t contact LDAP server
5578c09b mdb_db_open: database “dc=yunohost,dc=org” cannot be opened: No such file or directory (2). Restore from backup!
5578c09b backend_startup_one (type=mdb, suffix=“dc=yunohost,dc=org”): bi_db_open failed! (2)
slap_startup failed (test would succeed using the -u switch)

Je suis arrivé à une situation instable. Lors de l’upgrade je n’ai pas reconfigurer le paquet yunonhost ldap. mais j’arrive à me connecter. Mais je sais que le passage en mdb ne s’est pas bien fait. J’ai l’erreur slip_startup failed lorsque je veux faire appel à la commande slapcat.

j’ai une sauvegarde ldif de mon annuaire. je tacherai de faire d’autre essai pour rétablir la situation

Je n’ai pas fait de bidouille particulière sur mon instance ldap

13

Installing baikal on fresh YunoHost instance on debian Jessie x86_64 says:

Baïkal dependencies have not been installed. Please, execute “composer install” in the folder where you installed Baïkal.

Maybe the packager had the dependencies already installed so he didn’t notice the issue?

14

Bonjours,

J’ai eu le même souci que Tarul, Maniack Crudelis et PierreBoulet.

J’avais heureusement fait une sauvegarde de ldap via la commande : slapcat -v -l /chemin_vers_ma_sauvegarde/nom_de_ma_sauvegarde.ldif

Grâce a ceci j’ai pu restaurer ldap avec ces commandes :

service slapd stop
mv /var/lib/ldap /var/lib/ldap.old
mkdir /var/lib/ldap
chown openldap:openldap /var/lib/ldap
chmod go-rwx /var/lib/ldap
slapadd -v -l /chemin_vers_ma_sauvegarde/nom_de_ma_sauvegarde.ldif
chown openldap:openldap /var/lib/ldap/data.mdb 
chown openldap:openldap /var/lib/ldap/lock.mdb 
service slapd start 
sudo dpkg-reconfigure yunohost-config-slapd yunohost-config-others

Mais Attention :kissing: faites ceci uniquement si vous avez une sauvegarde ldap a jours.

15

Et cela résout-il le message qui apparait lors des mise à jour des paquet yunohost du style “insv sudo ldap already provided” ?

Merci pour ta restauration, je la testerai ce soir

16

Hello,

Oui j’avais toujours ce problème.
J’ai trouvé pourquoi pour chez moi j’avais cette erreur. J’avais aussi sudo dans le repertoir /etc/init.d/ et il était en conflit avec sudo-ldap. J’ai donc tapé rm /etc/init.d/sudo pour résoudre mon problème. :smile:

19

Thanks @Josue

After migration I had the new config in /etc/ldap/slapd.d (generated from /etc/ldap/slapd-yuno.conf), but slapd was using the old wheezy config /etc/ldap/slapd.conf which by chance had not been removed by the upgrade.
The server was using the old config because I had:

$ cat /etc/default/slapd  | grep "^SLAPD_CONF"
SLAPD_CONF=/etc/ldap/slapd.conf

while new pure-jessie install have an empty SLAPD_CONF, making ldap use config from /etc/ldap/slapd.d
That’s why I did not notice anything until hitting this : https://github.com/YunoHost/moulinette-yunohost/issues/85

I have manually regenerated the ldap db (actually did the migration from hdb to mdb) by executing the steps you describe.

I could get the slapcat output from the migrated server by launching :

$ slapcat -f /etc/ldap/slapd.conf

to obtain the ldap LDIF file reusing the old hdb ldap db.

Also I needed to change /etc/default/slapd to remove reference to /etc/ldap/slapd.conf

20

Hi,

I upgraded to jessie this week. After sudo apt-get dist-upgrade I had to restart my server manually because I couldn’t access my server with ssh (all users seem to have disapeared). After reboot I could do sudo dpkg-reconfigure yunohost-config-slapd yunohost-config-others and since I did it, all is working well.

However since the migration I receive this mail every day:

/etc/cron.daily/spamassassin:
Job for spamassassin.service failed. See ‘systemctl status spamassassin.service’ and ‘journalctl -xn’ for details.
invoke-rc.d: initscript spamassassin, action “reload” failed.

Then I had to restart spamassassin with sudo service spamassassin restart.

Edit: This problem can be solved with the method described here