Derniers messages
Dernier message par Tycho - 11 Février 2020 à 11:32:45
Cliquez pour afficher le message
Citation de: Zatalyz le 30 Janvier 2020 à 21:02:30
À noter qu'il faudra avoir un second serveur juste pour les sauvegardes ; là on peut rester sur du kimsufi ou autre pas cher mais avec de la place.
Je me permet de préciser que Online.net fournit gratuitement un espace de stockage FTP avec chaque serveur. Certes, ce n'est que du FTP (connexion non sécurisée), mais il est tout à fait envisageable de chiffrer les sauvegardes avec une clé OpenPGP avant de les envoyer. Si l'espace gratuit n'est pas suffisant, il est possible d'en commander d'autre en payant un peu. Ce sera toujours moins cher qu'un vrai serveur.
Ceci dit, prendre plusieurs serveurs est tout à fait envisageable. À ce sujet, et toujours en ne considérant que le cas d'Online.net, je recommande de se focaliser sur les serveurs disposant du RPNv2. Cette technologie permet d'avoir une seconde interface réseau qui relie ensemble toutes les machines dont nous disposons, et ce de manière sécurisée. Dans le cas où nous utiliserions Proxmox il serait alors possible de créer un cluster utilisant cette interface pour communiquer. Les avantages d'une telle configuration sont, d'une part, la simplicité et l'automatisation des sauvegardes qui seraient alors gérées par Proxmox et, d'autre part, la simplicité de migration future de l'infra (ajout/retrait de machines au cluster, déplacement transparent de VM/conteneurs d'une machine à une autre, etc).
Seul désavantage du RPNv2 : toutes les offres ne peuvent pas en disposer et celles qui le peuvent ne sont pas les moins onéreuses. D'après la FAQ du RPNv2, il existe une option de compatibilité avec le RPNv1, mais là encore les machines qui en disposent ne sont pas les premiers prix.
Dernier message par Zatalyz - 05 Février 2020 à 11:37:49
Cliquez pour afficher le message
J'avais ouvert un message dans la section réservée aux sysadmins, mais je me rends compte qu'il y a un peu plus à faire que juste gérer le déploiement. Il est possible que certaines ici aient envie de participer au code de Django. Vous êtes bienvenue ! Même s'il s'agie de donner juste votre avis.
Ce site (code) s'appelle Khaganat-Web.
Ressources
Vous trouverez le code ici : https://git.khaganat.net/Tycho/khaganat-web
Et pour la doc, les explications :
https://khaganat.net/wikhan/fr:khaganat_web
Cette page peut aider les moins expertes avec Django, mais, dans ce cas, ça sera peut-être juste laborieux de contribuer : le but ici est de coder, et suffisamment bien pour que Tycho accepte vos pull request
La version "en test" est visible sur Cipra : https://cipra.khaganat.net/
Les trucs à faire
Cette section mériterait peut-être des tickets dans la partie gitlab... Mais je réfléchis mieux sur forum.
Pour les techs
- Ajouter le contenu qui est déjà présent sur la partie du site qui sera remplacé. La liste est visible (hem) sur https://khaganat.net/bienvenue/fr:start?do=index ; soit 3 pages, chacune déjà traduite en français et en anglais. Il reste en fait uniquement la page sur le financement à transvaser... le reste est moins tech. Faut retrouver un truc similaire à https://khaganat.net/bienvenue/fr:soutien avec mise en avant de Helloasso et Redbricks. On a le droit de changer des aspects visuellement, tant que ça obéit à la même logique de manipulation mentale. Fait
- Pour la partie "flux rss" sur la page d'accueil, pour le moment Khaganat-Web ne lit pas le flux rss, donc autant remplacer ça par un lien vers le blog directement. Fait
- Arriver à lire un flux RSS et l'afficher. Et le paramétrer.
- Modifier le plugin dokuwiki qui permet de se connecter à Django. Tycho a amélioré la sécurité sur Khaganat-Web, ce qui fait que le plugin de base ne marche pas directement", mais il semblait dire que ce n'était pas très complexe à adapter. C'est plus du php que du django, là.
- Adapter les règles nginx à Apache. Notre serveur web utilise apache (parce que pleins de cms sont fait pour lui), et après discussion c'est plus simple dans ce sens là. Voir ici pour la doc django.
-Pied de page : je n'ai pas vu son module dans l'administration du site. Où modifie-t-on les liens ? La page "licences" doit pointer vers "https://khaganat.net/wikhan/fr:licence" et "contact"... faut que je la modifie => MAJ c'est changé à la main.
- Images sur la page "financer" : Bulma donne le choix entre un ratio précis pour l'image ou rien du tout. Mais le rien du tout, il force quand même à des trucs à la noix comme "vas-y met-toi à 100% dans l'élément, je m'en fous si t'es trop petit, je te tire". Une version très particulière du responsive à mon goût. Bref ça demande de toucher au CSS, et j'y touche pas avec Bulma.
Pas trop tech
- Relire les pages suivantes et noter si y'a des soucis (français et anglais) :
- https://cipra.khaganat.net/fr/page/legal/
- https://cipra.khaganat.net/fr/page/index/
- https://cipra.khaganat.net/fr/page/contact/
- https://cipra.khaganat.net/fr/page/financer/
- Les images en page d'accueil : ça serait bien d'en trouver qui font toutes la même largeur (ça réglera le souci des déformations). Si vous êtes inspirées, soit pour modifier celles déjà là, soit pour en proposer de nouvelles... Fait en dézinguant certaines classes à la noix de Bulma.
- Faire une proposition pour améliorer l'interface de rédaction des pages, afin de pouvoir les modifier sans lire le langage de balisage.
Je compléterais au fil de ce que je croise ; faites remonter aussi si vous voyez des choses.
Il y a aussi des "gros" trucs à faire sur Django, listé dans la page dokuwiki, et qu'on peut discuter. Là je me suis surtout concentrée sur ce qui permettait d'envoyer le site en prod. Je veux le voir en place...
Edit : maj d'une des tâches.
Edit bis : maj de pleins de tâches
Ce site (code) s'appelle Khaganat-Web.
Ressources
Vous trouverez le code ici : https://git.khaganat.net/Tycho/khaganat-web
Et pour la doc, les explications :
https://khaganat.net/wikhan/fr:khaganat_web
Cette page peut aider les moins expertes avec Django, mais, dans ce cas, ça sera peut-être juste laborieux de contribuer : le but ici est de coder, et suffisamment bien pour que Tycho accepte vos pull request
La version "en test" est visible sur Cipra : https://cipra.khaganat.net/
Les trucs à faire
Cette section mériterait peut-être des tickets dans la partie gitlab... Mais je réfléchis mieux sur forum.
Pour les techs
- Arriver à lire un flux RSS et l'afficher. Et le paramétrer.
- Modifier le plugin dokuwiki qui permet de se connecter à Django. Tycho a amélioré la sécurité sur Khaganat-Web, ce qui fait que le plugin de base ne marche pas directement", mais il semblait dire que ce n'était pas très complexe à adapter. C'est plus du php que du django, là.
- Adapter les règles nginx à Apache. Notre serveur web utilise apache (parce que pleins de cms sont fait pour lui), et après discussion c'est plus simple dans ce sens là. Voir ici pour la doc django.
-
- Images sur la page "financer" : Bulma donne le choix entre un ratio précis pour l'image ou rien du tout. Mais le rien du tout, il force quand même à des trucs à la noix comme "vas-y met-toi à 100% dans l'élément, je m'en fous si t'es trop petit, je te tire". Une version très particulière du responsive à mon goût. Bref ça demande de toucher au CSS, et j'y touche pas avec Bulma.
Pas trop tech
- Relire les pages suivantes et noter si y'a des soucis (français et anglais) :
- https://cipra.khaganat.net/fr/page/legal/
- https://cipra.khaganat.net/fr/page/index/
- https://cipra.khaganat.net/fr/page/contact/
- https://cipra.khaganat.net/fr/page/financer/
- Faire une proposition pour améliorer l'interface de rédaction des pages, afin de pouvoir les modifier sans lire le langage de balisage.
Je compléterais au fil de ce que je croise ; faites remonter aussi si vous voyez des choses.
Il y a aussi des "gros" trucs à faire sur Django, listé dans la page dokuwiki, et qu'on peut discuter. Là je me suis surtout concentrée sur ce qui permettait d'envoyer le site en prod. Je veux le voir en place...
Edit : maj d'une des tâches.
Edit bis : maj de pleins de tâches
Dernier message par Zatalyz - 30 Janvier 2020 à 21:02:30
Cliquez pour afficher le message
Mise à jour au fil des discussions.
Le partenariat avec ./play.it nous convient à tous, donc on part là dessus. Vv222 va faire des tests sur son instance gitlab pour voir comment mutualiser des ressources, tout en ayant deux vitrines séparées.
Le fournisseur à privilégier serait plutôt Online.net ; Tycho et Deed confirment la qualité du service. Suite aux soldes, les serveurs intéressants ne sont pas dispos, mais on verra ça quand on sera prêt à faire le transfert. L'idée est de privilégier un serveur avec pas mal d'espace disque, une bonne bande passante (plus que kimsufi), et j'aimerais dépasser les 20Go de ram ; le CPU devrait suivre. Côté prix, ./play.it vise plutôt du 25€/mois, nous on est actuellement sur du 42€ TTC, soit 67€ TTC / 55€ HT ; mais Khaganat étant dans une bonne situation financière et le but étant de monter en gamme, je pense qu'on peut envisager de payer plus de notre côté. Bref on va voir les diverses solutions, et valider avec notre Chef des Chiffres si ça rentre dans le budget. À noter qu'il faudra avoir un second serveur juste pour les sauvegardes ; là on peut rester sur du kimsufi ou autre pas cher mais avec de la place.
Le partenariat avec ./play.it nous convient à tous, donc on part là dessus. Vv222 va faire des tests sur son instance gitlab pour voir comment mutualiser des ressources, tout en ayant deux vitrines séparées.
Le fournisseur à privilégier serait plutôt Online.net ; Tycho et Deed confirment la qualité du service. Suite aux soldes, les serveurs intéressants ne sont pas dispos, mais on verra ça quand on sera prêt à faire le transfert. L'idée est de privilégier un serveur avec pas mal d'espace disque, une bonne bande passante (plus que kimsufi), et j'aimerais dépasser les 20Go de ram ; le CPU devrait suivre. Côté prix, ./play.it vise plutôt du 25€/mois, nous on est actuellement sur du 42€ TTC, soit 67€ TTC / 55€ HT ; mais Khaganat étant dans une bonne situation financière et le but étant de monter en gamme, je pense qu'on peut envisager de payer plus de notre côté. Bref on va voir les diverses solutions, et valider avec notre Chef des Chiffres si ça rentre dans le budget. À noter qu'il faudra avoir un second serveur juste pour les sauvegardes ; là on peut rester sur du kimsufi ou autre pas cher mais avec de la place.
Dernier message par Rollniak - 04 Novembre 2019 à 20:13:33
Cliquez pour afficher le message
Coucou,
Merci Zatalyz pour le récapitulatif. Il serait tentant de prendre la machine de guerre mais dans ce cas je préfère avoir une garantie de paiement sur le long terme.
De mon point de vue le choix de la machine dépend en partie de la possible mutualisation de Gitlab avec ./play.it.
- Si on mutualise avec ./play.it nous gagnons en ressource CPU/RAM pour un temps et nous pouvons nous concentrer sur une machine a faible coup dédier au backup.
les avantages sont nombreux, nous partageons les frais de la mutualisation de Gitlab, nous obtenons une machine à moindre coût, et nous récupérons CPU, RAM et espace disque sur les machines en productions.
Ce plan est celui que je préfère actuellement.
Dans le second cas, une formule a faible coup pour une troisième machine est envisageable dans la mesure ou nous connaîtrions aurions une idée de ce que nous ferions tourner dessus
en gros cela demande un peu plus d'approfondissement.
note de fin, il sera toujours possible ultérieurement de faire une migration d'un nos serveurs actuels vers des machines plus haut de gamme avec tous les services que cela implique plus tard.
Merci Zatalyz pour le récapitulatif. Il serait tentant de prendre la machine de guerre mais dans ce cas je préfère avoir une garantie de paiement sur le long terme.
De mon point de vue le choix de la machine dépend en partie de la possible mutualisation de Gitlab avec ./play.it.
- Si on mutualise avec ./play.it nous gagnons en ressource CPU/RAM pour un temps et nous pouvons nous concentrer sur une machine a faible coup dédier au backup.
les avantages sont nombreux, nous partageons les frais de la mutualisation de Gitlab, nous obtenons une machine à moindre coût, et nous récupérons CPU, RAM et espace disque sur les machines en productions.
Ce plan est celui que je préfère actuellement.
Dans le second cas, une formule a faible coup pour une troisième machine est envisageable dans la mesure ou nous connaîtrions aurions une idée de ce que nous ferions tourner dessus
en gros cela demande un peu plus d'approfondissement.note de fin, il sera toujours possible ultérieurement de faire une migration d'un nos serveurs actuels vers des machines plus haut de gamme avec tous les services que cela implique plus tard.
Dernier message par Zatalyz - 04 Novembre 2019 à 16:41:16
Cliquez pour afficher le message
Update sur les infos :
- Oneprovider a vraiment des bons prix. On a pas forcément beaucoup plus de service que kimsufi, mais la bande passante est vraiment plus importante.
- Rectification sur les prix : les serveurs sont pas chers actuellement et on paie plus qu'on ne devrait. Murbaz nous coute 21€ HT, là, mais si on prenait le même serveur chez kimsufi actuellement (KS-6) on paierait... 18€. Pour l'équivalent de nuxru on serait à 2€ de moins (complexité à comparer parce que l'offre est vieille).
- Oneprovider a vraiment des bons prix. On a pas forcément beaucoup plus de service que kimsufi, mais la bande passante est vraiment plus importante.
- Rectification sur les prix : les serveurs sont pas chers actuellement et on paie plus qu'on ne devrait. Murbaz nous coute 21€ HT, là, mais si on prenait le même serveur chez kimsufi actuellement (KS-6) on paierait... 18€. Pour l'équivalent de nuxru on serait à 2€ de moins (complexité à comparer parce que l'offre est vieille).
Dernier message par Zatalyz - 04 Novembre 2019 à 14:43:05
Cliquez pour afficher le message
Suite au grand plantage de l'autre week-end sur murbaz, j'ai pris un peu en urgence un 3e serveur pour s'assurer qu'on ne perde rien.
Après analyse, Murbaz ne semble pas mourant de façon claire donc on l'a remis en marche. Mais c'est tout de même le moment de se poser la question de l'évolution de notre archi, parce qu'on a de la trésorerie. Pas au point de pouvoir faire n'importe quoi, mais... on a vraiment plus d'options qu'avant. Il faudra attendre un peu pour une confirmation trésorière du montant annuel qu'on peut mettre sur les serveurs mais il faut aussi, ici, qu'on détermine les stratégies les plus intéressantes.
Actuellement, nous avons deux serveurs, Nuxru et Murbaz, qui se sauvegardent mutuellement : Nuxru garde une copie des données de Murbaz, Murbaz garde une copie des données de Nuxru. Il y a des VM sur les deux : le pad et des vm de test sur nuxru, le reste sur Murbaz. Nous venons d'ajouter un 3e serveur (sans nom) qui a des copies de Murbaz, mais d'une façon ou d'une autre il va être modifié.
J'aime bien les questions de blonde, elles sont pleines de bon sens. Je vous remet ma réponse longue (c''était du mail) :
Depuis, je dois dire que l'optique d'avoir un gros serveur avec un vrai service derrière et plus de garanties (et de bande passante) me plaît bien (chez ovh ou ailleurs, mais de la qualité). Nuxru étant étonnament fiable au fil des ans, on peut le garder pour le backup. Mais prendre un vrai serveur cher me semble pertinent si on mutualise avec les copains, sinon ça fait quand même cher et on n'a pas besoin tous les jours d'autant de CPU et de bande passante...
On pourrait aussi viser une solution intermédiaire, avec un serveur moyen de gamme offrant plus de garantie. C'est moins intéressant à mon goût parce que côté performance on ne gagne pas grand chose par rapport au surcoût, encore qu'il faudrait regarder ce que proposent Hertzner, online.net etc...
Si on reste sur la logique les deux serveurs se backupant mutuellement mais avec des serveurs pas cher, il me semble important d'envoyer une deuxième copie de tous les backup sur un 3e serveur, pour une raison très bête : nos deux serveurs sont actuellement dans le même datacenter. Ça, c'est pas bien, en terme de redondance
Et on a bien vu aussi que nuxru, tant que c'est un hyperviseur, est un peu faiblard pour restaurer les sauvegardes (on court après la place sur le disque dur, réservé par les VM).
Dans toutes ces situations, il me semble de toute façon intéressant de transformer Nuxru en "juste du backup" (on vire l'hyperviseur et les vm, donc ça veut dire les mettre ailleurs, mais autant avoir de la ressource pour ça). Nuxru a un avantage important, c'est une vieille offre et on a plus en disque dur que ce qui se fait actuellement (j'ai un mal fou à avoir l'info avec LVM, mais je crois que c'est 3To ?), et il s'est avéré stable ces dernières années.
Il serait bien qu'on se décide dans les jours qui viennent, pour deux raisons :
- éviter de payer le 3e serveur pour "rien" (actuellement il n'est pas configuré pour dédoubler les backups, ou héberger des vm, et suivant ce qu'on décide, on le garde ou on en prends un plus petit)
- il y a en fin de mois un horrible machin capitaliste qui fait qu'on peut espérer des supers promos sur les offres... c'est pas mal de pouvoir économiser les frais, quand même. Pas un argument suffisant (faut qu'on puisse payer même sans la promo) mais si on peut en profiter ce sera aussi bien pour nos finances.
Après analyse, Murbaz ne semble pas mourant de façon claire donc on l'a remis en marche. Mais c'est tout de même le moment de se poser la question de l'évolution de notre archi, parce qu'on a de la trésorerie. Pas au point de pouvoir faire n'importe quoi, mais... on a vraiment plus d'options qu'avant. Il faudra attendre un peu pour une confirmation trésorière du montant annuel qu'on peut mettre sur les serveurs mais il faut aussi, ici, qu'on détermine les stratégies les plus intéressantes.
Actuellement, nous avons deux serveurs, Nuxru et Murbaz, qui se sauvegardent mutuellement : Nuxru garde une copie des données de Murbaz, Murbaz garde une copie des données de Nuxru. Il y a des VM sur les deux : le pad et des vm de test sur nuxru, le reste sur Murbaz. Nous venons d'ajouter un 3e serveur (sans nom) qui a des copies de Murbaz, mais d'une façon ou d'une autre il va être modifié.
Citation de: LyneEst-ce qu'il est plus intéressant (financièrement et/ou technologiquement) d'avoir 3 serveurs, dont un dédié au back-up (et, j'espère, à peu près correct pour ne pas risquer un crash dessus au plus mauvais moment) ? Ou d'avoir 2 serveurs seulement (comme jusqu'à récemment) mais de meilleure qualité / plus robustes ? Ce n'est pas tant le détail de la réponse qui m'intéresse, mais l'avis résumé des chefs maj sur le sujet, hein (je rappelle que je suis blonde
J'aime bien les questions de blonde, elles sont pleines de bon sens. Je vous remet ma réponse longue (c''était du mail) :
Citation de: zatalyzEn fait, les serveurs un peu mieux (type soyoustart, hertzner) ou carrément mieux (offre pro d'ovh et consort) sont vite vraiment plus cher pour des produits équivalents en terme de ram/dd/cpu. Quand on trouve l'équivalent, parce qu'évidement plus c'est cher plus c'est des grosses machines. Pour un ordre d'idée (je vais donner tous les prix HT) :
- nous avons actuellement chez kimsufi un serveur à 10€, qui suffirait pour du backup mais qui n'a pas beaucoup de puissance pour plus, et un autre à 25€ sur lequel tout tourne ou presque. Le serveur de backup que j'ai pris dans l'urgence (dans l'idée qu'on allait ptet devoir faire un transfert des services aussi) est à 14€/mois, on pourrait se contenter de celui à 10€ ou même chercher d'autres offres qui offrent du stockage sans plus et qui seront peut-être moins cher. Ou pas, ces serveurs à 10€ me semblent honnêtes en backup
- le premier prix soyoustart est à 35€, il est un peu mieux que le kimsufi à 25€ pour le cpu et équivalent sur le reste.
- le premier prix chez ovh est à 53€. À ce prix par contre on a une machine de guerre et des services associés qui déchirent, hein (plus de bande passante, un vrai service de support, 32Gb de ram, un cpu de fou, autant de To sur les disques que sur nos deux serveurs, et un peu de sauvegarde en plus).
La question est cependant pertinente, parce qu'on voit les limites de gitlab actuellement (on aurait besoin de plus de place, plus de cpu, etc). De la discussion qu'on a eu avec play.it, il semble qu'on parte sur la possibilité de mutualiser nos gitlab et dans ce cas, un serveur au top commence à être intéressant s'il héberge nos autres services à côté. Pour rentrer dans un peu de détails techniques, on garderais une technologie de VM (xen ou autre mais on est 3 à maitriser assez xen à présent donc...), il y aurait une VM pour gitlab partagée avec play.it, et d'autres VM pour nos divers besoins. Et là encore, on peut mutualiser, prendre un peu plus puissant pour héberger tout play.it et Khaganat sur les mêmes machines par exemple. Dans cette optique, je garderais cependant le kimsufi à 10€, vidé de toutes les vm à une exception prête et dédié à la sauvegarde. L'exception, c'est si à un moment on se décide à héberger XMPP, je ne veux pas que ce soit sur le même serveur que le reste ; et je veux aussi avoir un bout de serveur externe sur lequel on peut rediriger en cas de gros plantage (comme là) pour dire "on est pas morts". Ceci dit ça consomme pas de ressources, ça
Dans cette optique on serait quand même à quelque chose comme 63€/mois soit 756€, soit 907€ TTC... Et moins souple en cas de souci de trésorerie. Actuellement, si la trésorerie s'effondre, on peut rapatrier les services essentiels sur le serveur à 10€ (les vm ont leur place réservée), couper les services gourmands sans perdre les données (gitlab, le pad, nextcloud). Si on met tout sur un gros serveur et que le petit est réservé au backup, il va falloir que tout la place soit là pour le backup... et donc en cas de rétropédalage ça sera un peu plus le bordel, et il faudra sortir des sous (reprendre un petit kimsufi en plus) avant de pouvoir fermer le gros. Et ça demandera plus de temps aussi. D'un autre côté, je n'envisage pas que notre croissance diminue
Voilà pour les éléments de réflexion...
Depuis, je dois dire que l'optique d'avoir un gros serveur avec un vrai service derrière et plus de garanties (et de bande passante) me plaît bien (chez ovh ou ailleurs, mais de la qualité). Nuxru étant étonnament fiable au fil des ans, on peut le garder pour le backup. Mais prendre un vrai serveur cher me semble pertinent si on mutualise avec les copains, sinon ça fait quand même cher et on n'a pas besoin tous les jours d'autant de CPU et de bande passante...
On pourrait aussi viser une solution intermédiaire, avec un serveur moyen de gamme offrant plus de garantie. C'est moins intéressant à mon goût parce que côté performance on ne gagne pas grand chose par rapport au surcoût, encore qu'il faudrait regarder ce que proposent Hertzner, online.net etc...
Si on reste sur la logique les deux serveurs se backupant mutuellement mais avec des serveurs pas cher, il me semble important d'envoyer une deuxième copie de tous les backup sur un 3e serveur, pour une raison très bête : nos deux serveurs sont actuellement dans le même datacenter. Ça, c'est pas bien, en terme de redondance
Et on a bien vu aussi que nuxru, tant que c'est un hyperviseur, est un peu faiblard pour restaurer les sauvegardes (on court après la place sur le disque dur, réservé par les VM). Dans toutes ces situations, il me semble de toute façon intéressant de transformer Nuxru en "juste du backup" (on vire l'hyperviseur et les vm, donc ça veut dire les mettre ailleurs, mais autant avoir de la ressource pour ça). Nuxru a un avantage important, c'est une vieille offre et on a plus en disque dur que ce qui se fait actuellement (j'ai un mal fou à avoir l'info avec LVM, mais je crois que c'est 3To ?), et il s'est avéré stable ces dernières années.
Il serait bien qu'on se décide dans les jours qui viennent, pour deux raisons :
- éviter de payer le 3e serveur pour "rien" (actuellement il n'est pas configuré pour dédoubler les backups, ou héberger des vm, et suivant ce qu'on décide, on le garde ou on en prends un plus petit)
- il y a en fin de mois un horrible machin capitaliste qui fait qu'on peut espérer des supers promos sur les offres... c'est pas mal de pouvoir économiser les frais, quand même. Pas un argument suffisant (faut qu'on puisse payer même sans la promo) mais si on peut en profiter ce sera aussi bien pour nos finances.
Dernier message par Zatalyz - 09 Octobre 2019 à 16:18:35
Cliquez pour afficher le message
Bonjour à toutes et à tous,
Notre gitlab montre ses limites, et nous avons évoqué la possibilité de faire un partenariat avec ./play.it sur ce service.
Cela amène pas mal de questions ; nous travaillons tout ça sur ce pad :
https://pad.khaganat.net/p/gitlab
Et sur le canal Krypte sur XMPP.
Complétez le pad. Posez vos questions, réflexions, etc, ici ou sur XMPP.
Notre gitlab montre ses limites, et nous avons évoqué la possibilité de faire un partenariat avec ./play.it sur ce service.
Cela amène pas mal de questions ; nous travaillons tout ça sur ce pad :
https://pad.khaganat.net/p/gitlab
Et sur le canal Krypte sur XMPP.
Complétez le pad. Posez vos questions, réflexions, etc, ici ou sur XMPP.
#68
Programmation / Re : Xen
Cliquez pour afficher le message
Bonsoir 
,
Il s'agit de la commandermp rpm, elle est dédié aux systèmes d'exploitations à base de Red Hat, il faut regarder de la commande dpkg sous Debian. Essaye ceci :
Si vous avait un accès physique a vos serveurs de test et de prod, je vous invite à regarder le projet suivant : https://xcp-ng.org/
Bonne soirée
,Citation de: mdoukermp permet de voir si un paquet est installé et s'il tourne : https://www.system-linux.eu/index.php?post/2008/12/21/Commande-rpm
Il s'agit de la commande
Code Sélectionner
dpkg-query -L *xen*CitationCela correspond tout à fait à ce que l'on envisage de faire. À savoir, enlever le serveur sous Debian 6 et migrer sur une autre machineEn ce qui concerne les machines virtuelles, je vous conseille de faire un essai en laboratoire (environnement de test) afin de vérifier le bon fonctionnement de ses dernières sur la nouvelle installation de votre hyperviseur.
Si vous avait un accès physique a vos serveurs de test et de prod, je vous invite à regarder le projet suivant : https://xcp-ng.org/
Bonne soirée
#69
Programmation / Re : Xen
Cliquez pour afficher le message
Bon alors là mille pardons 
Cela correspond tout à fait à ce que l'on envisage de faire. A savoir, enlever le serveur sous Debian 6 et migrer sur une autre machine
@shepeng
rmp permet de voir si un paquet est installé et si il tourne : https://www.system-linux.eu/index.php?post/2008/12/21/Commande-rpm
Merci,
Mdouke
Cela correspond tout à fait à ce que l'on envisage de faire. A savoir, enlever le serveur sous Debian 6 et migrer sur une autre machine
@shepeng
rmp permet de voir si un paquet est installé et si il tourne : https://www.system-linux.eu/index.php?post/2008/12/21/Commande-rpm
Merci,
Mdouke
#70
Programmation / Re : Xen
Cliquez pour afficher le message
Je connais pas la commande rmp, c'est sensé faire quoi rmp qa xend ?
