Pourquoi ne pas utiliser ISPCONFIG

Pause Café
#1

Bonjour

J’aurais très bien pu poser la question dans l’autre sens :wink:

Pourquoi utiliser ISPCONFIG : Pour avoir une interface de gestion, donc c’est plus simple pour administrer son serveur…

Mais souvent ce qui semble simple… au final devient lourd et bloquant (je parle en général et pas d’ispconfig)…

Voici mon utilisation, mon besoin (en réalité j’ai toujours utilisé cpanel, mais je suppose que ispconfing c’est la même chose) -> ajouter des domaines, créer les adresses mail qui vont avec et générer le certificat lets encrypt avec auto renouvellement).

Comme, je découvre debian, la mise en place d’un serveur, j’en arrive petit a petit à la gestion.

Si j’ai bien compris :

Pour ajouter des nom de domaines qui vont pointer sur un dossier spécifique 3 clics et c’est fait…
A la main il faut créer les dossiers et le virtualhost qui va avec (2 lignes de commandes)

et pour les mails et certificat (même si je n’en suis pas encore la) cela doit être du même ordre 3 clics contre 2 lignes de commandes

Je voulais avoir votre avis sur l’utilisation, l’intérêt OU PAS d’ISPconfig, voir les inconvénients

et même peut être les alternatives style 3 petites page php maison (1 pour ajouter un domaine, l’autre générer le certificat et l’autre créer les mails)… si c’est possible… ou si je délire…

et comme je passe du tout fait industriel au fait maison, forcement je découvre et ne percois pas forcement les intérêts ou difficultés

#2

Qu’est ce que ça fait dans “support debian” ?

Ca dépend de ton usage.
Toi, tu n’as pas un parc de 200 domaines à gèrer, donc pas besoin d’ispconfig.

#3

Salut,
Je suis en train de realiser la demarche de quitter ISPConfig après a peu pres 10 ans d’utilisation de ce dernier dans un cadre Pro. Je suis par ailleurs en train de finaliser mon projet.

Dans les avantage D’ISP :

  • Un avantage, et pas des moindres : Un accès ‘contrôlé’ pour les clients. Controlé avec ‘’, car le niveau d’accès est contrôlé d’une part par l’admin/revendeur, mais le client peut lui aussi faire un tas de chose, comme télécharger un backup, changer divers mots de passe jusqu’a l’enregistrement d’un nouveau NDD avec le site qui va avec si tu lui en laisse la possibilité en tant qu’admin.
  • Communauté plutôt active et projet perenne
  • C’est GRATUIT !
  • On utilise ou on ne connait pas forcement toutes les options
  • Pratique quand on a un niveau d’administration faible, ce qui était mon cas jadis.
  • Vraiment pratique pour les mails et les DNS
  • J’en oublis surement …

Dans mon cas, je l’installe quand le client a son propre serveur, ça lui permet d’avoir un accès assez complet graphiquement et assez simplement. En suite je configure les lacunes en amont.

Pour les clients que j’héberge, je me suis rendu compte qu’ils ne l’utilisaient jamais. Et donc la, je vais abordé les inconvenants :

  • Pas de wildcard letsencrypt
  • Pas de certificat avec autorité reconnue pour touts les services, du panel au mail en passant par FTP (du a la wildcard)
  • Pas de shell sécurisé par clés
  • Blocage sur php 7.0
  • Pas d’alertes en cas de soucis (j’ai dernièrement essuyé une attaque avec des tentatives de connexion mail, ca a faisait sauté la BDD MySql)
  • J’en oublis surement …

Quant a le remplacer avec 4 lignes de commande a chaque nouveaux clients/sites, je pense que tu en es loin et il n’est vraiment pas si simple de remplacer ISP, ou même un autre panel en ayant le même taux de services.

1 nouveau client :

  • création de l’user
  • creation des clés d’acces, perso, j’ai choisi de chroot au niveau d’SSHd pour permettre un acces SFTP dans le dossier web, mes clients n’iront jamais faire du shell. Pierre deux coup, securité + acces SFTP qui remplace donc l’acces FTP classique et non sécurise d’ISP.
  • creation du fichier Bind pour le NDD
  • creation du virtualhost
  • ajouter la ligne pour monter le fichier home/user/www dans var/user/www en passant par Bindfs (permet de regler les problemes de droits entre le user SFTP et Apache, j’ai pas trouvé meilleures solution)
  • création du backup par cron
  • création du/des mails
  • J’en oublis surement …

Je rejoins également la réponse précédente, ca depend donc du nombre de client/sites a gerer.
Je pense que dans le futur le lancerai un bash pour automatisé l’arrivé d’un new client.

#4

https://www.ansible.com/ marche trés bien avec debian.

1 J'aime
#5

Je me suis dit, tient c’est chere, et la je decouvre AWX !
Trop bien, merci :slight_smile: Comme quoi participer et aider sur un sujet peut apporter beaucoup :stuck_out_tongue:

#6

Merci qui ?

#7

Le pape :lying_face:

#8

AWX est la bêta du produit de RedHat (il faut le garder en tête).

En plus c’est un peu overkill, rien ne t’empêche de gérer des playbooks Ansible à la main depuis ton poste client (juste une connexion SSH).
Après l’automatisation peu venir via un mécanisme d’appel du playbook avec des userdatas sur un event (un slack, un commit sur un repo git, etc …).

#9

J’y bosse actuellement :stuck_out_tongue: