Tester discourse.debian.net en français ?

[Charles Plessy]

Le Tue, May 05, 2020 at 11:03:16PM +0200, Jean-Philippe MENGUAL a écrit :
> 
> tu peux te rabattre sur les ressources internes à Debian ou gérées par
> des proches du projet.

Bonjour à tous,

ça me fait penser que l'on teste en ce moment une instance de forum
« discourse » sur discourse.debian.net.

Nous pourrions demander l'addition d'une catégorie « francophone »,
qu'en pensez-vous ?

Amicalement,

Charles

-- 
Charles Plessy  Akano, Uruma, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_p

Re: Coup de gueule - Bannissement du wiki et du forum debian-fr.xyz

[Sebastien CHAVAUX]

Pas grave, viens sur debian-facile au moins les tuto même avec des liens 
sont tolérés...


Le 05/05/2020 à 21:49, G2PC a écrit :


La raison est parfaitement celle que j'ai cité.
J'ai copié le contenu intégrale de nos échanges, et, c'est très 
claire, OLIVIER LANGE, tout comme ta mauvaise fois.

https://wiki.visionduweb.fr/index.php?title=Coup_de_gueule

J'ai été exclus car j'ai partagé la configuration du serveur SSH dans 
le wiki de debian-fr.xyz avec UN LIEN VERS MON TUTORIEL dans la 
bibliographie du wiki ce qui a entraîné la suppression de mon apport 
et le bannissement de mon compte.


Des personnes comme toi, Olivier, complices de ce genre de méthodes, 
viennent donner leur avis en disant que ce que je dis est faux, pour 
justifier la censure et le harcèlement !
Ça suffit ! J'ai dupliqué la conversation, alors, je ne te permet tout 
simplement pas de dire que la raison n'est pas celle que j'ai mentionnée.
Contrairement à vous, je suis honnête ! Je suis venu partager un coup 
de gueule, pas une fake news !


*Consulte ma ressource sur le wiki, et, dis moi si mon partage était 
de mauvaise qualité ! La réponse est NON, le partage est de bonne 
qualité !*


*Justifie le fait que je n'ai pas à mentionner la source du partage, 
et, que ce serait malvenue que de mentionner la source, dans la 
bibliographie ?*
*Tu va à l'encontre des règles de recherches scientifiques que l'on 
nous apprend à l'université, lorsque l'on fait un partage, on 
mentionne la provenance !*


*Cette censure, et, ce harcèlement, ça suffit !*

Blacklist moi je m'en tamponne le coquillage mais à un point si tu 
savais !
Ça se permet de justifier un bannissement d'une communauté, du fait 
d'un backlink, on croit rêver, en bon français, on appel ça " 
mentionner une source " , OLIVIER LANGE, de développez !



>>>


developpez.com› tutorial › installation-debian-base › test 

 

PDF -Installation de base d'un serveur web sous /Debian/ par /Olivier 
Lange

<

Re: Debian testing ou stable ?

[Jean-Marc]

Tue, 5 May 2020 19:18:01 +0200
Francois Meyer  écrivait :

> Bonjour à tous,

salut François,

> Je dois installer debian sur une nouvelle machine (neuve, récente). Je 
> me demandais l'intérêt et les inconvénients éventuels d'installer 
> testing plutôt que stable. Auparavant, j'ai toujours utilisé des 
> versions 'stable' (<= jessie)
> 
> Intérêt : quelques fonctionnalités supplémentaires, peut-être un 
> meilleur fonctionnement sur une machine récente ?

L'intérêt principal est d'avoir des logiciels plus récent.

Il faut donc aussi voir si avoir la toute dernière version te sera nécessaire.

> Inconvénients : je ne sais pas ? les bogues sont-ils si graves ?

L'inconvénient majeur est que testing plante solidement de temps à autre.
La dernière fois, c'était un joli écran gris indiquant "Oops, je ne démarre 
plus !".
Bon, dans ces cas-là, il faut savoir mettre les mains dedans.

Donc, cela dépend de ta connaissance des systèmes.

De manière générale, c'est déconseillé pour les novices.

> C'est peut-être une question bateau, mais je n'ai pas trouvé de réponse 
> très détaillée dans la doc.

Sinon, Debian stable offre tout ce qu'il faut pour une utilisation quotidienne 
ordinaire (navigation internet, suite office, lecture vidéo, audio, ...).

> Bonne soirée à tous

Bonne soirée à toi aussi.

> François
> 
> 


Jean-Marc 
https://6jf.be/keys/ED863AD1.txt


pgpG3pfqcwXEu.pgp
Description: PGP signature

Re: [HS] Re: Coup de gueule - Bannissement du wiki et du forum debian-fr.xyz

[G2PC]

> Bonjour,
>
> Je n'ai rien suivi au sujet, déjà pris par des sujets sociaux internes
> à Debian. Je dirais juste une opinion parfaitement personnelle: si tu
> es déçu de ces forums & wiki, tu peux te rabattre sur les ressources
> internes à Debian ou gérées par des proches du projet. Je pense ainsi
> que contribuer à wiki.debian.org, ou au wiki debian-facile, à cette
> mailing, à forum.debian.net, qui reste un cercle rapproché de Debian,
> te garantit audience, un process de gestion des conflits plus global
> (par Debian, par une asso, etc). J'ai en mémoire, mais ça n'a rien à
> voir avec ça j'espère, un canal IRC #debian-fr, qui plusieurs années
> durant, a été animé par des gens peu recommandables avant une
> fermeture par freenode manu militari, à la demande de Debian, pour
> faire cesser le lien debian - cette communauté affreuse.
>
> DOnc pour moi, mais ça va avec mon aversion à la dispersion dans le
> libre, plus on bosse près de la source, plus on est soudé, protégé par
> la communauté, par des procédures, et plus son travail est visible. Ca
> n'xonère pas des conflits, mais le mécanisme de résolution est plus
> partagé, le respect plus fondé sur la do-cratie, et l'impression
> d'arbitraire moins présent.
>
> Amicalement,


Merci pour les liens proposés : wiki.debian.org, le wiki debian-facile,
le forum.debian.net

J'ai déjà pu partager un article, sur le wiki.debian.org et faires
quelques propositions rudimentaires.
Voilà l'article complet que j'ai proposé sur Mod Evasive, qui est un
total copier coller de l'article que j'ai rédigé sur mon propre wiki :
https://wiki.debian.org/fr/Apache/mod_evasive

Comme dit, mon coup de gueule est surtout du au fait que la ressource
que j'ai partagée ne pouvait que répondre aux besoins des
administrateurs lecteurs.
Le fait de justifier qu'une source dans la bibliographie est un backlink
sauvage, c'est de la mauvaise fois.
J'aurais pu partager le contenu, effectivement, sur de nombreuses autres
communautés.

Cette censure est méprisante, pour mon partage, le temps de recherche,
le travail effectué, et ma volonté d'améliorer une page du wiki de cette
communauté debian-fr.xyz

J'estime que c'est bien d'avantage méprisant pour la centaine et les
milliers d'administrateurs francophones qui suivront, et, qui devront
perdre du temps pour trouver la bonne information, voir, qui devront à
leur tour, tout comme moi, reconstruire l'information car l'information
est dispersée, et qui devront, de ce fait, effectuer de très nombreuses
lectures complémentaires, pour arriver au même résultat.

