Dashy, page d'accueil pour vos applications

[.Shad.]

Une petite application bien sympa pour créer ses marque-pages pour ses différentes applications.
Déployable facilement via Docker, édition par l'interface graphique ou en lignes de commande.
Le petit plus, une pléiade de thèmes pré-intégrés et qu'on peut facilement switcher via un menu déroulant.

Pour ceux qui sont curieux : https://github.com/Lissy93/dashy

[alan.dub]

Oh mais ça envoi du steak ça !

Pas de chance, mon DS418 n’est pas compatible 😅

[Kramlech]

C'est vrai qu'on doit pouvoir faire des choses sympas .... et remplacer avantageusement des listes de favoris interminables.

Première config rapide pour voir ce que cet outils a dans le ventre  :

[bruno78]

Bonjour,

de mon côté, je n'arrive pas à démarrer ce docker ....

root@ds918blam:/volume1/docker/dashy# docker logs dashy
yarn run v1.22.5
$ npm-run-all --parallel build start
$ node server
$ vue-cli-service build

Checking config file against schema...
No issues found, your configuration is valid :)

*******************************************************************************************
Welcome to Dashy! 🚀
Your new dashboard is now up and running in container ID 28c0bc8dd62a
After updating your config file, run  'docker exec -it 28c0bc8dd62a yarn build' to rebuild
*******************************************************************************************


-  Building for production...
 WARN  A new version of sass-loader is available. Please upgrade for best experience.

<--- Last few GCs --->

[61:0x55b98d09aa20]    35562 ms: Scavenge 252.7 (256.7) -> 252.6 (257.7) MB, 7.6 / 0.0 ms  (average mu = 0.378, current mu = 0.234) allocation failure
[61:0x55b98d09aa20]    35883 ms: Mark-sweep (reduce) 253.5 (257.7) -> 252.3 (258.5) MB, 319.4 / 0.0 ms  (+ 0.0 ms in 15 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 321 ms) (average mu = 0.322, current mu = 0.203) all

<--- JS stacktrace --->

FATAL ERROR: MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory
error Command failed with signal "SIGABRT".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
ERROR: "build" exited with 1.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Pourtant rien de spécial ....  . Au démarrage du docker (docker-compose up -d ) je vois la mémoire consommée par ce docker monter rapidement jusqu'aux environs de 255MB, puis plantage .... .

Si vous avez une idée ... Merci

[.Shad.]

Tu peux montrer ton docker-compose (ou script) ?

@Kramlech J'apprécie particulièrement la possibilité de changer rapidement de thème, et les différents formats et taille d'icone ou lien tout simplement. Le fait de pouvoir éditer la configuration depuis L'UI aussi, contrairement à Homer.

[Kramlech]

Il est certain, qu'une fois qu'on a compris le fonctionnement, l'ajout et la modification de lien est très rapide. le plus long, c'est la récupération et le stockage des icones !!!

La seule chose que je n'ai pas encore compris, c'est comment, après une modification via l'interface graphique, on peut mettre à jour le fichier conf.yml (hors un copier-coller manuel).

Sachant qu'une modification manuelle de ce fichier impose la reconstruction de l'appli :

Citation

• yarn build- Dans l'intérêt de la vitesse, l'application est pré-compilée, cela signifie que le fichier de configuration est lu pendant la construction, et donc l'application doit être reconstruite pour que toute nouvelle modification prenne effet. Heureusement, c'est très simple. Cours juste yarn build ou alors docker exec -it [container-id] yarn build

Il reste peut être des progrès à faire à ce niveau ...

[.Shad.]

Il y a un problème effectivement, que j'avais déjà signalé à la développeuse.
En fait tout est enregistré dans les cookies du navigateur, pas dans le fichier conf.yml.
Quand je lance la navigation en mode privé, je vois bien le résultat du fichier conf.yml alors qu'en mode normal, les enregistrements faits dans l'UI persistent et sont pris en compte, mais le fichier conf.yml ne bouge pas.
Donc en fait, même si tu changes manuellement ton fichier conf.yml, les cookies ont la préséance sur le fichier conf.yml. En mode privé, les répercussions sont bien visibles.
Peut-être pour favoriser l'expérience multi-utilisateur, mais je pense que c'est un mauvais procédé.

