[FRsAG] Re: Problème avec FIrefox ?

2022-01-13 Par sujet Michel Blanc

Le 13/01/2022 à 10:14, Frantz de Germain a écrit :

Bonjour,

avez-vous remarqué des problèmes avec Firefox depuis ce matin ?

On est plusieurs au boulot à avoir des problèmes de navigation qui ne
fonctionne pas avec Firefox. J'ai fait quelques tests et c'est très étrange :
ça ne dépend ni de l'OS (idem WIndows ou Linux), ni du réseau dans lequel on
se trouve (vpn, FAI), ni de la version de Firefox. La navigation fonctionne
avec les autres navigateurs.
Après relance ou crash de Firefox, ça refonctionne parfois.

Cordialement.




Souci de http3 visiblement.

https://twitter.com/jbaiter_/status/1481543050438619139

M
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

Re: [FRsAG] Retours sur galera cluster mariadb

2020-06-25 Par sujet Michel Blanc
Le 25/06/2020 à 09:00, Julien - ISWT a écrit :
> Est-ce qu'il existe un équivalent au MySQL Router pour Galera ou
> finalement le front HAProxy est la solution la plus simple?

Oui il y a https://proxysql.com/

Attention, bien que haproxy puisse faire loadbalancer TCP, il ne sait
pas faire du R/W splitting MySQL (sauf développement récent que j'aurai
loupé ou extension en LUA peut être ?). C'est l'application qui doit
choisir vers quel front haproxy elle doit envoyer sa query.


M
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Retours sur galera cluster mariadb

2020-06-25 Par sujet Michel Blanc
Le 24/06/2020 à 21:48, open doc a écrit :
> Bonjour,
> 
> nous devons updater notre vieux cluster master/slaves en mariadb. On
> étudie la possibilité d'intégrer galera cluster mariadb. J'aurai aimé
> avoir quelques retours sur la techno. En êtes-vous satisfait ? il y a
> t'il des choses sur lesquels il faut absolument faire attention ?

TL;DR: je ne mettrai du galera aujourd'hui uniquement en cas de
problèmes de performances en lecture sur un workload avec un
r/w ratio > 99%


C'est assez difficile de répondre sans connaître ton besoin ni les
motivations sur Galera.

En complément des réponses précédentes:

Galera a un mécanisme de "certification" des transactions: avant chaque
write, il va aller causer à tous les noeuds du cluster pour voir s'ils
sont d'accord pour exécuter ce write; en cas de souci ton write va
échouer; donc le RTT entre chaque noeud conditionne directement tes
performances en write (donc au final un impact majeur en perfs sur les
writes).

Pour éviter un échec des transactions, la technique habituelle est de
write sur un seul noeud; et là, problème. Soit ton application est
intelligente et sait faire elle même le R/W splitting, soit tu dois
mettre un proxy qui parle MySQL au milieu (haproxy ne suffit pas, tu
peux effectivement faire un front end "read" et un autre "write", mais
il ne peut pas décider seul ce qui est un read et ce qui est un write).

ProxySQL sait bien faire ça, mais ça n'est pas trivial à mettre en œuvre
correctement, notamment en cluster. Et si tu n'as qu'une instance de
loadbalancer, tu as seulement déplacé ton SPOF.

Chez nous on posait en général un ProxySQL (pas en cluster, indépendant)
sur chaque frontal et les apps pointaient localement sur ce proxy.

Maintenant, avec le recul (et dans notre contexte), je trouve que
l'impact en perfs de Galera et toute la machinerie annexe nécessaire
pour que ça marche bien (r/w splitting, failover, ...) vaut rarement le
coup. C'est intéressant si tu as un workload *très fortement READ*
(genre > 99%). Et même dans ce cas, c'est probablement aussi bien de
partir sur un setup primary/replica normal avec une bonne procédure de
failover et des LB au milieu.