Je le sais parfaitement, que mon contenu est pertinent, ce n'est pas de
la prétention.
En faisant mes recherches, j'ai bien pu me faire une idée de l'état des
lieux des tutoriels que l'ont retrouve sur la toile, et, je sais de ce
fait, que mon contenu, en français, apportait bien une valeur ajoutée.

C'est bien ça, qui me met en colère, cette fausse excuse de censurer un
contenu en parlant de backlink, alors qu'ils pointent vers un contenu
pertinent qui économisera du temps à d'autres !
Je n'ai jamais compté, à un seul moment, les backlink que je met en
place vers d'autres communautés, dont la communauté en question, qui
m'exclue pour avoir sourcé un partage.

J'ai donc suivi ton conseil, et, je suis allé compléter la page
concernant SSH, sur le wiki officiel wiki.debian.org
En espérant, cette fois, que le travail francophone ne sera pas sabordé
de l'intérieur.

Exemple de configuration SSH :
https://wiki.debian.org/fr/SSH#Exemple_fonctionnel_et_comment.2BAOk_pour_configurer_un_Serveur_SSH

Re: Debian testing ou stable ?

[Basile Starynkevitch]

On 5/5/20 7:18 PM, Francois Meyer wrote:

Bonjour à tous,

Je dois installer debian sur une nouvelle machine (neuve, récente). Je 
me demandais l'intérêt et les invonvénients éventuels d'installer 
testing plutôt que stable. Auparavant, j'ai toujours utilisé des 
versions 'stable' (<= jessie)


Intérêt : quelques fonctionnalités supplémentaires, peut-être un 
meilleur fonctionnement sur une machine récente ?



Tout dépend de ce que tu veux en faire.


Moi, je suis développeur de logiciels libres (censés être innovants). 
Pour ça, une Debian instable est préférable, elle fournit la version la 
plus récente des bibliothèques que je suis amené à utiliser, et en 
pratique c'est assez stable pour moi.



Un autre avantage de Testing ou Unstable est bien sûr le support de 
matériel très récent.


Mais si la machine est un serveur qui doit tourner 24h/24 il faut du stable.

L'intrermédiaire est testing.

Si la machine Debian sert par exemple d'interface graphique à un 
respirateur Covid, ou de gestion à un hopital surchargé par la pandémie 
actuelle, il faut du stable.



Autre critère: quelle compétence as tu sur Debian? Si tu pratiques 
Debian depuie une décennie, tu peux prendre le risque d'une testing ou 
d'une instable. Car en cas de problème tu saurais te débrouiller.



Donc, sans contexte additionnel, on ne peut pas te conseiller.


Librement

--
Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France; 
(mobile phone: cf my web page / voir ma page web...)

Re: Debian testing ou stable ?

[Sébastien Dinot]

Gaëtan Perrier a écrit :
> Tout dépend de ce que l'on appelle "en production" ...
> Sur un serveur ou un système embarqué oui bien sur. Sur une machine de
> bureau/portable perso testing/sid se défend.

Je partage cet avis pour plusieurs raisons :

1. J'ose commencer par un truisme : les versions récentes des logiciels ne
   sont souvent disponibles que dans la version testing.

   Dans mon métier, nous avons besoin de versions très récentes de diverses
   bibliothèques. Déployer des outils utilisant ces versions récentes sur une
   Debian testing est plutôt simple alors que le faire sur une Debian stable
   est parfois un tour de force. Cela fait d'ailleurs préférer Ubuntu (et ses
   nombreux PPA) à Debian à la plupart de mes collègues et fait qu'Ubuntu (et
   non Debian) est la distribution préconisée pour nos outils. Ou pour le dire
   à l'envers, sur une Debian stable, les utilisateurs auraient plutôt intérêt
   à déployer une version antédiluvienne de nos outils.

2. À titre privé, les outils ont tendance à se bonifier avec l'âge et les
   versions récentes bénéficient donc souvent d'une ergonomie améliorée. Ils
   sont plus agréables à utiliser et revenir sur une Debian stable est parfois
   assez désagréable sur un poste de travail.

3. Si personne ne teste la version testing et si personne ne remonte de bogue
   sur cette version, la version testing ne sert absolument à rien.

   Ce point évident à mes yeux ne semble pas l'être à beaucoup de monde. Mais
   en même temps, je comprends bien que chacun doit faire avec ses impératifs
   et sa compétence technique.

   Et tenez-vous bien, vu la manière dont fonctionne le basculement des
   paquets de unstable vers testing, on peut tenir le même raisonnement avec
   la version unstable (mais là, je préconise plutôt la machine virtuelle de
   test).

4. En général, je ne rencontre pas de problème, même si depuis quelques
   semaines je peste à cause d'un bogue concernant Firefox, récemment évoqué
   ici même et que je n'ai toujours pas creusé faute de temps. Ma précédente
   grosse galère avec une testing remonte à de longues années. Il y a un an et
   demi environ, je me suis sorti d'un problème ennuyeux mais relativement
   circonscrit en utilisant le snapshot Debian pour récupérer la version du
   logiciel qui fonctionnait 15 jours auparavant et la geler en attendant que
   le bogue affectant la version plus récente soit résolu.

À la maison, j'ai une épouse et deux ados et pour eux, la Debian testing
fonctionne au quotidien.

Être vraiment joueur, c'est déployer des paquets issus du dépôt experimental.
J'ai déployé il y a bien longtemps des outils piochés dans ce dépôt qui ne
sont jamais arrivés dans le dépôt unstable. Mais ce dépôt ne s'appelle pas
experimental pour rien. :)

Par contre, je vous rejoins sur les serveurs de production. Ils doivent
tourner et là, j'opte systématiquement pour des Debian stable (avec backport
ou une once de testing quand je ne peux faire autrement).

Mais face à ce choix cornélien, les conteneurs sont de plus en plus la
solution, même s'ils amènent leur propre lot de problèmes qui font que si je
les utilise massivement pour le développement et en intégration continue, je
suis plus réservé en production.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: [HS] Re: Coup de gueule - Bannissement du wiki et du forum debian-fr.xyz

[Jean-Philippe MENGUAL]

Jean-Philippe MENGUAL
Debian Developer non uploading
Community team member
Accessibility team member
debian-l10n-french team member
President of Debian France non-profit organization
Le 05/05/2020 à 22:38, G2PC a écrit :



J'imagine que tu dois être énervé de t'être fait ban quelques jours de
debian-fr.xyz mais est-ce si grave ? Essaye de te mettre à la place
des admins du wiki.
Allez, respire un coup, mets un [HS] devant le sujet car il ne
concerne pas des problèmes techniques sur debian. Et pour le reste,
t'emballes pas.

J'en ai profité pour aller voir ton wiki. Il y a plein d'infos
intéressantes dedans. Merci de partager ça avec tous.


Merci,
Je suppose que tu as pu constater également, que je n'ai aucun système
financier lié à mon site, et, aucun virus.
Je n'ai donc aucun intérêt à placer des backlink, hormis le fait de
sourcer la provenance du travail de recherches, et, de mentionner sur
mon propre wiki, les liens qui ont été utilisés.
C'est d'autant plus ridicule de la part de l'administrateur de
debian-fr.xyz que je mentionne à maintes reprises leur wiki, mais, qui
est malheureusement, souvent obsolète, avec de très vieux contenu.

Dès lors, les attaques de la part de certains admins qui pratiquent la
censure et le harcèlement sont de réels abus, et, de la totale
malveillance !
Je vais voir, moi aussi, a faire le ménage dans mes backlink en ce qui
concerne cette communauté, car j'avais partagé de nombreux liens vers
leurs ressources.

