la config de base de debian pour les install parties ?

On Fri, Nov 27, 2020 at 11:12:24AM +0100, Fernand wrote:

va être délicate Í  réaliser, même en Alsace (Troll du vendredi 😂 ), en
effet, le nombre de ports disponibles pour l'écoute n'est "que" de 2^16
soit 65535.

oops oui! merci :)

marc

Le 27/11/20 Í  10h06, Marc Chantreux <mc@unistra.fr> a écrit :

nous avons quelques notes ici:

https://framagit.org/flammekueche-connection/install_parties/-/blob/master/debian.md

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

* est-ce possible de faire un apt update selectif (uniquement le depot
security)?

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)

salut Daniel!

Merci, y'a plein de trucs intéressants (et faudra que j'essaie les window
manager cités !).

avec plaisir :)

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…

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

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";

ah ben oui! j'ai ca aussi et j'ai complètement oublié! merci: je vais le
rajouter.

/etc/apt/sources.list.d/deb-multimedia.list
deb http://www.deb-multimedia.org buster main non-free

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.

Je sais pas… la doc n'en parle pas

au pire je vais demander au mainteneurs de apt.

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).

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)

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é)

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

Bonsoir,

27 nov. 2020 Í  19:08 de no-spam@tootai.net:

Le 27/11/2020 Í  18:46, k6dedijon@free.fr a écrit :

Je me souviens pas que cron puisse lancer une commande lorsque l'on rallume la machine (alors que anacron le fait si cette opération était programmée alors que le PC était éteint), je ne me souviens pas que cron délivre un message disant qu'une opération aurait dÍ» être faite alors que le PC était éteint.

# Pour executer une commande au démarrage de cron
#
# m h  dom mon dow   command
@reboot /usr/bin/<ma commande>

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

Le vendredi 27 novembre 2020 Í  16:20:04 UTC+1, Marc Chantreux a écrit :
[...]

ah oui je sais mais l'idée ici c'est de:

* faire les mise a jour de secu frequement

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)

* les autres attendront la fin du mois (ou une commande manuelle)

[...]

ç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?

hello,

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)

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.

ç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.

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.

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?

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

Le samedi 28 novembre 2020 Í  20:00:07 UTC+1, Marc Chantreux a écrit :

hello,
> 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)
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.
> ç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.
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.
> 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?
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 :-)

hello,

Désolé de t'avoir involontairement pythonisé ;-)

ca n'est pas ta faute mais celle du développeur ;)

Loin de moi l'intention d'insister lourdement sur l'utilisation de
unattended-upgrades ou de quelque autre solution quelle qu'elle soit,
hein :-)

si j'ai soumis ma prose Í  la communauté c'était bien pour avoir un
retour! merci pour ce retour.

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.

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.

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)

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 :)

c'est maintenant standard dans Debian, donc le cas échéant Debian
fournira un upgrade adapté si ce genre de choses devait arriver.

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.

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.

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.

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 :-)

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

Le samedi 28 novembre 2020 Í  22:20:03 UTC+1, Marc Chantreux a écrit :
[...]

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.

[...]

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 ;-)

> * 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.

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).

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