Annonces concernant le VPS
Posté le 20/04/2018 11:18
Maintenant que je vais commencer à toucher au VPS de façon un peu plus importante, je vais poster ici les annonces des changements pouvant avoir un impact sur les utilisateurs finaux (ou pas en fait).
J'ajouterais les annonces sur le post principal, en faisant un up, afin que les réponses sur ce topic ne masquent pas les autres annonces.
Je mettrais les détails techniques et la documentation sur le Wiki du projet PCv5 sur le GitLab pour le moment (je commencerais ce Week-end).
20/04/2018 – Pare-feu
La première annonce concerne le pare-feu. Le serveur manquait quelque peu de sécurité (pas de pare-feu et quelques services en écoute publique), j'ai donc remédié à cela.
Il est possible que j'ai oublié d'autoriser certaines connexions, et que les services liés ne fonctionnent plus (normalement y'a pas de soucis, mais bon). En cas de problème, n'hésitez pas à me prévenir sur ce topic.
06/05/2018 – Gitea, instance de test
Étant donné que GitLab est relativement complexe à maintenir, et qu'à priori, on a du mal à le tenir (même s'il ne plante plus), nous sommes quelques-uns à avoir proposé Gitea comme alternative. J'ai donc installé une instance de celui-ci sur le VPS, accessible à l'adresse
http://gitea.planet-casio.com.
Cette instance fonctionne avec l'utilisateur
gitea, et je ne me suis pas vraiment penché sur la configuration de façon très poussée pour le moment. Le but de cette instance est
uniquement de tester Gitea pour le moment, GitLab reste la forge principale.
En effet, si l'on décide de ne pas conserver Gitea, tout ce qu'il y a dessus sera « perdu » (même si récupérable), et si on décide de le conserver, alors que je ferais une installation plus « propre » et finie, à la place du GitLab (avec l'utilisateur
git).
Les arguments avancés pour Gitea sont l'interface, qui est très proche de celle de Github, la stabilité, la légèreté et – mais c'est plus secondaire – sa facilité d'entretien (il s'agit d'un simple exécutable autonome, avec quelques fichiers de configuration).
Les arguments en faveur de GitLab sont l'interface (plus personnalisable, et éventuellement plus pratique, disons qu'entre les deux logiciels c'est une question de goûts), et les fonctionnalités. Apparemment GitLab a des fonctionnalité intéressantes que n'a pas Gitea, je doit avouer ne pas savoir lesquelles, pour avoir utilisé les deux logiciels.
Bref, faites vos tests, donnez vos impressions et surtout votre préférence.
13/06/2019
Petit point d'avancement.
Fait :
– Installation et configuration du serveur et des services de base (SSH, sécurité, etc, etc)
– Installation d'un système de monitoring (Grafana + Telegraf + InfluxDB, GoAccess à venir probablement)
– Installation et configuration de Gitea
– Installation et configuration d'un annuaire LDAP pour l'authentification
– Installation et configuration de Nginx, création d'espaces pour les sites à migrer
– Migration des sites p7.planet-casio.com et bible.planet-casio.com
– Création d'une documentation concernant tout ça
– Finir la configuration de creativecalc.fr
– Migrer creativecalc.fr
– Configurer les environnements de dev et prod de la v5
– Migrer les projets du Gitlab vers le Gitea
Reste à faire :
– Installer et configurer un serveur IRC (Breizh)
– Configurer le serveur Murmur (Mumble) (Breizh)
– Configurer un déploiement auto pour la v5 (devs)
– Déployer la v5 (devs)
À faire ensuite :
– Migrer le Casio Universal Wiki
Si j'ai oublié des trucs, ou que je me suis planté sur certains points, dites-le moi.
Citer : Posté le 06/05/2018 15:11 | #
Ajout de l'annonce concernant la mise en place d'une instance Gitea de test.
Citer : Posté le 06/05/2018 15:24 | #
Nice ! Concernant Gitea, aucun problème tant que ça permet de gérer un wiki de projet et éventuellement des tickets. Le reste, on s'en sert quasiment jamais. L'intégration continue peut être un plus, mais faudrait déjà qu'on sache s'en servir pour en avoir besoin
Citer : Posté le 06/05/2018 15:27 | #
Ça permet de gérer un wiki et des tickets, ainsi que des hooks git. L'intégration continue semble possible avec Drone (lien trouvé dans la doc de Gitea).
Citer : Posté le 06/05/2018 15:36 | #
So…
Citer : Posté le 06/05/2018 18:31 | #
Est-ce possible d'étendre le HTTPS à ce sous-domaine ?
Une autre suggestion, mais que je propose sans vraiment l'envisager vu la complexité du truc, serait de lier les comptes du forum aux comptes de la forge. Je ne pense pas que ce soit possible sur la v42, mais sur la v5 on pourra créer automatiquement celui de la forge à partir de celui du forum non ?
Bon, ben sinon j'approuve. Y'a plus qu'à faire rouler cette instance.
Citer : Posté le 06/05/2018 18:41 | #
Sinon, si le serveur LDAP tourne, on peut éventuellement commencer la création des comptes via Gitea, et élargir ça au reste par la suite ?
Je sais pas si c'est réalisable en pratique, mais ça me parait être une solution
Citer : Posté le 06/05/2018 18:42 | #
Je foutrais le HTTPS quand j'aurais refait le système de certification, très probablement mardi du coup, sauf si je fais la migration finale à la place (et du coup ce sera le certificat de git.planet-casio.com).
Et comme je l'ai dit, je ne pense pas pouvoir tout migrer côté serveur. Déjà les utilisateurs seront perdus, et je ne sais pas s'il y a des repos privés. Le mieux serait que chacun vérifie qu'il a ses dépôts en local (et wikis aussi), pour les remettre sur le nouveau Gitea ensuite (je vais cependant voir ce que je peux faire sans intervention des utilisateurs).
Concernant les comptes, le linkage sera possible sur la v5, si on passe par LDAP. Gitea accepte LDAP, SMTP, PAM et OAuth2, en plus des comptes locaux. Quant à GitLab, il accepte LDAP, OmniAuth,CAS, SAML, Okta et Authentiq. Sinon, il faudra linker manuellement, je ne sais pas si l'API le permet, ou si une méthode différente peut être utilisée.
Ajouté le 06/05/2018 à 18:46 :
Le serveur LDAP est pas prêt, mais oui, c'est une possibilité. Faut que je me penche dessus. J'en profiterais pour finir l'IRC aussi.
Citer : Posté le 06/05/2018 18:49 | #
Je migre certains de mes miroirs de https://git.planet-casio.com à https://gitea.planet-casio.com.
Je migrerai le dépôt concernant https://www.creativecalc.fr quand l'équipe aura ses comptes et que l'instance Gitea aura du HTTPS.
Le reste ne sera pas migré parce que je ne m'en occupe plus. Si vous voulez forker, c'est le moment.
Ajouté le 06/05/2018 à 19:27 :
Bon, j'ai fait les miroirs du module de traducteur textout en Python (non terminé) et celui de la libcasio (non terminée non plus) sur l'instance Gitea. Lephé m'a répété qu'il fallait attendre que ce soit une instance définitive, donc j'attendrai pour la suite.
Pour ce qui est des miroirs : j'ai ajouté ma clé SSH et j'ai push les repos via SSH, l'un, textout, directement en ajoutant une origine en local, et l'autre, libcasio, depuis le repo principal (miroir de Gitolite) sur ma forge. Seulement, l'explorateur de code des deux dépôts ne se sont pas actualisés et font croire que les dépôts sont vides, pourtant si on les clône on retrouve bien le contenu…
Mon blog ⋅ Mes autres projets
Citer : Posté le 06/05/2018 20:45 | #
Cake je pense qu'il aurais fallu cloner les dépots dirrectement à partir de l'interface web, c'est ce que j'ai fait avec mon fork de PCv5 et ça n'a posé aucun problème
Citer : Posté le 08/05/2018 15:42 | #
Je viens de remarquer que j'en ai pas parlé ici.
Concernant le problème que tu cites, Cake, effectivement, il y un bug dans Gitea. Étant donné les issues ouvertes sur leur dépôt, et les conditions d'installation sur le VPS, j'en suis arrivé à la conclusion que le bug est lié à Debian Jessie (il n'existe pas sur Stretch, et les autres causes possibles de ce problème ne sont pas présentent sur notre VPS).
Ce bug n'est pas bloquant, juste un peu gênant : le premier push n'est pas pris en compte par l'interface web. Si tu fais un second push, le contenu sera actualisé, et toutes les mises à jour suivante seront bien prises en compte.
À voir à quel point on considère ce bug comme gênant.
Citer : Posté le 08/05/2018 15:50 | #
Puisque réinstaller le Debian est probablement hors de propos, je suggère d'attendre la correction du bug sur Gitea.
Citer : Posté le 07/06/2018 19:42 | #
Gitea 1.4.2 semble avoir corrigé le bug dont il est question ci-dessus. Si vous pouviez tester à nouveau différents trucs (premièrement le bug pour valider, et ensuite le reste pour être sûr que ça casse rien
Si y'a rien à signaler, je migrerais ça un Week-End (ça va dépendre de pas mal de choses).
Évidemment, le Gitea actuel est toujours un test, évitez de mettre des repos principaux dessus, j'ai pas envie de jongler avec 3 forges.
Avant la migration, si elle a lieu, hésitez pas à cloner ou mettre à jour vos dépôts sur vos machines, ainsi que les Wiki, et si possible, récupérez la liste des issues et autres trucs du genre. On sait jamais.
Citer : Posté le 07/06/2018 20:32 | #
Comme Breizh_craft vient de m'indiquer qu'on ne fait pas de virtualenv en prod, j'ai toutes les infos pour mettre en place une beta pour la v5. J'ai déjà configuré nginx et je m'apprête à passer à la communication avec Flask. Ensuite viendra le système de mise à jour depuis le git, ce pour quoi j'ai relativement confiance en l'extensibilité du shell SSH de Cake. Ça devrait bien se passer.
La priorité pour l'équipe de dev' qui va se constituer ce soir sera probablement d'arranger les fichiers du repo en ayant le tête le fait que le dossier du repo sera utilisé comme racine du stockage du serveur web - même si le serveur peut avoir des fichiers en plus, notamment des fichiers statiques, qui seraient dans le .gitignore ; je dirais même que c'est une bonne idée.
Citer : Posté le 07/06/2018 20:35 | #
Arf. Le dev avance trop vite, lol. Faut que je finisse de migrer les sites et de refaire le shell de Cake moi
Ce Week-End, je me penche dessus, du coup. Gitea attendra, c'est moins urgent
Ajouté le 10/01/2019 à 12:07 :
Comme on en a discuté hier avec Lephé, il faudrait programmer la migration du serveur.
Au vu de mes astreintes et de certaines dates, je propose de planifier ça du 1er au 14 avril (oui c'est loin, mais j'ai d'autres trucs à caler entre mes astreintes avant, et je pense qu'avec autant de délai pas mal de monde arrivera à réserver du temps.
Je planifie la migration « idéale » comme cela :
– Du 2 (parce que lundi je récupère) au 5 : installation de la distribution, des services de base, et si possible préparation des confs nécessaires à la migration (probablement moi seul).
– Le 6 et 7 : migration du contenu du VPS actuel sur le nouveau, la plus grosse partie possible, et surtout le plus important
– Du 8 au 12 : finalisation des configurations (y'aura forcément des trucs à fignoler
– 13 et 14 : second Week-End de migration intensive
– 15 au 22 : si c'est pas fini le 14, on peut continuer ici, mais sans compter sur moi.
Il faut en priorité vider l'ancien VPS une fois que le nouveau sera en place, pour ne pas avoir les deux à payer trop longtemps.
Pour info, la nouvelle installation sera faite différemment, donc pas mal d'outils d'automatisme casseront – on les refera plus tard correctement, je pense qu'il vaut mieux une install propre, documentée et sécurisée où il faut faire des trucs à la main qu'une install brouillon automatique mais que personne ne saurait réparer
Je suis pas à l'abri que mes astreintes soient décalées, si ça arrive je préviendrais ici, et on verra comment on s'arrange.
D'ici là, j'essayerais sur VM de faire fonctionner une authentification centrale entre Gitea et IRC, afin de donner une idée de ce sur quoi il faudra vous adapter pour l'auth du site.
Autre question : quelle distrib' on met ? Si c'est Debian, ça juste marche, je sais gérer sans trop de soucis, mais on risque de devoir refaire une migration similaire pour chaque nouvelle version. Si c'est Arch (niklérageux), je sais aussi gérer, mais ça demandera plus de temps au quotidien pour l'administration système (pour moi, disons-le), et pour les devs, afin d'être sûr que rien ne casse lors des màjs, mais il n'y aura pas besoin de migration complète à l'avenir (disons que les deux demandent autant de taf, mais soit d'un coup, soit étalé tout au long de l'année).
Citer : Posté le 10/01/2019 12:40 | #
Ou plutôt comme je te l'ai dit hier, il faudrait programmer la migration.
Blague à part, je m'aligne sur ce que tu proposes. J'essaierai de documenter tous les automatismes avant qu'on commence à migrer.
Niveau distro, je connais mieux Arch désormais. Si je peux intervenir en cas de pépin en urgence, ça me paraît pas mal aussi. Après, c'est envisageable aussi sous Debian mais ça va demander plus de boulot de mon côté.
Citer : Posté le 10/01/2019 14:33 | #
+1 pour Arch.
Mes raisons :
– y'a tout dans les dépôts (à peu de choses près) ;
– pour ce qui n'y est pas, c'est facile de faire des packages pour surveiller les mises à jour ;
– on peut utiliser les dernières fonctionnalités des paquets (va utiliser des f-strings sous Debian…) ;
– ça force à prendre de bonnes habitudes (maintenance régulière, à l'inverse des gros patchs une fois par an) ;
– ce qui fait que c'est secure by-design ;
– on peut se le permettre vu le faible nombre de serveurs à administrer ;
– la doc est <3 ;
– et j'aime bien la distro en elle-même.
Concernant les râleurs qui veulent pas faire de la maintenance régulière, Let's Encrypt ne fait pas de certificats de plus de 3 mois pour les mêmes raison. Mais dans l'ensemble tout le monde est gagnant dans l'histoire.
Citer : Posté le 10/01/2019 16:59 | #
Petite idée préliminaire de la liste des services à installer ou migrer.
* La v5 (Python/Flask)
* Le wiki (PHP/MySQL sous MediaWiki)
* La forge Gitea (Go)
* Le serveur IRC
* Du LDAP
* La mise à jour de la v42
Éventuellement prévoir de quoi faire des trucs à la tools.planet-casio.com.
Pour le wiki, on a regardé des alternatives, notamment Gitit, mais dans tous les cas c'est assez pauvre en fonctionnalités : il manque des choses importantes comme les modèles de boîtes en début de page de calculatrices, de quoi faire des groupes de pages avec des boîtes de liens, ou des bannières pour les pages et les sections. Donc on reste sur MediaWiki.
Citer : Posté le 10/01/2019 17:10 | #
Ajoutons Murmur (Mumble).
Pour la màj de la v42, j'ai pas la moindre foutue idée de comment ça marche actuellement, et il me semble que Cake était pas très chaud la dernière fois qu'on lui avait demandé de l'aide pour le refaire / l'adapter / le documenter, donc faudra voir ça.
La forge ça avait été discuté il y a un petit moment, donc Gitea est validé, la v5 en Python/Flask aussi (d'ailleurs j'avais pas géré la conf de Nginx pour ça, donc il me faudra sûrement de l'aide sur ce point, j'ai encore jamais configuré d'applis Python, encore moins avec Nginx).
Pour IRC le choix est restreint du fait des fonctionnalités que l'on souhaite, donc ce sera certainement UnrealIRCd + Anope.
Pour le Wiki pareil, les besoins font qu'il n'y a pas vraiment d'alternative (après, le Wiki actuel est pas très actif il me semble – à part Lephé qui apparemment a pas mal taffé dessus), si vous en avez à proposer qui auraient les fonctionnalités nécessaires, perso je dis pas non
Pour le LDAP, c'est à priori le seul truc en commun avec tous les services pour l'auth, donc pas trop le choix non plus.
Pour tout ce qui n'est pas déjà sur le VPS (Wiki, tools…), on verra cela une fois la migration du VPS terminée.
Pour la distrib', Arch a déjà trois votes, notamment des trois personnes qui sont le plus susceptible de tripoter le serveur, donc je pense qu'on peut dire que c'est décidé aussi
Citer : Posté le 10/01/2019 17:21 | #
La partie màj de la v42 est bonne pour moi, je sais bien comment ça marche. On se connecte sur un utilisateur précis par ssh, son shell est un script Python custom avec quelques commandes. La commande de la v42 fait un git pull puis utilise lftp pour transférer le nouveau fichier vers le serveur OVH. Je saurai migrer tout ça.
Niveau nginx, j'en ai configuré au moins 5/6 fois notamment pour le combo Python/Flask, tant que ce qui est sur le VPS actuellement n'a pas disparu au moment où on configure le nouveau je m'en sortirai aussi. Ce serait du uWSGI, comme actuellement sur v5.planet-casio.com.
Le Wiki n'est pas actif c'est sûr, mais je voudrais vraiment l'intégrer plus au site dans le futur. Notamment parce qu'il a une fonctionnalité clé : l'édition collaborative. Pas mal de sujets récents en auraient bien eu besoin, notamment le tutoriel de Python de @Shadow15510, les pages d'aide du site qui sont difficile à modifier (voir la TODO list du forum), et plein d'infos qui ont disparu dans les tréfonds du parce que je le ne les ai pas écrites sur des pages statiques au bon moment.
Citer : Posté le 10/01/2019 17:26 | #
Sans vouloir… enfin, ce que je voulais dire, c'est que s'il n'y que 2 ou 3 personnes qui touchent à la trentaine de page du wiki actuellement, peut-être que changer la façon de structurer certaines pages ne serait pas si dramatique, en fait. Mais bon, on verra en temps et en heure.