Il semble qu'il soit malvenu de partager sur debian-fr, dès lors, il est
tout autant mal venu que de partager vers debian-fr.

Oui, je suis en colère, et, j'ai toutes mes raisons de l'être.
Vous êtes nombreux à savoir que cela va bien au delà de ce petit incident !


Bonjour,

Je n'ai rien suivi au sujet, déjà pris par des sujets sociaux internes à 
Debian. Je dirais juste une opinion parfaitement personnelle: si tu es 
déçu de ces forums & wiki, tu peux te rabattre sur les ressources 
internes à Debian ou gérées par des proches du projet. Je pense ainsi 
que contribuer à wiki.debian.org, ou au wiki debian-facile, à cette 
mailing, à forum.debian.net, qui reste un cercle rapproché de Debian, te 
garantit audience, un process de gestion des conflits plus global (par 
Debian, par une asso, etc). J'ai en mémoire, mais ça n'a rien à voir 
avec ça j'espère, un canal IRC #debian-fr, qui plusieurs années durant, 
a été animé par des gens peu recommandables avant une fermeture par 
freenode manu militari, à la demande de Debian, pour faire cesser le 
lien debian - cette communauté affreuse.


DOnc pour moi, mais ça va avec mon aversion à la dispersion dans le 
libre, plus on bosse près de la source, plus on est soudé, protégé par 
la communauté, par des procédures, et plus son travail est visible. Ca 
n'xonère pas des conflits, mais le mécanisme de résolution est plus 
partagé, le respect plus fondé sur la do-cratie, et l'impression 
d'arbitraire moins présent.


Amicalement,

Re: [HS] Re: Coup de gueule - Bannissement du wiki et du forum debian-fr.xyz

[G2PC]

> J'imagine que tu dois être énervé de t'être fait ban quelques jours de
> debian-fr.xyz mais est-ce si grave ? Essaye de te mettre à la place
> des admins du wiki.
> Allez, respire un coup, mets un [HS] devant le sujet car il ne
> concerne pas des problèmes techniques sur debian. Et pour le reste,
> t'emballes pas.
>
> J'en ai profité pour aller voir ton wiki. Il y a plein d'infos
> intéressantes dedans. Merci de partager ça avec tous.

Merci,
Je suppose que tu as pu constater également, que je n'ai aucun système
financier lié à mon site, et, aucun virus.
Je n'ai donc aucun intérêt à placer des backlink, hormis le fait de
sourcer la provenance du travail de recherches, et, de mentionner sur
mon propre wiki, les liens qui ont été utilisés.
C'est d'autant plus ridicule de la part de l'administrateur de
debian-fr.xyz que je mentionne à maintes reprises leur wiki, mais, qui
est malheureusement, souvent obsolète, avec de très vieux contenu.

Dès lors, les attaques de la part de certains admins qui pratiquent la
censure et le harcèlement sont de réels abus, et, de la totale
malveillance !
Je vais voir, moi aussi, a faire le ménage dans mes backlink en ce qui
concerne cette communauté, car j'avais partagé de nombreux liens vers
leurs ressources.

Il semble qu'il soit malvenu de partager sur debian-fr, dès lors, il est
tout autant mal venu que de partager vers debian-fr.

Oui, je suis en colère, et, j'ai toutes mes raisons de l'être.
Vous êtes nombreux à savoir que cela va bien au delà de ce petit incident !

Re: Coup de gueule - Bannissement du wiki et du forum debian-fr.xyz

[G2PC]

> La raison est parfaitement celle que j'ai cité.
> J'ai copié le contenu intégrale de nos échanges, et, c'est très
> claire, OLIVIER LANGE, tout comme ta mauvaise fois.
> https://wiki.visionduweb.fr/index.php?title=Coup_de_gueule
>
> J'ai été exclus car j'ai partagé la configuration du serveur SSH
> dans le wiki de debian-fr.xyz  avec UN LIEN
> VERS MON TUTORIEL dans la bibliographie du wiki ce qui a entraîné
> la suppression de mon apport et le bannissement de mon compte.
>
>
> C'est bien clair dans la réponse de l...@debian-fr.xyz
> , la raison n'était pas le partage de la
> configuration, mais du lien. Et visiblement ce n'était pas la première
> fois que t'y as mis un lien vers ton wiki.
> --
> Hai-Nam Nguyen

C'est bien claire, c'est mentionné dans dans ce post, que, sur mon coup
de gueule.

Le contenu de qualité c'est vu supprimé, sans aucun avertissement, du
fait que j'ai sourcé la provenance du contenu, vers mon wiki, puisque
sur mon wiki, je mentionne les articles qui m'ont servi a créé la
documentation en français.

A aucun moment je n'ai omis cette information. Tu aurais du lire
justement en entier, plutôt que de te baser sur deux phrases.

Lors d'un travail de recherche, on mentionne les sources.

Ici, le fait de mentionner la source, et, d'avoir partagé du contenu, de
qualité, entraîne un ban.

Comme je le disais précédemment, ce n'est effectivement pas la première
fois, que les administrateurs abusent de leurs pouvoirs !

Quant à Olivier, qui estime que j'ai la capacité de pourrir les réseaux,
je lui assure qu'il n'a encore rien vu, je ne suis pas encore à leur
niveau, en ce qui concerne le pourrissement !

Bonne soirée.

[HS] Re: Coup de gueule - Bannissement du wiki et du forum debian-fr.xyz

[fabricer]

Hello,

J'imagine que tu dois être énervé de t'être fait ban quelques jours de 
debian-fr.xyz mais est-ce si grave ? Essaye de te mettre à la place des 
admins du wiki.
Allez, respire un coup, mets un [HS] devant le sujet car il ne concerne 
pas des problèmes techniques sur debian. Et pour le reste, t'emballes pas.


J'en ai profité pour aller voir ton wiki. Il y a plein d'infos 
intéressantes dedans. Merci de partager ça avec tous.


f.

Re: Coup de gueule - Bannissement du wiki et du forum debian-fr.xyz

[jcisio]

Le mar. 5 mai 2020 à 21:49, G2PC  a écrit :

> La raison est parfaitement celle que j'ai cité.
> J'ai copié le contenu intégrale de nos échanges, et, c'est très claire,
> OLIVIER LANGE, tout comme ta mauvaise fois.
> https://wiki.visionduweb.fr/index.php?title=Coup_de_gueule
>
> J'ai été exclus car j'ai partagé la configuration du serveur SSH dans le
> wiki de debian-fr.xyz avec UN LIEN VERS MON TUTORIEL dans la
> bibliographie du wiki ce qui a entraîné la suppression de mon apport et le
> bannissement de mon compte.
>
Bonjour,

C'est bien clair dans la réponse de l...@debian-fr.xyz, la raison n'était
pas le partage de la configuration, mais du lien. Et visiblement ce n'était
pas la première fois que t'y as mis un lien vers ton wiki.

Pour le reste, j'y passe (et je l'ai pas lu).

--
Hai-Nam Nguyen

Re: Coup de gueule - Bannissement du wiki et du forum debian-fr.xyz

[G2PC]

La raison est parfaitement celle que j'ai cité.
J'ai copié le contenu intégrale de nos échanges, et, c'est très claire,
OLIVIER LANGE, tout comme ta mauvaise fois.
https://wiki.visionduweb.fr/index.php?title=Coup_de_gueule

