Installation de Sketchup Make 2017 en réseau

La dernière version disponible de Sketchup Make, la 2017, refusait de fonctionner sur notre réseau. Aucun problème pour une installation en local mais impossible d’utiliser les extensions avec un utilisateur du domaine.

Voici l’erreur au démarrage :

“Erreur de chargement du fichier /Application Data/SketchUp/SketchUp 2017/SketchUp/Plugins/su_trimble_connect/boot.rbe Failed to read RBE/RBS file.”

J’ai essayé toutes les manipulations trouvées sur le web sans succès et j’ai finalement réussi à faire fonctionner les extensions embarquées à Sketchup Make 2017 (dont le bac à sable, essentiel pour les paysagistes) en remplaçant les fichiers RBE et RBS par ceux d’une installation de Sketchup Make 2014.

Les étapes que j’ai suivi :

  1. Installer avec un compte administrateur local Sketchup Make 2017 (avec l’administrateur du domaine, l’installation échoue…)
  2. Se rendre dans le dossier C:\Programmes\Sketchup\Sketchup 2017\ShippedExtensions et supprimer tout son contenu.
  3. Copier les fichiers du dossier ShippedExtensions de l’installation Sketchup Make 2014 dans le dossier de l’installation 2017 : extension2014.zip
  4. Et voilà !

Cela résout le problème pour les extensions embarquées, mais pas pour les autres !

Kenavo.

Erreur Mahara : Site unavailable A nonrecoverable error occurred.

Voici l’erreur que nous avions à la connexion sur Mahara :

“e-Portfolio Mahara du Lycée CFA du Mené: Site unavailable A nonrecoverable error occurred. This probably means you have encountered a bug in the system”

Nous avons eu ce problème en début de semaine. Je partage ici le résultat de mes recherches, cela pourra sans doute servir à d’autres !

En cherchant dans les logs d’erreur,  j’ai trouvé l’origine du problème : l’application tentait de créer un fichier de session dans un répertoire qui n’existe pas  (sessions/a/n/b).

“[WAR] 5f (auth/session.php:559) session_regenerate_id(): open(maharadata/sessions/a/n/b/sess_anbrq1vp9p62ce4d8j9khq961aq1886o, O_RDWR) failed: Aucun fichier ou dossier de ce type (2)”

Voici ce que dit le fichier auth/session.php à ce sujet :

“if (check_dir_exists($sessionpath)) {
// Create three levels of directories, named 0-9, a-f
$characters = array(‘0’, ‘1’, ‘2’, ‘3’, ‘4’, ‘5’, ‘6’, ‘7’, ‘8’, ‘9’, ‘a’, ‘b’, ‘c’, ‘d’, ‘e’, ‘f’);
if (version_compare(PHP_VERSION, ‘7.1.0’) >= 0) {
$characters = array_merge($characters, array(‘g’, ‘h’, ‘i’, ‘j’, ‘k’, ‘l’, ‘m’, ‘n’,
‘o’, ‘p’, ‘q’, ‘r’, ‘s’, ‘t’, ‘u’, ‘v’));}”

Il vérifie la version de PHP du serveur et si elle est supérieure à la 7.1.0, il utilise des dossiers d’enregistrement supplémentaires pour enregistrer les sessions des utilisateurs. Notre espace est passée sur la version native de php 7.2 entraînant le déclenchement des enregistrements de sessions dans des dossiers inexistants. D’où le problème ! Pour une raison qui m’échappe, Mahara n’a pas réussi à les créer quand il en a eu besoin.

Pour résoudre le cas :

  1. Soit on remplace le numéro de version vérifiée dans le fichier session.php par un numéro supérieur à celle qui tourne sur le serveur : dans notre cas remplacer PHP_VERSION, ‘7.1.0’ par PHP_VERSION, ‘7.3.0’ partout dans le fichier auth/session.php solutionnait le problème (nous sommes en 7.2).
  2. Soit il faut créer les dossiers manquants dans maharadata/sessions, mais il en manque pas mal… Des milliers en fait… Pour ma part, j’ai installé un Mahara avec Softaculous puis j’ai récupéré l’arborescence des fichiers de sessions de cette installation toute neuve que j’ai ensuite transféré dans le dossier de notre plateforme. Il faut ensuite passer les permissions à 700 sur tous les dossiers ajoutés.

Kenavo.

Technologies Informatique et Multimédia – Bureautique – Infographisme – Web