Re: Conseils sur l'utilisation de certificats Letsencrypt
Bonjour Sébastien, J'arrive certainement après la bataille mais acmemgr.sh, compagnon de acme.sh pourrait répondre à ta demande... En tout cas, chez nous, c'est ainsi qu'on l'utilise... et ce pourquoi il a été conçu. La doc et les diagrammes sont assez explicites mais tu peux toujours demander des précisions par [MP]... https://github.com/sowebio/acmemgr.sh Le 26/11/2020 à 12:13, Sébastien Dinot a écrit : Raphaël POITEVIN a écrit : Sébastien Dinot writes: Bof, beaucoup de complications pour rien. Le seul cas de figure où la chose est intéressante, c'est lorsqu'on veut confier à Let's Encrypt la création de certificats pour des machines qui ne sont pas exposées (seul leur nom étant alors publié dans la zone DNS publique). Le « proxy » public dialogue alors avec les serveurs de Let's Encrypt et un outil maison distribue ensuite les certificats sur les machines qui en ont besoin en interne (et bien évidemment, dans ce cas, la résolution DNS interne ne donne pas le même résultat que la résolution DNS externe). Petite question à ce sujet : est-ce que le reverse proxy en front auquel on accède en https renvoie bien les informations chiffrées à la machine cible, sur la quelle je n’ai pas installé le certificat ? J'ai peur de ne pas avoir compris la question ou de m'être mal expliqué dans mon message initial. Il ne s'agit pas ici de mettre en place un (reverse) proxy. Mais seulement une machine mandataire, exposée publiquement et dont la seule fonction est le renouvèlement des certificats. Ces certificats sont ensuite distribués aux machines qui en ont besoin sur le réseau interne. Une rapide recherche sur Internet vient de me montrer qu'il existe pas mal d'articles sur le sujet sur le net, de qualité inégale. Celui-ci me semble pas mal : https://geontech.com/using-letsencrypt-ssl-internally/ J'ai évoqué cette solution car, par design, Let's Encrypt ne peut pas être utilié pour gérer les certificats d'un réseau interne. Sébastien -- Stéphane Rivière Ile d'Oléron - France
Re: Quelle(s) stratégie de sauvegarde?
Merci pour la thread, j'ai à la fois bien rigolé et ensuite j'approuve tous les conseils donnés, mais également les concepts réalistes sur la notion de liberté, et particulièrement de liberté individuelle . Ici (boite + perso) : * En local on-line : un serveur principal (raid/debian/ondulé vrai on-line) au sous sol dans une baie 42U, un serveur de sauvegarde (raid/debian/ondulé vrai on-line) 30 mètres plus loin planqué dans un caisson ventilé dans un grenier en R+2. Tout par Burp (soft libre génial, bien mieux que Bacula), y compris le s stations et les portables (tout sous Penguin quoique Burp gère Windows et le VSS et le mac aussi). Le serveur de sauvegarde gère aussi les sauvegardes des serveurs OVH. * En DC Serveurs OVH dans d'autres DC sauvant les serveurs de prod. * En local off-line (risque foudre, etc...) 3 disques mécaniques qui tournent à raison d'un par semaine pour les répertoires essentiels du serveur principal. AFIO est utilisé, c'est le format bien plus robuste que tar.gz et le plus simple. Le script récupère les logs générés. 3 disques mécaniques qui tournent à raison d'un par semaine pour les seafiles (nous gérons nous mêmes notre drives on-line) et la sauvegarde en DC. AFIO encore. C'est pas si lourd que ça : tout est automatique et logs détaillés en retour et le coté manuel me semble indispensable pour le off-line (les disques partant dans une armoire forte sur place) Toujours multiplier les sauvegardes, les formats, les technologies et les localisations physiques. Faut vraiment avoir eu peur une ou deux fois pour comprendre qu'il faut faire les choses soigneusement :> -- Stéphane Rivière Ile d'Oléron - France
Re: HS : était [Quelle stratégie contre le vol d'un serveur ?]
+1 sur la thread ps: malgré tout, ponctuellement, une défenestration vers du debian, je ne dis jamais non ;) Une défenestration... connaissais pas !!! magnifique :))) PS dans une vie antérieure, passé 8 ans à benner du doze serveur 2K et 2K3 pour du Gnu/Linux Debian avec Xen avec noyau recompilé à l'époque, Samba, Hylafax et Nuts pour la base...
Re: Firefox : défaut inhérents
> s’améliore avec les nouvelles versions plus ou moins >= 50. Faut dire > qu’il a eu beaucoup de changement à avaler avec HTML5 et l’évolution > rapide du JS. Donc il faut être bienveillant et ne pas croire qu’ils ne > voient pas ou ne se préoccupent pas du problème. +1. Les version 64 me semblent un peu mieux. > J’utilise LXDE / Xfce en bureau et ça permet de compenser la petite > mémoire de ma machine. +1. Voire pour les dingues de neXt... Windowmaker, encore sobre, génial quand on a compris. Mais quand on a compris (sic). FF, on critique, certes, c'est du Xul, ça fuit un peu, mais j'ai rien trouvé d'autre, avec les bons plugins, pour mon usage... Après, il y a le fork palemoon, mais bon... c'est pas plus transcendant que ça... Comme FF, ça fuit et c'est un code un peu vieux. Sinon, sur la station principale, ouvert sur 8 fenêtres et 40 onglets par fenêtre (via l'excellent plug-in d'onglets hiérarchiques affichés sur le coté : Tree Style Tab), quand il est trop gros au bout de deux semaines d'utilisation h24 (bouzin jamais arrêté), je le kill à l'arrache (pour ne rien perdre) et le rouvre, un clic pour restaurer toutes les fenêtres et onglets au moment du kill et c'est reparti. Je constate grosso-modo la même chose sous win et OSX. Mieux en 64 qu'en 32, pas parfait, pas trouvé mieux, certains plugins géniaux. -- Stéphane Rivière Ile d'Oléron - France 0xD7F43200.asc Description: application/pgp-keys
Re: Debian + vidéosurveillance
> Cela aurait changé, supporte t'il à présent 20 et + caméras sans soucis ? 1) Faut juste mettre le matos en face... 20 cams, c'est énorme, donc si c'est en 25ips et HD... Perso je tourne à 3/5 ips avec des résolutions au plus juste... Histoire aussi de ne pas consommer les ressources sans raison (et peut-être aussi pour avoir une cam en 4K si nécessaire). 2) On peut déporter (par scripts) la détection de mouvement en récupérant les infos de détection de mouvement directement dans les caméras (via leurs API) Quand à la soluce qui a l'air très complète, Zoneminder peut la gérer, faut juste retrousser ses manches et apprendre... Ce bestiau est complètement scriptable, donc on fait le café, mais y'a un effort à fournir initialement. Si une seule install de ce type avec rien derrière, acheter du tout fait... Si installs récurrentes, intéressant de s'investir. Effectivement, un réseau IP dédié est aussi bien. Et attention, la video ça bouffe, faut tout bien gérer, 'calculer' ses caméras (prendre les bonnes, sic...) Sans compter que si l'on veux une "vision humaine de loin", c'est du 4K impératif... Mais si c'est pour un gros plan de comptoir, du 720 suffit... La videosurveillance, limite, c'est un art. -- Stéphane Rivière Ile d'Oléron - France 0xD7F43200.asc Description: application/pgp-keys
Re: Debian + vidéosurveillance
Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Redémarrer pour la prise en compte. 3.3 Firefox root@system: aptitude install firefox-esr firefox-esr-l10n-fr En affichage « Montage », Firefox a tendance à figer la vidéo au bout de quelques heures. Installer le module : https://addons.mozilla.org/fr/firefox/addon/zoneminder-client (puis personnaliser firefox pour mettre les boutons sur une seule ligne à gauche de la zone d'URL par exemple ou modifier la configuration de firefox via about:config : browser.cache.check_doc_frequency 3 -> 1 browser.cache.disk.enable True -> False browser.cache.memory.enable -> False network.http.use-cache -> False network.http.max-connections-per-server -> 100 network.http.max-persistent-connections-per-proxy -> 100 network.http.max-persistent-connections-per-server -> 100 Des notes sur ce problème sont disponibles ici : https://forums.zoneminder.com/viewtopic.php?t=5066 Installer lanceur Firefox, avec le chemin : localhost/zm 3.4 zmNinja root@system: aptitude install libnotify-bin libconf-2-4 libnss3 Télécharger le binaire de zmNinja sur : https://github.com/pliablepixels/zmNinja/releases Installer l'arborescence du binaire dans /home//zmNinja Appliquer les droits sur /home//zmNinja Paramétrer le lanceur et cocher le démarrage automatique. https://github.com/pliablepixels https://github.com/pliablepixels/zmeventserver https://github.com/pliablepixels/ZoneMinderFoscamHDTrigger https://github.com/pliablepixels/zmhacks -- -- Stéphane Rivière Ile d'Oléron - France 0xD7F43200.asc Description: application/pgp-keys
Re: Log des connexions sortantes NATées
> 1. En effet, le firewall est un simple script iptables. C'est (imho) ce qu'il y a de mieux : clarté, franchise et simplicité :) Et puis ça force à "maîtriser" (un bien grand mot pour moi) le routage linux et netfiler/iptables (mouarf). > 2. J'ai essayé de logguer à la main ce que je souhaitais mais dans le > laps de temps imparti, je n'ai pas réussi à logguer ce que je voulais: > 1 seule ligne par connexion avec l'IP source, l'IP NATée et l'IP de > destination. > J'avoue aussi être affolé par le nombre de connexions ouvertes par la > simple navigation vers une page web. > Faut-il tout conserver ? Je ne connais pas le cahier des charges. Pour une fonction "sarkozy" conforme à la loi de 2006, j'avais creusé à l'époque et ma problématique était surtout d'associer un nom, une personne, avec un trafic (que j'avais résumé aux URL rendues par SQUID). Ca se règle simplement aujourd'hui avec un numéro de tel et un sms renvoyant le code. A l'époque, c'était plus compliqué. Mais j'ai pas eu de souci à l'usage, ça semblait coller (2 clients environ, sur l'île d'Oléron, de 2007 à 2013). Pour une fonction se limitant à un matériel d'un coté (donc une IP) et à un trafic complet (si j'ai bien suivi), quelque soit le port, ça devient honteux en terme de volume, et j'envisagerai de logguer directement dans un flux compressé - avec seulement, hors de la compression, les clés de recherches - heure, IP, etc...), le tout idéalement dans un babasse gérant les BD temporelles (Postgresql fait ça). Maintenant, ça me semble important à dev, je suppose qu'on devrait trouver du 'tout fait'. > Si oui, comment limiter la masse d'informations ? Oui, effectivement, quand je bricole, j'introduis des limitations dans les logs, histoire de ne pas être submergé... Ta problématique est intéressante. Je commencerais par bien fouiller le web anglophone, regarder comment les "portails captifs WIFI" s'y prennent désormais pour ça (regarde peut-être du coté de Alcazar, c'est un truc français que j'aurais bien aimé avoir dispo à l'époque au lieu d'avoir à tout faire dans mon coin)... > 3. C'est clair que les log de squid peuvent être précieux d'autant > qu'il existe plusieurs outils d'analyse des logs mais est-ce toujours > pertinent avec https quand on ne contrôle pas la configuration des PC ? > Qu'en penses-tu ? D'autant plus que si SQUID te sors des logs propres et exploitables facilement, quid des autres trafics et protocoles... Si tout doit être loggué, ça va être un projet à part entière, à moins que tu ne trouves un "truc tout fait" (et ça m'intéresserait aussi)... > PS: Pas de soucis de ma part pour que la réponse passe par la mailing > list debian. Je me suis fait avoir avec le reply/reply-to-list... Faut absolument que je trouve comment contrer cette "fonctionnalité" de thunderbird (en fonction des headers de telle ou telle liste, le "répondre" réponds à la personne et non pas à la liste :) -- Stéphane Rivière Ile d'Oléron - France 0xD7F43200.asc Description: application/pgp-keys
