[AlternC-dev] Koumbit, AlternC et Hostmaster

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

The Anarcat anarcat at anarcat.ath.cx
Ven 26 Sep 19:46:05 CEST 2008


On Fri, Sep 26, 2008 at 07:29:13PM +0200, Nahuel ANGELINETTI wrote:
> Le Fri, 26 Sep 2008 10:01:16 -0400,
> The Anarcat <anarcat at anarcat.ath.cx> a écrit :
> 
> > 
> > > The Anarcat a écrit :
> > [...]
> > > > L'intérêt pour les utilisateurs d'AlternC est multiple, une fois
> > > > le projet "AlternD" en place:
> > > >
> > > >  * sécurité accrue par l'utilisation de SSH/SFTP/SCP
> > > >  * sécurité accrue par l'isolation des sites par utilisateurs UNIX
> > > >  * accès multiples utilisateur au bureau, centralisation de la
> > > > gestion des comptes (même username/pass pour le FTP, mail,
> > > > bureau, etc)
> > > >  * gestion facile des applications (cliquez ici pour installer un
> > > >    Drupal, un SPIP, etc)
> > > >  * toutes les fonctionalités et convivialité existantes d'AlternC
> > >   
> > > Comment hostmaster est censé faire pour aller toucher aux fichiers
> > > de configuration système?
> > 
> > Hostmaster roule déjà comme deux parties: une interface web (Drupal)
> > et un cronjob (basé sur Drush, un module Drupal). Le cronjob roule en
> > user "hostmaster". Cet utilisateur a des droits d'écritures sur
> > /var/hostmaster/conf.d où sont stockés des fichiers de config apache.
> > C'est donc en se basant sur la base de données contrôlée par
> > l'interface web que le cron job génère les fichiers de conf.
> 
> Rah, j'ai un sacré problème avec ces "cronjob", c'est pas instantané...
> et qu'en est il d'autres services qu'apache qui ont besoin d'une
> création de répertoire(les mails) ?

Ils sont pas créés sur le champ, tout simplement.

> > Il y a en fait un concept de "tâche": créer un site, désactiver un
> > site, backup d'un site, ce sont toutes des tâches dans une file
> > d'attente qui est traitée par le cron job. Chaque module peut ajouter
> > des tâches à la file et étendre le cronjob pour les traiter.
> 
> Un peu à la update_domains.sh?

Oui.

> > > Comment gérer les nodes?
> > 
> > J'imagine que tu parles ici des serveurs: de mon point de vue, c'est
> > ici la tâche de Puppet de configurer les nodes avec un serveur web, un
> > serveur MySQL, etc. Hostmaster est cependant conçu pour être
> > multi-serveurs et donc pour configurer plusieurs machines à distance,
> > avec SSH.
> 
> Et pour répartir les configurations, etc...? Puppet avait des problèmes
> de tenue de charge selon mes souvenirs.

Puppet se comporte très bien avec beaucoup de serveurs. C'est quand on
parle de beaucoup de configuration par serveur que ça commence à moins
bien tenir la route. Donc mettre tous les usagers dans puppet, ça scale
pas.

> > Prenons l'exemple d'un node Web à ajouter. Puppet (ou un sysadmin) va
> > installer Apache puis la configuration minimal nécessaire à hostmaster
> > pour traiter les tâches le concernant. Dès lors, le cron job sur cette
> > machine va effectuer les tâches normalement.
> 
> Personnellement j'aurais plus vu le bouzin comme un daemon qui tourne
> sur chaque node, et qui attend les tâches à jouer de la part d'un
> maitre en fonction des modules activés.

C'est comme ça que hostmaster1 était écrit et c'était un peu bourrin
parce que personne comprenait comment il marchait.. En utilisant du PHP
en backend aussi, ça simplifie les choses et ça n'empêche pas de
ré-écrire le backend en daemon si on veut mieux scaler à l'avenir.

> > > Pourquoi Drupal?
> > 
> > Drupal est un choix assez pragmatique: c'est la plateforme de
> > développement de choix de Koumbit depuis ses débuts. C'est un logiciel
> > qui s'est prouvé très extensible et facile à programmer, même pour des
> > programmeurs n'ayant jamais utilisé ou programmé Drupal.
> > 
> > De plus, Hostmaster existe déjà et fait *beaucoup* de ce que nous
> > avons besoin. Je compte fort sur les modules de gestions de mailing
> > list, Bind et gestionnaire de fichiers déjà existants dans Drupal
> > pour faciliter le développement futur d'AlternD également.
> > 
> > Donc en bref, pourquoi Drupal? Pour ne pas réinventer la roue.
> 
> Ça n'est pas un peu lourd pour les besoins?

Selon moi, non.

> > > J'en ai d'autres, mais déjà répondre à celles là ce serait pas mal.
> > 
> > Voilà, j'espère que ça répond à tes questions. :)
> 
> L'idée de nodes daemonisés ça t'intéresse pas?

C'est intéressant, mais trop compliqué.

> > Non, pas pour l'instant. C'est un système de "provisionning",
> > seulement de Drupal pour l'instant.
> > 
> > C'est en version 0.1-alpha, à ce stade-ci, d'ailleurs, donc ce n'est
> > pas grand chose. Un paquet d'idées de concepts et de code.
> > 
> > Mais je (et d'autres développeurs de aegir) veulent aussi en faire une
> > plateforme d'hébergement mutualisée générique. D'autres sont également
> > intéressés au provisionning de vservers.
> 
> En fait, l'idée est bien, mais pour moi drupal ne devrait pas être
> celui qui touche au système. J'irais plutôt dans le sens ou le "drupal"
> communique avec un daemon, qui pourrait d'ailleurs avoir pleins de GUI
> disponibles.

C'est une vieille idée, mais je ne vois pas ça arriver avant un bon bout
de temps, c'est trop compliqué: il faut une trop grande cohésion entre
le GUI et le backend pour complètement les séparer, à mon avis.

> Quelle fin ? :) c'est un projet libre, qui ne "mourra" jamais, peut
> être il sera abandonné par manque de développeurs et utilisateurs, mais
> il ne mourra pas :)
 
Bons mots. :)

A.

-- 
Imagination is more important than knowledge
                        - Albert Einstein
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 197 octets
Desc: Digital signature
URL: <http://lists.alternc.org/arch/dev/attachments/20080926/f4ecbe5f/attachment.pgp>


Plus d'informations sur la liste de diffusion Dev