J'ai été exclus car j'ai partagé la configuration du serveur SSH dans le
wiki de debian-fr.xyz avec UN LIEN VERS MON TUTORIEL dans la
bibliographie du wiki ce qui a entraîné la suppression de mon apport et
le bannissement de mon compte.

Des personnes comme toi, Olivier, complices de ce genre de méthodes,
viennent donner leur avis en disant que ce que je dis est faux, pour
justifier la censure et le harcèlement !
Ça suffit ! J'ai dupliqué la conversation, alors, je ne te permet tout
simplement pas de dire que la raison n'est pas celle que j'ai mentionnée.
Contrairement à vous, je suis honnête ! Je suis venu partager un coup de
gueule, pas une fake news !

*Consulte ma ressource sur le wiki, et, dis moi si mon partage était de
mauvaise qualité ! La réponse est NON, le partage est de bonne qualité !*

*Justifie le fait que je n'ai pas à mentionner la source du partage, et,
que ce serait malvenue que de mentionner la source, dans la bibliographie ?*
*Tu va à l'encontre des règles de recherches scientifiques que l'on nous
apprend à l'université, lorsque l'on fait un partage, on mentionne la
provenance !*

*Cette censure, et, ce harcèlement, ça suffit !*

Blacklist moi je m'en tamponne le coquillage mais à un point si tu savais !
Ça se permet de justifier un bannissement d'une communauté, du fait d'un
backlink, on croit rêver, en bon français, on appel ça " mentionner une
source " , OLIVIER LANGE, de développez !


>>>


developpez.com› tutorial › installation-debian-base › test



PDF -Installation de base d'un serveur web sous /Debian/ par /Olivier Lange
<< La raison n'est pas celle que tu site... Par contre, tu as une
> capacité a polluer les ml assez importante. Donc fait une
> introspection, essaie d'écouter, et tu sera peut-être accepté.
>
> Mais la, je suis plus à te Blacklist ton email qu'autre chose, et
> c'est une action très rare me concernant...
>
> Olivier
>
> Le mar. 5 mai 2020 à 13:49, G2PC  > a écrit :
>
> Coup de gueule partagé sur mon wiki concernant l'administration de
> debian-fr.xyz  :
> https://wiki.visionduweb.fr/index.php?title=Coup_de_gueule
>
> La raison du coup de gueule est la suppression de ma contribution,
> et, mon bannissement du wiki et du forum, pour avoir partagé ceci
> sur le wiki de debian-fr.xyz  :
>
>
> La configuration du serveur SSH
>
> Un exemple complet et commenté pour configurer un serveur SSH :
>
> 
> # Configuration du Serveur SSH #
> 
> # Le Protocole 2 est mieux sécurisé :
> Protocol 2
> # Port à utiliser :
> Port 22
> # Clé publique du serveur à utiliser pour identifier le serveur :
> # HostKey /etc/ssh/ssh_host_rsa_key
> HostKey /etc/ssh/ssh_host_ed25519_key
> ##
> ##
> # Oblige l'authentification par clé SSH :
> # Valeur commentée par défaut !
> AuthenticationMethods publickey
> # Interdire l'authentification par mot de passe :
> PasswordAuthentication no
> # Interdire les mots de passe vide :
> PermitEmptyPasswords no
> # Autoriser la connexion pour les utilisateurs suivants :
> AllowUsers user1 user2 user3 user4
> # Choix de connexion pour l'utilisateur root sur le serveur SSH :
> PermitRootLogin no
> # Interdire certains utilisateurs :
> DenyUsers root
> ##
> ##
> # Durée maximum autorisée pour établir la connexion :
> LoginGraceTime 25s
> # Limiter a un nombre maximum les tentatives de connexions SSH non 
> authentifiée :
> MaxStartups 3:50:5
> # Maximum de 3 essais pour renseigner la passe phrase :
> MaxAuthTries 3
> # Maximum de 3 sessions ouvertes en même temps :
> MaxSessions 3
> # Autorise l'authentification par clé SSH :
> PubkeyAuthentication yes
> # Clés publiques autorisées pour établir une connexion :
> AuthorizedKeysFile  

Re: Debian testing ou stable ?

[Gaëtan Perrier]

Le mardi 05 mai 2020 à 19:58 +0200, Belaïd a écrit :
> Par "production" je veux dire une machine qui ne doit pas me faire perdre mon
> temps dans des réparations au lieu d'avancer dans mon travail quotidien. Une
> machine qui doit répondre à tout moment. Je parle de production perso ou pro
> , pour moi , dans mon domaine c'est pareil 
> 

Sauf qu'avec une debian stable sur une machine de boulot (servant surtout aux
dev) j'ai souvent perdu beaucoup de temps à essayer d'installer sans toujours y
réussir, des logiciels nécessaires à mon activité mais qui étaient trop récents
par rapport aux lib dispo en stable.
Pour moi il n'y a pas de version debian optimale dans ce genre de situation.
stable quand elle vient de sortir est très bien mais plus elle vieillit et plus
j'ai tendance à basculer en testing.


signature.asc
Description: This is a digitally signed message part

Re: Debian testing ou stable ?

[Eric Degenetais]

Le mar. 5 mai 2020 19:58, Belaïd  a écrit :

> Par "production" je veux dire une machine qui ne doit pas me faire perdre
> mon temps dans des réparations au lieu d'avancer dans mon travail
> quotidien. Une machine qui doit répondre à tout moment. Je parle de
> production perso ou pro , pour moi , dans mon domaine c'est pareil
>
Je suis d'accord... une machine qui est la seule de la maison et sert à
toute la famille n'a pas non plus le droit de faire faux bond. Surtout
quand on n'a que peu de temps disponible pour la bricoler...

>
> Le mar. 5 mai 2020 19:51, Gaëtan Perrier  a
> écrit :
>
>> Tout dépend de ce que l'on appelle "en production" ...
>> Sur un serveur ou un système embarqué oui bien sur. Sur une machine de
>> bureau/portable perso testing/sid se défend.
>>
>> Le mardi 05 mai 2020 à 19:44 +0200, Belaïd a écrit :
>> > Bonjour,
>> >
>> > Pour ce genre de question, j'imagine toujours  ce que donnerait un
>> système
>> > embarqué en cours de développement (Testing, unstable ...) installé
>> dans un
>> > avion de ligne ! 
>> >
>> > A mon avis en production, ça devrait toujours être du stable !
>> >
>> >
>> > Le mar. 5 mai 2020 19:27, Francois Meyer <
>> > francois-jean.me...@ac-versailles.fr> a écrit :
>> > > Bonjour à tous,
>> > >
>> > > Je dois installer debian sur une nouvelle machine (neuve, récente).
>> Je
>> > > me demandais l'intérêt et les invonvénients éventuels d'installer
>> > > testing plutôt que stable. Auparavant, j'ai toujours utilisé des
>> > > versions 'stable' (<= jessie)
>> > >
>> > > Intérêt : quelques fonctionnalités supplémentaires, peut-être un
>> > > meilleur fonctionnement sur une machine récente ?
>> > >
>> > > Inconvénients : je ne sais pas ? les bogues sont-ils si graves ?
>> > >
>> > > C'est peut-être une question bateau, mais je n'ai pas trouvé de
>> réponse
>> > > très détaillée dans la doc.
>> > >
>> > > Bonne soirée à tous
>> > >
>> > > François
>> > >
>> > >
>>
>>