Par ailleurs ça nous a rarement sorti le cul des ronces en prod (plutôt
l'inverse). On a parfois pu switcher des applis sur un autre noeud à
cause d'un souci, mais on est pas sur que ce souci n'ait pas été causé
par Galera en premier lieu.

Pour décider, tu as probablement intérêt à monter une maquette et
rejouer des slow querylogs de ton infra actuelle dessus pour voir ce que
ça donne, et te familiariser avec les procédures de recovery (bootstrap
de cluster, grastate.dat, etc...) avant de plonger dedans.


Bonne chance
---
M

___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Ticketing et "timer"

2020-03-30 Par sujet Michel Blanc
Le 30/03/2020 à 15:43, Arnaud Launay a écrit :
> Bonjour,
> 
> - tourne sous Linux
> - la techno on s'en fiche, on préférerait que ce soit léger, mais
>   si c'est une usine à gaz comme gitlab mais qui fait le travail,
>   ainsi soit-il. Jira on a regardé, mais les rares modules de
>   timetracking ne nous ont pas semblé adaptés, souvent difficile
>   de tester ceci dit.
>   Dans l'idéal, du PHP/MySQL ça nous arrangerait, ça demeure
>   simple, on maîtrise parfaitement, et on aurait rien à faire de
>   plus pour que ce soit installable et backupé... Du coup de
>   notre point de vue, c'est léger. Néanmoins, s'il faut du
>   nginx/passenger/postgresql, on fera aussi.
> - payant ou non. On préfère de l'opensource, mais si le prix est
>   raisonnable, pourquoi pas.
> - possibilité pour les utilisateurs de se connecter en web,
>   suivre leurs tickets et y répondre
> - possibilité de répondre par mail et que ce soit assigné au bon ticket
> 
> - ET LA @#¡! de possibilité de suivi temporaire.
>
Hello,

Alors ça colle pas trop aux specs mais perso j'en suis super content et
ça fait le taf dans mon cas: Toggl. Par contre ça fait juste le time
tracking (voir plus bas).

> - tourne sous Linux

Non, c'est du SaaS

> - payant ou non. On préfère de l'opensource, mais si le prix est
>   raisonnable, pourquoi pas.

$9/user/mois

> - possibilité pour les utilisateurs de se connecter en web,
>   suivre leurs tickets et y répondre

Toggl donc fait juste le time tracking mais s'insère "à la volée'
(a.k.a. à l'arrache en injectant dans le DOM) dans pas mal de trucs
(issue github/gitlab, tickets jira, ...), liste complète ici:

https://github.com/toggl/toggl-button#compatible-services

L'avantage c'est surtout quand toi tu dois t'adapter au système de
ticketing de tes clients (plutôt mon use case) que l'inverse.

> - possibilité de répondre par mail et que ce soit assigné au bon ticket

Tu peux faire du reporting/billing par tech, par client, par projet. Par
contre la création de clients/projets sera manuelle et indépendante de
ton système de ticketing.

Si tu as des questions là dessus fais signe.

A+

M
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] [JOBS] Sysadmin dans l'ouest lyonnais

2017-11-21 Par sujet Michel Blanc
Le 21/11/2017 à 22:28, cam.la...@azerttyu.net a écrit :
> Salut
> 
> N'hésite pas à venir lors du prochain apéro pour en parler :)

Je vais essayer. Je vois passer les invits de Meetups, à chaque fois je
me dis "cette fois c'est la bonne !", et voila, rattrapé par le chill et
le manque de motiv pour re-bouger après le taf (et après je culpabilise
en +).

Les lundis ça m'arrange pas, mais je vais faire un effort pour décembre
promis !

M
-- 
Michel Blanc
{ :github => "@leucos" }
___
Liste de diffusion du FRsAG
http://www.frsag.org/

[FRsAG] [JOBS] Sysadmin dans l'ouest lyonnais

2017-11-21 Par sujet Michel Blanc
Bonsoir la liste,

Une offre d'emploi à la campagne si ça vous tente. Sysadmin Linux
(exclusif) avec un peu d'expérience, qui a envie de jouer avec Ansible,
Docker, des orchestrateurs, et quelques datastores.

TL;DR: Des arbres, des vaches, et des pingouins (et des projets sympas,
enfin je trouve).

https://www.linuxjobs.fr/jobs/1130/sysadmin-e-tendance-devops-au-devops-works

N'hésitez pas si vous avec des questions (en DM de préférence, pour ne
pas gêner).

M
-- 
Michel Blanc
{ :github => "@leucos" }
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Comment transmettre des informations à ses clients ?

2017-09-18 Par sujet Michel Blanc
Le 18/09/2017 à 17:24, Jonathan Leroy a écrit :

>> Est-ce que quelqu'un aurait outil du type "brisez la vitre": tu laisse
>> des secrets dedans, au cas ou, et quelqu'un à qui tu as donnée l'URL+un
>> pass peut y accéder en laissant une trace en cas de besoin.
>>
>> Ça ressemble à 0bin/PrivateBin, sauf que je n'ai pas l'impression de
>> pouvoir vérifier si l'info a été lue (sauf avec le "burn after reading"
>> et en allant check mais ça n'est pas souhaitable dans mon cas).
>>
>> Une idée ?
> 
> Je pense que c'est possible avec l'API One Time Secret :
> https://onetimesecret.com/docs/api/secrets
> Tu peux créer un secret en spécifiant un TTL très élevé, puis vérifier
> s'il a été lu avec la fonction "Retrieve Metadata".
> 
> Note que One Time Secret est open-source :
> https://github.com/onetimesecret/onetimesecret

Merci, effectivement une piste. Le seul hic c'est que ça reste "one
time", et ça me pose un souci (une fausse manip coté destinataire, et
adieu le secret).

Après effectivement, c'est open source, donc il y'a moyen de mettre les
mains dans le ~cambouis~ Ruby.

M
--
Michel


___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Comment transmettre des informations à ses clients ?

2017-09-18 Par sujet Michel Blanc
Le 18/09/2017 à 16:30, Jonathan Leroy a écrit :

> Il y a aussi One-Time Secret, qui est plus accessible pour les clients
> je trouve : https://onetimesecret.com/

Hello la liste,

