Salut à tous,
La nouvelle image Raspbian est enfin disponible! Vous pouvez la télécharger sur Sourceforge ( sourceforge.net/projects/gladys … t/download ).
Cette nouvelle image amène de nombreuses nouveautés :
- Elle est basée sur Raspbian Jessie Lite ( Avant on était sur wheezy )
- Gladys tourne désormais avec Node.js v4.2.2
- Gladys est installée avec NPM, enfin !
- Gladys est désormais derrière une proxy Nginx ce qui permet de servir les assets plus rapidement ( compression Gzip ), de montrer un message d’erreur plus sympa à l’utilisateur quand Gladys est offline, de mettre en place plus facilement un certificat SSL, et d’accéder à Gladys sur le port 80 ( et plus 1337 ).
- Pour accéder à Gladys sur son réseau, il suffit de taper “http://gladys.local” dans son navigateur. Plus besoin de trouver l’IP
Pour faire la mise à jour, je vous conseille d’abord de faire une backup de votre base de donnée SQL ( tuto ici ), puis de récupérer le fichier sql sur un stockage externe ( Via FileZilla, SSH, ou une clé USB ), d’installer la nouvelle image, puis de restaurer votre base de donnée
Bonne installation !
N’hésitez pas si il y a des problèmes !
Oui il faut étendre la partition ! Même procédure !
Il n’y a aucunes commandes à faire Les commandes pour arrêter, relancer sont les mêmes ( sudo pm2 start/stop/restart gladys )
Pour mettre à jour, c’est juste différent ( et plus simple ) :
sudo npm install -g gladys --unsafe-perm
Puis :
sudo pm2 restart gladys
Pour les scripts je pense que je vais les sauvegarder en base plutôt que dans des fichiers à l’avenir, c’est pas super logique actuellement… vous en pensez quoi ?
Le dossier gladys n’est plus au même endroit, c’est normal !
Désormais Gladys est installée en global avec NPM, elle se situe donc à “/usr/local/lib/node_modules/gladys” !
Quelle est ton erreur lorsque tu étend la partition ? Les deux partitions c’est normales il me semble…
@Wickd : “The kernel still uses the old table. The new table will be used at the next rebo ot or after you run partprobe(8) or kpartx(8).”
Tu as essayé de reboot ? puis limite de retenter un “raspi-config” après ? j’ai cherché un peu partout cette erreur sur internet c’est ce que j’ai trouvé… Je vais enquêter sur pourquoi ça fait ça avec vous ^^
@GuillaumeT : Du coup tente la même manip 
@TOF : la pré pré alpha du module Zwave c’est pas pour tout de suite à mon avis, je t’avoue que j’ai eu beaucoup beaucoup de deadline récemment, et le développement du module Z-wave est assez conséquent, c’est pas quelques chose que je peux développer n’importe ou ( actuellement les petites features que je développe, les maj, je les fais de n’importe où, pas forcément posé chez moi ), le développement du Z-wave il me faut vraiment des journées complètes chez moi vu que c’est vachement de tests “en réel”. Et malheureusement actuellement je n’ai pas eu un seul instant de ce type pour bosser sur ça ! Mais bon tout n’est pas tout noir j’avais quand même pas mal avancé dessus. Ce qui me manque c’est vraiment un ou deux gros weeks ends pour finaliser tout ça, et pour l’instant je vois pas de weeks ends de dispo dans les semaines à venir
Est ce que Node.js fonctionne ? ( test la commande “node -v” ) ?
Pour ceux chez qui ça fonctionne/fonctionne pas (sans faire aucunes modifs), mentionnez votre config (Raspberry Pi B ou 2 ?) dans ce topic que je puisse voir d’ou vient le problème… j’ai l’impression que le soucis arrive seulement sur les Raspberry Pi ancienne gen.
Ok, je vois le problème pour Node.js. Pour le problème de partition je ne vois pas encore le soucis.
Le problème pour node.js est que j’ai utilisé la build pour “Armv7” or le Raspberry Pi B/B+ doivent utiliser la build pour processeur “Armv6”.
J’ai un petit quick fix pour voir si c’est bien ça le soucis. Execute les commandes suivantes (Attention cette manip est uniquement pour les possesseurs de Raspberry Pi B/B+ !) :
wget https://nodejs.org/dist/v4.2.2/node-v4.2.2-linux-armv6l.tar.gz
tar -xvf node-v4.2.2-linux-armv6l.tar.gz
cd node-v4.2.2-linux-armv6l
sudo cp -R * /usr/local/
Cela va installer la bonne build Node.js.
Normalement après cela tu pourras utiliser Node.js sans problème. Dis moi si c’est le cas!
Cela m’embête un peu dans le sens ou je vais devoir à l’avenir faire 2 images différentes, pour Raspberry Pi B/B+ et Raspberry Pi 2, c’est pas mal de boulot en plus…
Bizarre tes problèmes de timeout!
Les logs de PM2 ont l’air normales. ( il y a des “warn” mais qui sont normales ). A première vue aucuns soucis !
gladys-0 (out): info: New User connected : Guillaume T
Veut dire que tu as bien accédé à l’interface en te connectant, donc en théorie pas de soucis…
@GuillaumeT: Rassure moi tu avais bien relancé Gladys entre les deux ? Rien n’a changé côté GoogleAPI !
Est ce que vous pouvez préciser quel raspberry pi vous avez ?
Je vais me pencher sur le cas du Raspberry Pi B/B+ et faire une image alternative
@GuillaumeT : En fait le principe de cette image c’est que l’application Gladys Node.js écoute sur le port 1337, puis devant on place un proxy Nginx qui écoute lui sur le port 80 et forward les appels à Gladys sur le port 1337 de node.js
Donc en théorie les deux fonctionnent. Après le but de l’image est de ne plus appeler le Node directement pour avoir tous les avantages lié à Nginx que j’ai cité dans l’annonce de la version sur le premier post de ce topic ( Compression Gzip, chargement des assets plus rapide, cache, écoute sur le port 80, SSL, etc… )
Donc ça serait cool qu’il fonctionne Mais bon, je suis bon pour faire une image spécial Raspberry Pi B/B+, j’essaie de m’y coller cet aprem.
Je suis entrain de bosser sur l’image Raspbian sur mon Raspberry Pi B, j’ai exactement les mêmes symptomes que vous :
Rien ne marche de base, j’installe node 4.2.2 en build pour processeur arm61 là ça marche. Je me créé un compte et là timeout nginx.
Je travaille desssus
Bon pour l’instant ça ne donne rien… j’ai tenté une réinstallation de gladys ça n’a rien donné, toujours le timeout ( en étant parti de l’image cassée ). Je crois que je suis bon pour refaire l’image de zéro^^
Pour nginx non, il a l’air de fonctionner sans problème! J’ai le soucis de timeout même en accès direct à gladys.
Node.js a l’air de fonctionner lui aussi très bien. A mon avis c’est un soucis au niveau des dépendances NPM installé, étant donnés qu’ils sont compilés sur la machine qui les installe, la compilation est forcément différente sur arm61 que sur arm71.
Ce qui fait que l’image ne peut être générique entre Rpi B/B+ et 2 à mon avis… ( à vérifier )
@olivier87bobo : Oui tu peux fonctionner avec la version précédente
Sinon pour tous:
J’ai des news! Déjà le problème "Command (m for help): The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy
The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8)."
Apparait aussi sur mon Raspberry Pi B avec l’image Raspbian Jessie “pure” sans aucunes modifications. L’erreur ne vient donc pas de Gladys mais de l’image Raspbian fournies… Et visiblement cette erreur n’a pas d’impact, en rebootant je passe de :
pi@raspberrypi:~ $ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 1304692 952540 267828 79% /
devtmpfs 218244 0 218244 0% /dev
tmpfs 222516 0 222516 0% /dev/shm
tmpfs 222516 4468 218048 3% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 222516 0 222516 0% /sys/fs/cgroup
/dev/mmcblk0p1 61384 20344 41040 34% /boot
( on voit bien 79% de l’espace utilisé ) à :
pi@raspberrypi:~ $ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 15228900 953968 13628592 7% /
devtmpfs 218244 0 218244 0% /dev
tmpfs 222516 0 222516 0% /dev/shm
tmpfs 222516 4468 218048 3% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 222516 0 222516 0% /sys/fs/cgroup
/dev/mmcblk0p1 61384 20344 41040 34% /boot
Seulement 7% de l’espace utilisé ici. Donc ce qui veut dire que la partition a bien été étendue.
Ce qui fait déjà un problème élucidé !
Après un après-midi complet à bosser dessus, j’ai finalement trouvé le problème avec l’image ! Enfin !
Le problème est que nous sommes passés de bcrypt à bcryptjs ( une implémentation en pure JS de bcrypt qui sert à hasher nos mots de passe lors de la création de compte ). Hors, sur Raspberry Pi B/B+, cette implémentation est super lente … ( de type 40/50 seconde pour hasher un mot de passe ^^, j’ai testé sur un script vide avec que un mot de passe de 4 caractère à hasher )
Le problème intervient aussi sur le système de microblogging Ghost écrit lui aussi en Node.js, apparemment l’architecture ARM gère mal bcryptjs.
Résultat: on repasse à bcrypt !
C’est dommage car bcryptjs n’avait pas besoin d’être compilé et donc ça réduisait les problèmes qu’on pouvait avoir notamment sur Windows… Mais bon, bcryptjs ne fonctionne définitivement pas sur Rpi B/B+, pour l’instant on repasse à bcrypt.
Je tente de pousser une image dès que j’ai finis de l’adapter/l’extraire/la compresser/l’uploader.
J’en profite pour avoir trouvé un autre bug, une dépendance à sails que j’avais utilisé pour dev ( sails-hook-dev ) qui n’est plus maintenu et dont la dernière mis à jour casse tout… J’ai enlevé la dépendance.
Si vous avez déjà eu l’erreur " Error: Cannot find module ‘lodash/Lang/isObject’", c’était ça 
J’ai finalement réussi à faire une image qui marche autant sur Rpi B/B+ et 2 !
L’image est finie et en cours d’upload, mais honnêtement vu ma connexion ça sera pour demain je pense^^
Pour ceux qui avaient installés l’ancienne, inutile de mettre la nouvelle, absolument rien ne change ! ( j’ai fais quelques modifications liés au Rpi B/B+, ça change rien pour le 2 )
J’ai uploadé ( après 5H d’upload ) le nouveau fichier sur sourceforge via SFTP, mais c’est toujours l’ancien qui s’affiche… des experts SourceForge qui savent comment faire le switch ? ( d’habitude j’upload depuis l’interface web, mais là ça ne fonctionnait pas avec mon débit… )