Je vais la relancer là-dessus. 😉 

[bruno78]

De mon côté problème de démarrage réglé => je n'avais pas alloué assez de mémoire au docker, or au démarrage il réclame plus de 500MB ... . Ensuite ça se calme et on est aux environs de 100MB.

Pour le conf.yml, je n'ai pas trouvé autre chose que le copier/coller manuel, et oui, les icônes faut les récupérer à la main. Certains sont venus "tout seul" avec la directive icon: "favicon", mais pas d'autres, sans que je comprenne vraiment pourquoi. Du coup je les regroupe à la main dans le dossier spécifique /app/public/item-icons/

[.Shad.]

Perso je les place dans le dossier sur mon serveur correspondant à /app/public/item-icons dans le conteneur.
Tu peux créer des sous-dossiers pour classer éventuellement tes icônes, et suivre les instructions données ici pour les charger :

https://github.com/Lissy93/dashy/blob/master/docs/configuring.md#sectionicon-and-sectionitemicon

Pour la directive favicon, si j'ai bien compris ce sujet,c'est Google qui recherche automatiquement les icônes s'il arrive à les retrouver, si pas tu dois les importer manuellement.

[MilesTEG1]

Le 16/06/2021 à 12:24, .Shad. a dit :

En fait tout est enregistré dans les cookies du navigateur, pas dans le fichier conf.yml.
Quand je lance la navigation en mode privé, je vois bien le résultat du fichier conf.yml alors qu'en mode normal, les enregistrements faits dans l'UI persistent et sont pris en compte, mais le fichier conf.yml ne bouge pas.

Ce Dashy me plait bien, mais ce que tu évoques ici me met une barrière.
Est-il possible de sauvegarder dans le fichier .conf les modifications faites dans l'UI ?
 

[bruno78]

@MilesTEG1,

non, a priori pas possible d'enregistrer les modifs faites via l'UI dans le fichier conf.yml. Même les modifs de conf via le menu "config" ne sont que locales.  Il faut faire un copier coller manuel dans son fichier conf.yml et régénerer le tout pour que ce soit pris en compte.

[MilesTEG1]

Oué un peu galère quoi…

je vais passer mon chemin tant que ça n’aura pas évolué…

[Kramlech]

Tu as la possibilité de faire un sauvegarde (cloud) de la conf et de la restaurer sur une autre machine… Mais ce n’est pas très « friendly !

C’est sur que la non mise à jour de la conf est un choix bizarre qui peut se comprendre si on veux avoir une utilisation multi utilisateur, avec chacun sa propre conf …

[.Shad.]

C'est en cours de modification si j'ai bien lu.

[.Shad.]

La configuration est maintenant éditable depuis l'UI, pas mal d'autres petits changements, il suffit de mettre l'image à jour et de recréer le conteneur.

[MilesTEG1]

@.Shad.
Salut 🙂

J'ai mis en place Dashy depuis quelques jours, et avec mes essais sur les profils d'accès sur le nom de domaine pour accéder à DSM, j'ai un petit soucis avec Dashy et le statusCheck. Dashy me détecte le nom de domaine comme hors ligne, parce qu'il n'y a pas accès :

J'ai mis ça comme IP dans le profil d'accès :

• 192.168.2.0/24 : autoriser 
• 172.28.0.1     : autoriser           (j'ai aussi tenté l'ip du conteneur dashy 172.28.0.2, sans plus de succès)
• 192.168.10.0/24    : autoriser
• tous    : refuser

Comment faire pour que la pastille devienne verte ?

 

PS : je rappelle que j'ai une réécriture DSN sur le nom de domaine avec AdGuard Home, qui réécrit en 192.168.2.200, l'IP du NAS lui-même...
 

[.Shad.]

Et en mettant 172.28.0.0/24 ? 172.16.0.0/12 ?

