la config de base de debian pour les install parties ?
Le
Marc Chantreux
salut Í tous,
la flammekueche connection planche sur des recommendations de pratiques
communes pour ses install parties.
nous avons quelques notes ici:
https://framagit.org/flammekueche-connection/install_parties/-/blob/master/debian.md
Et nous allons faire une réunion mercredi prochain (Í 20h30 sur audio.sans-nuage.fr,
vous êtes bienvenus) pour discuter de ces pratiques.
Dans les questions ouvertes intéressantes, la stratégie de mise Í jour
fait débat et la réponse Í deux questions techniques permetteraient
de faire des propositions intelligentes.
* est-ce possible de faire un apt update selectif (uniquement le depot security)?
* est-ce pertinent de faire l'upgrade au moment d'un demarrage? l'idée
c'est:
* automatiser une update mensuelle
* si maj dispos apres update: notifier que le système sera mis Í jour
soit immédiatement (en cliquant sur ), soit au prochain redémarrage.
De manière générale: si vous avez des recommendations Í faire: on est
tout ouie :)
cordialement,
marc
la flammekueche connection planche sur des recommendations de pratiques
communes pour ses install parties.
nous avons quelques notes ici:
https://framagit.org/flammekueche-connection/install_parties/-/blob/master/debian.md
Et nous allons faire une réunion mercredi prochain (Í 20h30 sur audio.sans-nuage.fr,
vous êtes bienvenus) pour discuter de ces pratiques.
Dans les questions ouvertes intéressantes, la stratégie de mise Í jour
fait débat et la réponse Í deux questions techniques permetteraient
de faire des propositions intelligentes.
* est-ce possible de faire un apt update selectif (uniquement le depot security)?
* est-ce pertinent de faire l'upgrade au moment d'un demarrage? l'idée
c'est:
* automatiser une update mensuelle
* si maj dispos apres update: notifier que le système sera mis Í jour
soit immédiatement (en cliquant sur ), soit au prochain redémarrage.
De manière générale: si vous avez des recommendations Í faire: on est
tout ouie :)
cordialement,
marc
oops oui! merci :)
marc
Merci, y'a plein de trucs intéressants (et faudra que j'essaie les window
manager cités !).
Juste une remarque, je mettrais les backports dans un
/etc/apt/sources.list.d/flamekuche-backport.list
histoire de pouvoir les retirer / remettre plus facilement, mais certains
préfèreront aller commenter la ligne dans
/etc/apt/sources.list.d/flamekuche.list
probablement une question de goÍ»t…
Et quand on veut rester économe, ça peut être une bonne idée d'ajouter un
fichier /etc/apt/apt.conf.d/80no_reco_sugg.conf avec :
// on veut pas des recommandés ou suggérés
APT::Install-Recommends "0";
APT::Install-Suggests "0";
(Í utiliser en connaissance de cause, y'a certaines options de certains
softs qui pourraient ne plus fonctionner si un paquet recommandé n'est pas
installé)
Et autre chose, concernant non-free & co, j'ai l'habitude depuis des
lustres d'ajouter systématiquement le dépÍ´t de Christian Marillat pour les
codecs audio/vidéo, et pour avoir certains softs plus Í jour, je sais pas
vraiment si c'est toujours nécessaire avec buster…
/etc/apt/sources.list.d/deb-multimedia.list
deb http://www.deb-multimedia.org buster main non-free
Je sais pas… la doc n'en parle pas
Pour l'upgrade en revanche, avec aptitude tu peux utiliser tous les
patterns que tu veux (me rappelle plus celui qui permet de préciser le dépÍ´t
mais y'en a un).
Et je suis tout Í fait d'accord avec la fin sur apt vs aptitude ;-)
Surtout que même la doc d'apt recommande de ne pas l'utiliser dans des
scripts (conserver aptitude ou apt-get ou tout autre truc bien éprouvé),
Par ex
apt search aptitude
sort bien la liste voulue, mais
apt search aptitude|grep stable
sort d'abord un warning :
WARNING: apt does not have a stable CLI interface. Use with caution in
scripts.
--
Daniel
On n'a rien Í gagner Í emmerder les gens qui n'ont rien Í perdre.
Frédéric Dard (Les pensées de San-Antonio)
avec plaisir :)
ou d'habitude ... j'aurais tenance Í faire
sed -i '/backport/s/^/# /' /etc/apt/sources.list.d/flamekuche.list
sed -i '/backport/s/^# //' /etc/apt/sources.list.d/flamekuche.list
mais c'est vrai qu'un mv c'est bien aussi
ah ben oui! j'ai ca aussi et j'ai complètement oublié! merci: je vais le
rajouter.
je suis sous buster et je ne crois pas avoir de problèmes de
codec. si tu as un cas concret, je veux bien savoir.
au pire je vais demander au mainteneurs de apt.
ah oui je sais mais l'idée ici c'est de:
* faire les mise a jour de secu frequement
* les autres attendront la fin du mois (ou une commande manuelle)
alors ... j'adore aptitude mais tu payes son temps de démarrage par
rapport a apt. du coup pour les trucs vraiment simples et qui vont plus
bouger (genre apt update && apt upgrade), je fais le punk et j'utilise
déjÍ apt (comme 99% des dockerfiles par exemple).
par contre ce que je dis plus haut c'est que pour monsieur toulmonde et
madame michu, apt fait bien l'affaire :)
cordialement,
marc
27 nov. 2020 Í 19:08 de :
Il y a une différence entre planifier une cmd au reboot, et planifier une cmd qui se rattrapera au reboot si besoin ;)
Bonne soiréel0f4r0
[...]
c'est Í peu près le comportement par défaut de Debian depuis Debian 9, je crois: unattended-upgrades est installé, et l'installateur demande si on veut les MAJ de sécurité, qui ont alors lieu tous les jours (lorsqu'il y en a)
[...]
ça me semble correspondre aux notifications de MAJ intégrées Í Gnome, ou Í celles de paquets équivalents (en fait on dirait qu'il n'y a plus que gnome-packagekit qui joue ce rÍ´le, les autres semblent avoir disparu? J'ai peut-être regardé trop vite ). Du coup l'utilisateur est notifié visuellement qu'il y a des MAJ disponibles et il les installe si ça lui chante.
parce qu'en fait je me demande si le public visé (quelque part: le débutant qui n'a pas , ou pas encore, les compétences pour installer Debian tout seul, donc a fortiori pour l'administrer) a besoin d'une solution Í granularité plus fine que ça?
j'ai regardé le nom du paquet et j'ai l'impression que c'est exactement
ce que je ne veux pas.
j'ai regardé le manuel et ca confirme mon impression.
j'ai regardé le code et ca confirme mon impression (en plus j'ai du lire
du python: ma soirée est foutue ...)
en fait ce que je veux faire c'est de ne pas télécharger régulièrement
des listes de paquets qui peuvent bien attendre donc ne mettre Í jour
régulièrement que *la liste des paquets* de security.
moi j'aimerais que lorsque c'est security, c'est maintenant (si tu
cliques) ou au prochain reboot. pas quand tu veux et certainement pas
silencieusement comme le fait unattended.
par experience: ca les fait chier de mettre a jour donc autant ne pas
mettre la liste des paquets a jour tout le temps sauf qu'on negocie
pas avec la securité donc ca c'est a mettre a jour 1* par jour.
cordialement,
marc
Désolé de t'avoir involontairement pythonisé ;-)
Loin de moi l'intention d'insister lourdement sur l'utilisation de unattended-upgrades ou de quelque autre solution quelle qu'elle soit, hein :-)
Non, simplement, de ma fenêtre, un utilisateur lambda, effectivement, la sécurité et les MAJ ne sont pas sa préoccupation principale. Donc vu ses compétences et son attitude sur le sujet, je ne vois pas clairement le bénéfice de la faire intervenir dans la boucle. Debian ne fait que suivre d'autres distribs Linux et les OS commerciaux en automatisant des MAJ silencieuses qui autrement ne font que perturber l'utilisateur.
De plus, si jamais Í l'avenir, les gestion des dépÍ´ts, des MAJ de paquets ou autre, change (par exemple avec une prochaine release de Debian), dans l'idéal si vous fournissez une installation customisée, il vous faudrait pourvoir Í ce moment-lÍ fournir les procédures de MAJ de votre customisation (au cas o͹ celle-ci soit cassée par le changement introduit par/dans Debian), je vois mal l'utilisateur aller modifier le script que vous lui aurez fourni. Unattended-upgrades c'est maintenant standard dans Debian, donc le cas échéant Debian fournira un upgrade adapté si ce genre de choses devait arriver.
Je ne sais plus si c'était avec toi qu'on avait évoqué les gestionnaires de paquets en GUI versus les magasins d'applications suivant que l'opérateur est utilisateur ou administrateur mais c'est un peu la même problématique: autant je comprends le désir de contrÍ´le d'un admin sur ce qui est téléchargé, sa provenance, son volume et Í quel moment, autant l'utilisateur lambda, je doute que ça l'intéresse . Et c'est lui qui utilisera (ou quelqu'un de son niveau) pas le gars qui lui a installé son ordi :-)
(accessoirement, de mémoire, je crois qu'unattended-upgrades est paramétrable pour n'installer les MAJ qu'au prochain shutdown/reboot)
Considère mes élucubrations simplement comme quelques questions que je me pose et sens-toi parfaitement autorisé Í les considérer non-pertinentes et Í n'en pas tenir compte :-)
ca n'est pas ta faute mais celle du développeur ;)
si j'ai soumis ma prose Í la communauté c'était bien pour avoir un
retour! merci pour ce retour.
OK. je prend acte de ce retour mais pour ma part je trouve que:
* faire cliquer l'utilisateur pour mettre a jour, c'est lui donner la
possibilité de nous dire apres coup "apres la mise a jour, j'ai
constaté que ..."
* faire cliquer c'est responsabiliser. il y a quelque chose de
pédagogique qui doit etre le prolongement d'un message passé pendant
les install parties: la sécurité c'est l'affaire de tous.
d'ou l'idée d'avoir un depot Í nous: la mise a jour de la stratégie de
mise a jour se fait par une mise Í jour :)
on peut tres bien purger le paquet. y'a aussi libreoffice-gnome-integration
qu'il faut virer et si je m'écoutais (mais je ne m'écoute pas) je
virerais bien aussi nautilus dont je trouve l'ergonomie catastrophique.
ca l'intéresse pas de savoir pourquoi le démarrage était plus lent et
qu'il a rebooté et que depuis ca merde ... et que si ca se trouve ca met
meme plus a jour et ca foire silencieusement. par contre apres ce meme
utilisateur te diras que finalement ca marche pas tres bien debian.
donc non vraiment: je crois en un minimum de responsabilisation.
ohhh ... d'aileurs voilÍ un truc a ajouter: un sanity check du system
avec ce genre de tests! merci pour l'idée.
Je me sens parfaitement autoriser Í apprécier le fait que tu aies
argumenté ta réponse et je serais en mesure de la produire si tu ne le
fais pas toi-même mercredi prochain.
Je proposerais ta solution mais je préfère ma version (si elle est
réalisable ce qui n'est pour le moment pas sur).
cordialement,
marc
[...]
[...]
La lecture de ce passage m'a incité Í me demander si, finalement, je savais vraiment ce qu'est une install-party (du coup je suis allé regarder sur wikipedia). N'y ayant jamais participé, j'imaginais plutÍ´t ça comme une réunion occasionnelle de débutants qui demandent aux experts présents de leur installer Linux (dans le cas présent) plus que comme une session de débutants qui tentent d'installer eux-même sous la supervision attentive d'experts.
Bref: si il s'agit de cornaquer des débutants prêts Í accepter l'idée que le bon fonctionnement de leur PC dans des conditions de sécurité satisfaisantes est une responsabilité qu'ils auront Í assumer, je suis on-ne-peut-plus d'accord avec votre démarche :-)
Mais ça ne reflète pas exactement ma -maigre- expérience personnelle ;-)
OK. l'install party est comme le reste du monde du libre: elle est ce
qu'on en fait. je n'ai pas énormément d'install parties derrière moi
mais j'ai pas mal installé pour des amis et des potes et je me rend
compte que linux ne prend pas prise quand il y a un manque
d'accompagnement et de pédagogie. Nous voulons donc faire évoluer le
format vers quelque chose comme le début d'une collaboration:
* expliquer nos choix et leurs raisons.
* tenter de mettre en place un lien qui permette facilement
Í l'utilisateur de revenir Í nous.
* être un relais vers les services des chatons (ca c'est encore Í poser
mais on a quelques idées)
après: declicks (desclicks.net/) est présent mercredi et ils ont pas mal
d'install parties au compteur (en tout cas bien plus que moi) et j'ai
hate d'avoir leur point de vue.
cordialement,
marc