Derniers messages
#71
Programmation / Re : Xen
Cliquez pour afficher le message
Utilisez-vous lvm ?
Reste-t-il de la place sur le disque ?
Essayez de lancer vos commandes dans un screen ou un tmux comme ça s'il casse la session c'est le screen ou le tmux qui déconnecte et pas la connexion ssh.
Que disent les logs quand vous essayez de lancer xend ?
Reste-t-il de la place sur le disque ?
Essayez de lancer vos commandes dans un screen ou un tmux comme ça s'il casse la session c'est le screen ou le tmux qui déconnecte et pas la connexion ssh.
Que disent les logs quand vous essayez de lancer xend ?
#72
Programmation / Re : Xen
Cliquez pour afficher le message
moi je pense qu'à ce stade, le plus simple est de faire les migrations directement sans s'occuper de xen dans un premier temps :
1 - désinstaller xen et ne garder que des noyaux non xen
2 - migrer squeeze->wheezy->jessie->stretch
3 - installer xen
4 - réparer les VM
1 - désinstaller xen et ne garder que des noyaux non xen
2 - migrer squeeze->wheezy->jessie->stretch
3 - installer xen
4 - réparer les VM
#73
Programmation / Re : Xen
Cliquez pour afficher le message
CitationSalut les gars,Y'a aussi des filles
Y'aurais pas le mail, je te proposerais de faire moi-même la migration
Mais il y a moyen de migrer l'hyperviseur en laissant les VM avec de vieilles versions d'OS (pour commencer).Bon, déjà, c'est assez sûr, Xen n'est pas lancé. Ça c'est le tout premier point. D'ailleurs... Du coup les mails et l'app ne fonctionnent pas ? ou si ? Si oui, il se passe un truc réellement étrange (mais je ne connais pas votre archi, si vous avez plusieurs serveurs par exemple qui font de la redondance ?)
Je ne sais pas combien tu as d'utilisateurs qui risquent d'être impactés par les bidouilles. Si c'est du genre petite asso, que les mails, app et site soient indisponibles quelques heures voir quelque jours est acceptable, s'il y a des "clients" ou beaucoup de monde ça sera plus délicat. Quoi qu'il arrive, communique en amont parce qu'il va y avoir des interruptions de service, c'est assez sûr. Ça passera mieux si les gens sont prévenus. Sans entrer dans les détails techniques forcément (la plupart des gens n'y comprennent rien et s'en moquent), mais donne une durée potentielle pour les "troubles" et prévoit large.
Ensuite, vu les bidouilles à faire, la première chose à vérifier est que ton système de backup marche bien.
Une fois la partie "backup" vérifiée, et les utilisateurs prévenus, on va pouvoir passer aux bidouilles en tout genre.
Là, je te conseillerais bien de tester en local ou sur un second serveur d'installer une debian+Xen à jour, puis de transférer des clones de tes VM, de les lancer et de voir si ça tourne (sans faire de mise à jour sur les VM même, encore une fois ; y'aura que l'hyperviseur à jour).
Si vous avez des sous, prendre un second serveur est vraiment le meilleur plan, vous résilierez le précédent à la fin si tout se passe bien.
Les noms de domaines ne seront pas bons sans les redirections DNS (et à ce stade osef), donc il y aura des erreurs, mais voir si côté système tout marche, déjà : xen se lance, les vm se lancent, elles ont un lot d'erreur "logiques", elles arrivent à communiquer avec le reste d'internet. Si c'est le cas, double allelluia : ça supportera l'upgrade, ce qui veut dire un hyperviseur qui ne sera plus exposé à diverses failles de sécurités, et tu auras un truc fonctionnel en backup. Et quelque part, ta migration aura commencé sans en avoir l'air. Mais pour cloner une VM, il faut l'éteindre... Si Xen est down en principe elles ne sont donc pas lancées. J'espère qu'elles utilisent LVM, parce que dans ce cas, il suffit de suivre ce tuto (et il y a probablement plus élégant, mais chez nous ça a marché).
Note qu'en gros je te conseille de faire une migration en mode pas à pas
mais je pense vraiment que c'est le mieux à faire ; il y a vraiment pas mal de trucs de sécu corrigés dans les dernières versions de Debian et de Xen (et avec ssh aussi, arghhhh). Il est possible que vos soucis viennent de l'exploitation d'une faille : on ne va pas psychoter sur ça (y'a pleins de raisons possibles), mais le mieux est de mettre à jour sans transférer d'éventuels trucs compromis, donc de partir d'un hyperviseur neuf, où tu vas remettre tes règles iptables en regardant bien ce qui est ouvert et pourquoi, transférer les éventuels scripts en vérifiant qu'ils ne sont pas corrompus, et laisser tout ce qui est système sur l'ancien serveur. Cette partie là n'est pas complexe, promis, il faut juste prendre le temps de vérifier au fur et à mesure que tout marche comme attendu.Si ces étapes-là fonctionnent bien, on pourra voir pour mettre aussi les VM à jour. C'est le passage le plus délicat. Celle dont tu dis "qui gère les noms de domaines" j'imagine que c'est le proxy ; s'il est bien pensé, ça sera facile à mettre à jour et augmentera considérablement la sécurité de l'ensemble. Par contre, le mail, je ne touche pas, je sais juste que c'est complexe. Et l'app, suivant le langage et ce qu'elle fait, idem, ça peut être facile ou complexe. Mais là aussi, il y a des astuces pour tenter une mise à jour sans tout casser irrémédiablement, grâce aux snapshots et clones. Pour te donner un ordre d'idée, nous avons eu un souci similaire avec notre site internet, qui héberge divers CMS. L'upgrade risquait de mettre un bazar monstrueux. Nous avons donc laissé tourner l'ancienne VM, et à côté nous avons créé une seconde VM, où on a installé tous les CMS, puis transférer les données. Lorsque cette seconde VM a été opérationnelle (et à jour), on a mis la précédente en lecture seule, fait une dernière synchronisation des données, changé la redirection et hop ! c'était à jour. Bon, avec les moyens de bénévoles sans trop de temps et pas toujours toutes les compétences, mettre cette VM en place aura demandé quasi un an de tâtonnement... mais on y est arrivé
Bon courage, on reste présent pour aider. N'hésite pas sur toutes les questions, si ça va trop vite, ou au contraire si on te dit des trucs un peu trop évident. On peut aussi solliciter un réseau de sysadmin pour voir si quelqu'un serait dispo pour vous faire ça, mais uniquement si ça te semble la chose à faire : personnellement je n'aime pas que les inconnus puissent tripatouiller mes serveurs et tous les sysadmins de Khaganat ont mis du temps avant d'accéder à nos machines, le temps de bien se connaître.
#74
Programmation / Re : Xen
Cliquez pour afficher le message
Salut les gars,
Merci pour vos réponses.
C'est un serveur qui est sous Debian 6.0.10. Oui je sais c'est très très vieux avec un Xen 4.0. A vrai dire, on n'a jamais fait de migration de peur de tout casser car dessus on a une VM qui gère les noms de domaines et une autre pour les mails et une autre pour une app.
Alors pour répondre à vos interrogations :
uname -a renvoie:
Linux xxxx 2.6.32-5-xen-amd64 #1 SMP Fri May 10 11:48:05 UTC 2013 x86_64 GNU/Linux
xm list renvoie:
Error: Unable to connect to xend: Connection refused. Is xend running?
(ou xl list c'est pareil)
Et si je fais un simple xend --version, il se déconnecte de la session ssh.
Nous ne saurions pas faire une migration. Si vous connaissez quelqu'un qui pourrait le faire, moynnant rémunération, ça peut nous intéresser.
Merci,
Mdouke
Merci pour vos réponses.
C'est un serveur qui est sous Debian 6.0.10. Oui je sais c'est très très vieux avec un Xen 4.0. A vrai dire, on n'a jamais fait de migration de peur de tout casser car dessus on a une VM qui gère les noms de domaines et une autre pour les mails et une autre pour une app.
Alors pour répondre à vos interrogations :
uname -a renvoie:
Linux xxxx 2.6.32-5-xen-amd64 #1 SMP Fri May 10 11:48:05 UTC 2013 x86_64 GNU/Linux
xm list renvoie:
Error: Unable to connect to xend: Connection refused. Is xend running?
(ou xl list c'est pareil)
Et si je fais un simple xend --version, il se déconnecte de la session ssh.
Nous ne saurions pas faire une migration. Si vous connaissez quelqu'un qui pourrait le faire, moynnant rémunération, ça peut nous intéresser.
Merci,
Mdouke
#75
Programmation / Re : Xen
Cliquez pour afficher le message
Bonjour,
Il manque quelques informations pour pouvoir te répondre :
Sur quel système d'exploitation tourne ton Xen ?
Quelle est la version de ton système d'exploitation ?
Que retourne la commande uname -a ?
Nota: attention toutefois, ta version de Xen n'est plus maintenue depuis 2015, la préparation et l'exécution d'une mise à niveau est plus que recommandé.
https://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases
Nota 2: Le passage de Xen 4.0 a Xen >= 4.1 entraîne le changement des commandes de Xen.
https://wiki.xenproject.org/wiki/Migration_Guide_To_Xen4.1%2B#Toolstack_upgrade_notes
Il manque quelques informations pour pouvoir te répondre :
Sur quel système d'exploitation tourne ton Xen ?
Quelle est la version de ton système d'exploitation ?
Que retourne la commande uname -a ?
Nota: attention toutefois, ta version de Xen n'est plus maintenue depuis 2015, la préparation et l'exécution d'une mise à niveau est plus que recommandé.
https://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases
Nota 2: Le passage de Xen 4.0 a Xen >= 4.1 entraîne le changement des commandes de Xen.
https://wiki.xenproject.org/wiki/Migration_Guide_To_Xen4.1%2B#Toolstack_upgrade_notes
#76
Programmation / Re : Xen
Cliquez pour afficher le message
xm list ou xl list ? De notre côté on utilise xl, donc il va probablement falloir adapter ce que je raconte... Pour info, notre hyperviseur est en 4.8.4 sur une base Debian donc on va probablement avoir des différences dans certains trucs.
Je ne suis pas sûre de bien comprendre, je vais reprendre et tu me corriges si je me trompe. Votre hyperviseur est donc avec Xen 4.0. Déjà, de ce côté, il tourne bien ? Il répond ? Oublions les VM pour le moment, tant qu'il ne fais pas de message d'erreur et affiche dom0/Domaine-0 avec xl list, c'est déjà bon. Nous avions eu des soucis à un moment parce que le grub redémarrait sur le mauvais noyau (donc sans Xen) et à partir de là, forcément, rien ne marchait. De ce que je comprends, c'est déjà un premier souci si xm list ne marche pas ? Par contre c'est étrange que ça déconnecte la session ssh ; ça voudrait dire un gros plantage.
Je t'avoue aussi mon ignorance sur la commande "rmp qa xend", elle est sensée faire quoi ? Tu as le droit de me renvoyer sur la bonne entrée de manuel, hein mais ça clairement, on n'a pas eu l'occasion de jouer avec.
Si jamais c'est l'hyperviseur qui a un souci (et non la VM, même si ça peut être lié), tout dépend de ce qui est en cause. Avec un peu de chance, c'est juste grub (ou autre bootloader) qui est sur la mauvaise entrée, ce qui est à vérifier en premier, et je crois qu'on avait noté les manip dans le tuto sur le wikhan (mais pour être honnête on avait galéré un moment). Les options de notre hébergeur pour monter le disque en chroot avait bien aidé parce qu'on avait réussi à bloquer le démarrage...
Je ne suis pas sûre de bien comprendre, je vais reprendre et tu me corriges si je me trompe. Votre hyperviseur est donc avec Xen 4.0. Déjà, de ce côté, il tourne bien ? Il répond ? Oublions les VM pour le moment, tant qu'il ne fais pas de message d'erreur et affiche dom0/Domaine-0 avec xl list, c'est déjà bon. Nous avions eu des soucis à un moment parce que le grub redémarrait sur le mauvais noyau (donc sans Xen) et à partir de là, forcément, rien ne marchait. De ce que je comprends, c'est déjà un premier souci si xm list ne marche pas ? Par contre c'est étrange que ça déconnecte la session ssh ; ça voudrait dire un gros plantage.
Je t'avoue aussi mon ignorance sur la commande "rmp qa xend", elle est sensée faire quoi ? Tu as le droit de me renvoyer sur la bonne entrée de manuel, hein
mais ça clairement, on n'a pas eu l'occasion de jouer avec. Si jamais c'est l'hyperviseur qui a un souci (et non la VM, même si ça peut être lié), tout dépend de ce qui est en cause. Avec un peu de chance, c'est juste grub (ou autre bootloader) qui est sur la mauvaise entrée, ce qui est à vérifier en premier, et je crois qu'on avait noté les manip dans le tuto sur le wikhan (mais pour être honnête on avait galéré un moment). Les options de notre hébergeur pour monter le disque en chroot avait bien aidé parce qu'on avait réussi à bloquer le démarrage...
#77
Programmation / Xen
Cliquez pour afficher le message
Bonjour,
Nous avons un serveur sous Xen 4.0 qui date de 2012.
Suite à une copie de machine virtuelle, il y a un soucis quand on souhaite administrer la machine
Tout d'abord il semble que Xend ne soit plus lancé puisque que lorsqu'on fait rmp qa xend, on n'obtient rien.
Idem si on fait xm list, il n'y a pas de retour et plus inquiétant, la session ssh est déconnectée.
Si quelqu'un a une piste ?
Merci;
mdouke
Nous avons un serveur sous Xen 4.0 qui date de 2012.
Suite à une copie de machine virtuelle, il y a un soucis quand on souhaite administrer la machine
Tout d'abord il semble que Xend ne soit plus lancé puisque que lorsqu'on fait rmp qa xend, on n'obtient rien.
Idem si on fait xm list, il n'y a pas de retour et plus inquiétant, la session ssh est déconnectée.
Si quelqu'un a une piste ?
Merci;
mdouke
Dernier message par Stan` - 23 Octobre 2018 à 13:31:18
Cliquez pour afficher le message
Citation de: deed le 23 Octobre 2018 à 12:20:50
J'aimerai votre point de vue sur : "comment rendre compatible Godot au shard puis à Nel".
Il y plusieurs facteurs à prendre en compte, beaucoup de fonction du shard peut être désactiver dans les .cfg pour aider au portage.
Le login python de Tycho a été porté en Gdscript par Stan mais utilise le système actuel en PHP.
Une petite précision concernant le port du script de Tycho. Le mien ne supporte pas le chiffrement coté client. J'ai juste ajouté la possibilité de se connecter en HTTPS en envoyant en clair les credentials. Si chiffrement supplémentaire il doit y avoir, on pourra envisager de générer des clés publiques et privées de chaque coté, avec la clef publique du serveur déjà connue par les client. Cependant je ne sais pas si c'est possible avec le code actuel de Godot, et il ne me semble pas.
De toute façon on aura besoin de chiffrement pour XMPP. Il sera peut être interessant de porter libsodium en GDNative, et d'utiliser ça.
Citation de: deed le 23 Octobre 2018 à 12:20:50
La première partie serait :
- Nettoyer la DB SQL actuel
- Créer un mini-site Django pour remplacer le PHP (création de compte, ...)
- Relier Godot à Django donc avoir un login complet
- Désactiver les contrôles du shard
Cette liste demande peu de dev , au niveau du code openNel !
Mais on peut aussi choisir de changer mysql pour autre chose qui demandera de changer la librairies du shard donc "beaucoup plus" de travail C++.
Puis on réactive petit à petit les services porter dans godot qui demanderont des compétences de Dev.
Dango doit contenir :
- une installation facile (à coté du shard)
- les services minimum (création de compte )
- passage de apache2 à nginx ?
La suite est la connexion UDP de Godot ......
A vos clavier, bon Dev !
Je pense que dans les services minimum il devrait y avoir au moins
- Login
- Création de Compte
- Reset du mot de passe
Afin que on puisse avoir une interface godot complètement fonctionnelle.
De ce que j'ai compris on laisse tomber Snowball et on repart sur lyrria ?
Dernier message par deed - 23 Octobre 2018 à 12:20:50
Cliquez pour afficher le message
J'aimerai votre point de vue sur : "comment rendre compatible Godot au shard puis à Nel".
Il y plusieurs facteurs à prendre en compte, beaucoup de fonction du shard peut être désactiver dans les .cfg pour aider au portage.
Le login python de Tycho a été porté en Gdscript par Stan mais utilise le système actuel en PHP.
La première partie serait :
- Nettoyer la DB SQL actuel
- Créer un mini-site Django pour remplacer le PHP (création de compte, ...)
- Relier Godot à Django donc avoir un login complet
- Désactiver les contrôles du shard
Cette liste demande peu de dev , au niveau du code openNel !
Mais on peut aussi choisir de changer mysql pour autre chose qui demandera de changer la librairies du shard donc "beaucoup plus" de travail C++.
Puis on réactive petit à petit les services porter dans godot qui demanderont des compétences de Dev.
Dango doit contenir :
- une installation facile (à coté du shard)
- les services minimum (création de compte )
- passage de apache2 à nginx ?
La suite est la connexion UDP de Godot ......
A vos clavier, bon Dev !
Il y plusieurs facteurs à prendre en compte, beaucoup de fonction du shard peut être désactiver dans les .cfg pour aider au portage.
Le login python de Tycho a été porté en Gdscript par Stan mais utilise le système actuel en PHP.
La première partie serait :
- Nettoyer la DB SQL actuel
- Créer un mini-site Django pour remplacer le PHP (création de compte, ...)
- Relier Godot à Django donc avoir un login complet
- Désactiver les contrôles du shard
Cette liste demande peu de dev , au niveau du code openNel !
Mais on peut aussi choisir de changer mysql pour autre chose qui demandera de changer la librairies du shard donc "beaucoup plus" de travail C++.
Puis on réactive petit à petit les services porter dans godot qui demanderont des compétences de Dev.
Dango doit contenir :
- une installation facile (à coté du shard)
- les services minimum (création de compte )
- passage de apache2 à nginx ?
La suite est la connexion UDP de Godot ......
A vos clavier, bon Dev !
Dernier message par Zatalyz - 16 Octobre 2018 à 10:15:01
Cliquez pour afficher le message
Quid de la gestion de plusieurs projets et sous projets, des groupes ? Le système de ticket est-il au niveau de celui de Gitlab, avec possibilité de référence, méta-ticket (on ferme un ticket, ça le note comme fait dans la liste d'un autre ticket), tickets privés et publics ? Comment sont gérés les artefacts ?