Intéressant. Ça tombe à pic je cherche quelque chose de ressemblant
(mais légèrement différent).

Est-ce que quelqu'un aurait outil du type "brisez la vitre": tu laisse
des secrets dedans, au cas ou, et quelqu'un à qui tu as donnée l'URL+un
pass peut y accéder en laissant une trace en cas de besoin.

Ça ressemble à 0bin/PrivateBin, sauf que je n'ai pas l'impression de
pouvoir vérifier si l'info a été lue (sauf avec le "burn after reading"
et en allant check mais ça n'est pas souhaitable dans mon cas).

Une idée ?

--
Michel
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] remplacer ce bon vieux nagios

2017-08-24 Par sujet Michel Blanc
Le 24/08/2017 à 16:51, ML a écrit :

> tout à fait d'accord concernant promethus / grafana / influxDB ça
> s'approche plus de la métrologie que du monitoring server.

Sur ce point en fait je ne vois rien de rédhibitoire.

En fait, j'ai carrément abandonné le monitoring, pour ne faire que de la
métrologie avec des seuils sur les métriques appropriées (disk free,
taux de 5xx, you name it). Tant qu'à emmerder les serveurs pour savoir
s'ils vont bien, autant mesurer et collecter des métriques. On peut tout
transformer en chiffre mesurable (nombre de noeuds dans un cluster, RTT
avec un serveur) et alerter si les métriques n'arrivent plus.

J'ai quelques stacks qui sont surveillées par influx/grafana et jusqu'à
présent, je n'ai jamais ressenti le besoin de (re)mettre en service un
outil de monitoring dédié. IMHO, c'est bien plus souple en utilisant la
métrologie pure. C'est pluggué sur email/slack/sms et ça va plutôt bien.

Par contre, pour le coup, il faut monitorer la métrologie :D
Un uptimerobot/statuscake/pingdom suffisent pour ça.

Si vous avez un contre exemple de truc ou un monitoring est nécessaire
et ne peut être remplacé par la métrologie, je suis preneur (ce n'est
pas un troll, c'est une vrai question).

A+

--
M



___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] TR: choix/expérience hébergement cloud

2017-08-07 Par sujet Michel Blanc
Hello la liste,

Le 04/08/2017 à 11:23, lemonni...@ulrar.net a écrit :
>> https://www.online.net/fr
>>
>> service super, downtime jamais eu, sur l'offre business avec sla on a 3
>> serveurs avec proxmox dessus
>>
>> service client impeccable
> 
> J'irais pas jusque là, mais oui de façon générale ça semble plus stable
> c'est clair.

Alors je plussoie et je n'irai pas jusque là non plus.
Ça se dégrade clairement coté support depuis plusieurs mois. Tickets
traités hors délais, réponses complètement à coté de la plaque quand on
te prend pas carrément pour Mme Michu. Je les soupçonne de faire un
`telnet bofh.jeffballard.us 666` pour répondre aux tickets.

