Fabien a écrit 137 commentaires

Je possède depuis plus d'un an un ASUS ultrabook UX31E:
Core i7, 4Gb de ram, ssd 256go, cg intel, écran 1600x900 …

Mes reproches :
- un clavier qui bouffe certaines frappes (il m'oublie des lettres de temps en temps)
- un écran brillant

pour le reste, c'est pas mal, j'utilise le windows7 fourni et une debian full encrypted (avec quelques optimisations glanées sur le net concernant le ssd).

Tu peux regarder sa version UX31A :
- écran mat full hd
- clavier rétro-éclairé (peut être de meilleure qualité).

PS: je possède aussi un MSI Slim, bien plus vieux et moins performant mais tout aussi fiable au vue de l'utilisation intensive que j'en fais.

Voir la doc du filtrage de rsyslog

L'exemple précédant fait parti de ma configuration rsyslog
il utilise les "Property-Based Filters"

Entraîne toi déjà sur le serveur central à maîtriser ce type de filtrage en utilisant les logs déjà présents sur le serveur ou en générant de faux logs avec la commande logger ( -t 'tag' pour configurer l'étiquette du message).
Dès que tes règles seront en place, il ne te reste plus qu'à envoyer les logs de tes serveurs clients (tu peux utiliser cette technique de filtrage pour ne relayer que certains logs) vers le serveur central.

Rsyslog est capable de trier les messages grâce aux facilities mais dispose d'autres critères.
Il peut trier sur le contenu du message, le syslogtag et d'autres choses encore.

Voici un exemple :

:syslogtag, contains, "dovecot" /var/log/dovecot/dovecot.log
:syslogtag, contains, "dovecot" ~

Je trie sur le critère du tag du message, j'envoie les messages qui matchent vers un fichier spécifique.
La deuxième ligne me permet ensuite d'ignorer les messages précédemment matchés afin qu'ils ne se retrouvent pas dans d'autres fichiers de logs (tel que mail.info … dans mon cas).

L'idée est donc de regarder les critères de tri proposés (bien que celui du syslogtag soit efficace) et de formater tes messages sur les clients en fonction de ce tri.
Tu peux par exemple ajouter un nom de machine aux syslogtags afin de séparer les logs d'une même application tournant sur plusieurs clients.

N'oublie pas de configurer logrotate pour tous ces nouveaux fichiers.

raté, tu as mal lu les contraintes : "À l'exterieur de la France."

Sinon tu peux coupler nsd + unbound (Authoritative + Recursive).
Pour l'instant je n'utilise que unbound qui fonctionne pas mal. Je vais bientôt lui ajouter nsd pour l'authoritative.
Je pense que ce couple constitue une bonne alternative à bind, que je connais pourtant assez bien, mais la concurrence ne fait pas de mal.

Est ce que Gearman ne ferait pas aussi parti de la liste ?
Je ne l'ai pas vraiment comparé aux autres solutions et ne sait pas si elles sont équivalentes.

Je l'utilise car packagé par ma distribution, car l'extension php est facilement compilable car non packagée, et qu'il existe une lib php de gestion des workers .

peut être Kerrighed

Pas géniale comme solution, le mot de passe sera visible par tous les utilisateurs de la machine avec un simple 'ps …'
La solution en dessous est plus propre.

M'ont bien fait rire le nom de tes users, ça change de Mme Michu

le 1er lien, c'est juste le site officiel de ce module

DRBD n'implique pas l'utilisation d'un "filesystem cluster", il peut être utilisé avec n'importe quel FS, il suffit de ne pas accéder au slave (et donc ne pas monter la partition associée). Ca fonctionne aussi avec des partitions chiffrées.

J'avais centralisé tous les logs (et pour seulement une trentaine de serveurs - mix OpenBSD , Debian) vers un rsyslog qui insérait tout dans une base de données dédiées.
Ca donnait une conf du genre :

# templates
$template auth_log,"insert into auth_log (Message, Facility,FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values ('%msg%', %syslogfacility%, '%HOSTNAME%' ,%syslogpriority%, '%timereported:::date-pgsql%', '%timegenerated:::date-pgsql%', %iut%, '%syslogtag%')",sql

# rules
:syslogtag, contains, "pf_block"                        :ompgsql:localhost,Syslog,rsyslog,mon_password;pf_block_log
:syslogtag, contains, "pf_block"                        ~

La base de données était un "gros" Postgresql utilisant des tables partitionnées (sur le champ ReceivedAt) pour chaque type de log ( table partitionnée auth_log dans le cas de l'exemple).

Perso, ça ne me dérange pas qu'ils changent le format des logs tant qu'on garde une telle souplesse de configuration.
Par exemple, configurer le format d'écriture des logs reçus (on reçois du json, on écris dans un fichier dans le vieux style de log).

Pourquoi ne pas utiliser libevent au lieu d'attaquer directement epoll ?

Même constat lors de ma récente escale dans l'aéroport international de Kuala Lumpur.
J'ai oublié d'essayer en Thaïlande mais c'est compréhensible quand on peut acheter l'équivalent local d'une puce entrée libre pour 1€ environ.
Enfin, à 0€ le forfait, je peux pardonner beaucoup de chose …

Vue la liste des fonctionnalités de btrfs et des prochaines nouveautés, je me demande lequel de ZFS ou btrfs est le plus "bazar" tout en un ?

j'ai pas vu des gens dire "faudrait reprendre iptable sur openbsd pour avoir un truc commun avec linux".

très mauvais exemple, l'inverse serait plus pertinent.

faisable d'accord, mais simple ...

par contre, pour un cluster HA de firewall (sans perte de connexions), faudra utiliser d'autres outils.
c'est là que se place OpenBSD (faisable avec FreeBSD et peut être avec les autres, mais bon, autant utiliser l'original):
- 1 ligne pour faire de l'aggrégation de liens
- 1 ligne pour monter le partage d'adresses carp
- 1 ligne pour la synchro de la table d'états du firewall
- sûrement beaucoup moins de lignes pf que iptables

pour le reste des prérequis, ça doit être réalisable :
un coup de pflog vers un rsyslog distant fera l'affaire
pour le routage y a tous les outils
...

en plus, du greylisting avec pf, un load balancer utilisant pf (donc HA sans perte de connexions), du vpn ipsec en HA ...

je pense vraiment que cette solution mérite d'être envisagée / testée avant de dépenser un paquet de brouzouf dans l'appliance proposée (quel prix ?).

Sans plus de précisions et sûrement d'envie, il va pas aller loin.
Sinon, il me semble que j'avais des dell 1950 avec des cartes quad port gigabyte qui fonctionnaient bien.

C'est la méthode que j'ai retenue pour une partie des pages (celles qui contiennent une pagination).
J'utilise la classe php ParallelCurl pour gérer les commandes curl_multi .
Une boucle génère l'url de la page et la passe à parallelcul afin d'être récupérée, moyennant une limite configurable du nombre de connexions simultanées.

Je rajoute OpenBSD à la liste, ça tombe bien la 5.0 vient de sortir.
Il peux gérer tous les pré-requis concernant le firewalling et la haute disponibilité.

Je suis bien d'accord, la base est déjà pas mal optimisée (index de différents types sur les colonnes adéquates, tuning du serveur sql ...), EXPLAIN ANALYZE est mon ami.
Voir mon commentaire au dessus, j'ai optimisé une requête faisant des recherches dans une colonne de type tableau.

J'utilise postgresql pour plusieurs raisons :
- parce que je le préfère à tout autre sgbdr
- parce que j'utilise des triggers
- parce que j'utilise tsearch
....

Il reste une chose que je n'arrive pas à optimiser, les requêtes avec LIMIT .. OFFSET .. lorsque le nombre de résultat est trop grand (jusqu'à 1 million de ligne) et je ne peux pas utiliser les CURSORS. Il me semble que ce problème est commun à tous les sgbdr, je n'ai pas le temps de faire les tests avec mysql.

Pour la mise en cache, pourquoi s'en priver si je dispose des ressources nécessaires ?
apache ne répondra jamais aussi rapidement que varnish si la page est en cache, et encore moins lorsque le trafic simultané augmentera.

Je m'auto-réponds, ça peut toujours servir.

httrack reste le meilleur outil pour crawler une page, il parse bien les pages à la recherche de liens et maintient la liste des liens à scanner sans créer de doublon.
Par contre, je n'arrive toujours pas à lui faire ouvrir plusieurs connexions.

J'ai donc regarder du coté de curl, et j'ai découvert une classe php permettant d'exécuter plusieurs curl en parallèle ParallelCurl.
J'ai testé cette solution qui peut être intéressante, mais sur mon projet, elle met en avant un autre problème: la génération des pages n'est pas accélérée car dépendante du temps de réponse de ma base de données. J'ai donc optimisée quelques requêtes faisant des recherches dans une colonne de type tableau:
- création d'un index GIN sur la colonne cible ( tag dans mon cas )
- utilisation d'une requête de type WHERE tag @> ARRAY['%s'] , le %s est remplacé par la valeur adéquate grâce à un sprintf

Après optimisation, je peux modifier mon script de mise à jour de la db afin de lancer un curl parallèle permettant de générer les nouvelles pages dites statiques puis une purge des pages contenant une pagination et un httrach ciblant ces mêmes pages.

Je vais essayer avec wget, je n'avais pas vu qu'il dispose d'un mode spider, mais je doute de la possibilité d'ouvrir plusieurs connexions simultanées.

Etant le propriétaire du serveur, j'ai pu vérifier que httrack n'ouvre qu'une seule connexion bien que configuré pour lever les limites (--disable-security-limits) et les options qui vont bien. Il n'y a aucun filtrage sur le useragent ni limite conn/s

Je souhaite tout mettre en cache car j'en ai la possibilité (pas mal de ram dispo sur le serveur) et surtout parce que certaines pages peuvent être assez lente à générer (à cause d'une requête sql utilisant LIMIT .. OFFSET .. sur 1 million de records).

Pas vraiment LSM car n'utilise pas l'infrastructure du noyau, mais il propose les mêmes fonctionnalités et d'autres (il intègre pax).
Je l'ai utilisé sur de nombreux serveurs et l'utilise encore (activation de toutes les protections sauf RBAC) sur ceux qu'il me reste, et j'en suis content.
Je pense qu'il a sa place à coté des outils cités si l'on ne se limite pas aux systèmes 'LSM'.

J'aimerai bien savoir de quand datent tes observations concernant la rapidité.

Pour la complexité, je pense que ça dépendra de l'expérience de chacun.
Enfin moi, j'ai eu envie de pleurer quand j'ai essayé d'optimiser / tuner mysql (contraint de l'utiliser à cause de magento).
Pour les SERIAL, effectivement ça change des 'autoincrement' au début, mais c'est bien plus souple à l'usage.

Je pense qu'une des faiblesses de postgresql était la réplication, mais depuis la dernière version, on peux faire du asynchrone et même du synchrone (sans passer par drbd ou autre). Il ne lui manque plus que le mode cluster.