Re: Coup de gueule - Bannissement du wiki et du forum debian-fr.xyz

[Olivier Lange]

La raison n'est pas celle que tu site... Par contre, tu as une capacité a
polluer les ml assez importante. Donc fait une introspection, essaie
d'écouter, et tu sera peut-être accepté.

Mais la, je suis plus à te Blacklist ton email qu'autre chose, et c'est une
action très rare me concernant...

Olivier

Le mar. 5 mai 2020 à 13:49, G2PC  a écrit :

> Coup de gueule partagé sur mon wiki concernant l'administration de
> debian-fr.xyz : https://wiki.visionduweb.fr/index.php?title=Coup_de_gueule
>
> La raison du coup de gueule est la suppression de ma contribution, et, mon
> bannissement du wiki et du forum, pour avoir partagé ceci sur le wiki de
> debian-fr.xyz :
>
> La configuration du serveur SSH
>
> Un exemple complet et commenté pour configurer un serveur SSH :
>
> 
> # Configuration du Serveur SSH #
> 
> # Le Protocole 2 est mieux sécurisé :
> Protocol 2
> # Port à utiliser :
> Port 22
> # Clé publique du serveur à utiliser pour identifier le serveur :
> # HostKey /etc/ssh/ssh_host_rsa_key
> HostKey /etc/ssh/ssh_host_ed25519_key
> ##
> ##
> # Oblige l'authentification par clé SSH :
> # Valeur commentée par défaut !
> AuthenticationMethods publickey
> # Interdire l'authentification par mot de passe :
> PasswordAuthentication no
> # Interdire les mots de passe vide :
> PermitEmptyPasswords no
> # Autoriser la connexion pour les utilisateurs suivants :
> AllowUsers user1 user2 user3 user4
> # Choix de connexion pour l'utilisateur root sur le serveur SSH :
> PermitRootLogin no
> # Interdire certains utilisateurs :
> DenyUsers root
> ##
> ##
> # Durée maximum autorisée pour établir la connexion :
> LoginGraceTime 25s
> # Limiter a un nombre maximum les tentatives de connexions SSH non 
> authentifiée :
> MaxStartups 3:50:5
> # Maximum de 3 essais pour renseigner la passe phrase :
> MaxAuthTries 3
> # Maximum de 3 sessions ouvertes en même temps :
> MaxSessions 3
> # Autorise l'authentification par clé SSH :
> PubkeyAuthentication yes
> # Clés publiques autorisées pour établir une connexion :
> AuthorizedKeysFile  .ssh/authorized_keys .ssh/authorized_keys2
> # Interdire la prise en compte des fichiers de configuration des commandes r 
> avec SSH :
> IgnoreRhosts yes
> # Le serveur d'authentification challenge-response PAM n'est pas configuré 
> par défaut :
> ChallengeResponseAuthentication no
> # PAM fournit la gestion des sessions et des comptes !
> UsePAM yes
> # Refuser l'export display :
> X11Forwarding no
> # La valeur no désactive complètement l'impression de motd.
> PrintMotd yes
> # Refuser l'authentification basée sur les DNS :
> UseDNS no
> # Refuser l'authentification basée sur l'hôte :
> HostbasedAuthentication no
> # Permet au client de définir des variables d'environnement dès 
> l'établissement de la connexion :
> AcceptEnv LANG LC_*
> # Loguer les tentatives de connexions dans /var/log/auth.log en ajoutant la 
> ligne suivante :
> SyslogFacility AUTH
> # Permet d'avoir une trace d'audit claire de la clé utilisée pour se 
> connecter :
> LogLevel VERBOSE
> # Journaliser les accès aux fichiers de niveau sftp qui ne seraient pas 
> journalisés autrement :
> # Subsystem sftp/usr/lib/openssh/sftp-server
> Subsystem sftp /usr/lib/openssh/sftp-server -f AUTHPRIV -l INFO
> # Définir un temps limite d'inactivité pour forcer la déconnexion :
> ClientAliveInterval 900
> # Concerne le nombre maximal de requêtes :
> ClientAliveCountMax 0
> # Vérifie les modes et le propriétaire des fichiers et du répertoire home de 
> l'utilisateur avant de se connecter :
> StrictModes yes
> # La mort de la connexion ou le crash de la machines sera remarqué pour 
> mettre fin à la connexion :
> TCPKeepAlive yes
> # Afficher un message pour l'utilisateur suite à une demande de connexion :
> Banner /etc/issue
>
> # En règle général les entreprises préfèrent désactiver le Port Forwarding 
> pour éviter la fuite d'informations :
> AllowTcpForwarding no
> # Spécifie si le transfert de sockets de domaine Unix est autorisé :
> AllowStreamLocalForwarding no
> # Spécifie si les hôtes distants sont autorisés à se connecter aux ports 
> transférés pour le client :
> GatewayPorts no
> # Spécifie si le transfert de périphérique est autorisé :
> PermitTunnel no
> # Spécifie les destinations vers lesquelles le transfert de port TCP est 
> autorisé :
> PermitOpen any
>
> # Spécifier les algorithmes KEX (échange de clés) disponibles :
> KexAlgorithms 
> curve25519-sha...@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
> # Spécifier les ciphers autorisés :
> Ciphers 
> chacha20-poly1...@openssh.com,aes256-...@openssh.com,aes128-...@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
> # Spécifier les algorithmes MAC (Message authentication code) :
> MACs 
> 

Re: Debian testing ou stable ?

[Yoann LE BARS]

Salut à tous !

Le 05/05/2020 à 19:58, Belaïd a écrit :
> Par "production" je veux dire une machine qui ne doit pas me faire
> perdre mon temps dans des réparations au lieu d'avancer dans mon travail
> quotidien. Une machine qui doit répondre à tout moment. Je parle de
> production perso ou pro , pour moi , dans mon domaine c'est pareil 

À mon sens, dans ce cas, il n’y a pas à hésiter : stable + backports.

À bientôt.

-- 
Yoann LE BARS
http://le-bars.net/yoann/
Diaspora* : yleb...@framasphere.org

Re: Coup de gueule - Bannissement du wiki et du forum debian-fr.xyz

[ajh-valmer]

On Tuesday 05 May 2020 19:49:23 G2PC wrote:
> Coup de gueule partagé sur mon wiki concernant l'administration de
> debian-fr.xyz : https://wiki.visionduweb.fr/index.php?title=Coup_de_gueule
> La raison du coup de gueule est la suppression de ma contribution, et,
> mon bannissement du wiki et du forum, pour avoir partagé ceci sur le
> wiki de debian-fr.xyz :
>La configuration du serveur SSH...

> "Bannissement du wiki et du forum Debian",
pour motif de publier une info très instructive :
Pourquoi et je croyais faire partie d'une communauté Libre (de Liberté) !

Re: Debian testing ou stable ?

[Belaïd]

Par "production" je veux dire une machine qui ne doit pas me faire perdre
mon temps dans des réparations au lieu d'avancer dans mon travail
quotidien. Une machine qui doit répondre à tout moment. Je parle de
production perso ou pro , pour moi , dans mon domaine c'est pareil

Le mar. 5 mai 2020 19:51, Gaëtan Perrier  a écrit :