Au final, quand il y a un incident (en particulier réseau), tu n'as
jamais de réponse (et comme j'infogère, je suis comme un couillon pour
expliquer au client pourquoi son infra était injoignable; j'adore).

> En revanche, pas de support la nuit l'été, et comme ils ont à priori
> désactivé les alarmes de ping en DC parce que ça faisait trop de faux
> positifs ben un soucis hardware à 23h30 ça veut dire 7 / 8h de downtime,
> sans aucun recours.
> C'est du vécu :)

Vécu ça aussi très récemment (support business, ouverture à 1h, réponse
8h30). C'est officiel le "pas de support la nuit l'été" ?


--
M

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Centralisation de logs

2017-02-06 Par sujet Michel Blanc
Le 06/02/2017 à 14:44, Alexandre a écrit :
> Bonjour à tous,
> 
> je pense que se sujet a été abordés plusieurs fois mais je n'ai pas
> trouvé d'informations. 
> 
> Nous souhaitons centraliser nos logs (applicatifs, systèmes ...). Nous
> avons maquetté une solution standard avec Elasticsearh + Logstash +
> Kibana. Le trio fonctionne très bien, nous créons des custom logs et en
> y applique via logstash un template pour sortir tous les champs
> intéressant. 
> 
> Cependant si nous devons mettre en production cette solution comme nous
> l'avons maquetté, il faut que nous installation un logstash sur toutes
> les machines. Le déploiement pose aucun problème, mais mettre du java
> sur toutes mes machines sachant que le process mange du CPU et la RAM,
> cela me plaît très moyennement. 

Alexandre,

(Réponse un peu OT, désolé)

Il existe un autre moyen que tu voudra peut être tester: shipper tes
logs avec filebeat directement dans un ingest node Elasticsearch.

Un ingest node est juste un node qui a des pipelines d'ingestion qui
vont faire le taf de logstash, en utilisant les expressions Grok
habituelles..

Plus besoin de logstash, et plus besoin de bufferiser au milieu
(filebeat est normalement capable de ralentir le shipping si
Elasticsearch s'etouffe).

J'ai testé un peu et ça marche plutôt pas mal. Filebeat est assez léger,
et les pipelines ne font pas trop mal à Elasticsearch.

La conf coté filebeat est vraiment souple, pour peu que l'on la creuse
un peu (elle n'est pas forcément très bien organisée). Tu peux par
exemple shipper sur des pipelines/index dynamiques en fonction du
fichier de log lu assez facilement.

Par contre il faut ES 5.x.

https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html
https://www.elastic.co/guide/en/beats/filebeat/current/configuring-ingest-node.html

A+

M
--
{ :github => "@leucos", :gpg => "0X24B35C22" }

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Un reverse proxy de rêve ?

2016-06-10 Par sujet Michel blanc

Le 10/06/2016 à 10:26, Artur a écrit :
> Bonjour les gens,
> 
> J'aurais besoin de vos conseils pour mettre en place un reverse proxy
> applicatif devant une application node.js qui utilise des websockets.
> 
> J'ai déjà un nginx qui fait ça, mais il y a quelques détails qui me
> posent problème (sticky sessions pas en natif, paramétrage incomplet) et
> j'aimerais savoir quelles sont les alternatives.
> 
> Le proxy doit pouvoir gérer les connexions http et https (terminateur
> tls) avec des backends en http et ws, savoir gérer les sticky sessions
> avec des cookies (pas par adresse IP d'origine).
> 
> Et être tolérant avec ses backends. Par exemple, pouvoir réessayer si
> jamais il y a un souci de connexion, ne pas basculer sur d'autres
> backends sans qu'on lui demande dans la config (sticky sessions !),
> supporter un nombre de connexions ouvertes importantes (dizaine de
> milliers de websockets), ne pas être trop gourmand en ressources. Il
> peut aussi faire le chocolat chaud... je bois pas de café. :p


Hello Artur,

A priori, haproxy répond à tous les besoins (je ne suis pas complètement
affirmatif pour la partie chocolat chaud, mais café ok).

Pour "dizaine de milliers de websockets", suivant le nombre de dizaines,
il faudra peut être finasser avec des binds sur des IPs supplémentaires.

A+

M
-- 
Michel Blanc
{ :github => "@leucos", :twitter => "@b9m", :gpg => "0X24B35C22" }
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Outil de gestion des interventions et mises à jour

2014-10-29 Par sujet Michel Blanc
On 29/10/2014 19:59, Jonathan Leroy wrote:
 Bonsoir,
 
 Un exemple concret : mise à jour de tous les serveurs disposants de
 PHP 5.5 vers sa dernière version (5.5.18).
 Dans l'outil en question, je recherche tous les serveurs sur lesquels
 PHP 5.5 est installé, et envoi aux clients concernés un email les
 informants de la mise à jour.
 
 En fait, il me faudrait une sorte de intercom.io mais orienté admin sys :)


Hello Jonathan,

Je dirai que ça dépend un peu de ton inventaire actuel.
Mais si tu as moyen d'avoir un export sauce YAML de tes associations
client/serveur (ou encore plus simple, un fichier par host avec une
variable pointant sur l'email du client), avec Ansible c'est plié
rapidement.

Exemple, imaginons que pour chaque host, tu aies une variable
'email_client', et que les serveurs utilisent Apt, tu peux faire quelque
chose dans ce genre là :

- name: Recupère la version du package voulu
  shell: dpkg -s {{ package }}  2 /dev/null  | grep 'Version' | cut
-f2 -d' '
  register: version

- name: Prévient les clients si une mise à jour est nécessaire
  local_action: mail
host='smtp.server'
port=25
subject=Mise à jour imminente
body=Version {{ version }} obsolete - màj en vue
from=jonat...@unsigned.inikup.com
to={{ email_client }}
  when: version_cible not in version.stdout and not do_it

- name: Effectue la mise à jour si demandé
  apt:
name={{ package }}
state=latest
update_cache=yes
  when: do_it


Avec, coté ligne de commande :

# pour prévenir
ansible-playbook upgrade.yml -e 'package=php5 version_cible=5.5.18
do_it=false'

# pour mettre à jour
ansible-playbook upgrade.yml -e 'package=php5 version_cible=5.5.18
do_it=true'

Après, si tu veux juste prévenir le client après la mise à jour vers la
dernière version, c'est encore plus simple :

- name: Effectue la mise à jour
  apt:
name=php5
state=latest
update_cache=yes
  notify: Prévenir client

(le handler de notification 'Prévenir client' étant globalement
équivalent à l'envoi du mail ci-dessus).

et :

ansible-playbook upgrade.yml -e 'package=php5'


Bon, c'est fait à l'arrache sur un coin de nappe, et il y a plein de
manière que ça foire, donc YMMV, mais tu vois l'idée.


A+

M
-- 
Michel Blanc
{ :github = @leucos, :twitter = @b9m, :gpg = 0X24B35C22 }
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Playbook Ansible pour création de compte

2014-01-06 Par sujet Michel Blanc
On 06/01/2014 13:29, Greg wrote:

 et je suis confronté à vouloir faire une utilisation détournée. Je
 cherche une bonne pratique ou un retour d'XP si vous avez.
 Je suis en train de créer un playbook de création de compte d'employé
 qui se résume à :
 - sur serveurA, créer un compte mail via postfixadmin (donc du SQL)
 - sur serveurA, créer un compte jabber
 - sur serveurB, créer un compte Redmine
 - sur serveurB, créer un compte gitolite
 - sur serveurC, abonner l'adresse mail à 4 mailing-list mailman
 - sur serveurD, attribuer un numéro de téléphone sur le serveur VoIP
 
 Chacune de ces étapes serait un role au sens Ansible, pour qu'un user
 puisse par exemple avoir tous les roles sauf un numéro de téléphone.

 Sauf que Ansible a été créé pour configurer une grappe de serveur, ce
 qui me fait me poser des questions c'est d'avoir une tâche par
 serveur... 

Greg,

Un moyen serait d'avoir une liste de users (disons accounts) dans
group_vars/all (ou dans un endroit plus approprié) et d'exécuter tes roles :

- name: Jabber  Postifx
  hosts: serveurA
  roles:
- postfixaccounts
- jabberaccounts

- name: Redmine  Gitolite provisionning
  hosts: serveurB
  roles:
- postfix
- jabber
...

puis de looper dans tes rôles sur la liste de comptes
(roles/postfix/tasks/accounts.yml) :

- name: Account provisionning
  shell : postfixadmin ... {{ item.nom }}{{ item.prenom }}
  with_items: accounts

C'est robuste, idempotent (tu peux provisionner tous tes serveurs et
leurs comptes d'un coup de baguette magique), mais potentiellement super
long si tu as beaucoup d'utilisateurs.

Pour palier à ce dernier problème, tu peux écraser accounts quand tu
invoques ton playbook :

--extra-vars '{ accounts: { nom: gargamel, prenom:lucien }}'

et acccounts ne contiendra (pour l'invocation) que ce user.

 et comment calculer les variables à partir du prénom et du
 nom (en utf-8).

Je ne comprends pas bien le besoin derrière cette question mais je tente
quand même.
Si on repart sur le playbook dédié pour créer {un,tous les} utilisateur,
tu peux ensuite les concatener dans une tâche comme ça :

{{item.nom}}{{item.prenom}}
{{item.nom}}.{{item.prenom}}
{{item.nom}}_oulala_{{item.prenom}}
...

 voire les tripoter avec un filtre jinja, extraire un range à grand coup
de python (pas sûr de moi la dessus) ou faire mouliner un script en
local_action avec un register à la clef (ok, c'est un hack), ou mieux,
écrire ton propre filtre Jinja
(http://docs.ansible.com/developing_plugins.html#filter-plugins).

J'espère avoir compris ton besoin et donné quelques pistes.

A+

M
-- 
Michel Blanc
{ :github = @leucos, :twitter = @b9m, :gpg = 0X24B35C22 }
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] : Scalabilité Serveur de Mail

2012-11-15 Par sujet Michel Blanc
Bonjour,

On 15/11/2012 11:44, JC PAROLA wrote:
 Bonjour à tous,
 
 Après un fil très intéressant le mois dernier sur Les systèmes de
 fichiers distribués, je me permet de vous poser la question:
 
 comment gérez-vous la scalabilité de vos serveurs de mail.
...


 1/scalabilité vertical: on ajoute des machines identiques pour
 augmenter la capacité:

C'est horizontal. Vertical : tu ajoutes du hard sur une même machine
(RAM, disque, ...).

 avantage: simple à mettre en oeuvre
 inconvénient: oblige à installer un serveur d email complet (MTA,
 serveur POP, IMAP,repondeur)
 
 2/un serveur de stockage avec export NFS ou iSCSI avec une carte
 contrôleur disque adequat (du genre LSI MEGARAID CacheCade ou
 équivalent HP/DELL/NetApp)
 
 avantage: l'unité de stockage fait qqe To ce qui laisse voire venir
 inconvénient: coût (de 20K€ à 50 k€) et surtout le faible retour
 d'expérience (d'où mon ticket)
 
 3/un système de fichier distribué (GLUSTER,MOOSE,CEPH,PVFS,LUSTRE.)

Tu peux aussi distribuer au niveau applicatif : nginx par exemple, peut
servir de proxy imap et proxyifier vers les bon backend IMAP/POP
(http://wiki.nginx.org/ImapProxyExample).

Ça me parait beaucoup plus simple d'avoir 'n' petits backends cyrus
faciles à gérer avec du RAID1, 5 ou 6, et un nginx qui distribue en
front. Je vais probablement partir là dessus très bientôt  (j'ai un
cyrus avec 100k+ boites actuellement).

Tu peux aussi faire ça avec Perdition, un autre proxy imap.

Par contre tu n'a pas de tolérance de panne : si un backend tombe, tu
perds une partie des boites jusqu'à ce que tu le remontes.

A+

M
-- 
Michel Blanc - netWorks
8A68 0871 747A 65B6 E87C 3BEA 187C 36BB 2CE5 68BD
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Protéger au mieux son serveur http

2012-04-06 Par sujet Michel Blanc
On 06/04/2012 23:07, Hugues wrote:

 Toujours fan de perl... je cherchais qlq chose qui remplace les MVC en php
 ( je ne supporte plus de coder en php c'est trop la misère... ) - Dancer
 a l'air bien a première vue

Bon sinon y'a Ruby hein, ç'est dans l'esprit perl, mais avec des
nouvelles versions de temps en temps :)
Avec un framework pas trop lourdingue (suivez mon regard) genre Ramaze
c'est vraiment le bonheur.

 Deux firewall sous Openbsd + CARP ( un équivalent de cisco VRRP ) + PF +
 relayd et voila j'avais ma
 haute dispo, et mon LB- mais pas de prise en charge du SSL.

C'est à peu près l'objectif ici : deux haproxy avec ucarp et du DNS RR.

 Es ce que c'est une bonne idée d'ajouter la prise en charge du ssl sur
 les firewall ?

Question charge ? Pas de souci chez nous. haproxy compte pour du beurre,
et nginx pas vraiment gourmand non plus. Au final, c'est EEG plat chez
nous. Si tu splittes sur deux LB, à mon avis, tu devrais voir venir,
mais bon, à ajuster en fonction des caractéristiques serveur et trafic.

Si tu as besoin de confs pour te mettre le pied à l'étrier, fais moi signe.

Dans tous les cas, je te conseille de partir sur une conf du type
frontend/backend plutot que listen (en gros, deux méthodes pour définir
un service, la méthode listen décrivant la partie front+backends en
même temps est moins souple à mon goût).

A+

M
-- 
Michel Blanc - netWorks
8A68 0871 747A 65B6 E87C 3BEA 187C 36BB 2CE5 68BD
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Automatisation de contrôles web

2011-05-18 Par sujet Michel Blanc

On 18/05/2011 09:37, Julien Gormotte wrote:

Bonjour,

Bref, il faudrait un truc scriptable, pas trop chiant à utiliser, et qui
puisse tourner sur un Unix... Si vous connaissez quelque chose du style...



Hello,

Capybara + RSpec peut faire l'affaire :
http://railscasts.com/episodes/257-request-specs-and-capybara

A+

M
--
Michel Blanc
8A68 0871 747A 65B6 E87C 3BEA 187C 36BB 2CE5 68BD
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] interface web pour syslog

2011-03-11 Par sujet Michel Blanc
Hello,

J'ai entendu parler de GrayLog2 récemment :
http://www.graylog2.org/about

Si quelqu'un a un retour d'expérience, ça peut être sympa d'en faire
part à la liste.

A+

M
-- 
Michel Blanc - netWorks
8A68 0871 747A 65B6 E87C 3BEA 187C 36BB 2CE5 68BD
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] [FRsaG] présentation RHCA

2011-03-06 Par sujet Michel Blanc
Bonsoir,

On 06/03/2011 23:25, Youssef Ghorbal wrote:

 Bonjour,
 
  Ce que je suis vraiement curieux de savoir, c'est est ce que vous
 avez deja utilise des techniques que vous avez appris dans les
 certifications RH dans la vie reelle. Est ce que vous avez pu resoudre
 un probleme que vous n'auriez jamais pu resoudre sans les
 connaissances aquises pendant ces formations ?

Ce que tu fais au RHCE tu le mets en pratique tous les jours. C'est très
hands-on (en particulier le test :) ). Par contre, en ce qui me
concerne (RCHE en fast track seulement), je dirais que globalement, je
n'ai pas appris grand chose de fondamental que je ne savais en arrivant.
Malgré tout, c'est quand même intéressant. Je travaille plutôt en vase
clos, et en dehors de la liste (récemment), je n'ai que peu d'échanges
avec d'autres sysadmins. Au taf, très peu de turn-over, et on bosse
ensemble depuis plus de 10 ans. Alors chacun a ses habitudes de petit
vieux et on a plus grand chose à échanger techniquement.

Du coup en y allant, je me demandais si j'allais m'ennuyer ou être à la
ramasse. Ni l'un ni l'autre finalement, et j'ai appris des trucs
(essentiellement des nouvelles commandes et options) que mes habitudes
m'avaient fait manquer (qui a fait un 'man ls' cette année ?)

En gros, ça ouvre un peu l'horizon. Mais bon, un bon flux RSS sur
http://www.commandlinefu.com/ fait aussi l'affaire :)

Je ne suis pas sûr que ça présente plus d'intérêt qu'une bonne formation
Z d'admin système. Mais les intérêts que j'y vois : 1) ça permet de te
situer, 2) la certif. Pour ce dernier point, même si c'est
certainement un plus, je ne saurais dire quelle valeur cela peut avoir
sur le marché du travail (et attention, tu dois la repasser après deux
releases majeures). Ah oui, il y a aussi plein de goodies, ça fait
toujours plaisir aux enfants :)

  Derniere question, est ce que vous avez appris comme techniques sont
 vraiement RHEL centric, ou sont raisonnablement applicables a d'autres
 souches Linux ?

Pour le RHCE, et en dehors de la partie SELinux (survolée à ce stade),
tout est assez standard et praticable sous d'autres GNU/Linux (samba,
iptables, ... les services incontournables partout disons). Par contre,
je pense que pour certains modules RHCA (genre virtualisation, cluster
et storage) ça doit être assez RH centric : il y a pas mal de technos
différentes possibles, et celles de RH ne sont pas forcément utilisées
ailleurs. Je laisse les (le ?) spécialiste répondre.

