FRsAG October 2023

frsag@frsag.org

33 participants
12 discussions

Réflexion sur référentiel identité unique dans environnement Linux, Windows et web
by DUVERGIER Claude 22 Jan '24

22 Jan '24

Bon(soi|jou)r la liste, Je pose ici mes réflexions sur un problème qui, j'espère, parlera à certains (qui l'auront résolu), pourra en aider d'autres (qui l'ont/l'auront un jour). TL;DR : Quels sont les services à utiliser pour pouvoir authentifier des utilisateurs lors d'accès à des dossiers partagés CIFS, des serveurs SSH Linux et des applications Web avec un référentiel unique/centralisé. CONTEXTE : J'ai actuellement l'infrastructure suivante : * Annuaire LDAP sous OpenLDAP : c'est le référentiel unique, il contient utilisateurs/machines (PosixAccount) et groupes (PosixGroup). * Application (web) maison pour alimenter l'annuaire en fonction des embauches/départs (pas de base de données SQL ou autre, tout est dans le LDAP). * Serveur OpenID pour certaines applications web : utilise le LDAP comme source. * Les utilisateurs ont des comptes locaux sur leur stations de travail Windows/Linux (aucune interaction avec le LDAP). Ainsi, les utilisateurs peuvent s'identifier sur : * des application Web qui gèrent nativement LDAP (eg. Moodle, GitLab, GLPI, etc.). * des applications Web sous Apache/Nginx (via mod_authnz_ldap ou nginx-ldap-auth). * des applications Web qui gèrent OpenID. * des serveurs Linux en SSH via nslcd, libnss-ldapd et libpam-ldapd. (Et avoir un carnet d'adresse des collègues dans leur client de messagerie) Chaque application est responsable de qui elle accepte (utilisateur et/ou groupe) et de ce qu'elle lui autorise de faire (l'annuaire LDAP ne contient pas de permissions). PROBLÈMES/LIMITES : Cela fonctionne (bien) depuis des années, mais ne réponds pas aux besoins suivants (arrivés plus tard) : * (Le plus important): le partage de fichiers via CIFS/Samba (car nécessite des attributs spécifiques dans le LDAP). * stocker *facilement* des données complexes dans OpenLDAP (eg. variantes d'avatars/photo, jours de présence sur x semaines) Bonus facultatif : gestion "domaine" des comptes utilisateurs des stations de travail pour qu'ils utilisent les même identifiants lors de l'ouverture de leur session, que je puisse les gérer de manière centralisée, et qu'ils soient même pré-authentifiés sur les serveurs de fichiers. ÉBAUCHE DE SOLUTION : Je pense donc qu'il est temps de tout reprendre à zéro et c'est là que je découvre (car je suis néophyte sur ces questions) : * FreeIPA qui créer un "AD-like" pour machines Linux. * Samba v4 qui intègre désormais son annuaire LDAP et se comporte comme un Active Directory. * D'autres dont j'avais déjà entendu parler sans jamais les utiliser : Kerberos et RADIUS/DIAMETER. J'envisage donc l'architecture suivante : * Application maison pour stocker (dans une base SQL quelconque) les utilisateurs/groupes (+ des infos spécifiques complexes) ET qui alimente l'annuaire avec seulement les infos pertinentes/standardisées (le schéma LDAP sera plus simple et une API REST pourra exposer les autres infos aux applications si besoin). * Serveur d'annuaire LDAP (OpenLDAP, 389DS, le 389DS de FreeIPA, le LDAP de Samba4 ?). * Serveur(s) de fichiers (TrueNAS, OpenMediaVault, etc.) : qui se connectent à l'annuaire LDAP (ou autre forme de confiance/délégation). Si je prends le bonus "domaine" : que me faudrait-il ? Samba4 seul suffirait pour les stations de travail Windows ET Ubuntu ou bien il faudrait Samba4+FreeIPA pour tout couvrir ? L'idée d'avoir un AD Samba4 qui tourne sur Internet ne me plait guère. Et comme les serveurs de fichiers seront de toutes façons dans le LAN, je pense plutôt installer Samba4 en LAN et mettre en place, juste pour les applications web, une copie (synchro à sens unique) vers un OpenLDAP ouvert sur Internet (sans les attributs samba/domaine). Je suis ouvert à : * toute correction si j'ai dit une énormité sans nom * et surtout à toute suggestion d'outil que je n'aurais pas trouvé qui m'aide dans ma quête. Merci

7 6

Des sups ? Lesquelles et pour quel usage ?
by Jarod G. 31 Oct '23

31 Oct '23

Holà la liste, on est en train de réfléchir à la question des supervisions pour une petite infra qui peut être amenée à évoluer. Je dit "des" car on remarque vite que un outil tout en un qui fait tout correctement, bah ça existe tout simplement pas. On réfléchissait à monter donc au moins deux sups. Une sup "infra" qui fait uniquement du SNMP/ICMP pour tout ce qui est réseau/serveurs/vm et une sup "applicative" qui elle va gérer le reste (état nginx, systemd, etc...). Du coup on est en recherche d'idées, sur la partie "infra" on est plutôt familier avec Observium et LibreNMS même si on est pas fermé à autre chose. Quand à la partie "applicative" c'est un peu le flou (mix grafana+influx ?), surtout sur la partie alertes. Avez vous des retex sur des solutions que vous utilisez déjà ? (ou des noms de solutions "entendues" mais jamais testées) Notre seule et unique contrainte dans les solutions est que ça a besoin d'être gratuit (bonus si c'est libre). Jarod G.

9 8

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

FRsAG October 2023