This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

CoolRaoul

Membres
  • Compteur de contenus

    5 480
  • Inscription

  • Dernière visite

  • Jours gagnés

    43

CoolRaoul a gagné pour la dernière fois le 23 décembre 2017

CoolRaoul a eu le contenu le plus aimé !

À propos de CoolRaoul

  • Rang
    Brigade Synophile

Profile Information

  • Gender
    Male
  • Location
    Marseille

Visiteurs récents du profil

5 816 visualisations du profil
  1. Salut à tous, Je cherche à installer Node Red sur mon NAS. Mon problème est que l'installation échoue avec cette erreur: node-pre-gyp ERR! Pre-built binaries not found for bcrypt@1.0.3 and node@4.8.4 (node-v46 ABI) (falling back to source compile with node-gyp) et ensuite ça part en vrille. J'ai un peu googlé ce message d'erreur mais ca ne me ramène qu'une poignée de messages forums, tous en allemand, langue que je ne maîtrise guère Si il est nécessaire de disposer d'un compilateur pour installer des composant NodeJS, j'ai bien peur que le Syno ne soit pas la plateforme appropriée. Quelqu'un aurait-il une autre piste?
  2. Google authenticator

    Fervent utilisateur de Keepass, J'y ai jeté un oeil également, mais là aussi le projet semble un peu à l'abandon: la dernière livraison est datée de plus de deux ans et demi. Je viens de le tester et je rencontre par exemple aussi l'anomalie des menus en doubles signalée dans la buglist, pas rassurant. De son coté Authy m'a l'air pas trop mal fichu.
  3. Google authenticator

    merci, je vais tester La moindre des choses pour une appli de ce genre
  4. Google authenticator

    Je connaissais pas et j'ai voulu tester pour éventuellement remplacer l'appli de Google Par contre j'ai bien l'impression que le produit à été abandonné: le site sur lequel il était hébergé à été fermé le mail de support donné dans la fiche google est celui de la mailing list du projet et cette dernière semble ne plus avoir la moindre activité Résultat, en cas de problème (incompatibilité avec nouvelle version Android par exemple) on se retrouve à poil non?
  5. Choix cle USB wifi Nas DS413J

    Je parlais du support *des* clés USB en général, pas d'une en particulier. Et je tenais surtout à souligner que cette annonce laisse entendre que la liste des compatibles à aucune chance d'évoluer dans le bon sens à l'avenir.
  6. Choix cle USB wifi Nas DS413J

    Attention sur la pérennité du support des clés USB (en dehors de celles de stockage) , je suis tombé sur ce post du forum récemment qui m'a un peu refroidi. La source est ici: "Starting from DSM 6.2, the USB device drivers, including printers, cloud printers, DAC/speakers, Wi-Fi dongles, DTV dongles, LTE dongles, and Bluetooth dongles, will no longer be updated." Autrement dit, on court peut-être le risque qu'une clé WIFI actuellement supportée ne le soit plus à l'avenir.
  7. DTV compatible

    Voila qui est dommage pour l'enregistrement direct du flux antenne TNT via VideoStation: ça permettait à peu de frais de passer outre les restrictions imposées par certains diffuseurs sur l'enregistrement du flux ADSL (et même TNT sur les box!) Sans oublier la possibilité de faire des enregistrement HD sans monopoliser sa bande passante internet pour ceux qui ont des débits restreints
  8. SSH et Windows 10

    Par curiosité, tu peux essayer de lancer manuellement sur ton NAS un second démon sshd, sur une autre port, en verbosité maximale, dans une fenêtre de terminal, comme ceci: /bin/sshd -d -p 9999 et voir si dans la trace à l'écran tu trouves des informations pour te mettre sur la voie.
  9. SSH et Windows 10

    Pour en avoir le coeur net j'ai appliqué la même configuration que toi et pu me connecter dans tous les cas (et pas eu besoin d'utiliser le "-J" que ne connaissais pas d'ailleurs) Peut-être un réglage des options de chiffrement du serveur ssh du NAS: Sinon, ajouter de la verbosité au client windows (multiples options "-v" à la commande "ssh") peut donner des pistes aussi. L'analogie me semble un peu limite: une mise à jour DSM ne permet pas de retour arrière (ou vraiment difficilement). Ici les deux clients SSH (Putty et client Windows natif) restent bien entendu utilisables simultanément.
  10. serveur NFS: bug ou incompréhension de mon coté?

    Si on veux être plus rigoureux c'est pas "n'importe quel partage" et le "on" ne signifie pas n'importe quel compte client non plus: ne s'applique qu'aux partages pour lesquels on a explicitement spécifié des entrées d'autorisation NFS. Uniquement à partir de machines client NFS qui "matchent" une des entrées autorisations définies ci dessus. et pour ces dernières, seulement à partir des comptes faisant partie d'un groupe dont la valeur de GID est 101 (administrateurs sur le NAS). important: c'est le comportement normal de NFS pour les partages dont la sécurité est de type "sys". Dans ce cas, l'UID du user source et la liste des GIDS de ses groupe sont pris en compte tels quels sur le NAS pour autoriser ou nom l'accès demandé à la ressource et chacun des fichiers/répertoires qu'elle contient (ce mapping serait configurable via le mécanisme idmapd mais il semble impossible de l'activer complètement sous DSM) Techniquement il est possible de désactiver le droit d'accès à un partage au groupe "administrateurs" (droit attribué par défaut). L'inconvénient est que ça implique sa non visibilité dans filestation pour les compte administrateurs ("admin" y compris) . Ca complique la gestion des droits du partage. Contournement: créer un groupe spécifiquement destiné à cet usage (administration du stockage) dont le compte "admin" est membre (éventuellement unique). Donner l’accès R/W aux partages à ce groupe à la place du groupe "administrateurs". D'après ce que j'ai lu, ceci ne s'applique plus dans le cas ou on est capable de choisir l'authentification "Kerberos" pour le partage NFS, car dans ce cas on devient capable d'ajuster les mappings UID et GID.
  11. serveur NFS: bug ou incompréhension de mon coté?

    Trouvé! (par itérations): c'est l'appartenance au groupe "101" ("input" sur le pi, "administrators" sur le NAS) qui permet l'accès. (Les droits que j'avais donné au dossier du dossier était ouvert aux administrateurs en plus du compte isolé) Faudrait que je trouve un moyen de maîtriser plus finement le mappage des groupes sur NFS.
  12. serveur NFS: bug ou incompréhension de mon coté?

    C'est bien le cas. La version du protocole est V4 des deux coté. Sinon j'ai un peu avancé dans mes tests. Créé un compte sur le PI avec même user et UID qu'un compte existant sur le NAS, ce dernier n'a pas accès au dossier partagé (ce qui est normal, j'ai limité les droits du répertoire à un autre compte unique) Crée un autre compte sur le PI avec user et UID inexistants sur le NAS: pas d'accès non plus Autre compte ("pi2") créé sur le PI avec même uid et même gid que "pi": toujours pas d'accès Qu'est-ce qui peut bien faire que le compte "pi" du PI soit capable d'outrepasser les droits par NFS? Via ses groupes? pi@rasp.local> id uid=1000(pi) gid=1000(pi) groups=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),101(input),108(netdev),997(gpio),998(i2c),999(spi)
  13. serveur NFS: bug ou incompréhension de mon coté?

    Non: le compte "pi" c'est le compte par défault de la distrib raspbian sur le raspberry. Pour celui-ci j'ai l'impression que les partages du NAS accédés en NFS deviennent open bar alors que ce compte n'a pas d"équivalent sous DSM ayant le même UID. Je n'ai pas créé de compte "pi" sur le NAS. **EDIT** Désolé si je ne suis pas clair, je reformule: Dans une session shell tournant sur le PI avec le compte "pi" je peux allègrement créer/modifier/effacer des fichier sur le NAS par le montage NFS dans un dossier dont les droits ne devrait pas me le permettre.
  14. Salut, un pote m'a fait cadeau d'un raspberry et je fais un peu joujou avec. J'ai exporté en NFS un des partages du Syno. Dans ce dossier partagé je crée un sous-dossier limité (via les ACLs) à mon compte utilisateur DSM. Je vérifie qu'un autre compte DSM ne peut pas accéder à ce dernier (connecté root en ligne de commande, su - <userlambda> puis touch <chemin du dossier> me donne bien "permission denied". Et pourtant, à partir du raspberry, en étant connecté sur ce dernier au compte par défaut, "pi" (uid 1000) je peux accéder à ce dossier monté NFS et même y créer fichiers et sous-dossiers! Par quelle magie le compte "pi" du raspberry dispose de plus de privileges qu'un compte local DSM?
  15. Drive et ses dossiers ???

    Je ne sais pas si on parle bien de la même chose ("autoriser" vs "activer") mais je m'y prend comme ça: Lancement de: Puis: