freem a écrit 5059 commentaires

C'est vrai que c'est techniquement simple, mais, ça nécessite de configurer, et j'ai envie de dire que si on sait configurer sudo, alors on peut probablement s'en passer et n'utiliser que su -c à la place, qui en plus implique un mdp différent et donc une sécurité discutablement plus élevée.

Je ne connaissais pas l'option -k, d'ailleurs. Permets-t-elle d'éviter que, dans un script appelé ainsi, chaque instance de sudo ne conserve pas le timestamp? J'en doute.

En fait, ce que je trouve dommage avec sudo, c'est que ses réglages par défaut (oui, c'est configurable, oui, on peut en faire un outil très intéressant) sont plutôt mal foutus pour moi. Après, je n'ai pas testé toutes les distros, donc peut-être que j'utilise juste les mauvaises.

La durée est configurable, il me semble, et le comportement peut être désactivé.

Oui, tout est configurable.

Je parle bien du problème de la config par défaut, l'outil en soit, une fois bien configuré, je pense qu'il deviens très utile d'un point de vue sécurité, mais par défaut sous Debian, sudo s'apparente plus à une faille béante pour moi.

Il me semble que dans certaines régions une expérimentation existe pour (enfin!) interdire la distribution de prospectus sauf si les gens mettent un auto-collant pour l'autoriser.
Il y a des chances que ça contribue pas mal à la facture énergétique pour le coup :D

Espérons que sudo ne soit pas lancé par le script lancé par le script que tu veux exécuter (voire par un exécutable, c'est encore plus difficile a choper).

Quand tu changes d'UID, oui.
Pas quand tu as lancé une commande, disons, sudo apt-get update, et que tu peux toujours lancer n'importe quelle commande en devenant root par un simple sudo, sans tapper de mot de passe.

Je ne sais pas à quoi tu fais référence, mais en admettant que ce soit possible

Par défaut, au moins sous Debian, sudo va garder en mémoire ton password, de sorte que les prochaines commandes ne te demanderons pas le pass user pour passer root.
Toujours par défaut, sudo permets aux utilisateurs dans son groupe de lancer n'importe quelle commande root.

De manière générale, je trouve que les réglages par défaut de sudo vont à l'encontre de la sécurité d'une machine, vu qu'ils affranchissent de l'usage d'un 2nd mot de passe et, pire, permettent de réutiliser une session root (pendant 5 minutes je crois?) sans demander de mot de passe.

Par contre, je pense que sudo est très pertinent sur un serveur, avec des réglages pertinents, parce que ça permets d'autoriser certaines commandes à des utilisateurs avec moins de pouvoir ou tout simplement pouvoir identifier qui a foutu la merde, quand, et dans quelle circonstances (pour pouvoir apporter diverses solutions afin de réduire la probabilité que ça se reproduise).

Tu m'apprends que c'est possible, merci, je vais étudier ça.

Lors d'une itération précédente de debian, on a eu un paquet init qui incluais runit-init dans la liste des options, concrètement c'est juste pour s'assurer que le système est complet, le paquet runit existait déjà avant (mais pas runit-init, il fallait finaliser les choses à la main, pas très difficile cependant).

De nos jours, le paquet init ne fournit plus cette alternative, mais comme je l'ai dis, ce paquet est juste un méta-paquet, pas même essentiel (heureusement!), runit-init est toujours présent, et évite toujours de faire les opérations à la main, tout en fournissant un moyen simple et efficace de savoir si systemd-init essaie de s'inviter "discrètement" via une dépendance indirecte (*) vu qu'ils sont en conflit direct, et grâce au système de dépendances.
J'en profite pour mentionner une fois de plus l'interface ncurses d'aptitude, qui, bien réglée, rend ce problème trivial à résoudre.
Mon conseil:

• désactiver l'auto-réparation;
• activer la prévisualisation des actions avant installation;
• désactiver l'installation automatique des paquets recommandés;

Ces réglages permettent de réparer les conflits soi-même, d'en minimiser l'existence parce que pas de dépendances inutilisées qui peuvent tirer pas mal de trucs en cascade, donc d'apprendre a quoi servent les paquet présents et d'avoir un système raisonnablement léger, pour un coût de maintenance très faible, l'interface ncurses étant plutôt très bien foutue. Evidemment, elle n'est pas parfaite, loin de la, mais c'est largement supérieur à la CLI d'apt et apt-get, tout en fournissant le même degré de granularité. Quand elle est insuffisante, c'est que le dernier recours est probablement d'utiliser dpkg directement…

*: ça arrive régulièrement "grâce" à libgtk-3-common, qui dépends de dconf-gsettings-baackend | gsettings-backend, le 1er étant installé par défaut. Celui-ci dépend de dconf-service, qui dépend de default-dbus-session-bus | default-dbus-session-bus qui sont fournis soit par dbus-user-session, soit par dbus-x11, le 1er étant installé par défaut.
Celui-ci dépendant de libpam-systemd et systemd, un conflit est généré.
La solution est, pour le coup, très simple:

• soit installer gconf-gsettings-backend, qui est le choix que j'ai fait. Ce paquet dépend de gconf-service, qui ne requiert que des instances de libdbus-.*, qui ne nécessitent pas dbus du tout (d'où mon choix: je n'ai, après tout, aucune utilité pour dbus, n'en déplaise aux fanatiques du bureau tout intégré);
• soit installer dbus-x11 au lieu de default-dbus-session-bus ou dbus-session-bus (vivement qu'on puisse prendre le car tiens, j'en ai marre de ces bus moi) qui ne dépend pas de systemd, manquerait plus que ça!

la réponse devrait être sudo -i (tout seul).

Je ne suis pas convaincu que l'intérêt de sudo soit d'être lancé en mode interactif… le problème étant qu'il est facile de lancer un mode interactif root sans mot de passe avec les config par défaut, et absolument rien ne l'indique, à ma connaissance?

surprenant, mais merci pour l'info!

Ca à l'air… dommage.

Je teste vite fait sous windows (pas le choix, au taf) et… je me demande comment ils ont fait ce screenshot!

Par contre je suis tombé sur une fonction de debug de rendu… (qui n'est pas un debug du html/css, j'entend bien) du coup, désolé, il semble que non, pas d'onglets. Bizarre, j'étais pourtant sûr d'avoir utilisé des onglets un jour… je confond avec un autre brouteur?

Les critiques émettent un avis et cela est essentiel lorsqu'il y a des données scientifiques

Il existe d'autres situations. La censure ou la modération, par exemple (du style, ne pas diffuser de contenus pour adulte ou choquants en pleine rue, du type décapitation réelle ou pornographie (interdit si y'a pas d'étoiles sur les tétons et le sexe des sujets, l'étoile évite de choquer les moeurs j'imagine)), les procès qui forcent les éditeur a publier des excuses, les erratums, …

Ben non, pour un livre c'est un nouvel ISBN et un nouveau dépôt légal, donc une nouvelle fiche.

Une licence de MS Office 2020 n'est pas une licence de MS Office 2022 (nombres au hasard).

Tu peux le faire, salement, sur ton exemplaire. Mais ça ne se répercutera pas à tout le reste.

De la même manière que si tu modifies le code source sur ta machine, ça ne se répercuteras pas sur l'ensemble des codes sources du même logiciel du monde entier.

Non, mais comme tu sais forcément que moi et que la volonté des auteurs et des autrices ici on s'en fiche (sauf quand il s'agit de corrections sur des dépêches), je ne discuterai pas plus avant. Ça ne sert à rien.

Je n'ai jamais dis ça. Je dis juste que tes arguments en défaveur de l'art libre s'appliquent également au logiciel libre.

je ne discuterai pas plus avant. Ça ne sert à rien

Après avoir épuisé tes arguments, tu me fait dire un truc que je n'ai pas dit, puis refuses d'argumenter plus (plus d'arguments, c'est logique, du coup) en fermant la discussion.
Au moins sur le point que ça ne serve à rien, je suppose que je peux te rejoindre.

Souvent moins bon que NetSurf qu'il est dommage de voir complètement ignoré alors qu'ils font un très bon travail sur le développement d'un moteur léger et performant depuis plus d'une dizaine d'années…

Il y a également dillo dans le genre.

pas d'onglet => inutilisable pour moi ;

Ca se comprend, mais les onglets c'est en fait censé être géré par le WM pour moi. Avec une nouvelle instance et donc nouveaux processus a chaque fois, ce qui évite les crash en cascade. C'est au final ce que fait chromium il me semble?
De toute façon la question ne se pose pas, puisque netsurf supporte les onglets.

pas de debugger => comment je fais pour mettre au point mes sites ?

Ca, ça peut être un argument valide.
Par contre, l'argument inverse est tout aussi valide: le debugger intégré est un outil qui sers à une infime minorité d'utilisateurs, mais tous les utilisateurs sont obligés d'en charger le code, ce qui à forcément un impact (possiblement négligeable, mais, les impacts négligeables accumulés ça peut vite devenir non négligeable) en terme de performances.
Sans même parler de l'impact au niveau de la maintenance: plus de code à maintenir.

Oui et non, chaque édition est un nouveau livre et cela permet de voir les évolutions et ceci est aussi important.

Ca s'applique a un logiciel aussi.

Un logiciel, ça peut être fini, en fait. Un éditeur de texte, par exemple, quand on a cerné et implémenté toutes les fonctionnalités que l'on veut y mettre, deviens fini. Il se peut que les besoins et envies évoluent: cela donne une nouvelle édition, ou version, peu importe le terme, pas toujours très appréciée des utilisateurs, d'ailleurs.

Et tu les modifies comment dans un texte imprimé ? Par magie.

Avec du blanco, de l'encre, etc etc. De la même manière que l'on peut appliquer un patch à un code source donc.
Mais si je comprend bien, le problème du livre est le support? Donc, si on numérise l'oeuvre, ton argumentaire tombe à l'eau?

Je disais plus haut qu'il y avait d'autres possibilités mais peu employées (en règle générale).

Ca tombe bien, le logiciel libre qui rémunère est également une possibilité peu employée, en règle générale (une partie non négligeable de la maintenance des logiciels libre est faite de manière totalement bénévole).

Si je voulais troller, je dirais qu'un programme peut être imprimé sur un livre, et que du coup ça ne t'importerais pas qu'on n'ai pas le droit de modifier le-dit programme.

Si je voulais troller de façon plus subtile, je parlerais des livres scientifiques et des manuels scolaires, peu importe leur support: ils sont, eux-aussi, soumis a perpétuelle évolution.

Dans les romans eux-mêmes, on peut trouver de nombreuses fautes, de syntaxe, de grammaire, d'orthographe… des bugs, quoi.
Il peut également y avoir des erreurs factuelles, qui ne sont pas nécessairement volontaires de la part de la personne qui a écrit le texte et n'apportent donc rien, voire enlèvent, à la qualité de l'ouvrage.

Quant au problème de la rémunération, qui est bien réel, c'est de la qu'est partie l'idée des romans-feuilletons je crois: des romans dont une partie est publiée à chaque itération d'un périodique, qui lui est payant. Un peu comme ce type d'oeuvre, à la différence qu'ici le modèle économique est totalement basé sur des dons, des goodies, et un offset temporel pour ceux qui donnent.
C'est au final une variante de ce qu'un professionnel du logiciel libre fait: du support.

historiquement c'est Windows le gros truc monolithique, avec l'affichage qui est prioritaire sur le multi-tâches.

Le noyau Linux aussi est « monolithique »

Selon wikipedia, le noyau de windows NT est de type hybride, alors que linux est monolithique. Juste pour info.
Ce qui tendrais donc a indiquer qu'au niveau le plus bas, windows est plus unix que les distrib linux :D (selon cette métrique, du moins).

Chacun se fera son opinion de la pertinence de la différence, bien sûr, mais bon, wikipedia reste une référence assez utilisée et reconnue il me semble.

C'est valable avec des GUI aussi, ça. La différence c'est que dans un terminal, par défaut, ça se voit que t'es root (pas pour le sudo par contre), légèrement, certes, mais quand même ( # au lieu de % ou $)

ar contre, on doit faire très attention dès qu'on fait des opérations impactant le système globalement et ce que ce soit en ligne de commande ou avec un outil graphique

Un collègue a récemment supprimé par erreur un PC de l'AD (pas admin, tech, mais peu importe). Alors on peut se poser des questions sur la granularité des droits, mais aussi sur, en effet, le problème qu'une interface graphique, si on glisse un peu, on fait assez vite une connerie.
De mon côté, j'ai un script powershell pour ça (et qui génère en plus des trucs qu'il faut copier coller parce que moi flemme), ça m'évite de supprimer par erreur.

Tout ça pour dire, je suis bien d'accord :)

Enfin, pas "toujours", ou du moins pas en juste faisant un apt-get install, mais très certainement toujours depuis avant que debian ne passe à systemd par défaut.

Mettons que je sois fondé à vouloir utiliser un init codé dans la philosophie Unix. Bah j'ai dû aller chercher quelque chose d'autre que Debian

Je me demande comment tordre le cou à ce mythe… j'utilise Debian sous runit, ça juste marche, pas de soucis et, non, je n'ai pas compilé runit, j'ai juste sélectionné le paquet.
Je devrais le compiler, d'ailleurs, parce que le lien symbolique me coûte environ 1.5Mio de RSS par daemon géré, alors que si je compilais soit en statique soit en lien avec muslc au lieu de glibc, ça serait 8Kio (parce qu'en fait j'ai 2 process additionnels par daemon: le gestionnaire, et le logger).
Et ce, depuis avant qu'ils ne mettent systemd par défaut. Je veux bien qu'on tape sur Debian et systemd, mais ça serait pas mal de rester factuel au lieu de répandre des légendes: ça aiderait a garder le débat serein.

Il a toujours été possible d'installer, via le système de paquets et les paquets officiels, un init différent sous Debian (quant a ce que sysVinit+rc.d soient de la "philosophie Unix" je n'en ai pas tant que ça la certitude, après tout, cette philosophie indique que l'outil doit faire une seule tâche, la faire bien, et communiquer avec l'extérieur via stdin/stdout, entres autres?).

Après, malgré que je sois moi-même plutôt contre systemd, il faut reconnaître que c'est un outil qui a eu plusieurs mérites:

• gestion des dépendances
• watchdog
• gestion des journaux

Tout ça, c'est lié, et sysVinit ne le fait pas. Rc.d non plus.

Le chien de garde (watchdog), est notamment une fonctionnalité utile quand on commence a vouloir des systèmes autonomes qui s'auto-réparent (dans les limites du faisable). Oui, ça veut dire qu'il est souhaitable qu'un service qui tombe redémarre tout seul (pour éviter de cramer du fioul sur 400Km juste pour faire un redémarrage, par exemple).
C'est faisable avec runit (et les daemontools de manière générale) mais ce n'est pas a franchement parler efficace, en pratique on laisse le travail de gérer les dépendances aux daemons eux-mêmes. Je le sais: je l'ai fait.

Ce simple fait indique que les daemons ne peuvent, de facto, pas faire "une seule chose et la faire bien", et ça encourage a hard-coder la dépendance à un truc tiers, donc a réduire le choix de l'admin pour ses outils.
De ce point de vue, systemd est plus UNIX que sysVinit+rc.d, qu'il a remplacés sur de nombreux systèmes.

Pour ce qui est de la gestion des journaux, il n'est pas impossible que si l'on ne s'était pas farci sysVinit+rc.d pendant des décennies, les daemons auraient adopté plus tôt un comportement plus générique, c'est à dire: émettre par défaut sur stdout ou stderr, en laissant au gestionnaire de services le soin de les rediriger et traiter ou il faut, au lieu de s'appuyer sur syslog, qui est un outil unique pour toutes les instances, fait qui implique que s'il tombe, est corrompu, ou autre, on perds potentiellement tous les logs.
On peut également citer le double-fork-trick.

Encore une fois, systemd (et ici daemontools et ses héritiers le font aussi bien) est largement plus UNIX que les outils qu'il a permis de remplacer.

Moi, bien que je n'aime pas du tout systemd, je lui suis reconnaissant: sans systemd et les problèmes autour, je n'aurai jamais su qu'il était possible aussi simplement de s'affranchir de sysVinit+rc.d, je n'aurai probablement jamais (ou alors bien plus tard) trouvé runit, mon init+gestionnaire de services actuel.

Systemd a beau être une usine à gaz, un monstre de complexité, un framework alors que je préfère les bibliothèques, avoir eu des failles de sécurité réseau… je le trouve malgré tout largement préférable à la situation dont il nous a sortis.

En fait, ironiquement, c'est grâce à systemd que certaines distro, dont debian, ont commencé à supporter plusieurs systèmes d'init pour de vrai (le support des init autres que sysVinit+rc.d dans Debian reste parcellaire, soit, mais avant c'était le vide inter-sidéral).

Et le pire dans tout ça, c'est que malgré mon discours ici plutôt en faveur de systemd, ben, je refuse toujours de l'utiliser, pour mes raisons propres (un init qui dépend de dbus est le genre de trucs qui me chatouillent un peu par exemple).

et à mon sens ça me paraît évident que l'usage de la ligne de commande nécessite de faire attention à ce qu'on fait

Le problème c'est que j'ai l'impression que les gens pensent "sous linux, la ligne de commande est normal, c'est la routine". Du coup, peut-être qu'il y a un combo de deux biais culturels en conflit direct ici? Je sais pas, hein. Mais alors, vraiment pas. Je suis trop biaisé pour ça, je ne me rend pas compte de ce qui est compliqué en info pour les utilisateurs normaux, et je crois même, pour en avoir quelques un en collègues ces temps-ci, que même parmi les tech, le niveau moyen de linuxfr est plutôt très élevé (même si je ne suis pas du tout dans le top…).
C'est peut-être prétentieux de ma part cela dit.

Je suis pour ma part curieux de savoir le retour d'utilisateurs normaux sur les outils de mise à jour automatique, je crois que debian les as "hérité" d'ubuntu, je ne connais pas leur nom, je sais juste que ça existe. Je ne sais même pas s'il est possible de faire des MàJ majeures avec?

Évidemment, je salue le travail et les raisons du choix politique (car c'est clairement politique ici, politique du LL), il se fait rare, ces derniers temps, de défendre la polyculture qui est la force originelle de linux (qui n'est qu'un noyau «inutile» en soit, sans le reste du code, le CPU n'est qu'un bout de sable raffiné…).

Evidemment, ça ne serait pas intégré au moins avant longtemps, mais j'imagine qu'il est possible de demander. Vu que je ne sais pas comment faire moi-même, j'ai un peu cherché, et j'ai trouvé ça mais je ne sais pas comment soumettre de nouveaux paquets a cette liste (qui devrons évidemment trouver un mainteneur qui ait la volonté de le faire sur son temps libre, certes).