[MilesTEG1]

Il y a 11 heures, .Shad. a dit :

Et en mettant 172.28.0.0/24 ? 172.16.0.0/12 ?

J'ai essayé les deux, et même constat, la vignette reste rouge... (je rafraichi la page pour actualiser le ping qui n'est fait qu'au chargement de la page).

Je vais aller voir le parefeu, des fois que... mais je pense pas que ce soit lui le fautif...

[.Shad.]

Et avec un Shift+F5 au lieu de simplement actualiser ? D'après la documentation, le statusCheck part bien depuis le conteneur.

Tu peux toujours essayer un curl depuis le conteneur pour voir la réponse que tu obtiens.

[MilesTEG1]

@.Shad.
Alors, j'ai réussi à trouver le soucis graçe à ton indication du curl depuis le conteneur.
Cependant, curl n'est pas dispo dans le conteneur, j'ai fait un ping à la place.
Le ping sur l'ip du NAS fonctionne, mais pas sur le nom de domaine parce que l'ip retournée via le ndd est mon ip publique (box)...
Et là je me suis dit : DNS !! Les conteneurs utilises les DNS défini dans le NAS... Or j'ai mis des DNS personnalisé pour que le NAS ne passe pas par AdGuardHome... Et en virant ces DNS personnalisés, le NAS passe par AdGuardHome, et bingo, Dashy peut pinger le nom de domaine...
En fait, avec les DNS personnalisés dans la config du NAS, le nom de domaine était résolu par le DNS 1.1.1.1 (ou l'autre) mais pas par AdGuardHome, donc il n'était pas réécrit par AdGH... Donc l'ip source internet est bloquée par la règle du profil d'accès.

Sinon autre chose sur Dashy, c'est normal que je n'ai quasi jamais de favicon sur la page de dashy ??

[.Shad.]

Ça m'arrive aussi, mais je pense que ça a trait à mon installation. Car il y a certaines applications que j'utilise autant en local que sur mon VPS, dans les deux cas derrière un proxy inversé. Et là où je n'ai aucun problème sur le VPS pour que les icônes s'affichent (par exemple dans les Bitwarden) en local c'est la lotterie.

De mon côté je soupçonne un problème lié à Pi-hole, il suffit que l'API Google soit utilisée pour collecter les favicon pour que potentiellement la requête soit bloquée.

Mais je t'avoue que je n'ai pas encore eu le temps de me consacrer à la résolution du problème. 😉

[Kramlech]

Bonjour à tous

Je relance le sujet, car je viens de m’apercevoir que malgré la prise en charge par Watchtower, et un message m'indiquant qu'une nouvelle version a été trouvée et installée, je reste bloqué sur le version 1.8.0.

Dans Portainer, quand je regarde la log, Dashy semble bien être en 1.9.2.

Mais dans Dashy, il me dit qu'il est toujours en 1.8.0 ...

 

Où est le problème ????

[oracle7]

@Kramlech

Bonjour,

A priori Portainer serait en avance de phase car sous github, la dernière release serait la 1.90 :

Si dans ton fichier docker-compose tu as bien spécifié pour l'image "latest", en tuant le conteneur puis en le recréant, il devrait bien prendre la dernière version de l'image.

Mais Ok cela ne répond pas à ta question initiale sur la différence d'affichage de la version. A savoir si watchtower a bien fait la mise à jour. Je sais que parfois il a des ratés.

Cordialement

oracle7😉

[Kramlech]

@oracle7Bon, j'ai fini par trouver le problème.

Il semble que l'authentification qui était avant facultative soit devenue obligatoire. L'absence de cette authentification dans le fichier de configuration générait un warning.

Et cela empêchait Docker d'activer la nouvelle version. J'ai ajouté l'authentification, et maintenant c'est OK.

Et la dernière version est donc bien la 1.9.2 !!!!

[oracle7]

@Kramlech

Bonjour,

Bon bah super ! 👍 Juste quand même bizarre la différence de version entre github et chez toi, non ?

Cordialement

oracle7😉