M
-- 
Michel Blanc - netWorks
8A68 0871 747A 65B6 E87C 3BEA 187C 36BB 2CE5 68BD
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Légalité du filtrage SMTP

2011-02-25 Par sujet Michel Blanc
Merci pour vos réponses multiples et pertinentes.
Quelques fragments en plus :

* On 24/02/2011 23:16, Nicolas Steinmetz wrote:

 Est-ce que le contrat du service de messagerie indique ces limitations
 ? Il faut peut être commencer par là.

Oui Nicolas, coté usagers pas de souci. D'ailleurs, je suis prêt à lever
la restriction pour un destinataire s'il le souhaite (nous sommes plutôt
à l'écoute de leurs besoins d'une manière générale).
Je m'interrogeais plutôt pour les autres, ceux de l'extérieur, à qui
certes je ne dois rien contractuellement, mais qui peuvent m'accuser de
discrimination à leur encontre dans le traitement des courriels.

Je précise que nous fournissons un service gracieux. Même si cela ne
veut pas dire que l'on a tous les droits, on peut comprendre que nous
soyons dans l'économie et la préservation de nos ressources informatiques.

* On 25/02/2011 00:23, Pierre-Henry Muller wrote:

 Même tagué combien de fois on nous a demandé de pas taguer tel vendeur
 de médicament ou tel site d'accessoires érotique voir sm parce que 
 le monsieur était client ...