> Tout dépend de ce que l'on appelle "en production" ...
> Sur un serveur ou un système embarqué oui bien sur. Sur une machine de
> bureau/portable perso testing/sid se défend.
>
> Le mardi 05 mai 2020 à 19:44 +0200, Belaïd a écrit :
> > Bonjour,
> >
> > Pour ce genre de question, j'imagine toujours  ce que donnerait un
> système
> > embarqué en cours de développement (Testing, unstable ...) installé dans
> un
> > avion de ligne ! 
> >
> > A mon avis en production, ça devrait toujours être du stable !
> >
> >
> > Le mar. 5 mai 2020 19:27, Francois Meyer <
> > francois-jean.me...@ac-versailles.fr> a écrit :
> > > Bonjour à tous,
> > >
> > > Je dois installer debian sur une nouvelle machine (neuve, récente). Je
> > > me demandais l'intérêt et les invonvénients éventuels d'installer
> > > testing plutôt que stable. Auparavant, j'ai toujours utilisé des
> > > versions 'stable' (<= jessie)
> > >
> > > Intérêt : quelques fonctionnalités supplémentaires, peut-être un
> > > meilleur fonctionnement sur une machine récente ?
> > >
> > > Inconvénients : je ne sais pas ? les bogues sont-ils si graves ?
> > >
> > > C'est peut-être une question bateau, mais je n'ai pas trouvé de
> réponse
> > > très détaillée dans la doc.
> > >
> > > Bonne soirée à tous
> > >
> > > François
> > >
> > >
>
>

Re: Debian testing ou stable ?

[Gaëtan Perrier]

Tout dépend de ce que l'on appelle "en production" ...
Sur un serveur ou un système embarqué oui bien sur. Sur une machine de
bureau/portable perso testing/sid se défend.

Le mardi 05 mai 2020 à 19:44 +0200, Belaïd a écrit :
> Bonjour,
> 
> Pour ce genre de question, j'imagine toujours  ce que donnerait un système
> embarqué en cours de développement (Testing, unstable ...) installé dans un
> avion de ligne ! 
> 
> A mon avis en production, ça devrait toujours être du stable ! 
> 
> 
> Le mar. 5 mai 2020 19:27, Francois Meyer <
> francois-jean.me...@ac-versailles.fr> a écrit :
> > Bonjour à tous,
> > 
> > Je dois installer debian sur une nouvelle machine (neuve, récente). Je 
> > me demandais l'intérêt et les invonvénients éventuels d'installer 
> > testing plutôt que stable. Auparavant, j'ai toujours utilisé des 
> > versions 'stable' (<= jessie)
> > 
> > Intérêt : quelques fonctionnalités supplémentaires, peut-être un 
> > meilleur fonctionnement sur une machine récente ?
> > 
> > Inconvénients : je ne sais pas ? les bogues sont-ils si graves ?
> > 
> > C'est peut-être une question bateau, mais je n'ai pas trouvé de réponse 
> > très détaillée dans la doc.
> > 
> > Bonne soirée à tous
> > 
> > François
> > 
> > 



signature.asc
Description: This is a digitally signed message part

Coup de gueule - Bannissement du wiki et du forum debian-fr.xyz

[G2PC]

Coup de gueule partagé sur mon wiki concernant l'administration de
debian-fr.xyz : https://wiki.visionduweb.fr/index.php?title=Coup_de_gueule

La raison du coup de gueule est la suppression de ma contribution, et,
mon bannissement du wiki et du forum, pour avoir partagé ceci sur le
wiki de debian-fr.xyz :


La configuration du serveur SSH

Un exemple complet et commenté pour configurer un serveur SSH :


# Configuration du Serveur SSH #

# Le Protocole 2 est mieux sécurisé :
Protocol 2
# Port à utiliser :
Port 22
# Clé publique du serveur à utiliser pour identifier le serveur :
# HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
##
##
# Oblige l'authentification par clé SSH :
# Valeur commentée par défaut !
AuthenticationMethods publickey
# Interdire l'authentification par mot de passe :
PasswordAuthentication no
# Interdire les mots de passe vide :
PermitEmptyPasswords no
# Autoriser la connexion pour les utilisateurs suivants :
AllowUsers user1 user2 user3 user4
# Choix de connexion pour l'utilisateur root sur le serveur SSH :
PermitRootLogin no
# Interdire certains utilisateurs :
DenyUsers root
##
##
# Durée maximum autorisée pour établir la connexion :
LoginGraceTime 25s
# Limiter a un nombre maximum les tentatives de connexions SSH non authentifiée 
:
MaxStartups 3:50:5
# Maximum de 3 essais pour renseigner la passe phrase :
MaxAuthTries 3
# Maximum de 3 sessions ouvertes en même temps :
MaxSessions 3
# Autorise l'authentification par clé SSH :
PubkeyAuthentication yes
# Clés publiques autorisées pour établir une connexion :
AuthorizedKeysFile  .ssh/authorized_keys .ssh/authorized_keys2
# Interdire la prise en compte des fichiers de configuration des commandes r 
avec SSH :
IgnoreRhosts yes
# Le serveur d'authentification challenge-response PAM n'est pas configuré par 
défaut :
ChallengeResponseAuthentication no
# PAM fournit la gestion des sessions et des comptes !
UsePAM yes
# Refuser l'export display :
X11Forwarding no
# La valeur no désactive complètement l'impression de motd.
PrintMotd yes
# Refuser l'authentification basée sur les DNS :
UseDNS no
# Refuser l'authentification basée sur l'hôte :
HostbasedAuthentication no
# Permet au client de définir des variables d'environnement dès l'établissement 
de la connexion :
AcceptEnv LANG LC_*
# Loguer les tentatives de connexions dans /var/log/auth.log en ajoutant la 
ligne suivante :
SyslogFacility AUTH
# Permet d'avoir une trace d'audit claire de la clé utilisée pour se connecter :
LogLevel VERBOSE
# Journaliser les accès aux fichiers de niveau sftp qui ne seraient pas 
journalisés autrement :
# Subsystem sftp/usr/lib/openssh/sftp-server
Subsystem sftp /usr/lib/openssh/sftp-server -f AUTHPRIV -l INFO
# Définir un temps limite d'inactivité pour forcer la déconnexion :
ClientAliveInterval 900
# Concerne le nombre maximal de requêtes :
ClientAliveCountMax 0
# Vérifie les modes et le propriétaire des fichiers et du répertoire home de 
l'utilisateur avant de se connecter :
StrictModes yes
# La mort de la connexion ou le crash de la machines sera remarqué pour mettre 
fin à la connexion :
TCPKeepAlive yes
# Afficher un message pour l'utilisateur suite à une demande de connexion :
Banner /etc/issue

# En règle général les entreprises préfèrent désactiver le Port Forwarding pour 
éviter la fuite d'informations :
AllowTcpForwarding no
# Spécifie si le transfert de sockets de domaine Unix est autorisé :
AllowStreamLocalForwarding no
# Spécifie si les hôtes distants sont autorisés à se connecter aux ports 
transférés pour le client :
GatewayPorts no
# Spécifie si le transfert de périphérique est autorisé :
PermitTunnel no
# Spécifie les destinations vers lesquelles le transfert de port TCP est 
autorisé :
PermitOpen any

# Spécifier les algorithmes KEX (échange de clés) disponibles :
KexAlgorithms 
curve25519-sha...@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
# Spécifier les ciphers autorisés :
Ciphers 
chacha20-poly1...@openssh.com,aes256-...@openssh.com,aes128-...@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
# Spécifier les algorithmes MAC (Message authentication code) :
MACs 
hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-...@openssh.com


