Vous n'êtes pas identifié(e).
Pages : 1
Par défaut, c'est le groupe effectif de la session, qui est lui-même par défaut le groupe principal de l'utilisateur. Or Dans Debian, par défaut chaque utilisateur a son propre groupe principal qui a le même nom que l'utilisateur. Pour que des utilisateurs aient un même groupe principal, il faut le spécifier lors de leur création. Sinon, on peut changer le groupe effectif de la session avec newgrp. Ou bien on peut aussi positionner le SGID sur un répertoire avec chmod afin que les fichiers créés dans ce répertoire aient comme groupe propriétaire celui du répertoire.
A mon avis les ACL sont beaucoup plus pratiques à l'utilisation pour ce genre de situation.
Bonjour
Merci pour ta réponse.
Oui, effectivement les ACL simplifient le problème. Pour précisément, c'est une combinaison des deux solutions car j'utilise toujours le sticky bit.
J'ai essayé hier soir et je suis assez proche du résultat que je voudrais obtenir, mais je dois encore creuser cette solution.
Dans le cas de sous dossier par exemple pour que les permissions soit héritées, si c'est possible. SGID ?
J'utilisais effectivement le SGID pour réaliser la première partie de l'exercice mais je n'ai pas réussi exactement ce que je voulais.
Cependant, lorsqu’un fichier est créé dans un répertoire portant le droit SGID, alors ce fichier se verra attribuer par défaut le groupe du répertoire. De plus, si c’est un autre répertoire qui est créé dans le répertoire portant le droit SGID, ce sous-répertoire portera également ce droit.
Comme je l'ai dis il semblerait qu'il faille modifier l'umask par défaut. J'ai peut-être fait une erreur quelque part car il me semblait que ce soit possible sans les acl.
Un autre question, entre les droits Samba et les ACL qui prend la main ?
Je parle ici du fichier de configuration des partages samba où l'on peut spécifier des utilisateurs pour chaque dossiers.
Edit : je viens de trouver ceci:
Les ACL permettent de fixer des droits sur des fichiers et dossiers.
Ils permettent également de définir un héritage des droits sur les dossiers.
Cet héritage de droits fonctionne lorsque de nouveaux fichiers/dossiers sont créés dans le-dit dossier via un client Window$/Samba.
J'arrive +/- à faire ce que je veux avec le Dossier [Publique] mais le problème c'est qu'il faudrait actualiser les droits après la création de nouveaux fichiers ou dossier.
Ou alors modifier le umask. Le problème c'est que quand je crée un nouveau fichier le groupe ne possède que les droits de lecture. ??
Doit on préciser un parramètre dans le montage du disque ? J'ai mis defaults en option pour le disque ext4.
sur certaines machines, dans le bios y a des options pour la rétro-compatibilité des ports usb, mais je sais plus le nom exact de l'option, à aller checker dans le bios.
mais une chose est sure, si ça fonctionnait avant, et plus subitement, la panne matérielle est souvent l'origine du soucis.
surtout si l'os a pas changé, et que le problème est reproductible sur plusieurs os différents..
ça met vite les choses au clair (en général)
@raleur, c'est rare quand on est en accord tous les deux
Hello,
J'ai regardé dans le Bios hier soir mais il est minimaliste au possible.
Je n'ai rien vu de tel malheureusement.
Merci
Le Hub est en USB 1.1 , il est super vieux, ça a peut-être une incidence ?
je sais pas , possible .
je crois que la norme usb 2.0 définit un courant maxi de 500mA. par prise (ou par port , sais plus)
sauf erreur , je crois que l'usb 3.0 "bride" ses ports à 1 A. toujours en 5 Volts .
https://fr.wikipedia.org/wiki/Universal_Serial_Bus (je sais pas s 'il est exact . ses valeurs me semblent un peu trop hautes .)
Tu en sais déjà plus que moi.
si çà t'intéresse :
-- sources kernels pour debian --
-- wiki DF : compiler son noyau -- (debian)
-- kernel (wiki ubuntu.fr) --
-- LTS enablement stack --
Merci , ça peut-être utile.
Tuxuedo a écrit :Mais le Hub USB n'est PAS alimenté
Il est alimenté par l'ordinateur via le bus USB. Et il relaie cette alimentation vers ses ports USB (après avoir prélevé sa part pour sa propre consommation).
Il peut avoir un effet de stabilisation (lissage) de l'alimentation fournie par l'ordinateur si celle-ci est instable. Par contre je doute qu'il soit capable de remonter une alimentation faiblarde.
Oui, tu as raison. Je voulais dire que le Hub n'est pas auto-alimenté.
Le Hub est en USB 1.1 , il est super vieux, ça a peut-être une incidence ?
Merci
pure curiosité Tuxuedo , tu as pensé à upgrader ton kernel ? https://debian-facile.org/img/smilies/x … chhead.gif
tu utilises quelle distribution ?lsb_release -a
quel noyau : ?uname -a
Hello
Merci pour ta réponse.
Tout est à jour.
Il s'agit d'Ubuntu 18.04. Il doit s'agir du noyay 4.15.0-72-generic (Je précise que c'est une verrsion LTS)
Mais la distrib ne semble pas avoir d'importance.
J'ai retesté ce matin avec Arch-Linux , le même problème se produit. (J'ai testé sur Debian Buster Hier)
Je pensais booter sur un ancien noyau pour voir si il y avait un changement mais j'ai oublié de le faire.
A priori , je pense que le résultat serait le même.
Difficile de dire si c'est l'alimentation ou la communication qui est améliorée par le hub bus-alimenté.
PS : Je n'ai pas trouvé le commentaire de Melissa agressif. C'est une remarque qui est souvent faite quand on estime qu'une capture d'écran graphique n'était pas justifiée. D'ailleurs initialement j'avais écrit un commentaire de la même teneur dans ma réponse, puis l'ai supprimé quand j'ai vu le message posté par Melissa entretemps pour ne pas faire doublon. D'autre part, je ne vois pas en quoi une copie du texte brut était plus difficile qu'une copie d'écran graphique.
Hello
Je ne sais pas non plus. Mais le Hub USB n'est PAS alimenté.
Je vais chercher, bien que pour l'aspect pratique c'est plus ou moins résolu.
J'espère que la situation ne vas pas se dégrader et que c'est bien un problème software.
A propos du commentaire de Mélissa.
Je ne savais tout simplement pas que je ne pouvais pas ou que ce n'est pas conseillé de poster une capture d'écran.
Oui d'un point de vue technique c'est aussi facile de poster un log, c'était un choix , une préférence de ma part.
Elle aurait pu me le dire d'une façon plus aimable. Moi je l'ai trouvé que l'attitude était exagérée.
Nous somme ici pour nous aider, trouver des solutions.
Qu'est-ce que ça donne avec un périphérique auto-alimenté (=alimenté autrement que par le bus USB) ?
Si c'était un ordinateur de bureau, j'aurais suggéré de vérifier les tensions d'alimentation +5V et +5VSB.
Hello, Merci pour ta réponse.
Dans mes recherches , utiliser un hub alimenté / périphérique auto-alimenté était un piste à suive.
J'ai aussi essayé plusieurs choses sans succès jusqu'à présent.
https://paulphilippov.com/articles/how- … ress-error
https://urukrama.wordpress.com/2009/01/ … -error-71/
https://www.linuxquestions.org/question … 175640937/
Je vais essayer un disque dur alimenté voir comment réagissent les ports USB
Je vais aussi brancher un hub usb historie de voir, malheureusement le mien n'est pas alimenté.
Merci
Edit : Je viens de tester la souris USB via un hub non alimenté et elle fonctionne.
Le hub est donc reconnu et l'adressage de la souris est accepté.
Que faut-il en conclure ?
tu peux éviter de mettre des photos pour montrer des logs,
étant donné que c'est matériel en quoi on peut concrètement t'aider ?? [post modéré]
Vous aimez les ours blanc : utilisez la ligne de commande au lieu des captures d'écran
Je suis étonné de ton comportement agressif et de ton commentaire , jamais je n'avais vu un tel comportement dans la communauté open source ..
Pour te répondre :
- J'ai fais un screenshot car ce n'est pas mon pc, c'était plus facile pour moi.
- J'ai fais pas mal de recherche de mon côté et il semblerait que ce soit une erreur assez fréquente, il se pourrait que ce soit software -> Linux.
Franchement je suis déçu par ce type de réponse non constructive
toute manière on ne peut que subir
Lol, En effet ...
En parlant d'AMD j'ai encore un Athlon XP 1800+
J'ai trouvé une liste complète des processeurs affectés par Meltdown/Spectre, tout ceux ces vieux trucs ne semble pas y figurer mais j'aimerais être certain..
On dit pourtant dans la presse que même les processeurs datant de 95 sont affectés .. en 95 j'avais un 486 .. so !!
Merci pour tes réponses
Bonjour
Hello
Ce sont de beaux processeurs !
En ce qui me concerne, je n'ai que de vielles machines, dont beaucoup de vieux x86 32-bits à part 2 ou 3 exceptions.
Des pc familiaux ou que j'ai récupéré, je fais tourner Debian.
On m'a dit que ça n'avait pas de d'intérêt de tester le script sur des processeurs 32 bits parce que le script ne teste que (KPTI)..
Donc les processeurs 32 bits ne feraient pas de calcul spéculatif ?
Dans l'exemple que j'ai donné il s'agit d'un laptop avec un proc Intel Atom N270 x 2, il me semblait que cette série était immunisé !?
Sur chaque pc que j'ai testé (32bits ou 64), ils étaient tous vulnérables d'après le script pourtant j'ai fais un mise à jour de tous les systèmes.
J'ai par contre faire une erreur car sur les 64 bits ce sont de vielles debian dont j'ai toujours fais l'upgrade et il faut que je les formates pour les passer sour linux-image-64.
Mais j'aimerais vraiment comprendre ce qu'il en est pour tous les vieux pc en 32 bits.
Merci
Pages : 1