Dominique Feyer a écrit 58 commentaires

Oups un départ de troll sur systemd :)

Sinon bravo pour l'article ça fait plaisir à lire.

Presque à l'heure pour la sortie de Neos 1.0 on a lancé cette semaine la refonte de notre site sous TYPO3 Neos: http://ttree.ch/

Ce week-end c'est le dernier code sprint avant la sortie de la version finale, toujours planifiée au mardi 10 décembre. Impatient de livrer cette version.

Si jamais voici un liens vers une box Vagrant pour tester facilement: https://github.com/tlayh/vagrant-typo3neos

Tu as essayé TYPO3 CMS et non TYPO3 Neos ;)

Pour TYPO3 Neos c'est par ici http://neos.typo3.org, si tu peux te l'installer en local via composer c'est la meilleur solution, sinon tu peux tester le liens Launchr.

Un sympathique article de Bergie, développeur Midgard et Noflow, entre autre, de son retour d'expérience de développeur avec une tablette android, en anglais: http://bergie.iki.fi/blog/working-on-android/

{{#trollMode}}
Arrêtez avec vos discussions sur le choix des langages et autres "c'est toujours mieux ailleurs", un langage n'est qu'un outil n'importe quel imbécile peut faire un script / programme pourri dans beaucoup de langage … c'est comme pour le français on peut bien parler … mais on peut aussi faire plein de fautes d'otographe … c'est pas pour ça que le français c'est moins bien que l'anglais … quoi que …
{{/trollMode}}

Personnellement, je trouve l'application bien sympa, niveau code, on peut toujours faire mieux et l'équipe semble aller dans le bon sens. Je souhaite un bel avenir à cet outil, et je plussoie une intégration de Sharlii

En jetant rapidement un coup d'oeil à la norme, pour les DTD Task … je pencherais plutôt vers des solutions comme le BDD (behavior driven development), de cette manière les tâches (task, user story, fonctionnalité…) peuvent directement être utilisées par les développeurs pour tester l'application.

Pour le reste … ça semble lourd et complexe quand même. Faut voir si vous avez beaucoup de contenus qui sont très régulièrement réutilisés.

Chez nous on travaille de plus en plus avec Restructured Text pour tout ce qui est documentation et BDD pour les user stories/feature/task. L'avantage on reste dans un format texte très léger, facilement lisible par n'importe qui et versionnable.

Je dois faire parti des geeks qui réfléchissent pas comme les autres ... jamais pu adhérer à SVN. Quelques semaines sous GIT dans un gros projets et tout semble tellement plus souple et naturel, là où y fallait pas avoir peur de branché sur SVN, ça devient un réflexe sous GIT

Une petite pensée quand même à ceux qui sont encore forcé d'utiliser CVS

Je suis passé d'un XFCE + Compiz à un environnement AWESOME y a quelques semaines ... le placement et le redimensionnement des fenêtre n'est pas vraiment un problème vu que dans mon cas ... je l'utilise tout simplement plus du tout, le WM le fait lui même, et moi je me concentre sur l'utilisation des mes applications plutôt que sur le placement des mes fenêtres.

C'est un peu la même approche dans ce WM.

Perso, je repasserais pas sur un WM "classique" ;-)

C'est assez marrant de lire ce forum, si je fais un petit résumé, pour qu'une entreprise puisse racheté un logiciel libre (ou une entreprise qui développe un LL), il faut:

1. Qu'elle paie tous les contributeurs (par ligne, par heure de travail, par nombre de patch ???)

2. Qu'elle engage le(s) développeur(s) principale(s) en ne le faisant que travailler sur le LL en question et que tout son travail soit publier sous GPL.

Faut pas abuser, racheter un LL (ou l'entreprise qui le maintient), c'est un signe fort que les LL sont une très bonne solution.

Mais payer les contributeurs c'est juste ridicule ... impossible, presque stupide comme réflexion. Je contribue sur quelques projets, et j'y passe de longues heures. Mais je n'espère pas gagner de l'argent si un de ces logiciels se fait "racheté". Je gagne ma vie en vendant du support sur ces LL, en formant, en documentant, en traduisant, ...

Maintenant au sujet de la personne en charge du développement de CUPS, qui bosse donc maintenant pour Apple. Le fait de l'engager, c'est reconnaitre ses qualités de développeur et son expértise de CUPS. Mais de là à l'obliger à travailer que sur du LL sous GPL, ce n'est pas réaliste.

A faire trop de philosophie vous vous emportez sur des détails. CUPS vivra, comme la plupart des projets majeurs, encore de très longue année. Au lieu de passer du temps à philosopher sur des détails, contribuez, le LL s'en portera encore mieux ;-)

Extrait du site principale de wapiti:

"lswww (la webspider utilisé par wapiti) fails to extract informations from bad-coded webpages."

Donc t'inquiète on va pas avoir un rapport très rapidement ;-)

Ce site est une bonne initiative, mais je soutiens les remarques sur l'accessibilité, les popup c'est le truc le plus affreux qu'on a inventé :-( et les tableaux tout partout ... beurk aussi.

Pour HitParade quand on parle de coût c'est le vitesse d'affichage de ton site qui est ralenti. Si hitparade est surchargé ton site sera plus lent.

Le truc horrible avec les "gens habitué à Windows" c'est qu'il sont aussi habitué à se mettre hors la loi pour contourner les limitations que leur impose M$ et les autres éditeurs proprio.

Alors il trouve normale que pour lutter contre le DRM il faille mettre en place un réseau paralèle de diffusion de puce (qui sertait totalement illégale et fortement puni par la loi vu qu'elles permettent de contourner un moyen de protection) ou alors de hardware modifié qui serait tout autant hors la loi.

Ce n'est pas une solution, mais un pensement sur la plaie pour éviter qu'elle s'infecte et qu'on perde le bras.

Lutter contre les DRM c'est lutter contre leur mise en place, pas essayer de vivre avec, jusqu'à aller acheter des cartes mères sous le manteau ;-)

C'est un problème de philosophie ... prévenir plutôt que soigner nos maux.

Je viens de mettre en place un cluster Postfix + Dovecot + PostgreSQL

C'est une très bonne solution assez stable (mais vivement la 1.0 finale quand même).

Premièrement 1 conseils, utilise excusivement la version 1.0 (la RC2 est très stable). La version 0.99 n'est plus supporté par la communauté.

Pour ce qui est de ma configuration, Postfix récéptionne les mails sur SMTP/SMTPS et le transmet à Dovecot LDA (Local Delivery Agent) qui lui le dépose dans la mailbox (sur un share NFS dans notre cas).

Tu peux aussi laisser Postfix déposé le message directement dans la mailbox, mais tu perds quelques avantages offert par Dovecot LDA:

1. Les index sont mis à jour à la récéption et plus uniquement quand on se connecte en IMAP (la connexion est donc plus rapide et plus "légère" pour le serveur)
2. Il existe des plugin pour LDA qui permette la gestion des quota, des script sieve (vacation, redirect, filtre, ...)

Dans les grandes lignes, notre configuration est assez proche de ça http://wiki.dovecot.org/DovecotPostgresql

Sous debian, j'utilise toujours le mapper pour faire un mount. Mais normalement ça ne devrait pas changer grand chose, tu peux faire un mount /dev/lvmmail/prod

Sinon ta suite de commande semble correct.

Désolé pour le problème de "mise à niveau" ... c'est pas toujours facile de sortir d'un datacenter et d'expliquer simplement les choses ;-) Je suis sysadmin, pas prof et je sais pourquoi ;-)

En espérant t'avoir quand même éclairer.

Ce howto devrait répondre à toutes tes questions (et en français)
http://www.ibiblio.org/pub/linux/docs/HOWTO/translations/fr/(...)

Je te conseille de tout bien lire, et de bien essayer les différentes manipulations, de cette manière tu seras à l'aise avec LVM. En cas de problème c'est quand même plus agérable que de lire la doc en urgence ;-)

Dès que topn Volume Physique est créer il faut faire un Volume Logique, puis formater normalement le Volume Logique avec des commandes comme mkfs.xfs et le mounter avec mount (+ éditer /etc/fstab).

Bonne lecture,

L'intérupption pour créer une snapshot sera très courte par rapport à une copie brut de tous les fichiers. Je peux difficilement te donner un temps exact, tout dépendant de la taille des fichiers, de leur nombre, de la vitesse de ton disque, ...

Pour ce qui est de la coupure le freeze ne sera plus là au reboot et ton snapshot LVM sera certainement corrompu, il suffit de le supprimer et de recommencer.

Pour l'admin amnésique ;-) faut qu'il prenne des notes quand il fait ses backup histoire d'éviter ce genre de souci.

Maintenant combien d'utilisateur comptes tu avoir sur ton serveur ? POP ou IMAP ? Les disques IDE ne sont pas des foudre de guerre et les performances serait meilleures, y compris pour faire le snapshot sur du SCSI.

Maintenant pour LVM, tu dois créer un volume LVM, puis formater ce volume en XFS. Le mieux serait d'avoir deux disques, l'un pour le système + log et l'autre pour les données du serveur de mail. Les performances seront bien meilleure. Installer Linux sur le disque 1 et au reboot créer un volume LVM sur le disque 2, y plein de doc sur Internet pour LVM.

Si t'as qu'un seul disque, il faut que l'install se fasse sur un minimum d'espace pour tes partitions / /root /home /usr /var, ... ce qui laissera de la place pour que tu puisse créer un volume LVM après le reboot sur le reste du disque.

La seul solution c'est les snapshot LVM ou d'autre système de fichier supportant les snapshot, mais c'est pas moins complexe.

Voici une solution avec LVM et un volume en XFS. Pourquoi XFS, simplement parce qu'il supporte le freeze (empêcher l'écriture sur un disque pendant un moment) et le redimensionnement à chaud de la taille de la partition, mais ça c'est un autre sujet.