Héhé. Bon, chez nous je ne pense pas que le cas se présente chez nous.
Ils se contenteront de pester en silence :)
Mais ça pose le problème d'un antispam classique sur une grande base
d'utilisateurs d'horizons divers. Chez nous, on a pas réussi à résoudre
cette quadrature du cercle : comment assurer un taux de faux positifs
suffisamment bas sur 100k+ users... Mission Impossible, sauf si on forme
les utilisateurs à faire du training d'antispam (Mission Impossible II).

* On 25/02/2011 00:50, Benjamin Billon wrote:

 Sérieusement ?
 Le principe est d'envoyer à l'expéditeur un mail non désiré dans le but 
 (louable certes) de luter contre les mail non désiré.
 Y'a comme un problème dans l'énoncé.

Benjamin, je crois que Pierre-Henry préconisait de regarder les CGV du
service, et pas forcément de le mettre en place.
Effectivement, je n'aime pas ce type de solution non plus.

 Quant à bannir en fonction du X-mailer je ne vois pas bien
 l'efficacité dans la mesure où X-mailer, comme son nom l'indique est
 un header optionnel. Il suffirait donc de ne pas le mettre pour
 passer le filtrage ?

Disons que c'est une des méthodes utilisées, et qui marche pas trop mal
dans la mesure ou certains logiciels de mass mailing (ou ceux qui les
mettent en œuvre) sont assez stupides pour faire de l'auto-promo dans le
X-Mailer :D
Mais on matche pas mal sur les éventuels List-Unsubscribe, les From: qui
se distinguent régulièrement, des Message-ID, ..etc...


En résumé, je retiens ceci :

* on peut légalement filtrer à condition que :
  - l'utilisateur final soit au courant et ait accepté des CGV
(CGU/Charte dans notre cas vu la gratuité)
  - l'utilisateur final ait la possibilité de demander le déblocage d'un
expéditeur

En revanche, pour les autres (les expéditeurs de l'extérieur vers
nous), dur de se prononcer. Je pense que je vais interroger un juriste
là dessus.

A+

M
-- 
Michel Blanc - netWorks
8A68 0871 747A 65B6 E87C 3BEA 187C 36BB 2CE5 68BD
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Légalité du filtrage SMTP

2011-02-25 Par sujet Michel Blanc
On 25/02/2011 10:05, Pierre Chapuis wrote:
 On Thu, 24 Feb 2011 22:10:46 +0100, Michel Blanc wrote:
 
 Légal je ne sais pas trop mais si j'étais l'expéditeur, que c'était des
 mails sollicités et que ça nuisait à mon business :
 
 1) je trouverais un moyen de contourner le filtrage (pas trop dur),

Oui, bien sûr, mais quand on utilise un mass-mailer, on as pas forcément
la possibilité de le faire (dans le cas précis qui m'occupe, il ne peut
pas).

 2) j'inclurais dans un mailing à mes clients le fait que leur
provider mail bloque mes courriers et qu'ils devraient en changer
s'ils veulent continuer à les recevoir (à la DailyMotion)

