[AlternC-dev] Koumbit, AlternC et Hostmaster

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

Nahuel ANGELINETTI nahuel at altnetvision.info
Lun 29 Sep 15:49:05 CEST 2008


The Anarcat a écrit :
> 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 me semblait que cette méthode était considéré comme "ultra-chiante"
pour les utilisateurs et que l'idée d'un daemon était plus convenable,
qui peut entre autre retourner un code d'erreur en live.

>>>> 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.
>   

Tout passerait par de la conf de puppet alors?

>   
>>> 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.
>   

C'est une question de documentation si personne ne comprend, pas une
question de fonctionnement. Dans le principe dans ressemblerait à
quelquechose comme puppet, dans le fonctionnement ce serait quelquechose
de plus adapté à un système modulable/node dont un maître récupère
toutes les méthodes et les autorise ou pas à son utilisateur.

>   
>>>> 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.
>
>   

Est il question de séparer les dev "core" et "gui"? Pour pouvoir
intégrer différents UI?

>>>> 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é.
Mais très intéressant à développer, et évolutif :)

>>> 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.
>
>   
Si l'API du backend est bien définie je ne vois pas en quoi c'est trop
compliqué, et ça permet de bien séparer les rôles de chaque partie du code.


--
Nahuel



Plus d'informations sur la liste de diffusion Dev