Donc on va dire que /var/mail est un volume LVM formté en XFS, pour le backupé:



# Empécher toutes le écriture pendant la création du snapshot pour éviter les problème, /var/mail correspond au volume LVM /dev/lvmmail/prod
xfs_freeze -f /var/mail

# Créer un nouveau volume LVM qui sera une vue instannée du /var/mail
lvcreate -l 500 -s -n snap /dev/lvmmail/prod

# Monter le snapshot pour le bakcuper
mount -o nouuid,ro /dev/mapper/lvmmail-snap /var/mail-snap

# Unfrreze du volume /var/mail
xfs_freeze -u /var/mail

# Sauvegarder avec tar, cpio, ou n'importe quoi d'autre
...

# Destruction du snapshot
unmount /var/mail-snap
lvremove -f /dev/lvmmail/snap


C'est pas si complexe ;-)

Un truc à faire gaffe vu que tu freez ta partition /var/mail, ton MTA (postfix,exim, ...) ne pourront pas déliver les mails et risque de faire de belle erreur dans les logs. Idem pour POP et IMAP que ne pourront pas supprimer les messages.

Pour le MTA, tu peux l'arrêter avant le freeze, pour autant que tu as un serveur de mail secondaire dans tes DNS. Quand tu un unfreeze tu peu relancer SMTP, pour POP et IMAP tu peux aussi arrêter le service et le rédémarrer ensuite, l'intéruption ne sera pas très longue.

