Et ça n’a pas été de tout repos.
Le présent blog ainsi que mon site ont été down pendant plus de 3 semaines. Très concrètement, j’ai tenté une update de mon serveur, qui a foiré lamentablement, et a complètement crashé Debian.
Ça faisait un bout de temps que je n’avais pas fait de mise à jour de Debian. En plus, j’étais resté sur Wheezy, dont tous les repos commençaient à rouiller. Donc, ayant brillamment (hum …) réussi l’upgrade vers Buster de mon PC fixe et de mon PC portable, je me suis dit que je devrais profiter de la mise à jour pour aussi upgrade vers Buster. J’ai fait mes backups et j’ai lancé l’upgrade. C’est là que ça a commencé à déconner.
Pour rappel, pour mettre à jour la distro il faut déjà se mettre droit au niveau des repos et des paquets. Ensuite on modifie les chemins d’accès du sources.list vers les repos de la distro qu’on vise, et on fait un dist-upgrade. Passer vers stretch s’est fait sans trop d’encombres. Par contre, quand j’ai monté les repos de Buster ça s’est mis à déconner. Plein d’erreurs aptitude / apt, les trucs qui me plaisent pas. Sur mes autres postes, je les avait réglés en enlevant au fur et à mesure les paquets qui remontaient des erreurs, jusqu’à ne plus avoir d’erreurs, puis réinstallé les paquets dans la version correcte. Là j’ai essayé de faire pareil, mais j’avais un mille-feuilles de dépendances foireuses qui me paraissait inextricable. J’ai alors commis une erreur fondamentale : je suis passé outre.
Le dist-upgrade s’est lancé, et a cassé tellement de choses que je n’avais même plus l’interface réseau fonctionnelle. Partant de là, impossible de faire quoi que ce soit.
Toutes les datas étant intactes, et ayant en plus des backups, je me suis dit qu’il était plus simple de remonter un serveur from scratch, et de remonter les services avec les backups. Ça me permettrait d’avoir un système à jour, et surtout de nettoyer les couches de merdier que j’ai accumulé depuis des années sur ce serveur qui me servait de bac à sable. Et au passage, ça me permettrait de refaire un tour sur les différents outils, pour me remettre un peu dedans. Donc je suis parti sur une réinstallation complète du système.
Idéalement je souhaitais ne pas formater le disque, pour avoir un backup supplémentaire, en plus de mes backups manuels. Sur le NUC qui me sert de serveur, le SSD est en mSATA 42mm, très difficile à trouver de nos jours. Un pote m’a déniché un SSD d’occasion piqué sur une tablette Lenovo HS. Je me suis demandé s’il n’était pas temps également de changer de distro. Parce que bon, Debian c’est bien gentil, mais ça reste adapté si on considère légitime de passer sa vie à bricoler sa distro pour réussir à la faire tomber en marche. Ma vie étant déjà suffisamment triste comme ça, je me suis dit qu’il fallait prendre autre chose. J’avais beaucoup entendu parler de CentOS depuis quelques temps, je me suis dit que c’était l’occasion de tester.
Autre évolution à laquelle je pensais depuis longtemps : séparer mon blog et mon site des mes outils perso (gitlab, owncloud). Mon idée était de mettre le blog et le site sur un hébergement tiers, et garder mes outils perso chez moi. Après quelques recherches rapides, le plus simple était de louer une deuxième instance VPS chez OVH, en plus de celle que j’ai déjà. A 4€ par mois, c’est pas la mort. Par contre ça suppose d’être plus rigoureux sur les backups, mais c’est pas la mort non plus.
D’une façon générale, je trouve que cette offre VPS est vraiment intéressante. C’est moins performant qu’un dédié, mais gravement moins cher, et c’est, je trouve, beaucoup plus pratique qu’un hébergement mutualisé, où tu peux pas faire ce que tu veux, les BDD sont configurées jamais comme il faut … Alors oui ça demande plus de temps et de compétence de sysadmin, mais au moins on fait à peu près ce qu’on veut. Après ils ne sont bien entendu pas les seuls à avoir une offre de ce genre, exemple Scaleway.
Concernant CentOS, le changement est douloureux, mais ce n’est pas très surprenant. n’ayant jamais joué avec des distros autres que Debian-based, la réacclimatation n’est pas facile. En plus j’ai décidé de passer direct sur CentOS 8 plutôt que 7, pour m’éviter un upgrade futur, et cette version est pas encore sèche, en plus d’avoir beaucoup de différences avec la précédente qui est beaucoup mieux documentée. Mais j’y reviendrai plus tard.
Dotclear et OVH
Ayant quelques déboires avec CentOS, je me suis dit qu’il valait mieux que je reste sur un système que je connais pour le VPS, donc je suis parti sur Debian Buster. L’installation d’apache s’est bien passée, RAS, puis j’ai mis Dotclear, là ça a été moins évident. Déjà, PHP déconnait, mais c’était parce que j’avais oublié certains modules. Au temps pour moi. Puis j’ai eu des soucis d’affichage, genre quand je faisait dotclear.domain.tld/dotclear ça s’affichait correctement, par contre dotclear.domain.tld je n’avais pas de mise en page, et si j’allais dans un article la mise en page disparaissait également. En fait tout était dans la config de Dotclear, il y a des chemins d’accès à mettre dans les option about:config, et je n’étais pas sur les bons URLs.
Puis il a fallu remonter les backups. Là ça s’est corsé.
La doc de dotclear présente quelques trous … Savoureux. Entre autres, en ce qui concerne les backups, il y a des infos sur les procédures pour effectuer les backups, mais la partie qui concerne la restauration est vide. Grmpf … j’ai donc pris mon bâton de pèlerin et ai écumé les forums pour trouver comment faire. En gros il y avait deux grandes approches : soit en passant par l’interface d’admin, soit en écrasant les données à la rache. J’ai essayé la première méthode, mais il faut upload les datas, sachant que de base l’upload est llimité à quelques Mo, sachant que mon fichier de backup en fait 750 … Clairement, ça ne passe pas :(
Donc j’ai fait la méthode bourin : écrasement du répertoire public d’une part, remplacement de la base de donnée d’autre part. J’ai pris le backup des données, et ai écrasé le répertoire public de Dotclear, puis l’ai repassé en chown -R www-data:www-data. Pour la base de données … c’est plus compliqué. La BDD Dotclear existe déjà, vu que je l’ai créée pour tester “à vide”. J’ai utilisé mysqldump pour écraser son contenu. Et à partir de là, ça a commencé à déconner, le blog s’affichait bien, sauf la barre latérale qui foirait completement, par contre impossible de se connecter à l’interface d’admin, il me disait systématiquement “Wrong login or password”. Je me suis bien pris la tête là-dessus, avant de finir par trouver la solution.
Il faut noter que les login / mot de passe dans Dotclear sont stockés dans la BDD, et les mots de passe sont hashés, à priori en HMAC-SHA1 si on en croit les réponses sur le forum. Or, la seed est écrite en clair dans le fichier inc/config.php. A mon avis il faut remettre la seed qui a servi à générer les hash pour que ça fonctionne, donc récupérer le config.php d’origine. Mais ça ne marchait toujours pas. En farfouinant, j’ai trouvé un script permettant de réinitialiser les mots de passe Dotclear si on a accès au serveur, ce qui est mon cas. A noter qu’il faut modifier le script et donner explicitement l’adresse IP à partir de laquelle on se connecte, sinon il nous jette, précaution appréciable. Mais ça n’a pas marché. Il me trouvait bien l’utilisateur - donc il avait bien accès à la BDD - et me donnait un nouveau MDP, quand je faisais un check dans la BDD je voyais bien le hash se modifier (pour info : table dc_user field user_pwd), mais il me jetait toujours quand j’essayais de me log avec. J’étais parti à réécrire le hash à la main dans la BDD , mais j’ai eu un éclair de génie : j’ai fait un ls -lah et j’ai vu que le script était bien en www-data, mais qu’il était en r seulement. Donc chmod 775 et là ça a marché. Ouf !
Récapitulatif:
- Chopper le script et mettre l’adresse du terminal avec lequel on se connecte au serveur
- Upload dans admin
- chown pour le donner à www-data:
- chmod pour le passer en 775
A la suite de tout cela, j’ai check la barre latérale, et me suis rendu compte que j’appelais un script dans plugins, script custom que je n’avais pas copié, je l’ai donc choppé dans le backup, copié dans plugin, chown pour www-data, et tout est rentré dans l’ordre.
Concernant le site, RAS, j’ai juste copié les fichiers puis chown à www-data. Puis j’ai modifié mes enregistrements DNS chez Gandi pour pointer vers le VPS, qui aura une adresse fixe, donc pas de script updateDNS requis.
CentOS et Gandi
Maintenant l’autre. Bigre, CentOS est vraiment différent de Debian. En plus ils ont ajouté SELinux dans la 8, qui complique beaucoup en bloquant systématiquement plein de trucs. Mais bon, une fois qu’on a compris ce qu’il faut whitelister, on s’en sort. Néanmoins, c’est loin d’être intuitif.
Concernant Owncloud, après avoir bien vérifié plusieurs fois quels modules PHP il faut installer et activer, on arrive à afficher le site. Par contre il faut activer le SSL / HTTPS pour pouvoir y accéder. De une.De deux : il faut remettre en place le script de mise à jour automatique de l’enregistrement DNS, sachant que les interfaces Gandi sont en pleine évolution, et je ne veux pas rester en arrière du progrès.
Bon, j’ai re-généré ma clé d’API, et j’ai essayé de lancer le script d’origine avec la nouvelle clé. Problème : le script me remonte systématiquement une erreur d’authentification …
Bon, je change mon fusil d’épaule : Gandi a amélioré ses outils, et propose maintenant une API RESTful, ce qui est surement très bien vu que j’entends parler d’API RESTful de partout et que ça a l’air d’être LA feature à la mode même si je ne comprends pas du tout ce que c’est. Bref. On trouve maintenant beaucoup plus d’exemples et de scripts pour cette nouvelle interface, par exemple ça, ça ou encore ça que j’ai choisi d’utiliser au final.
Je le lance : erreur 401, googoo me dit : échec d’authentification. Merde !
Je vais dans l’interface Gandi, je génère une nouvelle clé, je la copie dans le fichier de config, sans les guillemets ce coup-ci, là ça marche. Ouiiii !
J’ai ajouté une ligne pour qu’il remplisse un fichier de log, ligne que j’ai repiqué sur mon script d’origine pour XML-RPC:
logging.basicConfig(filename='./livedns_updater.log',level=logging.INFO)
Je fais une tâche cron à 15 minutes pour ça. A noter que pour ce qui est des permissions, on m’a dit “lance ta tâche en root comme tout le monde”. Okay.
*/15 * * * * python3 /usr/local/bin/livedns_updater.py -c config.cfg
Bien, maintenant on peut s’attaquer à Owncloud.
Owncloud et SSL
Mon problème est donc de réussir à faire marcher le putain de HTTPS sur ce nouveau serveur. Pas une mince affaire, surtout que j’ai toujours du mal avec ces histoires de clé de chiffrement et de certificat. Trop abstrait pour moi, je me mélange toujours.
Ne pas oublier Listen 443 dans le httpd.conf ! -> Hum, non, c’était pas ça.
Pour comprendre ce qu’il se passe je suis passé en LogLevel debug sur le vhost, et j’y ai vu quelque chose :
owncloud.domain.tld:443 Cert does not match for name 'owncloud.domain.tld'
A mon avis, quand j’ai généré la clé j’ai indiqué domain.tld, et en fait il fallait explicitement mettre owncloud.domain.tld. Ok, on re-génère … Pareil.
C’est là que j’ai craqué.
Ubuntu Server et Apache
Vu que j’ai toujours l’intention de pouvoir me servir de ce serveur pour des manips perso, je n’ai pas envie de me traîner des problèmes de repos trop vieux, donc plutôt que Debian, je mets une Ubuntu. Compromis acceptable, je pense.
Première action : activer le compte root. Deuxième action : installer UFW. Bien penser à allow le port 22 et / ou OpenSSH avant de l’activer.
Puis installation d’Apache, et allow dans UFW. Faire ufw app list pour avoir la liste des applications autorisables. Je préfère autoriser les applications plutôt que les ports ou les protocoles, mais c’est personnel. Pour Apache yen a 3, Apache Full va allow automatiquement le port 80 et le port 443, les deux autres activent uniquement un des deux. Vu qu’il y a deux mots, il faut mettre le paramètre entre ‘ : ufw allow 'Apache Full'.
Pif paf pouf, Apache est installé. Ensuite on va suivre l’installation de SSL en suivant [ce tutoriel](https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-16-04). Je me rappelle quand j’ai installé mon serveur en 2014 Let’s Encrypt c’était de la science fiction. Que de chemin parcouru depuis. Bref … Si on essaye de mettre des sous-domaines mais qu’ils n’existent pas, il refuse de générer les certificats, donc je reste sur le domaine de base.
On teste la validité du bazar en allant sur https://www.ssllabs.com/ssltest/analyze.html?d=example.com et en remplaçant example.com par son nom de domaine. Par défaut le rating est “seulement” B parce qu’il y a des protocole ‘weak’ qui sont autorisés. C’est pas la mort.
Ensuite je remets le script magique pour le DNS dynamique. A noter : faire un wget en choppant l’URL d’un fichier Github ça ne marche pas, il va télécharger le HTML de la page Github … Donc il faut copier le contenu à la main, ou clone le repo, ou le transférer par FTP. ne pas oublier d’installer python, ça marche mieux avec (il est installé par défaut sur Ubuntu Server).
Bien, nous pouvons désormais nous attaquer à Owncloud. Les repos pour Ubuntu sont là. Le nom du package est owncloud-files.
Ne pas oublier d’installer toutes le dépendances, PHP, mariaDB et cie, voir ici. Attention pour mariadb : ne pas oublier de faire mysql_secure_installation.
Les tutoriels proposent de modifier la conf apache par défaut. Perso je préfère copier les confs (SSL et pas SSL), désactiver les confs par défaut et activer ceux de owncloud que je viens de créer. Ne pas hésiter à faire des systemctl restart. Ensuite, on se connecte et on fait apparaitre l’interface d’install. Petit défaut : un seul champ pour créer le mot de passe du compte principal, donc si on fait une faute de frappe … Ce qui m’est arrivé, heureusement on peut le changer autrement. Pour se connecter c’est forcément en HTTPS.
Bon, maintenant il faut remonter les backups.
Là j’ai eu une erreur étrange : quand on va sur la page la première fois, on lui indique un utilisateur, un nom de BDD et le mot de passe et le user qui va avec. Or, si je mets root en user avec le bon mot de passe, il n’arrive pas à se connecter. Par contre, si je créé un user owncloud et que je lui dit d’utiliser ce user ça marche. Par contre, si j’arrive à me connecter, en fait par la suite ça déconne parce qu’il n’arrive pas à créer les BDD oc_, ce qui n’est pas étonnant vu qu’il n’est pas root dans mysql / mariadb. Très bizarre, mais à priori c’est d\^à une connerie de ma part : n’ayant pas de compte root par défaut après installation de mysql j’ai modifié le MDP “à la main”, et à priori ça a tout cassé. Voir ici. Donc je suis parti pour faire une réparation de mysql : dump, remove, install, restore. Bien entendu ça n’a pas marché, j’ai eu exactement le même problème.
Là, après plusieurs heures à essayer de faire marcher ça, je suis arrivé à la conclusion que j’avais merdé. Et que je n’avais pas d’autre option que de recommencer tout depuis zéro. Encore deux jours de taf de perdus sur une fausse manip.
Je dois avouer qu’ici mon moral est au plus bas. Je commence à sérieusement en avoir plein le cul.
Dépression
Là vraiment j’en ai marre. Ça fait des semaines que je suis dessus, et j’en chie. Rien ne se passe bien, et à chaque petite erreur je me mange des heures de taf pour comprendre ce qu’il se passe, la moitié du temps je ne comprend juste pas ce qu’il se passe et je reset tout, l’autre moitié la solution ne marche pas et je reset tout.
J’ai déjà détruit - je ne vois pas d’autre mot - des dizaines d’heures de ma vie sur cette connerie. Ça ne vaut clairement pas le coup.
Dans Trublion, les autres se sont penchés à un moment sur la mise en place d’un serveur, avec différents services, dans l’optique de pouvoir faire une doc expliquant comment mettre en place un tel serveur, pour d’autres associations. Ce projet a explosé en plein vol, et nous a vraiment fait du mal. J’ai pensé que c’était lié à l’ambition démesurée du projet, trop gros. Mais quand je vois comment j’en chie pour ne serait-ce que faire marcher owncloud … Je me dis qu’il n’y avait aucune chance que ce projet aboutisse. Aucune.
Ne faites pas d’auto-hébergement. Sérieusement : ne faites pas cette connerie. Allez chez google, chez amazon, chez microsoft, je m’en fous, mais ne vous auto-hébergez pas.
Je vais encore laisser une chance. Il faut que ça marche cette fois-ci, sinon je ne pense pas que j’aurai la force de repartir, et je vais tout abandonner. Et je n’ai aucune idée de ce que je vais bien pouvoir faire pour pouvoir à nouveau bosser. J’en suis à un point où je suis prêt à payer de l’hébergement pour avoir un owncloud déjà tout fait, et faire du gitlab.com ou me jeter sur github tellement j’en ai marre.
Troisième tentative avec owncloud
Cette fois je vais suivre strictement un tuto étapes par étapes, en n’en déviant surtout jamais, ne surtout pas essayer de lancer une autre install en parallèle, en réfléchissant à chaque fois si il ne manque pas des choses par rapport à tout ce que j’ai enduré jusque-là. Celui-là a l’air de coller. Par contre, il manque la procédure pour générer les clés de chiffrement. Grrr … A cause de ça je suis obligé de diverger du tutoriel la putain de sa mère.
J’en ai marre, je laisse tomber let’s encrypt, il me fait chier avec des histoires de DNS. Je repars sur un certificat auto-signé.
Bon, une fois le certificat créé ça se passe mieux. Mais ça continue à merder au niveau du NDD, il ne prend pas en compte le sous-domaine. RRRAAAAAAAH …
Je prend un ou deux jours sans y toucher, pour redescendre un peu. Entre-temps j’en ai parlé avec des membres du Lab, et ils m’ont expliqué que, dans Ubuntu, il y a un système de sache DNS qui fout le bordel dans les résolutions d’URL, et que mon problème de sous-domaine qui ne marche pas doit très probablement venir de là. Ils m’ont aussi dit qu’il était horriblement difficile de le désactiver. Voilà voilà voilà. Ils m’ont aussi dit qu’il était tout a fait souhaitable de supprimer SELinux, ou au moins le désactiver pendant qu’on fait des installations.
Donc : dilemme. Je suis parti à tout réinstaller, encore, mais est-ce que je mets une Debian pour revenir sur quelque chose que je connais, ou bien est-ce que je re-tente ma chance avec Centos sans SELinux ?
Vu que je ne suis plus à une réinstallation près, je décide de laisser sa chance à Centos.
Je réinstalle donc tout. Premier truc à faire : mettre SELinux en Permissive, avec la commande \@setenforce Permissive@@, comme ça il me bloquera pas, il couinera seulement si ya des trucs qui lui plaisent pas. Et comme d’hab : config de ssh pour interdire les connections root.
Puis je suis ce tuto. Je vois bien la page de test, tout va bien. Je ne la trouve pas dans /var/www/html d’ailleurs, cette page de test, mais bon …
Puis je suis [ce tuto pour mariadb et PHP](https://linuxconfig.org/how-to-install-lamp-on-redhat-8), puis celui-là pour Owncloud. Étonnamment, ici et contrairement à ma tentative précédente avec Centos, je n’ai pas eu de soucis ni pour que Owncloud accède à la BDD sans être root, ni pour arriver à me connecter en http pas s. Comme quoi SELinux devait être l’agent du chaos. Bref.
Maintenant, mettre un vhost adapté, et https, quand-même. Vu que ce n’est pas pour de l’accès public, je vais me faire un certificat auto-signé (et d’ailleurs, tant que j’y pense et vu que c’est la tendance, il faudra aussi que je mette un certificat et du https sur mon VPS pour mon blog et mon site, mais on verra ça plus tard). Quand j’aurai ça de fonctionnel, je ferai des essais pour comprendre comment générer un certificat fonctionnel pour Let’s Encrypt, parce que c’est pas du tout trivial. On va suivre ce tuto. Pour ne pas m’embêter, je ne vais pas faire de sous-domaines, je vais tout laisser en sous-répertoires de mon nom de domaine principal. Ça sera moins joli, mais je m’en fous, c’est que pour moi. Je suis aussi allé sur le générateur de config de Mozilla, histoire de piquer des cyphers kivonbien.
Bon, maintenant il faut que je rapatrie le backup.
Owncloud backup restore - Rambo edition
Je pars donc d’un backup d’une version 9.1.6.2, pour aller vers une 10.3.2.2. La procédure officielle pour un restore est ici. En essayant le restore de la base de donnée en direct, je me prend une erreur “foreign key error”. En suivant ce post, je teste la suppression de la table oc_persistent_keys. Je restart httpd, ça n’affiche rien. Grmpf ?
(Je me demande s’il ne serait pas plus judicieux d’installer un owncloud de la version du backup, de restore, puis de faire un upgrade)
Trêve
Là nous étions en février. Je commençais à en avoir passablement ras-le-bol, quand le ventilateur du NUC qui me sert de serveur a décidé de se manifester bruyamment. Il grattait déjà légèrement, mais là le bruit devenait insupportable, beaucoup trop fort. Il faut dire qu’il tourne H24 depuis plusieurs années, il doit finir par en avoir marre.
Je l’ai donc démonté, et j’ai essayé de mettre un peu d’huile de vaseline pour le lubrifier. Ça l’a calmé pendant quelques heures, puis il est reparti à faire un boucan infernal. Misère …
Ce genre de ventilateur n’est pas très courant, tout plat et petit comme ça, ce n’est pas un ventilateur de laptop. J’ai cherché la référence sur internet, et il se trouve qu’il y en a des neufs en vente sur ebay / amazon. Mon collègue de boquette ayant un compte amazon, je lui ai demandé s’il pouvait y ajouter sur sa prochaine commande. Le délai de livraison était donné pour 3 semaines, pour un prix, hum, non négligeable de 16€ . Mais bon, pas trop le choix. Ça c’était début mars. Puis il y a eu le confinement …
Ellipse jusqu’à fin juin, réception du colis. Je change le ventilateur, et je pose le NUC dans un coin, je m’en occuperai plus tard.
Ellipse jusqu’à fin juillet, je me décide à remettre mon serveur en route, je l’allume, et il se met à faie un boucan monstrueux. WTF ? Je checke le ventilateur, il a l’air de yoyoter à vide, pas bon ça … Je checke l’ancien que j’avais gardé, il semble plus rigide. Alors quoi, je me suis fait refourguer un ventilateur défectueux ? Ils ne sont pas strictement identiques au niveau étiquetage, donc ça peut être deux lots différents. Bon, je remets “l’ancien”, il gratte légèrement, mais largement pas aussi fort que l’autre. peut-être ma mémoire me fait des tours, et j’ai cru changer le ventilateur alors que je ne l’avais pas fait ? Bon, toujours est-il que le grattement est hautement désagréable, et qu’il faut que je fasse quelque chose. Je décide de NOYER l’axe dans l’huile de vaseline. Et depuis il est beaucoup plus silencieux :)
Je reprends donc à “owncloud est installé mais il refuse de fonctionner”. Je savais déjà que Nextcloud avait une réputation d’être plus récent, mieux suivi, mieux foutu. Je regarde les dernières release : Nextcloud moins d’une semaine, Owncloud plus d’un an. Ah oui …
Bon, je teste 2-3 configs, amarchepa, ça me saoule, je passe à Nextcloud. Tant pis pour le backup, je rajouterai les fichiers à la main, et je reconstruirai mes notes et mes calendars.
Nextcloud
Installation sans souci, juste faire attention, au premier affichage de la page, le choix de la BDD est masqué sous un onglet qu’il faut cliquer, ce que je trouve ultra-piégeux. Je me suis fait avoir la première fois, et par défaut il met SQlite, donc j’ai dû tout désinstaller. j’ai installer à partir des sources, il n’y a pas de paquet tout fait pour centOS à ma connaissance.
Et là, et là ! Là ça marche sans (trop) faire d’histoires. Et c’est effectivement très moderne en apparence, mais en fait c’est quasiment identique. L’app Rainloop est identique, j’ai essayé l’app mail “intégrée”, mais on ne peut pas enregistrer plusieurs comptes, donc ça ne m’intéresse pas, je n’ai pas envie de passer mon temps à retaper mes credentials.
Truc qui m’a pris un peu de temps : monter mon NAS en SMB. Bon, en fait c’est surtout que la doc manque de quelques détails. Comme le fait qu’il faut installer samba-client pour que ça marche :-/ Ou alors je l’ai raté, hein ? Tout à fait possible. note : dans le champ “Domain”, on peut ne rien remplir. Et dans mon cas il ne faut rien mettre.
Notes : comme on aurait pu s’en douter, bien entendu les fichiers de notes sont en HTML sur Owncloud, et en TXT sur Nextcloud … Donc il faut tout convertir. Je pense faire un passage dans Notepad++, CTRL-H et remplacer tous les \<p> et \</p> par des vides, ça me semble la méthode la plus rapide.
D’une façon générale, rapatrier des données “à la main” n’est pas très compliqué, on peut copier des fichier directement dans les répertoires data correspondant, et faire un coup d’occ pour lui faire scanner les nouveautés: sudo -u apache php occ files:scan
Calendar : là pas de secret, il faut tout refaire. Il faut surtout que je reconfigure mon caldav sur mon téléphone pour la nouvelle adresse. Ça n’a pas été très compliqué. Mais je n’ai pas pu réintégrer mes calendriers précédents :( Donc les anciens (sauvés en local sur mon téléphone) et les nouveaux vont cohabiter un moment le temps de migrer.
ATTENTION ATTENTION !! La synchro avec les clients est assez foireuse. Tant que je n’ai pas touché la config précédente, j’avais plein de messages d’erreur sur mon téléphone, mais les RDV restaient en mémoire. Mais à partir du moment où j’ai changé pour switcher sur les nouveaux caldav, ils ont été effacés ! Argh ! Donc la prochaine fois, penser à faire un backup avant de faire des manips.
Tâches : l’avantage du caldav, c’est que j’ai tout le contenu en local dans mon téléphone et surtout mon PC fixe, donc je fait du copypasta, je recréé les tâches, je copypasta le contenu, et voilà. C’est pas très élégant, mais c’est efficace.
NDD
Dans l’interface de Gandi, ne pas oublier de mettre un enregistrement en A pour *.domain.tld, histoire qu’il gère tous les sous-domaines.
Gitlab
J’installe, c’est un peu long mais ça se passe bien. Un truc quand-même à faire attention : il y a une version entreprise (Entreprise Edition, EE) et une version “perso” (Community Edition , CE). Ces deux versions ont des repos distincts, mais seule la version EE est dispo sur le site a priori. Et de ce que j’ai compris, en fait le tronc commun est le même, c’est juste que certaines options ne sont pas disponibles sans licence. Ça me va.
Ne pas oublier de désactiver le serveur nginx que Gitlab installe automatiquement par défaut.
Nouveau challenge, comme si c’était pas suffisant: je n’ai pas fait de backup de Gitlab. Mais j’ai gardé le disque, donc il faudrait que j’arrive à en extraire ce que j’ai besoin pour remonter un backup. Faire du chroot ? Grmpf, ça va être charmant …
Déjà, les recommandations sont assez rigides.
Je remarque que les data de Gitlab, et donc les repositories, sont stockées dans /var/opt/gitlab. Or, il semble possible d’importer des repos directement. Je pense que je vais explorer cette voie.
Récupération des backups
Or donc, j’ai l’ancien disque dur, qui est en format M2 “court” de 40mm (de tête), ce qui est rare en ce moment. Je l’ai monté dans un boîtier M2-USB. Vu que c’est le filesystem Linux en direct, bien entendu windows ne le reconnaît pas. Sous Linux par contre, on va faire un fdisk -l pour identifier les disques disponibles. je l’ai monté en direct sur un port USB du serveur, donc il le voit en /dev/sdb. Attention piège : il ne faut pas essayer de monter /dev/sdb en direct, ça envoie un message d’erreur, car ce n’est pas un système de fichiers unique, mais ça contient les différents disques du Debian. Pour avoir le détail on fait un lsblk -f, ce qui va afficher tous les disques, ainsi que les partitions et leur système de fichier. Sur ce disque, cela me donne:
sdb
├─sdb1 vfat 1C2C-8426
├─sdb2 ext2 b07f25f3-3aae-4481-8f19-537b37458cad
└─sdb3 swap 20540275-0d78-4b8d-b048-c74dbe927a68
Et donc, les données qui m’intéressent sont dans le disque “de données”, qui est celui en EXT4. Donc on fait un mkdir /mnt/usbdrive et un mount /dev/sdb/sdb2 /mnt/usbdrive pour le monter, et là on y a accès.
Retour à Gitlab
Bien, maintenant que j’ai monté mon ancien disque, il est temps d’aller voir ce qu’on trouve dans /var/opt/gitlab/git-data/repositories. Là je retrouve les repositories, classés par répertoires en rapport au groupe dans lequel ils étaient. Bien bien. Ensuite, il y a un fichier .git par repository, et un pour chaque wiki. Bon, si on suit la doc Gitlab il faut donc copier les répertoires et fichiers dans /var/opt/gitlab/git-data/repositories, modifier les attributions à git via chown -R git:git, puis on passe le programme d’import : gitlab-rake gitlab:import:repos['/var/opt/gitlab/git-data/repositories/<repertoire>']. Ca me sort plein d’erreurs, mais bon, essayons quand-même. Je repasse dans l’interface, en admin, et je vais dans ‘Projetcs’, et je vois les projets sous “Administrateur”. Bien bien bien bien. Je les transfère, à la main (pfff …), sous les groupes kivonbien.
Bon, ça été très laborieux, mais j’ai quand-même récupéré les repositories. Par contre, pas les issues … Grmpf …
D’une façon générale, il faut noter que Gitlab est trèèèèès leeeeent à démarrer. Après un reboot serveur, qui ne dure que 1 ou 2 minutes, il faut bien attendre 5-10 minutes que Gitlab soit up. Ce qui n’est pas très surprenant, Gitlab est connu pour être très gourmand en ressources. Par contre, il ne faut pas se faire avoir, après un reboot il va afficher une erreur 502 pendant longtemps avant d’être prêt.
Autre chose à noter, qui m’embête un peu avec Centos et yum / dnf : j’ai l’impression que ça arrive souvent qu’il n’installe pas les dépendances. Genre là je me rends compte qu’installer Gitlab n’a pas installé Git … C’est con ! Donc il ne faut pas oublier de l’installer manuellement à côté.
Conclusion
J’ai réussi à remonter mes services. Je suis content. Mais j’en ai chié. Et j’ai perdu des choses en route.
J’ai définitivement migré sur CentOS, ça marche bien mieux que Debian je trouve. J’en suis à me demander si le fork Devuan n’a pas foutu la merde, parce que ça tournait pas mal avant quand j’ai monté mon serveur la première fois.
Ce qu’il faut retenir à mon avis, c’est que les backups sont d’une importance vitale, mais ça n’a rien de nouveau.
Bon, content d’en avoir fini avec ce sujet. Pour le moment …