Premiers pas avec un compte revendeur Plesk

Plesk 12.5 et versions ultérieures sont livrés avec des contrôles de compte revendeur extrêmement puissants. Contrairement à cPanel (et WHM), il n'est pas nécessaire d'apprendre à utiliser deux panneaux complètement différents, Plesk intègre tout magnifiquement dans un panneau facile à gérer. Cela dit, il y a quelques choses à savoir sur l'ensemble de fonctionnalités et les meilleures pratiques pour l'organisation des plans d'hébergement.

Vous n'avez pas encore de compte d'hébergement revendeur ?

Nous pouvons aider! Avec des tarifs d'hébergement revendeur compétitifs et un stockage SSD à très haute vitesse, vous aurez du mal à trouver une meilleure option que Websavers.

Revendeur Hébergeur

Facturation

Plesk n'inclut pas de solution de facturation. Si vous souhaitez également fournir une automatisation complète de l'hébergement Web, de la commande jusqu'à la connexion à Plesk sans votre intervention, vous devrez également commander une solution de facturation, comme WHMCS. Avec WHMCS, vous pourrez configurer des formulaires de commande, des comptes clients, des factures et des plans d'hébergement récurrents qui se connectent à vos plans de service revendeur Plesk. De cette façon, lorsqu'un client commande, le produit qu'il a choisi sera automatiquement provisionné sur votre compte revendeur.

Si vous ne configurez pas de solution de facturation adaptée à l'hébergement, vous devrez créer manuellement des factures pour vos clients avec des logiciels comme Square ou PayPal, puis créer et gérer manuellement leur plan d'hébergement.

Forfaits de services

Dans Plesk, les packs de services sont essentiellement des modèles et des contrôles de restriction pour les packs d'hébergement que vous créez. Si vous proposez à vos clients plusieurs forfaits, comme un avec 5 Go de stockage et un avec 20 Go, vous devrez créer un forfait pour chacun.

Vous pouvez également faire des choses intéressantes avec les plans de service du point de vue des modèles. Par exemple, vous pouvez appliquer des configurations, comme l'activation de la mise en cache gzip dans nginx, à votre plan de service et cette configuration sera automatiquement activée sur tous les abonnements nouvellement créés qui sont générés à partir du plan de service.

Si vous n'avez pas avez modifié un abonnement après l'avoir créé (c'est-à-dire s'il est toujours synchronisé avec le plan de service), vous aurez également la possibilité de synchroniser toutes les modifications que vous apportez à votre plan de service avec tous les abonnements créés précédemment, déployant ainsi tous les changements sur tous abonnements client en une seule fois !

Limites et autorisations

Lors de la création de plans de service, vous aurez la possibilité de configurer un certain nombre de "valeurs par défaut" qui s'appliqueront automatiquement aux abonnements créés à partir du plan de service. La plupart des paramètres sont assez explicites, comme le nombre de domaines à autoriser (à vous de décider !) Mais certains d'entre eux peuvent ne pas être aussi clairs. Voici de l'aide avec ça !

Remarque :pour tous ces préréglages, vous pouvez remplacez-le toujours par abonnement (ce qui empêchera l'abonnement d'obtenir de futures modifications) ou activez-le simplement pour tous en modifiant le plan de service et en synchronisant les modifications de tous les abonnements.

Gestion des accès au serveur via SSH : sauf si vous avez des clients très techniques, il est probablement préférable de ne pas autoriser cela.
Gestion FTP anonyme :laissez décoché
Accès au catalogue d'applications :cela fait référence au système d'application Web Plesk intégré. Puisque nous utilisons Installatron, cela peut être décoché en faveur d'Installatron.
Accès à distance pour les utilisateurs de la base de données :il est préférable de ne pas cocher cette case pour des raisons de sécurité. L'accès à distance signifie que quelqu'un peut utiliser une application SQL pour se connecter à sa base de données et la gérer depuis son ordinateur.
Configuration d'options de script Web potentiellement non sécurisées :cela fait principalement référence à la possibilité de modifier les paramètres PHP comme upload_max_filesize. Si vous avez des clients techniques (comme des développeurs Web), activez-le. Si ce n'est pas le cas, mieux vaut ne pas activer l'accès à cela. Vous pourrez toujours apporter les modifications vous-même ; seul le client ne le fera pas.
Taille de la boîte aux lettres :si vous hébergez des e-mails, il est préférable de configurer une limite de taille de boîte aux lettres. Oui, tout le monde veut des comptes de messagerie de 20 Go comme avec Gmail, mais en fin de compte, votre compte a un espace limité et vous voulez vous assurer qu'il fonctionne bien. Être averti lorsqu'un client a une très grande boîte aux lettres vous aidera à l'aider à contrôler la taille de la boîte aux lettres.
Onglet Messagerie :Politique relative aux e-mails pour les utilisateurs inexistants :rejeter .
Onglet Journaux :il est fortement recommandé de configurer une rotation des journaux lorsque la taille du fichier atteint 1 Mo et de conserver 10 fichiers journaux ou moins. Cela garantira des performances optimales. Si les fichiers journaux atteignent des tailles très importantes, l'écriture dans le fichier journal prendra plus de temps, ce qui signifie que chaque accès au site Web prendra plus de temps en attendant la journalisation.
Date d'expiration :si vous définissez une date, le domaine sera sera automatiquement suspendu à cette date, sauf si vous le mettez à jour manuellement à une nouvelle date. Ceci est utilisé pour appliquer automatiquement le non-paiement. Si vous disposez d'une méthode alternative pour l'appliquer, utilisez-la et définissez-la sur illimité.
Paramètres PHP : nous recommandons les valeurs par défaut suivantes :
- Version : 7.0.x FastCGI servie par apache
- memory_limit :128 Mo
- post_max_size :64 Mo
- upload_max_filesize :64 Mo
- opcache.enable :activé
- Tout le reste par défaut.

