Derniers messages
#91
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...
#92
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 ?
Dernier message par deed - 16 Octobre 2018 à 10:10:38
Cliquez pour afficher le message
GITEA :
POUR:
1/c est léger
2/c est facile à installer (j ai réussi rapidement , moi , le noobs
3/c est facile de entretient
4/c est léger
5/Tycho l utilise :p
6/c est rapide à mettre à jour
7/c est facile
CONTRE:
1/ Il ne s auto heberge pas
2/le CI est manuelle
3/blablabla dit Dracula :p
Merci
POUR:
1/c est léger
2/c est facile à installer (j ai réussi rapidement , moi , le noobs
3/c est facile de entretient
4/c est léger
5/Tycho l utilise :p
6/c est rapide à mettre à jour
7/c est facile
CONTRE:
1/ Il ne s auto heberge pas
2/le CI est manuelle
3/blablabla dit Dracula :p
Merci
Dernier message par Stan` - 03 Octobre 2018 à 10:12:28
Cliquez pour afficher le message
Par les temps qui courent la sécurité est de plus en plus importante et c'est la raison pour laquelle je crée ce Thread.
Pour l'instant on a un système qui a été désigné à l'époque ou les certificats HTTPS coutaient très chers, et qui offrait
une sécurité relative à l'époque. @Tycho à rendu ça un peu plus robuste en passant de DES à Sha-512. Le souci de la
méthode actuelle est qu'elle requiert un travail supplémentaire d'authentification au niveau du client, que Godot ne
supporte pas nativement.
L'idée serait donc de déporter tout ce travail de hashage et de salage sur le serveur, et d'envoyer les identifiants en clair
via HTTPS. C'est une solution raisonnable, mais ce n'est pas la plus sécurisée. Le hashage passerait aussi d'une méthode
SHA-512 à Argon2 qui est plus récent, et serait plus robuste.
Link Mauve parlait de passer par le processus de SCRAM qui est utilisé par XMPP, pour chiffrer et sécuriser nos communication
ce qui demanderait un travail supplémentaire. Il semblerait cependant qu'il y ait moyen d'avoir le support natif dans une version
ultérieure, les briques étant déjà là dans le code CPP. (Via mbedTLS)
Dans la mesure du possible pour des procédures aussi simples il serait idéal d'éviter de passer par des plugins et des librairies
externes pour des soucis de compatibilité cross-plateform.
Dans un second temps pour le chiffrement des paquets UDP (qui synchronisent tous les clients) il serait bien de définir un plan
de sécurité.
Voilà j'aurais aimé avoir votre avis sur les deux questions (Login, et communications). La cryptographie n'est pas mon domaine
du tout donc je vous prie de m'excuser si j'ai écrit des horreurs un peu plus haut.
J'en profite pour poster le schéma de fonctionnement actuel
Pour l'instant on a un système qui a été désigné à l'époque ou les certificats HTTPS coutaient très chers, et qui offrait
une sécurité relative à l'époque. @Tycho à rendu ça un peu plus robuste en passant de DES à Sha-512. Le souci de la
méthode actuelle est qu'elle requiert un travail supplémentaire d'authentification au niveau du client, que Godot ne
supporte pas nativement.
L'idée serait donc de déporter tout ce travail de hashage et de salage sur le serveur, et d'envoyer les identifiants en clair
via HTTPS. C'est une solution raisonnable, mais ce n'est pas la plus sécurisée. Le hashage passerait aussi d'une méthode
SHA-512 à Argon2 qui est plus récent, et serait plus robuste.
Link Mauve parlait de passer par le processus de SCRAM qui est utilisé par XMPP, pour chiffrer et sécuriser nos communication
ce qui demanderait un travail supplémentaire. Il semblerait cependant qu'il y ait moyen d'avoir le support natif dans une version
ultérieure, les briques étant déjà là dans le code CPP. (Via mbedTLS)
Dans la mesure du possible pour des procédures aussi simples il serait idéal d'éviter de passer par des plugins et des librairies
externes pour des soucis de compatibilité cross-plateform.
Dans un second temps pour le chiffrement des paquets UDP (qui synchronisent tous les clients) il serait bien de définir un plan
de sécurité.
Voilà j'aurais aimé avoir votre avis sur les deux questions (Login, et communications). La cryptographie n'est pas mon domaine
du tout donc je vous prie de m'excuser si j'ai écrit des horreurs un peu plus haut.
J'en profite pour poster le schéma de fonctionnement actuel
Dernier message par neodarz - 31 Août 2018 à 10:35:39
Cliquez pour afficher le message
En effet google peut les aider !
Merci pour l'ancien robots.txt !
Merci pour l'ancien robots.txt !
Dernier message par Zatalyz - 31 Août 2018 à 10:28:32
Cliquez pour afficher le message
Les robots spammeurs s'en moquent, mais ils trouvent le site plus facilement si google les aide... et google respecte publiquement le robots.txt 
Le robots.txt est celui par défaut (plus ces deux modifs), je te le met ici si besoin :
Le robots.txt est celui par défaut (plus ces deux modifs), je te le met ici si besoin :
Code Sélectionner
# See http://www.robotstxt.org/robotstxt.html for documentation on how to use the robots.txt file
#
# To ban all spiders from the entire site uncomment the next two lines:
User-Agent: *
Disallow: /
# Add a 1 second delay between successive requests to the same server, limits resources used by crawler
# Only some crawlers respect this setting, e.g. Googlebot does not
# Crawl-delay: 1
# Based on details in https://gitlab.com/gitlab-org/gitlab-ce/blob/master/config/routes.rb, https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec$
User-Agent: *
Disallow: /autocomplete/users
Disallow: /search
Disallow: /api
Disallow: /admin
Disallow: /profile
Disallow: /dashboard
Disallow: /projects/new
Disallow: /groups/new
Disallow: /groups/*/edit
Disallow: /users
Disallow: /help
# Global snippets
User-Agent: *
Disallow: /s/
Disallow: /snippets/new
Disallow: /snippets/*/edit
Disallow: /snippets/*/raw
# Project details
User-Agent: *
Disallow: /*/*.git
Disallow: /*/*/fork/new
Disallow: /*/*/repository/archive*
Disallow: /*/*/activity
Disallow: /*/*/new
Disallow: /*/*/edit
Disallow: /*/*/raw
Disallow: /*/*/blame
Disallow: /*/*/commits/*/*
Disallow: /*/*/commit/*.patch
Disallow: /*/*/commit/*.diff
Disallow: /*/*/compare
Disallow: /*/*/branches/new
Disallow: /*/*/tags/new
Disallow: /*/*/network
Disallow: /*/*/graphs
Disallow: /*/*/milestones/new
Disallow: /*/*/milestones/*/edit
Disallow: /*/*/issues/new
Disallow: /*/*/issues/*/edit
Disallow: /*/*/merge_requests/new
Disallow: /*/*/merge_requests/*.patch
Disallow: /*/*/merge_requests/*.diff
Disallow: /*/*/merge_requests/*/edit
Disallow: /*/*/merge_requests/*/diffs
Disallow: /*/*/project_members/import
Disallow: /*/*/labels/new
Disallow: /*/*/labels/*/edit
Disallow: /*/*/wikis/*/edit
Disallow: /*/*/snippets/new
Disallow: /*/*/snippets/*/edit
Disallow: /*/*/snippets/*/raw
Disallow: /*/*/deploy_keys
Disallow: /*/*/hooks
Disallow: /*/*/services
Disallow: /*/*/protected_branches
Disallow: /*/*/uploads/
Dernier message par neodarz - 31 Août 2018 à 10:21:38
Cliquez pour afficher le message
En effet vu que c'est à nous, on s'en fiche. Il me semble que le fichier robots.txt de gitlab avant modifications était celui par défaut, si c'était pas le cas ça sera cool que tu le poses quelque part car je l'utilisais...
Et je peux aussi dire d'ignorer le fichier robots.txt, pas besoin de rajouter le nom du crawler dans le fichier robots.txt ça change pas grand-chose mise à part la propreté du système (et le respect des normes par la même occasion
).
Pour l'histoire des robots spammeur ils ignorent totalement l'existence du robots.txt donc bon...
Et je peux aussi dire d'ignorer le fichier robots.txt, pas besoin de rajouter le nom du crawler dans le fichier robots.txt ça change pas grand-chose mise à part la propreté du système (et le respect des normes par la même occasion
).Pour l'histoire des robots spammeur ils ignorent totalement l'existence du robots.txt donc bon...
