Re: App Linŭx de cryptage
On Wed, Apr 08, 2020 at 09:15:52AM +0200, Gabriel Moreau wrote: > > En faisant un tour sur OpenPGP on trouve cette page qui recense quelques > > clients mail de cryptage : > > https://chiffrer.info/ On notera que le commentaire sur "chiffrage" est faux, ref l'académie française: https://www.dictionnaire-academie.fr/article/A9C2007 J'aime à l'employer dans son sens cryptographique pour semer le trouble chez les managers. Y.
Re: Jitsi sur serveur debian/testing
Le 13/04/2020 à 18:03, BERTRAND Joël a écrit : NoSpam a écrit : Rappelle toi que jitsi utilise le port 443 pour le proxy. Si ton apache écoute également sur ce port ... Chez moi nginx écoute le 6443 (MV dont le port 443 de l'extérieur est forwardé sur ce port) et fait proxy_pass vers le pour jitsi qui utilise également le 80, le 443 pour *son* proxy_pass et le 4445 pour turn Je fais le proxy_pass sur le 6443 car j'ai d'autres MV qui utilisent également le 443, celle ci est en front. Je pense qu'il y a quelque chose que je ne saisis pas bien dans le fonctionnement de jitsi. Je viens de lire et relire la doc et ce n'est pas franchement plus clair. À quoi sert le proxy et de quels flux s'occupe-t-il (et sur quels ports) ? De ce que j'ai compris : - le 80 externe est redirigé sur le 443 - le 443 répond en https (jitsi-meet) - le proxy qui s'occupe du videobridge. La question qui se pose est donc la suivante : en supposant qu'on ne puisse pas rediriger le port 443 externe sur autre chose, comment organiser l'ensemble des ports pour que ça fonctionne ? Ce que je ferai: une règle PREROUTING qui redirige le 443 sur un port X sur lequel écoute ton apache en plus des ports nécessaires pour jitsi. Ensuite tu rediriges ton traffic via apache en proxy_pass vers jitsi port , Extrait de la config jitsi nginx: # this is jitsi-meet nginx module configuration # this forward all http traffic to the nginx virtual host port # and the rest to the turn server Donc le port 443 jitsi renvoi sur 127.0.0.1: (web) et 127.0.0.1:4445 (turn) Ma config court-circuite le 443 de jitsi en écoutant sur 6443 et renvoi directement sur n'ayant pas besoin du serveur turn (pas de LAN derrière) -- Daniel
Re: Lancer une appli graphique en ssh
On 13/04/2020 15:12, ajh-valmer wrote: > Bonjour, > > Je tente de lancer une appli graphique depuis chez moi (client) > depuis un serveur distant : > > ssh root@ -X xclock > "X11 connection rejected because of wrong authentication. > Error: Can't open display: localhost:10.0" > Je suppose que to serveur ssh accepte le login root. > J'ai vainement cherché, rien ne fonctionne, c'est désespérant, > dont de lancer sur mon serveur distant xhost + Je n'utilise pas xhost mais xauth. Jette un oeil dans le man sur l'exemple pour l'utiliser en ssh. -- Fabien
Re: Lancer une appli graphique en ssh
On Monday 13 April 2020 17:36:52 Pierre Malard wrote: > Vous pouvez toujours essayer un : > ssh -Y @ > Personnellement je me suis bricolé une fonction dans le « bashrc » > qui me lance un « xhost + >/dev/null » pour forcer l’autorisation > du forwarding W11 dès que je repère le lancement d’un « ssh -X » > ou « ssh -Y ». > le « forwarding IP », tout con non ? Du coup, que vous ayez lancé > un serveur X11 sur votre PC ou non, il refuse l’affichage de la > fenêtre X11 venant d’ailleurs le bougre ! Et vous avez une gentille > phrase comme : > root@:~# gparted > Unit -.mount does not exist, proceeding anyway. > Invalid MIT-MAGIC-COOKIE-1 key > (gpartedbin:7370): Gtk-WARNING **: 17:00:09.843: cannot > open display: :10.0 à chaque tentative. > Finalement, j’ai trouvé la solution dans un post sur StackOverFlow, > voici ce qu’il faut faire : > lancer un serveur X11 sur son PC si ce n’est pas déjà > le cas > lancer la commande « xhost + » sur son PC avant de > faire le SSH -X ou -Y > C’est tout con, le XHost avec un « + » autorise simplement > l’affichage de toute fenêtre venant de l’extérieur… > Essayez… : X11 = Xorg (mode graphique ?) Lancer un serveur X11 sur le serveur ou sur le client ? Sur le client = je suis en mode graphique (Nvidia). Sur le serveur, Xorg ou X11 installé mais j'arrive pas à le lancer. Sur le client, xhost + : unable to open display "192.168.0.24:0" Rien à faire... Serait-ce le display xhost du client ?
Re: Jitsi sur serveur debian/testing
NoSpam a écrit : > Rappelle toi que jitsi utilise le port 443 pour le proxy. Si ton apache > écoute également sur ce port ... Chez moi nginx écoute le 6443 (MV dont > le port 443 de l'extérieur est forwardé sur ce port) et fait proxy_pass > vers le pour jitsi qui utilise également le 80, le 443 pour *son* > proxy_pass et le 4445 pour turn > > Je fais le proxy_pass sur le 6443 car j'ai d'autres MV qui utilisent > également le 443, celle ci est en front. Je pense qu'il y a quelque chose que je ne saisis pas bien dans le fonctionnement de jitsi. Je viens de lire et relire la doc et ce n'est pas franchement plus clair. À quoi sert le proxy et de quels flux s'occupe-t-il (et sur quels ports) ? De ce que j'ai compris : - le 80 externe est redirigé sur le 443 - le 443 répond en https (jitsi-meet) - le proxy qui s'occupe du videobridge. La question qui se pose est donc la suivante : en supposant qu'on ne puisse pas rediriger le port 443 externe sur autre chose, comment organiser l'ensemble des ports pour que ça fonctionne ? JKB
Re: Debian/Sid sur "gros" ordinateur de bureau - plantage économiseur d'écran donc comment vidanger sur disque SSD
Bonjour, Le lundi 13 avril 2020, BERTRAND Joël a écrit... > Je rebondis un peu sur le sujet, désolé de me greffer dans la > discussion. J'ai parcouru un peu les archives internet et je n'arrive > pas à avoir une idée claire. J'envisage de changer ma machine de bureau > justement pour un Ryzen 7 ou 9, mais sans GPU intégré (il me faut une > carte graphique de 2 ou 4 Go pour travailler sereinement). Est-ce que ce > bug se limite aux CPU avec GPU intégré (utilisés ou non) ou à tous les > Ryzen ? Il y a un sujet fleuve sur kernel.org https://bugzilla.kernel.org/show_bug.cgi?id=196683 Il y a un moment que je ne l'ai pas parcouru. De mémoire, certains on fait pas mal de tests avec de CM et des cartes graphiques différentes, mais les résultats n'étaient pas probants. J'ai une MSI B350M. Il me semble que la version du bios de l'époque (il y a 1 an et demi) était plus ou moins en cause. Quant aux Ryzen, je pense que les 7 sont également touchés. Les 9, je ne sais pas. En CM, j'éviterais MSI avec les Ryzen. Le script zenstates.py fait bien le job en désactivant l'état c6 du processeur, je ne suis plus ennuyé avec ça depuis que systemd l'active au boot. -- jm
Re: Lancer une appli graphique en ssh
Bonjour, Vous pouvez toujours essayer un : ssh -Y @ Personnellement je me suis bricolé une fonction dans le « bashrc » qui me lance un « xhost + >/dev/null » pour forcer l’autorisation du forwarding W11 dès que je repère le lancement d’un « ssh -X » ou « ssh -Y ». J’ai déjà eu ce genre de comportements entre Ubuntu et Debian. En fouillant dans mes archives, j’ai trouvé ceci : En fait cela tient au fait que le poste local (votre PC) interdise le « forwardigng IP », tout con non ? Du coup, que vous ayez lancé un serveur X11 sur votre PC ou non, il refuse l’affichage de la fenêtre X11 venant d’ailleurs le bougre ! Et vous avez une gentille phrase comme : root@:~# gparted Unit -.mount does not exist, proceeding anyway. Invalid MIT-MAGIC-COOKIE-1 key (gpartedbin:7370): Gtk-WARNING **: 17:00:09.843: cannot open display: :10.0 à chaque tentative. Finalement, j’ai trouvé la solution dans un post sur StackOverFlow, voici ce qu’il faut faire : • lancer un serveur X11 sur son PC si ce n’est pas déjà le cas • lancer la commande « xhost + » sur son PC avant de faire le SSH -X ou -Y C’est tout con, le XHost avec un « + » autorise simplement l’affichage de toute fenêtre venant de l’extérieur… Essayez… Source https://stackoverflow.com/questions/14174188/invalid-magic-cookie-when-connecting-in-mac > Le 13 avr. 2020 à 15:12, ajh-valmer a écrit : > > Bonjour, > > Je tente de lancer une appli graphique depuis chez moi (client) > depuis un serveur distant : > > ssh root@ -X xclock > "X11 connection rejected because of wrong authentication. > Error: Can't open display: localhost:10.0" > > J'ai vainement cherché, rien ne fonctionne, c'est désespérant, > dont de lancer sur mon serveur distant xhost + > > Merci d'une piste, d'un tuto explicatif précis... > > Bon confinement. > -- πr « Il n'y a pas de Paradis, mais il faut tâcher de mériter qu'il y en ait un ! » Jules Renard (1864-1910) - Journal, 10 septembre 1903 |\ _,,,---,,_ /,`.-'`'-. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) πr perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print' - --> Ce message n’engage que son auteur <-- signature.asc Description: Message signed with OpenPGP
Re: Lancer une appli graphique en ssh
On Monday 13 April 2020 16:05:30 hamster wrote: > Le 13/04/2020 à 15:12, ajh-valmer a écrit : > > Je tente de lancer une appli graphique depuis chez moi (client) > > depuis un serveur distant : > > ssh root@ -X xclock > > "X11 connection rejected because of wrong authentication. > > Error: Can't open display: localhost:10.0" > > J'ai vainement cherché, rien ne fonctionne, c'est désespérant, > > dont de lancer sur mon serveur distant xhost + > D'habitude je met l'option avant le login@ip, mais je sais pas si ca a > une importance : Idem. > Le transfert de la connexion X est dangereux parce que ca permet de > faire du keylogging. Cette option est donc fréquamment désactivée dans > la configuration du serveur X. Si c'est le cas sur la machine a laquelle > tu essaye de te connecter, c'est normal que ca coince. Tu peux essayer > avec l'option -Y a la place de -X. Je te laisse aller voir dans le man > ssh quelle est la différence : -X ou -Y ou -A : idem ssh root@ -X gparted marchait très bien avant et ça me rendrait tellement service.
Re: l'economiseur d'ecran c'est deprecie
L'économiseur d'écran sur un écran LCD peut toujours être utile. En effet, j'ai
déjà vu des écrans LCD ayant une image fantôme à cause d'un affichage quasi
constant sur de nombreuses années. En l'occurrence c'était les bordures
semi-graphiques qu'on rencontre typiquement dans une appli en TUI.
Le 13 avril 2020 16:15:14 GMT+02:00, hamster a écrit :
>Le 13/04/2020 à 15:06, Basile Starynkevitch a écrit :
>> Ma machine à la maison est une "grosse" machine: AMD Ryzen
>> Threadripper 2970WX, carte mère MSI X399 SLI Plus, 64Go de RAM,
>> boitier bien ventilé, 12 Tera de disque dont un Samsung SSD 970 EVO
>> 2TB, deux cartes graphiques (AMD Radeon 570 + Nvidia GTX 1050 Ti).
>> Noyau Linux 5.5.0, xorg 2:1.20.8
>>
>> En général, elle est peu chargée. J'y développe actuellement
>> https://github.com/bstarynk/helpcovid/
>>
>> Régulièrement cette machine gèle ("freeze"). Je dois appuyer sur le
>> bouton Reset du boitier (le bouton d'ext Je n'ai pas eu le temps de
>> chercher pourquoi, mais mon intuition est un économiseur d'écran qui
>> plante le noyau ou au moins le serveur Xorg (j'incrimine Nvidia et ou
>> un truc OpenGL) lié à XFCE ou MATE. Car chaque fois que ça freez,
>> l'économiseur d'écran tournait!
>
>Ca ne répond pas a ta question mais l'économiseur d'écran c'était un
>truc fait pour économiser les tubes cathodiques. Avec un écran LCD (ou
>autre technologie d'écran plat) ca fait travailler le processeur pour
>rien.
>
>A moins que tu n'ait encore un vieil écran cathodique (ce donc je
>doute)
>il vaut bien mieux configurer ton ordi pour qu'il eteigne l'écran au
>bout d'un temps d'inactivité.
>
>Personnellement, je désinstalle systématiquement l'économiseur d'écran
>a
>chaque fois que je met debian sur un ordi. Je ne comprend d'ailleurs
>pas
>qu'une vieillerie caduque comme l'économiseur d'écran soit toujours
>installée et activée par défaut dans les distribs. Zut a la fin, on est
>au 21e siècle !
--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma
brièveté.
Re: l'economiseur d'ecran c'est deprecie
hamster a écrit : > Ca ne répond pas a ta question mais l'économiseur d'écran c'était un > truc fait pour économiser les tubes cathodiques. Avec un écran LCD (ou > autre technologie d'écran plat) ca fait travailler le processeur pour rien. > > A moins que tu n'ait encore un vieil écran cathodique (ce donc je doute) > il vaut bien mieux configurer ton ordi pour qu'il eteigne l'écran au > bout d'un temps d'inactivité. > > Personnellement, je désinstalle systématiquement l'économiseur d'écran a > chaque fois que je met debian sur un ordi. Je ne comprend d'ailleurs pas > qu'une vieillerie caduque comme l'économiseur d'écran soit toujours > installée et activée par défaut dans les distribs. Zut a la fin, on est > au 21e siècle ! > Mon truc, c'est l'électronique. Et dans mon dernier boulot, c'était même les panneaux d'affichage LCD. Deux choses. On arrive à marquer des écrans LCD. Les LCD à rétroéclairage LED supportent mieux les cycles allumages/extinction que les écrans utilisant des tubes. Mais l'électronique n'aime pas beaucoup les cycles d'allumage et d'extinction. Donc l'économiseur d'écran n'est pas forcément idiot. JKB
Re: Debian/Sid sur "gros" ordinateur de bureau - plantage économiseur d'écran donc comment vidanger sur disque SSD
Jean-Michel OLTRA a écrit : > > Bonjour, > > > Le lundi 13 avril 2020, Basile Starynkevitch a écrit... > >> Ma machine à la maison est une "grosse" machine: AMD Ryzen Threadripper >> 2970WX, carte mère MSI X399 SLI Plus, 64Go de RAM, boitier bien ventilé, 12 >> Tera de disque dont un Samsung SSD 970 EVO 2TB, deux cartes graphiques (AMD >> Radeon 570 + Nvidia GTX 1050 Ti). Noyau Linux 5.5.0, xorg 2:1.20.8 > >> En général, elle est peu chargée. J'y développe actuellement > > Sur les Ryzen (j'ai un Ryzen 5), il y a un problème de gel de la machine lié > à un certain état du processeur. J'ai vu des discussions sur les 5 et les 7. > Pour le tien, je ne sais pas. Sur noyaux 4.x et 5.x, par ailleurs. > > Si ça peut être ça, chercher "ryzen linux kernel freeze when idle" par > exemple. Chez moi, la solution a été avec le script zenstates.py. Je rebondis un peu sur le sujet, désolé de me greffer dans la discussion. J'ai parcouru un peu les archives internet et je n'arrive pas à avoir une idée claire. J'envisage de changer ma machine de bureau justement pour un Ryzen 7 ou 9, mais sans GPU intégré (il me faut une carte graphique de 2 ou 4 Go pour travailler sereinement). Est-ce que ce bug se limite aux CPU avec GPU intégré (utilisés ou non) ou à tous les Ryzen ? Bien cordialement, JKB
Re: l'economiseur d'ecran c'est deprecie
Le 13/04/2020 à 15:06, Basile Starynkevitch a écrit :
> Ma machine à la maison est une "grosse" machine: AMD Ryzen
> Threadripper 2970WX, carte mère MSI X399 SLI Plus, 64Go de RAM,
> boitier bien ventilé, 12 Tera de disque dont un Samsung SSD 970 EVO
> 2TB, deux cartes graphiques (AMD Radeon 570 + Nvidia GTX 1050 Ti).
> Noyau Linux 5.5.0, xorg 2:1.20.8
>
> En général, elle est peu chargée. J'y développe actuellement
> https://github.com/bstarynk/helpcovid/
>
> Régulièrement cette machine gèle ("freeze"). Je dois appuyer sur le
> bouton Reset du boitier (le bouton d'ext Je n'ai pas eu le temps de
> chercher pourquoi, mais mon intuition est un économiseur d'écran qui
> plante le noyau ou au moins le serveur Xorg (j'incrimine Nvidia et ou
> un truc OpenGL) lié à XFCE ou MATE. Car chaque fois que ça freez,
> l'économiseur d'écran tournait!
Ca ne répond pas a ta question mais l'économiseur d'écran c'était un
truc fait pour économiser les tubes cathodiques. Avec un écran LCD (ou
autre technologie d'écran plat) ca fait travailler le processeur pour rien.
A moins que tu n'ait encore un vieil écran cathodique (ce donc je doute)
il vaut bien mieux configurer ton ordi pour qu'il eteigne l'écran au
bout d'un temps d'inactivité.
Personnellement, je désinstalle systématiquement l'économiseur d'écran a
chaque fois que je met debian sur un ordi. Je ne comprend d'ailleurs pas
qu'une vieillerie caduque comme l'économiseur d'écran soit toujours
installée et activée par défaut dans les distribs. Zut a la fin, on est
au 21e siècle !
Re: Jitsi sur serveur debian/testing
NoSpam a écrit : > Sur la partie apache je ne peux t'aider. Ton apache ne devrait pas > écouter le 443, le 6443 comme dans mon exemple puis faire un proxy_pas > sur jitsi.systelia.fr: en fonction du hostname appelé. À partir de > là cela devrait être fonctionnel. Oui, sauf que ça, c'est impossible. J'ai des utilisateurs qui n'ont d'accessibles que les ports 80 et 443. Donc je fais avec ça. Mon apache écoute sur les ports 80 et 443. jitsi-videobridge écoute sur le 4443. Ça devrait donc fonctionner. J'ai pourtant l'impression qu'il y a un souci côté videobridge puisque : Root rayleigh:[~] > wget https://192.168.254.1:4443 --2020-04-13 15:33:23-- https://192.168.254.1:4443/ Connexion à 192.168.254.1:4443… connecté. GnuTLS: The TLS connection was non-properly terminated. Incapable d’établir une connexion SSL. Root rayleigh:[~] > wget http://192.168.254.1:4443 --2020-04-13 15:36:26-- http://192.168.254.1:4443/ Connexion à 192.168.254.1:4443… connecté. requête HTTP transmise, en attente de la réponse… Aucune donnée reçue. Nouvel essai. --2020-04-13 15:36:42-- (essai : 2) http://192.168.254.1:4443/ Connexion à 192.168.254.1:4443… connecté. requête HTTP transmise, en attente de la réponse… ^C Root rayleigh:[~] > À tout hasard, que donnent ces commandes chez toi ? En remplaçant naturellement le 4443 par 443. JKB
Re: Debian/Sid sur "gros" ordinateur de bureau - plantage économiseur d'écran donc comment vidanger sur disque SSD
Bonjour
Les pistes évoquées ressemblent étrangement à un bug que j'ai rencontré sur une
machine à base de CPU j1900 chez Intel. Apparemment ce processeur a un bug de
conception provoquant des freezes apparemment aléatoires, quand la machine est
peu sollicitée.
La solution était de désactiver dans le BIOS (enfin... L'UEFI) certains niveaux
d'économie d'énergie du CPU (les C-states pour être précis).
Peut être qu'une petite expérimentation a tâtons sur des réglages similaire
pourrait aboutir à une stabilisation du système.
Par contre je trouve fâcheux ce genre de bug, quand ils se trouvent au niveau
du hardware.
Je trouve une explication intéressante des C-states ici :
https://www.dell.com/support/article/fr-fr/qna41893/qu-est-ce-que-le-c-state?lang=fr
J'ignore si ils s'appliquent aux CPU d'AMD, n'en ayant pas utilisé depuis très
longtemps. Mais les C-states étant une réponse à un besoin commun aux deux
fondeurs, il y a des chances que ça existe au moins sous une autre appellation
chez AMD.
Le 13 avril 2020 15:30:26 GMT+02:00, Michel a écrit :
>Le 13/04/2020 à 15:10, Basile Starynkevitch a écrit :
>> Bonjour
>>
>>
>> Ma machine à la maison est une "grosse" machine: AMD Ryzen
>Threadripper
>> 2970WX, carte mère MSI X399 SLI Plus, 64Go de RAM, boitier bien
>ventilé,
>> 12 Tera de disque dont un Samsung SSD 970 EVO 2TB, deux cartes
>> graphiques (AMD Radeon 570 + Nvidia GTX 1050 Ti). Noyau Linux 5.5.0,
>> xorg 2:1.20.8
>>
>> En général, elle est peu chargée. J'y développe actuellement
>> https://github.com/bstarynk/helpcovid/
>>
>> Régulièrement cette machine gèle ("freeze"). Je dois appuyer sur le
>> bouton Reset du boitier (le bouton d'ext Je n'ai pas eu le temps de
>> chercher pourquoi, mais mon intuition est un économiseur d'écran qui
>> plante le noyau ou au moins le serveur Xorg (j'incrimine Nvidia et ou
>un
>> truc OpenGL) lié à XFCE ou MATE. Car chaque fois que ça freez,
>> l'économiseur d'écran tournait!
>>
>>
>
>Bonjour Basile,
>
>J'avais ce type de problème sur un portable ( Asus ROG G53SX, avec
>carte
>Nvidia GeForce GT 560M ), freezes aléatoires là aussi. J'avais testé
>plusieurs choses sans succès, puis j'ai désinstallé light-locker et
>tout
>est rentré dans l'ordre.
>
>Sans garantie, mais ça ne coûte rien d'essayer.
--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma
brièveté.
Re: Lancer une appli graphique en ssh
Le 13/04/2020 à 15:12, ajh-valmer a écrit : > Bonjour, > > Je tente de lancer une appli graphique depuis chez moi (client) > depuis un serveur distant : > > ssh root@ -X xclock > "X11 connection rejected because of wrong authentication. > Error: Can't open display: localhost:10.0" > > J'ai vainement cherché, rien ne fonctionne, c'est désespérant, > dont de lancer sur mon serveur distant xhost + > > Merci d'une piste, d'un tuto explicatif précis... D'habitude je met l'option avant le login@ip, mais je sais pas si ca a une importance. Le transfert de la connexion X est dangereux parce que ca permet de faire du keylogging. Cette option est donc fréquamment désactivée dans la configuration du serveur X. Si c'est le cas sur la machine a laquelle tu essaye de te connecter, c'est normal que ca coince. Tu peux essayer avec l'option -Y a la place de -X. Je te laisse aller voir dans le man ssh quelle est la différence.
Re: Debian/Sid sur "gros" ordinateur de bureau - plantage économiseur d'écran donc comment vidanger sur disque SSD
Le 13/04/2020 à 15:10, Basile Starynkevitch a écrit :
> Bonjour
>
>
> Ma machine à la maison est une "grosse" machine: AMD Ryzen Threadripper
> 2970WX, carte mère MSI X399 SLI Plus, 64Go de RAM, boitier bien ventilé,
> 12 Tera de disque dont un Samsung SSD 970 EVO 2TB, deux cartes
> graphiques (AMD Radeon 570 + Nvidia GTX 1050 Ti). Noyau Linux 5.5.0,
> xorg 2:1.20.8
>
> En général, elle est peu chargée. J'y développe actuellement
> https://github.com/bstarynk/helpcovid/
>
> Régulièrement cette machine gèle ("freeze"). Je dois appuyer sur le
> bouton Reset du boitier (le bouton d'ext Je n'ai pas eu le temps de
> chercher pourquoi, mais mon intuition est un économiseur d'écran qui
> plante le noyau ou au moins le serveur Xorg (j'incrimine Nvidia et ou un
> truc OpenGL) lié à XFCE ou MATE. Car chaque fois que ça freez,
> l'économiseur d'écran tournait!
>
>
Bonjour Basile,
J'avais ce type de problème sur un portable ( Asus ROG G53SX, avec carte
Nvidia GeForce GT 560M ), freezes aléatoires là aussi. J'avais testé
plusieurs choses sans succès, puis j'ai désinstallé light-locker et tout
est rentré dans l'ordre.
Sans garantie, mais ça ne coûte rien d'essayer.
Re: Debian/Sid sur "gros" ordinateur de bureau - plantage économiseur d'écran donc comment vidanger sur disque SSD
Bonjour, Le lundi 13 avril 2020, Basile Starynkevitch a écrit... > Ma machine à la maison est une "grosse" machine: AMD Ryzen Threadripper > 2970WX, carte mère MSI X399 SLI Plus, 64Go de RAM, boitier bien ventilé, 12 > Tera de disque dont un Samsung SSD 970 EVO 2TB, deux cartes graphiques (AMD > Radeon 570 + Nvidia GTX 1050 Ti). Noyau Linux 5.5.0, xorg 2:1.20.8 > En général, elle est peu chargée. J'y développe actuellement Sur les Ryzen (j'ai un Ryzen 5), il y a un problème de gel de la machine lié à un certain état du processeur. J'ai vu des discussions sur les 5 et les 7. Pour le tien, je ne sais pas. Sur noyaux 4.x et 5.x, par ailleurs. Si ça peut être ça, chercher "ryzen linux kernel freeze when idle" par exemple. Chez moi, la solution a été avec le script zenstates.py. -- jm
Re: Jitsi sur serveur debian/testing
Sur la partie apache je ne peux t'aider. Ton apache ne devrait pas
écouter le 443, le 6443 comme dans mon exemple puis faire un proxy_pas
sur jitsi.systelia.fr: en fonction du hostname appelé. À partir de
là cela devrait être fonctionnel.
Ma conf nginx:
server {
# SSL configuration
#
listen 6443 http2 ssl;
listen [::]:443 http2 ssl;
server_name webconf.tootai.net;
location / {
# jitsi-meet le port 443 est utilisé par le serveur turn bbb
ecoute dans ce cas le
# si le serveur turn est désinstallé le port 443 peut à nouveau
être utilisé par nginx
#
proxy_pass https://webconf.tootai.net:;
include include.d/proxy.conf;
}
include include.d/ssl_meetings.conf;
}
Le 13/04/2020 à 15:06, BERTRAND Joël a écrit :
NoSpam a écrit :
Rappelle toi que jitsi utilise le port 443 pour le proxy. Si ton apache
écoute également sur ce port ... Chez moi nginx écoute le 6443 (MV dont
le port 443 de l'extérieur est forwardé sur ce port) et fait proxy_pass
vers le pour jitsi qui utilise également le 80, le 443 pour *son*
proxy_pass et le 4445 pour turn
Je fais le proxy_pass sur le 6443 car j'ai d'autres MV qui utilisent
également le 443, celle ci est en front.
Effectivement, lorsque je regarde ce qu'il se passe par défaut sur les
ports utilisés pas jitsi, j'obtiens des processus qui écoutent sur :443
et :4443.
J'ai donc rajouté dans sip-communicator.properties :
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
Le videobridge écoute donc maintenant sur 4443 (et plus sur 443). Ma
configuration de mod_proxy d'apache est la suivante :
# If you want to use apache2 as a forward proxy, uncomment the
# 'ProxyRequests On' line and the block below.
# WARNING: Be careful to restrict access inside the block.
# Open proxy servers are dangerous both to your network and to the
# Internet at large.
#
# If you only want to use apache2 as a reverse proxy/gateway in
# front of some web application server, you DON'T need
# 'ProxyRequests On'.
#ProxyRequests On
#
# AddDefaultCharset off
# Require all denied
# #Require local
#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server version; "Block" removes all outgoing
Via: headers)
# Set to one of: Off | On | Full | Block
#ProxyVia Off
Je ne vois pas comment le proxy fait le lien entre le port 443 d'apache
et le 4443 de jitsi. J'ai l'impression qu'il manque quelque chose.
J'ajoute donc dans le fichier de conf de jitsi.systella.fr :
ProxyPass / http://localhost:4443/
ProxyPassReverse / http://localhost:4443/
Et ça ne fonctionne toujours pas mieux (mais j'ai une autre erreur) :
[Mon Apr 13 14:59:26.187471 2020] [proxy:error] [pid 1781414]
(111)Connection refused: AH00957: HTTP: attempt to connect to
127.0.0.1:4443 (localhost) failed
[Mon Apr 13 14:59:26.187493 2020] [proxy_http:error] [pid 1781414]
[client 192.168.10.103:58684] AH01114: HTTP: failed to make connection
to backend: localhost, referer: https://jitsi.systella.fr/
Effectivement, dans le fichier de conf du videobridge, j'ai écrit :
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=192.168.254.1
Je modifie donc la conf d'apache :
ProxyPass / http://192.168.254.1:4443/
ProxyPassReverse / http://192.168.254.1:4443/
Nouvelle erreur, mais j'ai l'impression que je progresse :
[Mon Apr 13 15:04:48.096005 2020] [proxy_http:error] [pid 1787092]
(20014)Internal error (specific information not available): [client
192.168.10.103:59084] AH01102: error reading status line from remote
server 192.168.254.1:4443
[Mon Apr 13 15:04:48.096045 2020] [proxy:error] [pid 1787092] [client
192.168.10.103:59084] AH00898: Error reading from remote server returned
by /
Je continue à creuser.
JKB
Lancer une appli graphique en ssh
Bonjour, Je tente de lancer une appli graphique depuis chez moi (client) depuis un serveur distant : ssh root@ -X xclock "X11 connection rejected because of wrong authentication. Error: Can't open display: localhost:10.0" J'ai vainement cherché, rien ne fonctionne, c'est désespérant, dont de lancer sur mon serveur distant xhost + Merci d'une piste, d'un tuto explicatif précis... Bon confinement.
Re: Jitsi sur serveur debian/testing
NoSpam a écrit :
> Rappelle toi que jitsi utilise le port 443 pour le proxy. Si ton apache
> écoute également sur ce port ... Chez moi nginx écoute le 6443 (MV dont
> le port 443 de l'extérieur est forwardé sur ce port) et fait proxy_pass
> vers le pour jitsi qui utilise également le 80, le 443 pour *son*
> proxy_pass et le 4445 pour turn
>
> Je fais le proxy_pass sur le 6443 car j'ai d'autres MV qui utilisent
> également le 443, celle ci est en front.
Effectivement, lorsque je regarde ce qu'il se passe par défaut sur les
ports utilisés pas jitsi, j'obtiens des processus qui écoutent sur :443
et :4443.
J'ai donc rajouté dans sip-communicator.properties :
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
Le videobridge écoute donc maintenant sur 4443 (et plus sur 443). Ma
configuration de mod_proxy d'apache est la suivante :
# If you want to use apache2 as a forward proxy, uncomment the
# 'ProxyRequests On' line and the block below.
# WARNING: Be careful to restrict access inside the block.
# Open proxy servers are dangerous both to your network and to the
# Internet at large.
#
# If you only want to use apache2 as a reverse proxy/gateway in
# front of some web application server, you DON'T need
# 'ProxyRequests On'.
#ProxyRequests On
#
# AddDefaultCharset off
# Require all denied
# #Require local
#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server version; "Block" removes all outgoing
Via: headers)
# Set to one of: Off | On | Full | Block
#ProxyVia Off
Je ne vois pas comment le proxy fait le lien entre le port 443 d'apache
et le 4443 de jitsi. J'ai l'impression qu'il manque quelque chose.
J'ajoute donc dans le fichier de conf de jitsi.systella.fr :
ProxyPass / http://localhost:4443/
ProxyPassReverse / http://localhost:4443/
Et ça ne fonctionne toujours pas mieux (mais j'ai une autre erreur) :
[Mon Apr 13 14:59:26.187471 2020] [proxy:error] [pid 1781414]
(111)Connection refused: AH00957: HTTP: attempt to connect to
127.0.0.1:4443 (localhost) failed
[Mon Apr 13 14:59:26.187493 2020] [proxy_http:error] [pid 1781414]
[client 192.168.10.103:58684] AH01114: HTTP: failed to make connection
to backend: localhost, referer: https://jitsi.systella.fr/
Effectivement, dans le fichier de conf du videobridge, j'ai écrit :
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=192.168.254.1
Je modifie donc la conf d'apache :
ProxyPass / http://192.168.254.1:4443/
ProxyPassReverse / http://192.168.254.1:4443/
Nouvelle erreur, mais j'ai l'impression que je progresse :
[Mon Apr 13 15:04:48.096005 2020] [proxy_http:error] [pid 1787092]
(20014)Internal error (specific information not available): [client
192.168.10.103:59084] AH01102: error reading status line from remote
server 192.168.254.1:4443
[Mon Apr 13 15:04:48.096045 2020] [proxy:error] [pid 1787092] [client
192.168.10.103:59084] AH00898: Error reading from remote server returned
by /
Je continue à creuser.
JKB
Debian/Sid sur "gros" ordinateur de bureau - plantage économiseur d'écran donc comment vidanger sur disque SSD
Bonjour
Ma machine à la maison est une "grosse" machine: AMD Ryzen Threadripper
2970WX, carte mère MSI X399 SLI Plus, 64Go de RAM, boitier bien ventilé,
12 Tera de disque dont un Samsung SSD 970 EVO 2TB, deux cartes
graphiques (AMD Radeon 570 + Nvidia GTX 1050 Ti). Noyau Linux 5.5.0,
xorg 2:1.20.8
En général, elle est peu chargée. J'y développe actuellement
https://github.com/bstarynk/helpcovid/
Régulièrement cette machine gèle ("freeze"). Je dois appuyer sur le
bouton Reset du boitier (le bouton d'ext Je n'ai pas eu le temps de
chercher pourquoi, mais mon intuition est un économiseur d'écran qui
plante le noyau ou au moins le serveur Xorg (j'incrimine Nvidia et ou un
truc OpenGL) lié à XFCE ou MATE. Car chaque fois que ça freez,
l'économiseur d'écran tournait!
J'ai par ailleurs chaque jour le mél automatique suivant:
This message was generated by the smartd daemon running on:
host name: rimski
DNS domain: lesours
The following warning/error was logged by the smartd daemon:
Device: /dev/nvme0, number of Error Log entries increased from 535 to 536
Device info:
Samsung SSD 970 EVO 2TB, S/N:S464NB0KA03837J, FW:2B2QEXE7, 2.00 TB
For details see host's SYSLOG.
De ce que j'en comprends, c'est l'usure normale d'un disque SSD. Quand
je lance (chaque mois) à la main
rimski# smartctl -t short /dev/nvme0n1
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.5.0-1-amd64] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke,
www.smartmontools.org
NVMe device successfully opened
puis
rimski# smartctl -a /dev/nvme0n1
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.5.0-1-amd64] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke,
www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number: Samsung SSD 970 EVO 2TB
Serial Number: S464NB0KA03837J
Firmware Version: 2B2QEXE7
PCI Vendor/Subsystem ID: 0x144d
IEEE OUI Identifier: 0x002538
Total NVM Capacity: 2,000,398,934,016 [2.00 TB]
Unallocated NVM Capacity: 0
Controller ID: 4
Number of Namespaces: 1
Namespace 1 Size/Capacity: 2,000,398,934,016 [2.00 TB]
Namespace 1 Utilization: 297,127,981,056 [297 GB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 002538 5a81b50e6f
Local Time is: Mon Apr 13 14:52:45 2020 MEST
Firmware Updates (0x16): 3 Slots, no Reset required
Optional Admin Commands (0x0017): Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f): Comp Wr_Unc DS_Mngmt Wr_Zero
Sav/Sel_Feat Timestmp
Maximum Data Transfer Size: 512 Pages
Warning Comp. Temp. Threshold: 82 Celsius
Critical Comp. Temp. Threshold: 82 Celsius
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 6.20W - - 0 0 0 0 0 0
1 + 4.30W - - 1 1 1 1 0 0
2 + 2.10W - - 2 2 2 2 0 0
3 - 0.0400W - - 3 3 3 3 210 1200
4 - 0.0050W - - 4 4 4 4 2000 8000
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 0
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 45 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 0%
Data Units Read: 255,508,747 [130 TB]
Data Units Written: 8,230,365 [4.21 TB]
Host Read Commands: 1,555,762,509
Host Write Commands: 82,030,381
Controller Busy Time: 2,108
Power Cycles: 249
Power On Hours: 1,138
Unsafe Shutdowns: 186
Media and Data Integrity Errors: 0
Error Information Log Entries: 536
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Temperature Sensor 1: 45 Celsius
Temperature Sensor 2: 49 Celsius
Error Information (NVMe Log 0x01, max 64 entries)
No Errors Logged
Donc je ne m'inquiète pas. Devrais-je m'inquiéter?
dmesg | grep nvm me donne
[ 1.320357] nvme nvme0: pci function :41:00.0
[ 1.541104] nvme nvme0: missing or invalid SUBNQN field.
[ 1.541204] nvme nvme0: Shutdown timeout set to 8 seconds
[ 1.572816] nvme nvme0: 32/0/0 default/read/poll queues
[ 1.582443] nvme0n1: p2 p3 p4 < p5 >
[ 7.544896] EXT4-fs (nvme0n1p3): mounted filesystem with ordered
data mode. Opts: (null)
[ 7.843577] EXT4-fs (nvme0n1p3): re-mounted. Opts: errors=remount-ro
[ 8.260884] EXT4-fs (nvme0n1p2): mounted filesystem with ordered
data mode. Opts: (null)
[ 8.539560] EXT4-fs (nvme0n1p5): moun
Re: Jitsi sur serveur debian/testing
Rappelle toi que jitsi utilise le port 443 pour le proxy. Si ton apache écoute également sur ce port ... Chez moi nginx écoute le 6443 (MV dont le port 443 de l'extérieur est forwardé sur ce port) et fait proxy_pass vers le pour jitsi qui utilise également le 80, le 443 pour *son* proxy_pass et le 4445 pour turn Je fais le proxy_pass sur le 6443 car j'ai d'autres MV qui utilisent également le 443, celle ci est en front. Le 13/04/2020 à 14:01, BERTRAND Joël a écrit : BERTRAND Joël a écrit : NoSpam a écrit : Une idée: tu pourrais faire l'authentification avec apache .htaccess sans toucher à Jitsi. J'y ai pensé ce matin, mais ça ne me donne pas la souplesse attendue. Sinon, pas d'erreur grossière ? À propos d'erreur, en voici une qui pourrait expliquer des choses (mais je ne vois pas comment l'analyser). Lorsque je tente une création d'une conférence "famille", je me prends ceci dans les logs : [Mon Apr 13 13:49:34.933594 2020] [proxy_http:error] [pid 1602538] (20014)Internal error (specific information not available): [client 192.168.10.103:48388] AH01102: error reading status line from remote server localhost:5280, referer: https://jitsi.systella.fr/famille Bien cordialement, JKB
Re: Jitsi sur serveur debian/testing
BERTRAND Joël a écrit : > NoSpam a écrit : >> Une idée: tu pourrais faire l'authentification avec apache .htaccess >> sans toucher à Jitsi. > > J'y ai pensé ce matin, mais ça ne me donne pas la souplesse attendue. > Sinon, pas d'erreur grossière ? > À propos d'erreur, en voici une qui pourrait expliquer des choses (mais je ne vois pas comment l'analyser). Lorsque je tente une création d'une conférence "famille", je me prends ceci dans les logs : [Mon Apr 13 13:49:34.933594 2020] [proxy_http:error] [pid 1602538] (20014)Internal error (specific information not available): [client 192.168.10.103:48388] AH01102: error reading status line from remote server localhost:5280, referer: https://jitsi.systella.fr/famille Bien cordialement, JKB
Re: Jitsi sur serveur debian/testing
NoSpam a écrit : > Une idée: tu pourrais faire l'authentification avec apache .htaccess > sans toucher à Jitsi. J'y ai pensé ce matin, mais ça ne me donne pas la souplesse attendue. Sinon, pas d'erreur grossière ?
Re: Jitsi sur serveur debian/testing
Une idée: tu pourrais faire l'authentification avec apache .htaccess
sans toucher à Jitsi.
J'ai fais différemment: je n'autorise que certaines salle prédéfinies
avec accès sans mot de passe.
Le 13/04/2020 à 11:23, BERTRAND Joël a écrit :
NoSpam a écrit :
Le 11/04/2020 à 14:49, BERTRAND Joël a écrit :
Bonjour à tous,
J'essaie d'installer jitsi sur l'un de mes serveurs et je sèche. J'ai
besoin d'une authentification (je ne veux pas que n'importe qui puisse
faire n'importe quoi sur un serveur accessible sur internet).
J'ai donc installé les paquets suivants :
- jicofo
- jitsi-meet
- jitsi-meet-prosody
- jitsi-meet-web
- jitsi-meet-web-config
- jitsi-videobridge
et configuré apache en conséquence pour qu'il réponde sur
https://jitsi.systella.fr
Alors attention, le port 443 est réservé par jitsi (dans nginx,
paragraphe stream) pour proxy_pass, Jitsi écoute le
As tu suivi leur tuto ?
https://github.com/jitsi/jicofo/blob/master/README.md#secure-domain
La réponse est oui ;-)
Mais je vais reprendre point par point le howto en question.
J'ai donc créé un fichier /etc/prosody/conf.d/jitsi.systella.fr.cfg.lua
qui contient :
VirtualHost "jitsi.systella.fr"
-- enabled = false -- Remove this line to enable this host
authentication = "internal_plain"
ssl = {
key = "/etc/prosody/certs/jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/jitsi.systella.fr.crt";
}
-- we need bosh
modules_enabled = {
"bosh";
"pubsub";
"ping"; -- Enable mod_ping
}
c2s_require_encryption = false
Component "conference.jitsi.systella.fr" "muc"
storage = "memory"
--modules_enabled = { "token_verification" }
admins = { "fo...@auth.jitsi.systella.fr" }
Component "jitsi-videobridge.jitsi.systella.fr"
component_secret = "xxx"
VirtualHost "auth.jitsi.systella.fr"
ssl = {
key = "/etc/prosody/certs/auth.jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/auth.jitsi.systella.fr.crt";
}
authentication = "internal_plain"
Component "focus.jitsi.systella.fr"
component_secret = ""
L'utilisateur fo...@auth.jitsi.systella.fr existe (avec le bon mot de
passe, j'ai vérifié) puisque je trouve son mot de passe dans le fichier
/var/lib/prosody/auth%2ejitsi%2esystella%2efr/accounts/focus.dat
Dans /etc/apache2/sites-enabled, j'ai un fichier jitsi.systella.fr.conf
de configuration d'apache2:
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
Le fichier de configuration
(/etc/jitsi/meet/jitsi.systella.fr-config.js) contient quant à lui :
var config = {
hosts: {
domain: 'jitsi.systella.fr',
muc: 'conference.jitsi.systella.fr'
},
bosh: '//jitsi.systella.fr/http-bind',
clientNode: 'http://jitsi.org/jitsimeet',
testing: {
enableFirefoxSimulcast: false,
p2pTestMode: false
},
desktopSharingChromeExtId: null,
desktopSharingChromeSources: [ 'screen', 'window', 'tab' ],
desktopSharingChromeMinExtVersion: '0.1',
channelLastN: -1,
enableWelcomePage: true,
enableUserRolesBasedOnToken: false,
p2p: {
enabled: true,
stunServers: [
{ urls: 'stun:stun.l.google.com:19302' },
{ urls: 'stun:stun1.l.google.com:19302' },
{ urls: 'stun:stun2.l.google.com:19302'
Re: économie numérique - Re: prestataire videoconférences en Europe
Le Sun, 12 Apr 2020 13:21:15 +0200, "ajh-valmer" a écrit : > Je lis dans la presse de ce matin : > "Après le covid, la France doit faire repartir sa magnifique industrie au > plus vite". > Mais elle est ou cette industrie ? Ah ça je sais : https://www.les-crises.fr/1000-emplois-supprimes-par-general-electric-lhistoire-dun-piege-americain-et-dune-trahison-francaise-par-jean-charles-hourcade/ https://www.les-crises.fr/jean-michel-quatrepoint-la-vente-dalstom-etait-un-scandale-ecrit-davance/ https://www.les-crises.fr/projet-poseidon-les-naufrageurs-de-lindustrie-navale-francaise-par-marianne/ https://www.liberation.fr/futurs/2013/10/08/alcatel-lucent-histoire-d-un-desastre-industriel_937893 https://www.les-crises.fr/comment-la-france-sest-vendue-aux-gafam-par-tarik-krim/ https://www.les-crises.fr/comment-la-france-a-sacrifie-sa-principale-usine-de-masques-par-benoit-collombat/ Bon, je prends les premiers liens qui me tombent sous la main, mais je peux creuser et étoffer le dossier quand vous voulez. C'est dommage que le crime pour haute trahison ne soit plus sanctionné, ça aurait permis de raccourcir quelques ambitions avec une Sokkomb DIY.
Re: Jitsi sur serveur debian/testing
NoSpam a écrit :
>
> Le 11/04/2020 à 14:49, BERTRAND Joël a écrit :
>> Bonjour à tous,
>>
>> J'essaie d'installer jitsi sur l'un de mes serveurs et je sèche. J'ai
>> besoin d'une authentification (je ne veux pas que n'importe qui puisse
>> faire n'importe quoi sur un serveur accessible sur internet).
>>
>> J'ai donc installé les paquets suivants :
>>
>> - jicofo
>> - jitsi-meet
>> - jitsi-meet-prosody
>> - jitsi-meet-web
>> - jitsi-meet-web-config
>> - jitsi-videobridge
>>
>> et configuré apache en conséquence pour qu'il réponde sur
>> https://jitsi.systella.fr
>
> Alors attention, le port 443 est réservé par jitsi (dans nginx,
> paragraphe stream) pour proxy_pass, Jitsi écoute le
>
> As tu suivi leur tuto ?
>
> https://github.com/jitsi/jicofo/blob/master/README.md#secure-domain
La réponse est oui ;-)
Mais je vais reprendre point par point le howto en question.
J'ai donc créé un fichier /etc/prosody/conf.d/jitsi.systella.fr.cfg.lua
qui contient :
VirtualHost "jitsi.systella.fr"
-- enabled = false -- Remove this line to enable this host
authentication = "internal_plain"
ssl = {
key = "/etc/prosody/certs/jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/jitsi.systella.fr.crt";
}
-- we need bosh
modules_enabled = {
"bosh";
"pubsub";
"ping"; -- Enable mod_ping
}
c2s_require_encryption = false
Component "conference.jitsi.systella.fr" "muc"
storage = "memory"
--modules_enabled = { "token_verification" }
admins = { "fo...@auth.jitsi.systella.fr" }
Component "jitsi-videobridge.jitsi.systella.fr"
component_secret = "xxx"
VirtualHost "auth.jitsi.systella.fr"
ssl = {
key = "/etc/prosody/certs/auth.jitsi.systella.fr.key";
certificate = "/etc/prosody/certs/auth.jitsi.systella.fr.crt";
}
authentication = "internal_plain"
Component "focus.jitsi.systella.fr"
component_secret = ""
L'utilisateur fo...@auth.jitsi.systella.fr existe (avec le bon mot de
passe, j'ai vérifié) puisque je trouve son mot de passe dans le fichier
/var/lib/prosody/auth%2ejitsi%2esystella%2efr/accounts/focus.dat
Dans /etc/apache2/sites-enabled, j'ai un fichier jitsi.systella.fr.conf
de configuration d'apache2:
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
Le fichier de configuration
(/etc/jitsi/meet/jitsi.systella.fr-config.js) contient quant à lui :
var config = {
hosts: {
domain: 'jitsi.systella.fr',
muc: 'conference.jitsi.systella.fr'
},
bosh: '//jitsi.systella.fr/http-bind',
clientNode: 'http://jitsi.org/jitsimeet',
testing: {
enableFirefoxSimulcast: false,
p2pTestMode: false
},
desktopSharingChromeExtId: null,
desktopSharingChromeSources: [ 'screen', 'window', 'tab' ],
desktopSharingChromeMinExtVersion: '0.1',
channelLastN: -1,
enableWelcomePage: true,
enableUserRolesBasedOnToken: false,
p2p: {
enabled: true,
stunServers: [
{ urls: 'stun:stun.l.google.com:19302' },
{ urls: 'stun:stun1.l.google.com:19302' },
{ urls: 'stun:stun2.l.google.com:19302' }
],
preferH264: true
},
analytics: {
},
deploymentInfo: {
}
};
Jicofo tourne :
/usr/lib/jvm/java-8-openjdk-amd64/bin/java ... org.jitsi.jicofo.Main
--host=localhost --domain=jitsi.systella.fr --port=5347 --secret=xx