Ainsi que la référence vers mon wiki, dans la bibliographie : 
https://wiki.visionduweb.fr/index.php?title=SSH

Re: Debian testing ou stable ?

[Belaïd]

Bonjour,

Pour ce genre de question, j'imagine toujours  ce que donnerait un système
embarqué en cours de développement (Testing, unstable ...) installé dans un
avion de ligne ! 

A mon avis en production, ça devrait toujours être du stable !


Le mar. 5 mai 2020 19:27, Francois Meyer <
francois-jean.me...@ac-versailles.fr> a écrit :

> Bonjour à tous,
>
> Je dois installer debian sur une nouvelle machine (neuve, récente). Je
> me demandais l'intérêt et les invonvénients éventuels d'installer
> testing plutôt que stable. Auparavant, j'ai toujours utilisé des
> versions 'stable' (<= jessie)
>
> Intérêt : quelques fonctionnalités supplémentaires, peut-être un
> meilleur fonctionnement sur une machine récente ?
>
> Inconvénients : je ne sais pas ? les bogues sont-ils si graves ?
>
> C'est peut-être une question bateau, mais je n'ai pas trouvé de réponse
> très détaillée dans la doc.
>
> Bonne soirée à tous
>
> François
>
>
>

Debian testing ou stable ?

[Francois Meyer]

Bonjour à tous,

Je dois installer debian sur une nouvelle machine (neuve, récente). Je 
me demandais l'intérêt et les invonvénients éventuels d'installer 
testing plutôt que stable. Auparavant, j'ai toujours utilisé des 
versions 'stable' (<= jessie)


Intérêt : quelques fonctionnalités supplémentaires, peut-être un 
meilleur fonctionnement sur une machine récente ?


Inconvénients : je ne sais pas ? les bogues sont-ils si graves ?

C'est peut-être une question bateau, mais je n'ai pas trouvé de réponse 
très détaillée dans la doc.


Bonne soirée à tous

François

Re: fail2ban regex

[G2PC]

> > Un outil de bannissement « définitif » pour ceux qui insistent
> > lourdement « multiban » répétés, basé sur l’analyse des logs de
> > Fail2ban. Vous pouvez le trouver sur l’URL suivante :
> >
> https://www.cybernaute.ch/bannir-definitivement-ip-bannies-frequemment-fail2ban/
>
> >  Mais cela ne suffisant pas car les réseaux servant à beaucoup
> > d’attaques permettent le changement d’IP, nous ajoutons des règles
> > « ipset » nourries par des RBL qui bloquent même certains réseaux
> > connus pour leurs pratiques douteuses. La solution simple est basée
> > sur 3 ou 4 sites (https://blognote32.net/iptables-ip-blacklist/)
> > Vous pouvez aussi aller voir sur
> > https://iplists.firehol.org/#aboutCollapseThree…
>
>
>     Intéressant. Je note pour plus tard.
+1

Re: le paquet pump chez Debian existe t'il encore

[MERLIN Philippe]

Bonjour,
Je voudrai vous faire part de mes essais de remplacement de pump par un autre 
logiciel .
J'ai essayé Wicd + dhcpcd5  je n'ai jamais réussi à me connecter en wifi après 
analyse des logs on observe qu'on obtient une adresse ip du serveur Wifi mais  
y a  déconnexion immédiate ensuite pourquoi ?
Donc je suis revenu à pump qui me permet d'établir une connexion de temps en 
temps.
 Ce n'est pas satisfaisant mais il faut que je m'en contente.
J'ai essayé de tracer au maximum tous les logiciels, Je ne sais pas quoi 
faire.
Un problème Hard de la carte wifi Intel N6205 ? Comment le savoir ?
J'ai une autre carte Wifi plus moderne qui marcherait très bien dans mon 
ordinateur Lenovo seulement il est Blacklisté par le Bios Lenovo n'acceptant 
que certaines cartes, la carte en question est plus récente et donc ne fait 
pas partie de celles autorisées. Il y a bien une modification du Bios pour 
retirer cette Whitelist cela me fait un peu peur, Y a t'il quelqu'un de la 
liste qui a tenté cette opération ?
Un Bug au niveau des drivers iwlvifi comment le faire resortir ?
Vous voyez j'ai beaucoup d'interrogations et vos idées seront la bienvenue.
Philippe Merlin

Re: debian testing, kernel 5.6 et nvidia optimus

[didier gaumet]

ta mise à jour a-t-elle bien mis les kernel-headers ou kernel-source en 5.6?

sinon d'après ce que j'ai compris tu pourrais tester (ça ne mange pas de
pain) le paquet mate-optimus à la place de bbswitch

sinon le wiki Archlinux sur Optimus semble assez complet quant aux
possibilités qui te sont offertes:
 https://wiki.archlinux.org/index.php/NVIDIA_Optimus
et la page Nouveau:
 https://wiki.archlinux.org/index.php/Nouveau

Re: Jitsi sur serveur debian/testing

[BERTRAND Joël]

Bonjour à tous,

J'ai enfin réussi à configurer jitsi correctement. C'est une saleté,
mais une fois fait, ça fonctionne raisonnablement bien. Si quelqu'un
veut faire un tuto quelque part (je n'aurai pas le temps), vous pouvez
me contacter par mail.

En fait, la doc de jitsi est fausse. Totalement. But de la manoeuvre :
avoir un serveur (ici Debian testing sur amd64, un i7/4770 avec 16 Go de
RAM, sur une connexion PPPoA). En aparté, le PPPoA fonctionne mieux que
le PPPoE parce qu'il y a moins de latence. Mais ça fonctionne aussi sur
du PPPoE à partir du moment où l'on chiade la QoS.

Connexion principale : ADSL (PPPoA), modem Netopia avec QoS.
Connexion secondaire pour certains utilisateurs : OpenVPN (tap sur udp)
sur une connexion VDSL2 (PPPoE), modem CISCO avec QoS.

Les deux connexions sont natées.

Utilisation :
- possibilité pour certains utilisateurs de créer une conférence.
- les invités doivent s'authentifier. Un invité ne peut créer une
conférence.

Pour cela, il faut :
- prosody ;
- jicofo ;
- jitsi-meet (videobridge) ;
- apache

Commençons par apache. Il faut activer le module proxy. Une fois cela
fait, j'ai créé un fichier de conf pour rendre accessible
jitsi.systella.fr en http et https :


ServerName jitsi.systella.fr
Redirect permanent / https://jitsi.systella.fr/
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]



  ServerName jitsi.systella.fr

  SSLProtocol TLSv1 TLSv1.1 TLSv1.2
  SSLEngine on
  SSLProxyEngine on
  SSLCertificateFile /etc/letsencrypt/live/systella.fr/cert.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/systella.fr/privkey.pem
  SSLCertificateChainFile /etc/letsencrypt/live/systella.fr/chain.pem
  SSLCipherSuite
"EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED"
  SSLHonorCipherOrder on
  Header set Strict-Transport-Security "max-age=31536000"

  DocumentRoot "/usr/share/jitsi-meet"
  
Options Indexes MultiViews Includes FollowSymLinks
AddOutputFilter Includes html
AllowOverride All
Order allow,deny
Allow from all
  

  ErrorDocument 404 /static/404.html

  Alias "/config.js" "/etc/jitsi/meet/jitsi.systella.fr-config.js"
  
Require all granted
  

  Alias "/external_api.js" "/usr/share/jitsi-meet/libs/external_api.min.js"
  
Require all granted
  

  ProxyPreserveHost on
  ProxyPass /http-bind http://localhost:5280/http-bind/
  ProxyPassReverse /http-bind http://localhost:5280/http-bind/

  RewriteEngine on
  RewriteRule ^/([a-zA-Z0-9]+)$ /index.html


Un utilisateur se connecte directement en http, il est redirigé
automatiquement sur le site https, le proxy est en route et se
débrouille avec le reste de la communication. Les certificats sont ici
des certificats étoilés de letsencrypt (j'héberge mon propre DNS rien
que pour cela).

Une fois cela fait, il faut réussir à faire parler jicofo et prosody
pour l'authentification. Commençons par prosody. La configuration se
fait ici : /etc/prosody/conf.d/jitsi.systella.fr.cfg.lua. Attention,
l'ordre des lignes est importante, ça évitera se s'arracher les cheveux !

Pour éviter les erreurs SSL, rajouter au _début_ du fichier :
consider_bosh_secure = true;
https_key = "/etc/prosody/certs/jitsi.systella.fr.key";
https_certificate = "/etc/prosody/certs/jitsi.systella.fr.crt";

qui sont des liens vers les certificats du domaine (étoilés dans mon
cas, sinon, corriger pour que cela soit cohérent avec sa propre
configuration).

Ensuite, on crée les différents sous-domaines :

VirtualHost "jitsi.systella.fr"
authentication = "internal_plain"
ssl = {
key = "/etc/prosody/certs/jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/jitsi.systella.fr.crt";
}
modules_enabled = {
"bosh";
"pubsub";
"ping"; -- Enable mod_ping
}
c2s_require_encryption = false

VirtualHost "guest.jitsi.systella.fr"
authentication = "internal_plain"
c2s_require_encryption = false

-> pour que les invités soient contraints à 'authentifier (forme
inv...@jitsi.systella.fr, pas de guest devant !)