Voilà si tu veux plus d'infos, n'hésite pas ;-)

Et pour ta question, vous ne backupez jamais vos mails ... biensûre qu'on les backup (bon certaiement pas tous le monde ;-) quand tu proposes un service d'accès IMAP, t'es obligé de backupé vu que les clients n'ont que rarement un copie de leur mails sur leur ordi.

Il existe aussi une autre solution pour backuper des mails à chaud. Donc sans aucune interuptions de services, mais ça demande une machine dédié avec autant d'espace disque que sur ton serveur de mail principale. Tu dois avoir un serveur IMAP sur les deux serveurs et tu peux synchronisé les BAL via IMAP avec des outils comme imapsync ou autre. L'avantage c'est que ton système reste parfaitement disponible, mais le backup sera plus lent (pas de compression).

Tu peux imaginer synchroniser les comptes via IMAP durant la journée, puis arrêter le service IMAP sur le serveur de backup qui sera ensuite backupé par une solution comme Amanda pour finir sur un lecteur de bande.

Autre avantage de la solution tu as un serveur de backup complétement fonctionnel, en cas de panne sur le premier, tu n'as qu'a changer l'adresse IP de la machine de backup et hop ton service de mail est à nouveau dispo.

Des serveurs IMAP comme Cyrus ou Dovecot permettent d'avoir un utilisateur qui a accès au toutes les BAL ça simplifie la synchro. Sinon faut te loguer avec les mots de passe des tes utilisateurs à chaque fois.

C'est risquer de faire une archive tar avec des fichiers qui peuvent changer durant l'archive, ça peut donner des archives irrécupérable.

Une solution c'est l'utilisation de LVM pour la partition /var/mail, ensuite les fonctions de snapshot de LVM permette de figer le système de fichier et d'en faire une "vue" qui peut être backupé très simplement par tar, cpio, amanda, ... A la fin du backup il suffit de supprimer le snapshot.

J'oubliais tous les détails sur le fichiers de config:

http://wiki.dovecot.org/MainConfig

Premier truc n'utilise pas la version 0.99 elle n'est plus maintenu. Avec les version 1.0beta1-9 ou la RC1, il y une nouvelle structure dans le fichier de configuration.

Donc aucune correction de bug pour la 0.99 et si tu demandes de l'aide sur la mailing list il te demanderont certainement de mettre à jour vers 1.0 RC1

Comme c'est toujours plus simple de mettre en place un nouveau fichier de conf avant de mettre en production. Je te conseille de partir direct sur la 1.0

Maintenant pour ton cas particulier pourquoi ne pas mettre les utilisateurs virtuel dans une DB c'est quand même plus souple ?

Dans ta config:

first_valid_uid = 8
last_valid_uid = 0
first_valid_gid = 1
last_valid_gid = 0

Je te conseille de commencer la numérotation de tes utilisateurs depuis 500 (sur redhat) ou 1000 (sur debian)

