[AlternC-dev] Presentation ( un peu en retard)

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Remi remi+tech at b6.be
Lun 5 Mar 20:27:27 CET 2012


On Mon, 5 Mar 2012, denis wrote:

|Salut,
|
|On 05/03/12 11:42, Remi wrote:
|> L'arborescence /var/alternc/html, /var/alternc/mail/, /var/alternc/dns, 
|> ... serait remplacée par une arborescence du type 
|> /var/alternc/users/0/1/2010/html, /var/alternc/users/0/1/2010/mail 
|> /var/alternc/users/0/1/2010/dns où 2010 est l'uid de l'utilisateur
|Ce qui est embêtant avec cette solution, c'est que ça rend compliqué la
|gestion des mails sur un serveur dédié.

Je pense que tu cites le cas précisé par Km qui se résume ainsi: "si on 
veut séparer les services, c'est plus difficile".

Pas tellement en réalité...

Avant toute chose, précision suite à la question de Alan 0/1/2010 c'est 
uid=2010; Pour uid 1234, ça serait 4/3/1234 à la manière de ce qu'on fait 
pour les login dans l'arbo actuelle. Je prends les derniers chiffres car 
c'est la meilleure manière de répartir équitablement.

On peut ainsi faire 10 partitions (voire 100) pour répartir les 
utilisateurs sur 10 serveurs NFS différents ou 10 partitions de disque 
dur.

Par ailleurs, dans l'idéal, il faut rendre personnalisable ce chemin 
système (afin de pouvoir rendre possibles des config comme 2 serveurs NFS, 
...). Genre une petite fonction PHP resolvePath() customisable par 
l'admin.

Le fait d'avoir un serveur spécialisé pour les mails n'a aucune incidence. 
Il suffit de mapper les différentes partitions et de n'utiliser que les 
répertoires dont on a besoin. Le nombre de lecture/écriture sur le serveur 
de mails sera toujours le même, et le nombre de lecture/écriture sur le 
serveur Web sera toujours le même. A ceci près qu'on pourra maintenant 
répartir équitablement les utilisateurs sur différentes partitions, alors 
qu'auparavant on était obligés de mettre tous les logins commençant par 
"a" dans le même panier (qui ne sont pas aussi nombreux que ceux 
commençant par "q").

Le nombre de lectures/écritures sera même ainsi normalement équivalent sur 
chaque partition alors qu'auparavant, il était disproportionné entre la 
mail et le html.

Evidemment, quand on peut s'acheter un serveurs de fichiers en RAID.42, on 
n'en a que faire.

Mais, ce n'est pas le seul avantage que j'y vois comme indiqué 
précédemment.

Pour moi c'est surtout l'avantage de ne pas se baser sur le login, puisque 
le mec qui veut changer de login pour X raison ou Y, aujourd'hui, on est 
obligé de déplacer toute son arborescence.

Tu veux désactiver un compte sans le supprimer, tu fais chmod 0, sur la 
racine du compte. Tu veux migrer les comptes 1 à 1 sur un nouveau serveur, 
tu copies le répertoire et basta. Tu veux gérer le quota en temps réel, ya 
voy. Tu veux fournir un backup quotidien de toute le compte, yop.

Et tu veux un serveur spécial pour gérer les mails, tu montes les 
partitions, ya esta. Sauf qu'effectivement, tu ne peux plus faire une 
partition pour les mails, un partition pour le web, mais que par défaut tu 
dois en faire 1 ou 10... sauf si on met en place la fonction resolvePath 
indiquée plus haut.

Voilà, j'ai défendu l'idée, je l'aime bien, mais je suis conscient que ça 
peut perturber les habitudes.

Je ne défendrais pas plus, je trouve l'API plus primordiale (même si avec 
la pratique la refonte de l'arborescence aurait intéressé l'admin sys 
bénévole que je suis).

Remi



Plus d'informations sur la liste de diffusion Dev