Oui bon. Ça va pas être simple de faire partir les utilisateurs dans
notre cas mais c'est une idée :)

 Bloquer du spam OK, mais quand un expéditeur râle et est dans son
 bon droit la moindre des choses me semble d'être de changer les
 règles de filtrage.

En l'occurrence, je n'ai aucun moyen objectif de savoir si l'expéditeur
qui râle et est dans son bon droit. Je ne vais pas ouvrir les mails en
question, je n'en ai pas le droit. Je ne vais pas appeler l'utilisateur
final pour savoir si oui ou non, il désire recevoir les courriers de la
société 'X', j'ai d'autres serveurs à fouetter.

Le plus simple est qu'il prévienne son client, et que le client nous
fasse la demande. Dans ce cas, on débloque. Je veux bien changer les
règles de filtrage à la demande des utilisateurs. Mais hors de question
de le faire pour une société externe : autant arrêter tout de suite de
filtrer...

M
-- 
Michel Blanc - netWorks
8A68 0871 747A 65B6 E87C 3BEA 187C 36BB 2CE5 68BD
___
Liste de diffusion du FRsAG
http://www.frsag.org/


[FRsAG] Légalité du filtrage SMTP

2011-02-24 Par sujet Michel Blanc
Bonsoir,

Je vois qu'il y a pas mal de monde calé en droit ce soir. Je saute sur
l'occasion (et j'en profite au passage pour remercier la liste pour le
niveau de échanges, c'est toujours très instructif).

J'opère un serveur SMTP qui alimente quelques dizaines de milliers de
boites. Pour essayer de soulager au maximum les usagers de la plaie que
vous savez, je filtre de facto les emails entrants en provenance de
logiciels de mass mailing (par X-Mailer ou d'autres éléments de l'en-tête).

Je conçois que c'est peut être un peu radical, mais sachant que ces
logiciels sont utilisés dans 99% des cas pour envoyer des emails
commerciaux non sollicités, j'ai pris la décision de fonctionner comme
cela dès le début. C'est d'ailleurs clairement expliqué dans le 450
renvoyé par Postfix.

J'ai eu aujourd'hui un expéditeur (externe), ému de ne pouvoir envoyer
une newsletter à ses clients, à qui j'ai expliqué la situation.
Discussion cordiale, terminée par un status-quo : je ne vais pas
vérifier visuellement ses envois (là par contre, je n'en ai pas le
droit) pour vérifier sa bonne foi et changer les règles de filtrage en
conséquence.

Mais du coup, je m'interroge sur les implications légales possibles.
Est-ce légal de filtrer ainsi ? L'expéditeur externe peut-il
légitimement arguer du fait que ce filtrage nuit à son business ? Et les
éditeurs de logiciels de mass-mailing ?

En dehors de la méthode utilisée ici (qui discrimine explicitement des
mass mailers), la question se pose aussi concernant les anti-SPAM
traditionnels ou l'exclusion par domaines et RBLs.

C'est quand même étrange d'en venir à se poser ce genre de question
(suis-je en droit de balayer les cochonneries à ma porte d'entrée),
mais bon... le droit n'étant pas mon point fort, je préfère avoir vos avis.

Merci et bonne soirée

M
-- 
Michel Blanc - netWorks
8A68 0871 747A 65B6 E87C 3BEA 187C 36BB 2CE5 68BD
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Reverse DNS

2010-12-11 Par sujet Michel Blanc
Le 11/12/2010 08:20, Raphael Mazelier a écrit :

 Tiens personne n'a de script qui génère automatiquement les ptrs
 automatiquement pour bind (j'en avais trouvé mais j'ai oublié) ? ah que
 je regrette mon djbdns.
 

Rooo, quand même, un petit coup de Google là dessus :D
https://sites.google.com/a/kluge.net/mkrdns/

A+

M
-- 
Michel
___
Liste de diffusion du FRsAG
http://www.frsag.org/


Re: [FRsAG] Amanda ou Bacula

2010-11-16 Par sujet Michel Blanc
On 16/11/2010 15:54, Issa Moussa wrote:
 Bonjour,
 
 J'aimerai mettre en place une solution de sauvegarde j'hésite entre
 Amanda ou Bacula.
 Mon utilisation sera essentiellement la sauvegarde d'une base MySQL sur
 disque.
 
 Que me conseillez-vous ?

Bonjour,

Pour du mysql, un outil de backup standard ne suffira pas, sauf si tu
coupes mysql avant ton backup (ou si tu aimes les frissons à la
restoration).
A chaud, il te faudra mysql{dump,hotcopy}, ou des snapshots LVM, ou
[insérer votre méthode favorite ici].

Après pour le filesystem et pour backuper sur disque, j'aime bien
bontmia backup. Simple, efficace, basé sur rsync+ssh.

J'ai un petit wrapper perl sous la main pour paralléliser et configurer
plusieurs backups sous bontmia au passage si ça tente quelqu'un.

M
-- 
Michel Blanc
8A68 0871 747A 65B6 E87C 3BEA 187C 36BB 2CE5 68BD
___
Liste de diffusion du FRsAG
http://www.frsag.org/