Clients, abonnements et domaines :comment cela fonctionne

Clients sont assez simples. Pour chaque client que vous avez, vous devez créer un client dans Plesk. Même s'ils ne veulent pas d'accès maintenant, ils pourraient le faire à un moment donné dans le futur, et vous assurer de leur fournir leur propre compte client dès le début, facilite la fourniture de cet accès pour vous à l'avenir. De plus, il est plus simple de trouver des comptes plus tard lorsqu'ils sont organisés proprement dès le départ, car vous pouvez rechercher des noms de clients, des domaines, des comptes de messagerie, etc. chaque fois qu'ils sont organisés en conséquence.

Les clients possèdent un ou plusieurs abonnements auxquels ils ont accès.

Abonnements sont des versions « en direct » ou provisionnées d'un plan de service. Ils commencent généralement par un domaine - le domaine principal - et peuvent avoir autant de domaines complémentaires, sous-domaines, alias, comptes de messagerie, comptes ftp, etc., que vous l'avez autorisé dans le plan de service à partir duquel il a été provisionné.

Lorsque vous ajoutez des domaines à un abonnement, ils partagent tous le même dossier utilisateur avec leurs dossiers racine Web individuels dans le dossier utilisateur. Les adresses e-mail de tous les domaines d'un abonnement s'affichent lorsque vous consultez la liste des comptes de messagerie.

Vous avez la possibilité de configurer chaque Client avec un ou plusieurs abonnements.

Les domaines qui partagent le même abonnement peuvent être un peu difficiles à séparer à l'avenir, si jamais vous le souhaitez, car de nombreuses applications Web reposent sur un emplacement de fichier statique sur le disque. Cela signifie qu'il est pratique de configurer vos domaines dans les bons abonnements dès le départ, mais cela signifie également que vous pouvez toujours remanier les choses plus tard si le besoin s'en fait sentir.

La prochaine question naturelle est alors :si un client possède deux domaines, dois-je les configurer avec deux abonnements (un pour chaque domaine) ou un abonnement qui héberge les deux domaines ?

Nous préférons aborder cette décision en répondant à ces deux questions (qui sont des versions vraiment différentes de la même question) :

Est-il possible que les domaines doivent être séparés ultérieurement ? C'est beaucoup plus simple de le faire s'il s'agit d'abonnements distincts, donc si la réponse est oui, alors utilisez des abonnements distincts !
Les domaines sont-ils réellement liés ? Par exemple, si le domaine principal est BestBuy.com et que vous créez un site de carrières sur bestbuy-jobs.com, vous devez absolument ajouter bestbuy-jobs.com à l'abonnement BestBuy.com. C'est parce qu'il s'agit de deux sites distincts, mais ils font partie de la même entreprise. D'un autre côté, s'ils veulent créer un site Web pour leur PDG CorieBarry.com, il serait peut-être préférable de le configurer sous son propre abonnement, car Corie pourrait passer à une autre entreprise à l'avenir et ce sera super facile et rapide pour déplacer simplement l'abonnement de ce domaine vers un nouveau client.

C'est à peu près tout ce qu'il y a à faire ! Vous créez vos plans de service en tant que modèles à provisionner pour les abonnements des clients, qui hébergent vos domaines.

Hébergement revendeur bien fait.

Besoin d'une société d'hébergement qui garantit une marge de croissance? Fatigué d'être nickel et obscurci par chaque petit détail ? Il est temps de passer aux Websavers !

Revendeur Hébergeur