Les UID/GID en dessus peut déjà être utilisé par ta distribution ce qui peut poser des problème de sécurité.

Autre conseil, fait tourner dovecot-auth avec une utilisateur spéfique (auth_user, ex: dovecot-auth) et utilise un autre utilisateur pour login_user (ex: dovecot-login) de cette manière tu n'as pas besoin de chrooter tes services (login_chroot) et t'a un maximum de sécurité.

Si je comprends bien ce que tu veux faire, c'est avoir tous tes mails avec le même utilisateur virtuel. Avec le nouveau format du fichier de configuration (version 1.0)

userdb static {
args = uid=500 gid=500 home=/var/mail/%d/%u
}
passdb passwd-file {
args = /etc/dovecot/cram-md5.pwd
}

Maintenant au niveau sécurité c'est vraiment pas le top, s'il y a un bug dans dovecot-login, tout tes mails sont potentiellement "en danger".

Pour notre configuration on a choisi un UID/GID par domain, ça permet une certaine souplesse et surtout ça cloisonne mieux les processus.

Il manque aussi la config du type de boîte au lettre que tu veux utiliser:

default_mail_env = maildir:/var/mail/%d/%u/

Dans ce cas tu utilises le format MailDir plus souple que Mbox et surtout comporte presque aucun bug contrairement au Mbox qui peut encore poser des problèmes.

Je viens de mettre en production un cluster (>14'000 utilisateurs) Dovecot 1.0beta9 avec des utilisateurs virtuelle qui fonctionne à merveille c'est un excellent serveur POP/IMAP

Quelle version de Dovecot utilises tu ?

Peut tu poster tout ton ficher de configuration (sans les commentaires, ligne vide pour gagner de la place) ?

Quel MTA utilise tu pour la récéption des mails (nous, Postfix) ?

J'utilise la dernière version beta, on devrait passer en RC1 ce week end sur un partie du cluster. Les utilisateurs sont stocké dans un base de donnée PostgreSQL (on y accéde via un pool de connexion pgpool pour faire du load balancing sur deux serveurs postgres)

La mailing list officielle est très active mais en anglais.

Ton graal devrait se trouver dans ces fichiers de configuration:

/etc/warnquota.conf

ou un petit

man warnquota

Ensutie il faut définir des alias pour les comptes locaux, histoire que les mails soit envoyé dans un compte mail à l'extérieur vi /etc/alias; newaliases ...)

ça devrait te fournir exactement ce que tu veux.

La virtualisation est une excellente réponse à ta question. Tout administrateur système sait parfaitement qu'un serveur = un service permet de garantir une sécurité correct bien plus facilement, et accessoirement permet de faciliter la maintenance dans certain cas ...

Mais tout bon administrateur système connait aussi les relations avec le département compatable, manque de budget, ...

Les machines récentes peuvent très bien supporter une solution comme Vserver.

Je l'utilise dans mon entreprise pour le serveur Intranet, virtualisé en 6 machines

1. Firwall/VPN (communique avec l'exterieur via ADSL)
2. Serveur de fichiers (samba,coda,ftp)
3. Apache Intranet
4. Proxy HTTP/SOCKS
5. Mail (en fait un proxy filtrant le spam, virus)
6. DNS Primaire (le secondaire est sur un vieux serveur physique)

Le tout fonctionne sur un bi xénon 3.2 Ghz, 2Go RAM, sous Debain 3.1, 280Go de disque en RAID V (hardware) partagé entre les vhosts avec LVM pour simplifier la gestion des partitions.

Sur le serveur physique, il n'y a aucun service sauf SSH.

J'ai pas mal d'autre configuration fonctionnant sous VServer, jamais eu de problème majeur.

Et bien virtualise ;-)

V-Server
http://linux-vserver.org/

Vu que tu n'as qu'une seule machine, et que les tâches que tu dois effectuer sur la machine te pose des problèmes au niveau des règles de sécurité, le meilleure truc à faire c'est de virtualisé.

Tu crée autant de serveur virtuel que tu veux sur ta machine physique:

1 pour le partage de fichier
1 pour le calcul
1 pour l'hébergement web

Tu peux partager des dossiers entre différents V-Server donc gérer tes fichiers web depuis le v-server de partage de fichier par example.

Les possibilités sont infini et très souple. En plus les mécanisme d'isolation des V-Server sont bien plus sécurisé qu'un simple chroot.

L'overhead sur un V-Server et de l'ordre de 2% donc sur un bi-xénon c'est négligeable.

http://www.delouw.ch/linux/Postfix-Cyrus-Web-cyradm-HOWTO/ht(...)

J'utilise une configuration très proche sur quelques serveurs qui gére plusieurs milliers de compte sans souci. Stable et performant.