- FRsAG - frsag.org

Web version mobile sur MacOS....
by David Ponzone 25 Oct '23

25 Oct '23

Aux gurus du web, Ca fait un moment que ça me turlupine, et il est temps que je comprenne. J’ai certains sites qui s’affichent systématiquement dans leur version mobile, alors que je suis sur Safari MacOS. Par exemple: https://www.yealink.com/en/product-detail/ip-phone-t48u <https://www.yealink.com/en/product-detail/ip-phone-t48u> Même si j’ouvre une fenêtre privée et que je change le User-Agent pour Chrome Windows…. Si je l’ouvre avec Chrome MacOS, c’est bon. Une idée ? Ils ont un mécanisme (foireux) de détection du navigateur qui outrepasse le User-Agnt et se plante ? Merci David

3 4

[TECH] Fiabilité Lanner (problème démarrage sur FW-7551)
by DUVERGIER Claude 23 Oct '23

23 Oct '23

Bonjour, Un de nos routeur basé sur un mini-ordi/appliance Lanner FW-7551 (Atom C2000) [1] a planté ce week-end. Il ne réponds plus et il n'y aucune sortie sur le port console. Le by-pass réseau semble fonctionner (pas testé mais les LEDs de port réseau semblaient le confirmer). Le crash semble être matériel : le disque est OK (mais il faut que je teste la RAM). Le fichier de /var/crash/info.0 (récupéré sur le système FreeBSD) indique clairement qu'un problème va survenir : Dump header from device: /dev/gpt/swapfs Architecture: amd64 Architecture Version: 4 Dump Length: 156160 Blocksize: 512 Compression: none Dumptime: 2023-10-21 17:44:55 +0200 Hostname: router.example.com Magic: FreeBSD Text Dump Version String: FreeBSD 13.2-RELEASE-p3 stable/23.7-n254799-01e2d59d337 SMP **Panic String: NMI indicates hardware failure** Dump Parity: 3771926898 Bounds: 0 Dump Status: good Le système est repartit sur le matériel de réserve mais je m'étonne de ce genre de panne (matériel normalement plutôt fiable) et de n'avoir aucune sortie sur le port console, ni même de bip ou LED de diagnostic. Chose étonnante : il devrait ne devrait normalement pas s'allumer (du moins tenter) dès qu'on le branche au secteur mais c'est pourtant ce qu'il fait. Une idée de comment diagnostiquer tout ça ? Au moins histoire de comprendre car j'ai déjà entamé les recherches pour un remplaçant. Merci et bon début de semaine. [1]: https://www.lannerinc.com/products/network-appliances/x86-desktop-network-a… -- Duvergier Claude

2 1

squid sur ovh
by Dang Herve 16 Oct '23

16 Oct '23

Bonjour Je n'arrive plus depuis un moment de configurer un serveur squid sur du dédiée OVH J'ai les erreurs suivantes: sendto FD 12: (1) Operation not permitted ipcCreate: CHILD: hello write test failed Quelqu'un aurait une idée de qui est devenu spécifique chez eux ? Merci Hervé

4 5

[TECH] Traefik et multi-network
by Olivier Vailleau 16 Oct '23

16 Oct '23