Component "conference.jitsi.systella.fr" "muc"
storage = "memory"

admins = { "fo...@auth.jitsi.systella.fr" }
-> le nom de l'administrateur autorisé à créer des conférences

Component "jitsi-videobridge.jitsi.systella.fr"
component_secret = "lkjhlkjolkj"

VirtualHost "auth.jitsi.systella.fr"
ssl = {
key = "/etc/prosody/certs/jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/jitsi.systella.fr.crt";
}
authentication = "internal_plain"

Component "focus.jitsi.systella.fr"

Re: le paquet pump chez Debian existe t'il encore

[didier gaumet]

Je te suggère d'essayer aussi isc-dhcp-client (dhclient) à la place de
pump, pour voir.

Je serais toi, j'essaierais d'abord de déterminer si le problème vient
de mon installation et je testerais un live CD Debian avec firmwares:
 
https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/

je commencerais par une Debian 10.3 live LXDE (c'est le seul
environnement à utiliser wicd) puis un weekly-build testing LXDE

Si l'une ou l'autre (ou les deux) fonctionnent, c'est ta Debian qui est
bancale (ce que l'on ne peut exclure sur une Sid, qui plus est
mise-à-jour depuis longtemps). Reste alors à la remettre d'aplomb ou la
réinstaller. Voire à se poser la question d'utiliser Stable à la place
(j'ai une carte Realtek, le driver est hors-noyau en DKMS, il ne
fonctionne que sous Stable (linux 4.19) chez moi; en
Stable+Backports/Testing/Sid ou autre distro linux 5.x, pas
d'association. Mais là c'est le cas particulier d'un pilote hors
arborescence noyau).

Si les live Debian ne fonctionnent pas, tu peux aussi te poser la
question de l'utilisation de Wicd: j'ai vu qu'il y avait encore de la
maintenance (alors que je croyais le projet mort) mais de quel niveau et
suivi est-elle? éventuellement se poser la question de remplacer wicd
par connman ou network-manager. Tu peux tester connman (cmst) avec
l'environnement LXQT ou network-manager avec tous les autres environnements.

Accessoirement, vu que tu as dû faire des essais et câblages de cartes
wifi dans ton portable: es-tu sûr de tes raccordements antenne(s)? Si tu
as 2 câbles d'antennes, il doivent être raccordés tous les 2,
généralement ils sont repérés et il vaut mieux respecter les repères
(1/2, main/aux...) et les connecteurs d'antenne doivent offrir un
contact franc (les signaux d'antenne c'est potentiellement faible)

debian testing, kernel 5.6 et nvidia optimus

[Jérémy Prego]

bonjour,

Depuis ce matin, ma debian testing est passé au noyau 5.6. depuis ce
passage, j'ai bbswitch-dkms qui ne veut plus se compiler. En
conséquence, je viens vers vous pour savoir ce qui se fait de mieux
aujourd'hui pour gérer la carte nvidia au mieu avec le pilote libre, si
possible. mon pc est toujours le dell g5 15 5587.
# lspci |grep -i nvidia
01:00.0 3D controller: NVIDIA Corporation GP107M [GeForce GTX 1050 Ti
Mobile] (rev a1)

Il faut savoir qu'avec bumblebee / bbswitch, ça ne fonctionnait déjà pas
bien, j'avais un souci lors du réveil de la carte, avec un message du
genre: ":01:00.0: Refused to change power state, /currently in D3/".
Par contre, même si j'avais ce message, je constatait que la carte se
réveillait quand même, puisque le pc se mettait à chauffer ~10° en plus.
La seule solution pour éteindre la carte
était d'arrêter le pc complètement, avant de le rallumer bien sûr. un
simple reboot ne suffisait pas.

J'avais commencé a faire des recherches sur ce sujet mais vu la
complexité de ce que j'avais trouvé et que ça s'appliquait peut être pas
a debian, j'ai pas poursuivi.

En conséquence, je viens vers vous, pour prendre des nouvelles à jour
sur optimus avec debian, avec le pilote libre, de préférence :) ce que
je trouve sur le net est souvent de 2012/2013 ...

merci d'avance de m'avoir lu et de vos réponses :)

Jerem

PostgreSQL et réplication

[BERTRAND Joël]

Bonjour à tous,

Petit problème du jour avec une réplication PostgreSQL (11).

J'utilise une base de données conséquentes sur un site A. Sur le site
B, distant, j'ai installé une réplication de la base de données en
question. Cette réplication fonctionne. Le maître vient de partir en
vrille parce que /var était plein...

Problème : les fichiers d'archive de la base principale ne sont jamais
effacés :
postgres@rayleigh:~/11/archive$ ls -1
000100010085
000100010085.0028.backup
000100010086

Tous les jours, je me prends un fichier supplémentaire. Dans la doc de
PostgreSQL, je vois qu'on peut utiliser dans le fichier recovery.conf de
la réplique la commande archive_cleanup_command = 'pg_archivecleanup
/var/lib/postgresql/11/archive %r', ce qui suppose tout de même que
l'arborescence du maître est montée sur l'esclave. Cela pourrait se
faire, il y a un VPN entre les deux.

Mais dans mon cas, les uid/gid des maître et esclave sont différents,
donc ça ne va pas pouvoir se faire en claquant des doigts.

D'où ma question : existe-t-il un moyen dans PosgreSQL d'indiquer au
maître qu'il peut effacer les fichiers d'archive sans en passer par une
verrue de style pg_archivecleanup dans un cron ?

Bien cordialement,

JKB