sudo ne demande jamais le mot de passe root, c'est justement pour éviter de le connaitre que sudo existe. Il faudrait en effet savoir si l'utilisateur marietherese est bien dans les administrateurs du système.
Avec cet utilisateur que donne la commande:
je connais pas ce script, mais c'est peut être une question idiote. Pourquoi renseigner le mot de passe root alors que le script demande le mot de passe de marietherese ?
Aucune idée si ça peut aider, mais il dit qu'il faut un vrai shell. Donc je sais pas 1) comment tu t'es connecté pour taper la commande, et 2) pourquoi le faire en root ? Y'a pas un icone pour lancer dnfdragora dans ta session graphique ?
En gros on dirait qu'il veut causer à l'interface graphique, mais qui doit tourner sous un autre utilisateur... bref il trouve pas d'affichage peut être.
Oui c'est normal, c'est le comportement souhaité sur Fedora. Pas de mot de passe root, donc pas de risque qu'on accède à ta machine avec ce compte. CQFD.
Ce n'est pas un problème c'est le comportement normal. Utiliser le compte root n'est pas nécessaire (sans parler du fait que c'est dangereux), donc utilise la commande sudo. Par ex, sudo -i pour passer root. Pour plus d'info, n'oublie pas de faire un tour sur la doc https://doc.fedora-fr.org/
La mise à jour régulière est je trouve un moyen efficace d'être sécurisé. La plus part des malwares et attaques mettent quand même du temps à se propager à grand échelle, en tout cas pour les utilisateurs lambda. Ils ciblent donc forcément des versions moins à jour.
Le circuit habituel, c'est qu'une faille est détectée sur un produit X, les développeurs de ce produit X vont pour la corriger sortir une nouvelle version. C'est rare qu'ils fassent directement du backport eux même (sauf s'ils gèrent une sorte de version LTS de leur produit).
Alors que les distro dites "stabilisées", avec leur circuit de backporter un patch vers une version plus ancienne, je trouve ça pertinent pour certains cas, heureusement, mais ça reste moins naturel, ou en tout cas ça demande plus d'effort. Surtout que souvent en plus les développeurs du produit X ça ne les intéressent pas (ils se concentrent sur la version à jour). Et ça demande aussi un effort certains pour suivre les failles, les backporter comme il faut etc car on finit par avoir une version spécifique à la distro pour le produit X. Ce qui peut aussi être un avantage quelque part...
Bref on peut pas tout avoir. Soit un produit stabilisé, avec une version figée pour éviter les ajouts de fonctionnalité, de code, et donc de bugs et/ou de failles. Soit un produit à jour tel que vu par ses créateurs, plus simple à suivre pour l'utilisateur niveau sécurité, mais avec toujours beaucoup de changements, en bien ou en mal... Mais forcement ils peuvent faire des refontes, du code et des approches plus modernes etc Fedora existe aussi pour ça, avoir la souplesse qu'il n'est pas possible d'avoir sur RH/CentOS. Pour tester, tenter des choses, et pas trainer un passif tel un boulet.
Mais ça va aussi dépendre des projets, certains développeurs sont pas forcément à la pointe question sécurité. C'est un métier à part entière.
Donc vaut-il mieux faire confiance aux développeurs d'un projet donné, question sécurité, ou vaut-il mieux faire confiance à l'équipe sécurité en charge des backports de la distro ?
Normalement les distro dites "stabilisées" existent à la base plutôt pour garantir un environnement logiciel qui ne cassera pas pendant un certains nombres d'années. Pour ceux qui développent des logiciels qui s'appuient fortement sur une version d'une lib, ou d'un kernel, c'est très important. Mais pas forcément pour des questions de sécurité à la base. Faut dire que Linux est déjà bien foutu de base!
Voilà pour mon avis, une belle réponse de normand ?
Y'a un truc que j'aime bien par ex sur github, y'a des bots qui proposent automatiquement des patchs sur des failles de sécu, sur l'utilisation de vieilles bibliothèques etc (genre https://dependabot.com/) donc ça va dans le bon sens. Bref on a de plus en plus de meilleurs outils pour la sécurité, c'est rassurant non ?
oui c'est une bonne précision, ne pas utiliser la carte SD pour les écritures. Même côté OS il faut couper le maximum, sinon la carte SD ne durera que quelques mois. Vaut mieux ajouter un disque externe pour les données.
Pas sûr qu'il s'agisse ici d'enregistrement continue, juste d'envoyer une video suite à une détection de mouvement.
En effet le support Fedora reste non officiel, si tu veux être tranquil le mieux reste raspbian. Surtout pour la video si tu veux pour l'acceleration materielle de la caméra. Pas techniquement impossible sur Fedora mais bon je ne sais pas pourquoi le support est pas mieux que ça. Tu peux toujours tester et voir ce que tu en penses.
Pour la caméra si tu veux l'acceleration il faut passer par le bus CSI, tu économisera du CPU. C'est possible d'utiliser une webcam USB comme avec n'importe quel Linux, mais tu verras la différence en terme de consommation CPU. Les modules camera officiels sont très bien, bonne qualité d'image (capteur sony) mais pas d'autofocus me semble. A voir si ça te gêne.
Pour le module 4G je pense que ça peut être transparent. En tout cas tout ceux que j'ai eu sous la main fonctionnait en autonome et communiquait avec la machine via une émulation ethernet over USB (module usbnet), qui est assez standard. J'ai actuellement un Huawei E3372 qui marche comme ça sur mon PC classique avec Fedora, je testerais à l'occasion sur un RPI mais il ne devrait pas y avoir de surprise.
Pour la surveillance, détection des mouvements etc l'incontournable reste ZoneMinder
Je pense qu'on peut supprimer ce fil du coup ? Pour l'autre je sais pas trop si ça a sa place dans "Comptoire du libre", mais vu que ça reste pas forcément lié à Fedora pourquoi pas
oui c'est plutôt déconseillé à l'usage. Ou alors il faudrait configurer au moins que les ~/.config ~/.local soient tout de même différents.
Chargement…
Une erreur est survenue lors du chargement de la version complète de ce site. Veuillez vider le cache de votre navigateur et rafraîchir cette page pour tenter de corriger cette erreur.