Salut les gens, Ça faisait quelques temps que je n'avais pas posté sur cette liste. C'était plutôt signe que tout allait bien, mais le sort en a décidé autrement ! J'ai tenté d'utiliser l'outil Traefik pour publier mes containers. Tout marchait bien en test, et hop, je part en prod. Hélas, je sui sconfronté à un souci : Mes containers ont plusieurs réseaux : un dédié au "front" Traefik et un dédié à la machinerie de l'appli (relier l' apache à la bdd, etc). Traefik est censé repérer la bonne conf réseau grâce aux labels - traefik.docker.network=front_network Cependant, il pioche au hasard dans les réseaux du container et pointe souvent sur le mauvais. Est-ce que quelqu'un a déja rencontré ce souci ? bien à vous ! Olivier.

3 3

Greylisting par Offic365 ce matin ?
by David Ponzone 12 Oct '23

12 Oct '23

Hello, Je suis le seul à m’être fait greylisté depuis ce matin par les serveurs outlook.com <http://outlook.com/>, ou c’est pas isolé ? (Réponse:451 4.7.500 Server Busy, retry later) Merci David

11 27

Re: sip, xmpp, communication interopérable : et si on essayait?
by dlorah＠ik.me 09 Oct '23

09 Oct '23

bonjour personnellement j'ai été presque deux ans sur matrix, et le constat est très décevant : **le client lourd est justement assez lourd, pas compatible avec les anciens systèmes (oui, on peut utiliser sip ou xmpp sur de l'android 4, et meme sur ordi sur d'autres anciens systèmes), donc cette compatibilité serait remise en cause l'interface web jongle entre : **lourdeur extraordnaire, d'autres avis sur les forums me disent avoir abandonné cette messagerie car clairement elements fait ramer leur ordi (le mien aussi) **très souvent les messages reçus sont chiffrés, et ya un gros bug là dessus : plusieurs fois on m'a recommuniqué un message qui est à nouveau arrivé indéchiffrable, bien que le login session + mdp de déchiffrement ait été entrés **manque de simplicité, qui dissocie l'id/mdp de la session, à celui du déchiffrement : ca plaira indéniablement aux plus geeks, mais à la longue ca peut être considéré comme handicapant (j'ai eu des retours en ce sens) **le serveur en lui meme est également très consommateur : cf https://lukesmith.xyz/articles/matrix-vs-xmpp/ https://djan-gicquel.fr/matrix-vs-xmpp ayant testé ce matrix pendant presque deux ans, j'ai immédiatement préféré xmpp, standardisé, plus léger, pratique et flexible/souple ya eu un débat dessus : https://linuxfr.org/users/tkr/journaux/petit-topo-des-messageries-securisee… https://forum.hardware.fr/hfr/gsmgpspda/android/application-messagerie-secu… Le 2023-10-06T23:12:32.000+02:00, nathanael(a)isidorus.fr <nathanael(a)isidorus.fr> a écrit : > Salut, > > Je partage bien ton analyse. Par contre après avoir utilisé xmpp > quelques années je lui ai préféré Matrix. Principalement pour le > fait qu'il existe des clients stables, cohérents et globalement > simples à utiliser sur toutes les plateformes. Accessoirement > j'apprécie de pouvoir agréger plusieurs messagerie en une via les > bridges (SMS, signal et whatsapp). > > On en parle un peu dans le collectif chantons.org > [http://chantons.org] sur le forum et ici > https://matrix.to/#/#chatons-messageries:sans-nuage.fr > [http://sans-nuage.fr] > > Quant au sujet de l'interroperabilité, j'ai beaucoup apprécié > cette démonstration : > https://www.youtube.com/watch?v=FDnUJXzVn3s&t=3715s lors d'une > session de travail autour du DMA, à Bruxelles, une demo de bridges > entre whatsapp et Google chat, et Matrix, avec lesdits bridges > tournant sur le client, permettant donc de (presque) conserver les > chiffrement de bout en bout. Le tout en présence de représentants > de messagerie précitées. Pour aller plus cet article de blog > raconte en détail le travail de mise en place du DMA > https://matrix.org/blog/2023/03/15/the-dma-stakeholder-workshop-interoperab… > > Bonne soirée, > -- > Nathanaël H > > Le 6 octobre 2023 18:08:15 GMT+02:00, "Loïs Poujade" > <frsag(a)lpo.host> a écrit : > >> Salut, >> >>> d/ anticiper l'exigence EU d'appliquer une interopérabilité >> entre les messageries (qui ne se fera sans doute"certainement >> "exclusivement entre géants", donc bye le jabber associatif >> local) >> >> Qu'est ce qui te fait dire ça ? Je connais pas les détails de >> cette exigence mais je pensais naïvement que le but était >> justement d'obliger ces géants à proposer un genre d'API pour >> permettre aux petits de s'interconnecter avec eux et casser un peu >> les quasi-monopole >> >> Loïs >> >> Le 6 octobre 2023 17:28:32 GMT+02:00, dlorah--- via FRsAG >> <frsag(a)frsag.org> a écrit : >> >>> bonjour, >>> >>> Au vu des quelques frasques de whatsapp ces dernières années >>> (vie privée, pannes..) et du fait que ses concurrents >>> principaux (signal, telegram, olvid, threema, wire, >>> viber......[...]...) resteront sans doute non intéropérables, >>> et les dents ascérées jusqu'à la disparition/exode de l'un >>> d'eux vers un autre, j'envisageais de prendre les devants dans >>> mon entourage proche et moins proche, pour justement "avoir une >>> fenêtre de tir". >>> >>> les raisons sont les suivantes : >>> >>> a/ la confidentialité et protection de la vie privée, ne pas >>> avoir l'impression d'appartenir à un mastodonte >>> >>> b/ les échanges possibles entre différents serveurs/infras, >>> avec xmpp ou sip >>> >>> c/ la résistance technique en cas de panne d'un presta (les >>> autres restent fonctionnels) >>> >>> d/ anticiper l'exigence EU d'appliquer une interopérabilité >>> entre les messageries (qui ne se fera sans doute"certainement >>> "exclusivement entre géants", donc bye le jabber associatif >>> local) >>> >>> cela porte à interrogation, notamment pour les futures >>> générations (ou les actuelles) qui ne sont pas encore >>> habituées de ce genre de moyens de communication, ou qui >>> envisageraient de changer de crèmerie. >>> >>> pour rappel, je pense au sip/xmpp, car de base il est de ce que >>> j'appelle "fédéré", au meme titre que les échanges de >>> courrier électroniques : >>> >>> il suffit que sip:alice@domain.net appelle bob(a)domain.org pour >>> que cela fonctionne >>> >>> le schéma est décalqué sur celui de l'email (ou inversement?) >>> >>> pour sip et xmpp, la schématique est la même, le contenu >>> (spécialiste de la voix pour l'un, voix/messagerie pour >>> l'autre) diffère un peu. >>> >>> les avantages à "encourager" à rejoindre un tel système : >>> >>> -redondance aux pannes : si whatsapp &consors sont indispo, >>> xmpp/sip ne sont pas limités à 1 infra >>> >>> -respect de la vie privée plus solide >>> >>> -fédéré, interopérable aux fournisseurs de services tiers >>> (en gros plus besoin d'installer/ouvrir un compte chez un autre >>> presta de services) >>> >>> -prêt aux réseaux 100% données/data de demain, pouvant palier >>> un premier temps aux appareils non volte >>> >>> -application quicksy pensée pour simplifiée avec un simple no >>> de tel >>> >>> -communications sip possiblement gratuites depuis un tel >>> fixe/portable via passerelles >>> >>> A titre personnel je ne vois que de beaux avantages sur le plan >>> technique. Un peu comme quand j'ai découvert les emails, cela >>> avait de quoi mettre sous le charme. Maintenant, sur le plan >>> pratique, deux énormes inconvénients viennent démolir, ce qui >>> partage le même schéma que l'email (qui le rends cela dit, >>> détesté): >>> >>> -inscription souvent fastidieuse : choisir (le bon) fournisseur, >>> un mdp associé, le 2FA si nécessaire (pas présent sur >>> xmpp/sip, excepté quicksy) >>> >>> -risques conséquents de spam/escroqueries si cette techno est >>> adoptée massivement, à l'instar de telegram/signal/whatsapp(?) >>> >>> cependant, je vois bien les choses : >>> >>> **les grandes masses habituées aux "datavores" 100% >>> urbains/connectés en auront rien à foutre, aiment payer pour >>> une simplciité (ces profils apprécient aussi les réseaux des >>> géants : twitter, gm, facebook...) >>> >>> **les plus prudents, conscients qu'utiliser ces derniers >>> services, souvent de qualité, les possèdent/enferment des >>> années, et ne permettent aucun recours en cas de probleme >>> (allez débannir un compte fb/whapp/gm/twi..) >>> >>> il est à noter qu'il est probable que xmpp ait servi de >>> tremplin à whatsapp, signal, duo/meet et consors (peut être >>> rcs), tout comme SIP est utilisé dans teams, au travers de la >>> volte, ou plus simplement par les opérateurs sur des réseaux >>> fermés ; l'intérêt justement de "dévulgariser la chose" >>> serait de faire adopter sip/xmpp par le grand public (et les >>> pros), de manière ouverte, à ce que les communications ne >>> soient pas exclusivement utilisées au travers des services >>> opérateurs (facturées), mais "controlées" par les >>> utilisateurs directement (comme l'email) >>> >>> je pense fortement que la gent geek/nerd/passionnés/ingés a un >>> role a jouer, un peu comme elle a recommandé signal lors de de >>> l'exode whatsapp, mais qu'il est évident que si personne ne >>> s'investit dans cette sensibilisation (à l'instar des GUL), le >>> choix se portera à nouveau sur les géants.. >>> >>> voilà, à vos idées, suggestions, remarques, etc.. > > -- > Nathanaël > Envoyé depuis /e/OS Mail.

1 0

sip, xmpp, communication interopérable : et si on essayait?
by dlorah＠ik.me 09 Oct '23

09 Oct '23

bonjour, Au vu des quelques frasques de whatsapp ces dernières années (vie privée, pannes..) et du fait que ses concurrents principaux (signal, telegram, olvid, threema, wire, viber......[...]...) resteront sans doute non intéropérables, et les dents ascérées jusqu'à la disparition/exode de l'un d'eux vers un autre, j'envisageais de prendre les devants dans mon entourage proche et moins proche, pour justement "avoir une fenêtre de tir". les raisons sont les suivantes : a/ la confidentialité et protection de la vie privée, ne pas avoir l'impression d'appartenir à un mastodonte b/ les échanges possibles entre différents serveurs/infras, avec xmpp ou sip c/ la résistance technique en cas de panne d'un presta (les autres restent fonctionnels) d/ anticiper l'exigence EU d'appliquer une interopérabilité entre les messageries (qui ne se fera sans doute"certainement "exclusivement entre géants", donc bye le jabber associatif local) cela porte à interrogation, notamment pour les futures générations (ou les actuelles) qui ne sont pas encore habituées de ce genre de moyens de communication, ou qui envisageraient de changer de crèmerie. pour rappel, je pense au sip/xmpp, car de base il est de ce que j'appelle "fédéré", au meme titre que les échanges de courrier électroniques : il suffit que sip:alice@domain.net appelle bob(a)domain.org pour que cela fonctionne le schéma est décalqué sur celui de l'email (ou inversement?) pour sip et xmpp, la schématique est la même, le contenu (spécialiste de la voix pour l'un, voix/messagerie pour l'autre) diffère un peu. les avantages à "encourager" à rejoindre un tel système : -redondance aux pannes : si whatsapp &consors sont indispo, xmpp/sip ne sont pas limités à 1 infra -respect de la vie privée plus solide -fédéré, interopérable aux fournisseurs de services tiers (en gros plus besoin d'installer/ouvrir un compte chez un autre presta de services) -prêt aux réseaux 100% données/data de demain, pouvant palier un premier temps aux appareils non volte -application quicksy pensée pour simplifiée avec un simple no de tel -communications sip possiblement gratuites depuis un tel fixe/portable via passerelles A titre personnel je ne vois que de beaux avantages sur le plan technique. Un peu comme quand j'ai découvert les emails, cela avait de quoi mettre sous le charme. Maintenant, sur le plan pratique, deux énormes inconvénients viennent démolir, ce qui partage le même schéma que l'email (qui le rends cela dit, détesté): -inscription souvent fastidieuse : choisir (le bon) fournisseur, un mdp associé, le 2FA si nécessaire (pas présent sur xmpp/sip, excepté quicksy) -risques conséquents de spam/escroqueries si cette techno est adoptée massivement, à l'instar de telegram/signal/whatsapp(?) cependant, je vois bien les choses : **les grandes masses habituées aux "datavores" 100% urbains/connectés en auront rien à foutre, aiment payer pour une simplciité (ces profils apprécient aussi les réseaux des géants : twitter, gm, facebook...) **les plus prudents, conscients qu'utiliser ces derniers services, souvent de qualité, les possèdent/enferment des années, et ne permettent aucun recours en cas de probleme (allez débannir un compte fb/whapp/gm/twi..) il est à noter qu'il est probable que xmpp ait servi de tremplin à whatsapp, signal, duo/meet et consors (peut être rcs), tout comme SIP est utilisé dans teams, au travers de la volte, ou plus simplement par les opérateurs sur des réseaux fermés ; l'intérêt justement de "dévulgariser la chose" serait de faire adopter sip/xmpp par le grand public (et les pros), de manière ouverte, à ce que les communications ne soient pas exclusivement utilisées au travers des services opérateurs (facturées), mais "controlées" par les utilisateurs directement (comme l'email) je pense fortement que la gent geek/nerd/passionnés/ingés a un role a jouer, un peu comme elle a recommandé signal lors de de l'exode whatsapp, mais qu'il est évident que si personne ne s'investit dans cette sensibilisation (à l'instar des GUL), le choix se portera à nouveau sur les géants.. voilà, à vos idées, suggestions, remarques, etc..

2 2

candidature pour un stage à partir du 30 janiver 2024
by Martin Guerout 06 Oct '23

06 Oct '23

Mesdames et messieurs, Je vous contacte dans le cadre de ma recherche de stage de 4e année en école d'ingénieur. Je recherche un stage à partir du 30 janvier 2024 au 30 juillet 2024 en Ile de France, dans le domaine de l'administration système. Si votre entreprise recrute je serai ravi de vous envoyer un CV ainsi qu'une lettre de motivation. En l'attente de vos réponses je reste à votre disposition pour toute information complémentaire et vous prie de passer une agréable journée, Très cordialement, Martin Guerout

1 0

Re: Proxmox et GPU
by Vincent Tondellier 05 Oct '23

05 Oct '23

Bonjour, On jeudi 5 octobre 2023 16:59:28 CEST, Ronan Dily wrote: > Est-ce que quelqu’un parmis vous a déjà expérimenté le vGPU ou > GPU passthrought avec proxmox ? Oui pour les 2 avec qemu/kvm sans la surcouche proxmox, mais ca ne change pas grand chose. Ce qui est en dessous ne concerne pas le passthrough (dédier UNE carte a UNE VM), qui fonctionne depuis longtemps sans aucune bidouille (du moins sur les quadro) ni licence, juste un peu de configuration pour changer le driver vers vfio-pci (chercher vfio pour les tutos). > J’ai des Nvidia T16 que je veux monter sur des RDSH. > > Je découvre l’histoire des licences GRID, le vgpu_unlock… et > tout ça n’est pas très clair. > Est-ce que le gpu_unlock ne concerne que les gpu grand public > type RTX1000 ou RTX2000 ? Oui, c'est seulement pour les grand public et les Quadro également. Les Tesla sont prévues pour le vGPU, pas besoin de faire sauter la limitation logicielle (mais ca permet certaines choses comme changer la quantité de vRAM en dehors des valeurs fixées par nvidia). Attention, les dernières générations ont changé de mode de virtualisation (PCIe natif) et ne sont plus supportées par vgpu unlock. > Est-ce que le gpu_unlock permet de s’affranchir des licences GRID ? vgpu_unlock en lui même non, il faut toujours un serveur de licence. pour une des réponses a cette question voir https://gitlab.com/polloloco/vgpu-proxmox/-/issues/13 et le tuto complet aussi ... https://gitlab.com/polloloco/vgpu-proxmox

1 0

[FRSaG][JOBS] Recherche ingénieur sys/net/sec Strasbourg
by Philippe 04 Oct '23

04 Oct '23

Hello la liste, Après 15 ans dans l'entreprise AxesSim, je laisse ma place pour voir un peu autre chose. L'entreprise recherche donc mon remplaçant, si possible un profil geek et très orienté Open-source. Je pense que poster ici est la meilleure chose possible pour recruter ce genre de profil :) Le poste est à pourvoir juste à côté de Strasbourg (Illkirch). N'hésitez pas à m'écrire directement pour toute question ou sur des détails techniques. Voici l'annonce : En tant qu'Ingénieur système, réseau et sécurité, vous serez responsable de la conception, de la mise en œuvre et de la gestion des infrastructures majoritairement Linux et comprenant quelques Microsoft Windows au sein de notre entreprise. Vos principales missions comprendront : • Installer, configurer et maintenir les systèmes d'exploitation et les services associés. • Assurer la disponibilité, la performance et la sécurité des serveurs et stations de travail. • Gérer et optimiser les environnements de virtualisation basés sur Linux, tels que KVM (Proxmox) ou Xen. • Surveiller et résoudre les problèmes liés aux performances, à la sécurité et à la stabilité des systèmes. • Collaborer avec les équipes de développement et d'infrastructure pour déployer et maintenir les applications sur les serveurs et stations de travail. • Participer à l'élaboration et à la mise en œuvre des politiques de sécurité et des bonnes pratiques pour les systèmes. • Fournir un support technique aux utilisateurs et résoudre les problèmes techniques liés aux environnements hétérogènes. • Intégrer en partie l’équipe BUILD en tant que devops. Profil candidat: Passionné et geek dans l’âme, vous aimez tout ce qui touche à l’open-source dans l’informatique et les technologies. Solide expérience dans l'administration et la gestion des systèmes d'exploitation Linux (Debian, Ubuntu, CentOS etc.) ainsi qu’un minimum d’expérience dans l’administration d’un domaine Active Directory (Samba4) pour le système d’exploitation Microsoft Windows. Maîtrise des outils et des technologies associés à l'environnement Linux, tels que les services réseau, la gestion des utilisateurs, les systèmes de fichiers. • Connaissance approfondie des environnements de virtualisation basés sur Linux. • Bonnes connaissances en sécurité des systèmes Linux et en durcissement des serveurs et des stations de travail. • Bonnes connaissances en sécurité réseaux • Capacité à diagnostiquer et à résoudre les problèmes système complexes. • Bonnes compétences en communication et en travail d'équipe. • Capacité à gérer plusieurs tâches simultanément et à respecter les délais. Technologies et outils utilisés, liste non exhaustive: Pfsense, OPNSense, OpenVPN, CEPH, Infiniband, Proxmox/PBS, KVM, Ubuntu, Debian, CentOS, Samba4/LDAP, Gitlab, Jenkins, Nagios, odoo, zimbra, Ossec-HIDS, Prometheus/Grafana, SLURM. Nous vous proposons : Poste à temps plein (39h), statut cadre RTT, télétravail partiel possible Mutuelle d'entreprise Tickets restaurant Prime de vacances Intéressement annuel, Plan d'Epargne Groupe Rémunération : entre 40 - 60 k€ de part fixe selon profil ( plus part variable sur objectifs)

1 0