Note que ça donne une idée (mais encore de l'ordre du hacking) :
lorsqu'un serveur enclenche un renouvellement lui permettre d'activer sur server1 un vhost spécifique pour rediriger les flux http/https vers serverX (grâce a apache2 reverse proxy) et quand l'opération est terminée désactiver ce vhost.
Ou dans le même ordre d'idée lors d'un renouvellement serverX pourrait désactiver apache2 sur server1 et activer 2 tunnels SSH depuis server1:80/443 vers serverX:80/443 puis une fois le challenge terminé désactiver les tunnels sur server1 et ré-activer apache2.
Mais les webservices n'apprécieraient vraiment pas cela.
Je pourrais en effet, mais je cherche une solution pour automatiser le renouvellement. Changer les redirections sur le NAT ne semble pas pouvoir se faire automatiquement
Oui je suis désolé pour le désagrément, je suis en train de revoir la configuration de mes serveurs suite a une cascade de panne (j'ai eu la totale ce mois-ci, aujourd'hui je me suis encore tapé un nouveau bug que j'avais jamais eu)
Fait exceptionnel le site est accessible en http (sans TLS) pour compenser le https actuellement cassé.
Et bien c'est résolut, il faut bien démarrer (voir redémarrer au pire) le volume en ajoutant force --mode=script à la fin de la commande
Pour démarrer le volume dans un script
sudo gluster volume start monVolume force --mode=script
Pour arrêter le volume dans un script
sudo gluster volume stop monVolume force --mode=script
Ensuite attendre un petit peu.
Mon script ressemble à ça:
#!/bin/bash#on verifie qu'on est bien en rootif[ ! "$SUDO_USER"];thenexit 0
fi
sleep 10# petit délais d'attente afin que les disques soient prêt#sudo gluster volume stop localPiGluster1 force --mode=script
gluster volume start localPiGluster1 force --mode=script
sleep 1
mount -t glusterfs 127.0.0.1:/localPiGluster1 /media/localPiGluster1
Ah oki ! J'étais persuadé que chaque user disposait de sa propre paire de clés et de sa propre emprunte. (un peu à la manière de TLS avec les hostnames)
Merci d'avoir rectifié le tir.
Alors oui à ce moment là la partie génération de clés pour l'user dédié sur le serveur est complètement inutile.
Il n'y a pas d'intérêt (au contraire) à ce que root fasse le montage.
Avec le fstab il me semble qu'avec l'option allow_other dans fstab puis un mount fait par l'user ça fonctionne sans root.
Par contre avec le script on peut l'appeler sans root pour effectuer le montage (ça fonctionne faut juste commenter le if qui vérifie si root comme ici), mais le umount (dans le script) lui ne fonctionne pas sans root (bon, il n'est utile que si l'utilisateur veut appliquer un démontage/remontage)
Tu dois pouvoir faire la même chose sans toucher au fstab et en modifiant le fichier ~/.ssh/config à la place. Ça simplifiera toutes tes commandes et tu peux te contenter d'avoir les 2 fichiers de config et faire un lien qui va bien pour que ça fonctionne.
Je suis ouvert à toute méthode :) (plus c'est "assimilé" par le système et mieux ça me convient ^ ^ )
Faire un montage réseau au démarrage ce n'est pas forcément tip top, le réseau ça peut mettre du temps à s'initialiser.
Avec fstab il y a l'option _netdev qui permet d'attendre que le réseau soit prêt si non dans mon script j'ai mis un délais d'une minute (se qui semble largement suffisant pour le RPI 1 sur lequel j'ai testé, sur un pc portable avec connexion automatique désactivée je privilégie 5 minutes)
mais ces clefs ne sont jamais utilisées puisqu'on se connecte de l'exterieur vers userCommun et non du serveur vers l'exterieur.
Alors quelles sont les clés utilisées? (Si je ne m'abuse l'initialisation se fait dans un tunnel avec crypto asymetrique le temps d'échanger une clé temporaire qui va permettre de créer un second tunnel avec crypto symetrique qui va remplacer le premier. Si le serveur peut envoyer la clés symetrique via la clé publique du client, ça ne m'étonnerait (supposition) pas qu'il demande une confirmation avant de créer le tunnel en crypto symetrique.)
PS: intéressant, y a un troll qui moinsse tout mes messages à chacun de mes journaux :D
Après test, root ne semble pas nécessaire pour lancer le montage via script. Vous pouvez supprimer le sudo devant l'appel du script dans /etc/rc.local si vous suivez la partie sur le montage via script maison. :)
pourquoi tu génère systématiquement 2 paires de clefs (une rsa et une ed25519) ?
Il me semble (d'après mes souvenirs peut-être faussé) que RSA est moins solide que edDSA. Hors pour une raison que j'ignore edDSA ne fonctionne pas toujours sur raspbian.
Donc dans le doute je propose une de chaque mais en effet l'utilisateur peut n'en générer qu'une seule ou 50 c'est au choix (le paramètre -i PathDeLaKey.pub permet de spécifier quelle clés utiliser).
Ça me fait penser que j'ai oublié d'ajouter ssh-add dans le tuto.
plutôt que de présenter la liste des algo forts ou faibles actuellement je pense qu'il serait plus intéressant d'indiquer comment savoir qu'un algo est cassé ou non :)
Peut-être quelqu'un aura-t-il une réponse. Ma liste est originellement récupérée sur le net en recherchant "sécuriser ssh".
il y a pas mal de manipulation dont l'intérêt n'est pas très clair (il y a beaucoup de génération de clef par exemple,
Il y a deux générations de clés pour le client dans le tuto : une pour l'utilisateur courant et une pour root. Pour un montage au boot avec fstab l'utilisateur est root. Note que je n'ai pas vérifié si root est nécessaire pour le montage via script.
rapidement je n'ai pas bien compris pourquoi la procédure pour le montage au démarrage est aussi complexe)
Elle n'est pas complexe (6 points pour le montage via fstab et 9 point pour le montage via script).
C'est juste que j'explique deux méthodes différentes de montage avec leurs avantages&inconvénients :
fstab : permet d'utiliser mount/umount, hostname statique uniquement
script lancé au boot : ne permet pas d'utiliser mount, compatible hostname dynamique
Par contre dans ma mise en page les retours chariot que j'ai mis entre les différentes section/chapitre ont été supprimé automatiquement se qui donne cette impression d'un tas un peu indigeste
Désolé je ne me suis pas encore complètement adapté aux balises ^ ^ Je n'ai pas réussi à utiliser la liste à puce numérotée non plus (elle restait à 1. alors j'ai mis des puces normales) ^ ^
Je le rajoute en commentaire si non on va me dire que je fais encore trop long ^ ^
Vous pouvez augmenter la sécurité de votre installation en supprimant les algo déjà cassé et en désactivant UseRoaming (source) :
Côté client
Désactiver la feature UseRoaming
Éditez le fichier de configuration générale du client ssh /etc/ssh/sshconfig_
sudo nano /etc/ssh/ssh_config
Et ajoutez la ligne suivante avant les Host :
UseRoaming no
N'autoriser que les algorithmes de chiffrement symétrique sûr (non cracké actuellement)
Éditez le fichier de configuration du client ssh /etc/ssh/sshconfig_
J'ai eu le même problème lorsque j'ai voulu coder une API de contrôle à distance de mes RPI.
Il y a moyen d'autoriser des commandes réservées à root en chipotant avec sudoers. Je saurais pas t'en dire plus, les tuto ne m'ont pas aidé quand j'ai voulu tenter cette solution ^ ^ (mais tout le monde m'a dit de passer par ce truc pour autoriser non pas la commande d’arrêt (par sécurité) mais un script dans lequel je lance la commande d’arrêt)
J"ai reposté un fichier log (/var/log/glusterfs/bricks/media-Seagate3To1-gfs.log) montrant le redemarrage d'un bricks. Dedans on peut y voir le port utilisé (--brick-port 49156).
Mais le port utilisé n'est ni signalé dans volume status (port N/A) ni dans nmap.
J'ai lancé un scan des ports et rien ne semble apparaître (gluster utilise 111, 24007, 24008 et un ports par bricks à partir de 49152)
sudo nmap 127.0.0.1 -sS -sU
Starting Nmap 6.47 ( http://nmap.org ) at 2016-10-31 18:26 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000085s latency).
Not shown: 1995 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
68/udp open|filtered dhcpc
123/udp open ntp
5353/udp open|filtered zeroconf
tu te demandais comment cette société avait eu ton adresse
En Belgiques les communes*1 aussi se permettent de revendre les informations de leur "usagers". (encore une preuve que se soit payant ou gratuit on est le produit)
*1 note que les autres entités institutionnelles doivent être aussi corrompues
Posté par EauFroide .
En réponse au message SSD dans un serveur ?.
Évalué à 1.
Dernière modification le 30 octobre 2016 à 18:54.
Ça a déjà été abordé ici maintes fois : lorsqu'il y a peu de ressources correctes sur un sujet (en général un sujet pointu ou qui intéresse peu de gens), alors ça n'est généralement pas une bonne idée de ne pas connaître la « langue commune »
Viens où j'habite, les flamands pensent a peu près ce genre de chose à propos de tout les non neerlandophones…
Perso plus tôt que de m'exclure je préfère avancer. Trop facile de dire "tu parle pas anglais, va jouer aux billes".
Le sujet de la langue est très, très, très sensible pour les belges*1, vaut mieux éviter ce sujet sur LinuxFR (mon point de vue est qu'on devrait virer le français et le néerlandais des écoles/lieux publique en Europe et imposer l'américain et le chinois en immersion obligatoire, apprendre une langue natale inutile a des gosses je suis un bon exemple du résultat*2 ;) ).
*1 ce sujet est est encore plus chaud que l'immigration (note que c'est lié, le français est "la langue de l'envahisseur" d'après les flamands)
*2 comme tout le monde j'ai eu cours d'anglais à l'école avec des profs peu motivant
Absolument aucun :-) J'en ai juste entendu parler récemment, ça avait l'air sympa comme idée. En gros tu peux avoir 2 disques avec chacun leur arborescence. Donc là on parle au niveau filesystem. Et avec AuFS tu peux créer un point de montage qui va fusionner ces 2 filesystem.
C'est le fonctionnement de glusterfs-server et mhddfs : tu t'occupes toi-même du montage/partitionnement de tes disques. Ensuite tu crées un dossier sur chaque disque et lors de la création de ton raid/jbod avec glusterfs ou mhddfs, tu indiques le path des dossiers. En cas de panne du logiciel ou de disque, les datas sont toujours accessible via le filesystem que ton raid/jbod soit monté ou non :) (note que ça ne doit pas fonctionner si tu strip les données ou passes par un raid supérieur à 1).
Ma question va vous sembler peut-être idiote mais :
glusterfs-server est axé réseau, si je lui donne plusieurs disques d'une même machine je dois les indiquer comme si chaque disque était un pair. Cela signifie-t-il qu'en cas de lecture/écriture sur la même machine les données transitent par la carte réseau (ça utilise localhost)?
[^] # Re: Modifier ports
Posté par EauFroide . En réponse au message Let's encrypt et plusieurs serveurs sur la même IP. Évalué à 0. Dernière modification le 06 novembre 2016 à 15:24.
Note que ça donne une idée (mais encore de l'ordre du hacking) :
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Modifier ports
Posté par EauFroide . En réponse au message Let's encrypt et plusieurs serveurs sur la même IP. Évalué à 2.
Je pourrais en effet, mais je cherche une solution pour automatiser le renouvellement. Changer les redirections sur le NAT ne semble pas pouvoir se faire automatiquement
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: En Bonus
Posté par EauFroide . En réponse au journal [Tuto/HowTo] SSHFS : mises en place et montage. Évalué à 2.
Non, c'est juste que ton "argument" se résume à un troll de guerre de clocher :P
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: En Bonus
Posté par EauFroide . En réponse au journal [Tuto/HowTo] SSHFS : mises en place et montage. Évalué à 0. Dernière modification le 03 novembre 2016 à 16:50.
Oui je suis désolé pour le désagrément, je suis en train de revoir la configuration de mes serveurs suite a une cascade de panne (j'ai eu la totale ce mois-ci, aujourd'hui je me suis encore tapé un nouveau bug que j'avais jamais eu)
Fait exceptionnel le site est accessible en http (sans TLS) pour compenser le https actuellement cassé.
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
# Résolut
Posté par EauFroide . En réponse au message Problème de montage de volume glusterfs après reboot. Évalué à 1.
Et bien c'est résolut, il faut bien démarrer (voir redémarrer au pire) le volume en ajoutant force --mode=script à la fin de la commande
Pour démarrer le volume dans un script
Pour arrêter le volume dans un script
Ensuite attendre un petit peu.
Mon script ressemble à ça:
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: manipulations inutiles
Posté par EauFroide . En réponse au journal [Tuto/HowTo] SSHFS : mises en place et montage. Évalué à 1. Dernière modification le 02 novembre 2016 à 16:36.
Ah oki ! J'étais persuadé que chaque user disposait de sa propre paire de clés et de sa propre emprunte. (un peu à la manière de TLS avec les hostnames)
Merci d'avoir rectifié le tir.
Alors oui à ce moment là la partie génération de clés pour l'user dédié sur le serveur est complètement inutile.
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: lmgtfy
Posté par EauFroide . En réponse au message Download RPM packages for Oracle installation. Évalué à 1.
excellent le lien !
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: manipulations inutiles
Posté par EauFroide . En réponse au journal [Tuto/HowTo] SSHFS : mises en place et montage. Évalué à 2.
Tu veux dire que l'emprunte et la paire de clés utilisée par openssh-server sont les mêmes peu importe l'user?
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Merci pour le partage
Posté par EauFroide . En réponse au journal [Tuto/HowTo] SSHFS : mises en place et montage. Évalué à 1. Dernière modification le 02 novembre 2016 à 15:37.
Je prend note, merci de ton retour :)
Avec le fstab il me semble qu'avec l'option allow_other dans fstab puis un mount fait par l'user ça fonctionne sans root.
Par contre avec le script on peut l'appeler sans root pour effectuer le montage (ça fonctionne faut juste commenter le if qui vérifie si root comme ici), mais le umount (dans le script) lui ne fonctionne pas sans root (bon, il n'est utile que si l'utilisateur veut appliquer un démontage/remontage)
Je suis ouvert à toute méthode :) (plus c'est "assimilé" par le système et mieux ça me convient ^ ^ )
Avec fstab il y a l'option _netdev qui permet d'attendre que le réseau soit prêt si non dans mon script j'ai mis un délais d'une minute (se qui semble largement suffisant pour le RPI 1 sur lequel j'ai testé, sur un pc portable avec connexion automatique désactivée je privilégie 5 minutes)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: manipulations inutiles
Posté par EauFroide . En réponse au journal [Tuto/HowTo] SSHFS : mises en place et montage. Évalué à 1. Dernière modification le 02 novembre 2016 à 15:13.
Alors quelles sont les clés utilisées? (Si je ne m'abuse l'initialisation se fait dans un tunnel avec crypto asymetrique le temps d'échanger une clé temporaire qui va permettre de créer un second tunnel avec crypto symetrique qui va remplacer le premier. Si le serveur peut envoyer la clés symetrique via la clé publique du client, ça ne m'étonnerait (supposition) pas qu'il demande une confirmation avant de créer le tunnel en crypto symetrique.)
PS: intéressant, y a un troll qui moinsse tout mes messages à chacun de mes journaux :D
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Merci pour le partage
Posté par EauFroide . En réponse au journal [Tuto/HowTo] SSHFS : mises en place et montage. Évalué à -2.
Après test, root ne semble pas nécessaire pour lancer le montage via script. Vous pouvez supprimer le sudo devant l'appel du script dans /etc/rc.local si vous suivez la partie sur le montage via script maison. :)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Correction
Posté par EauFroide . En réponse au journal [Tuto/HowTo] SSHFS : mises en place et montage. Évalué à 0. Dernière modification le 02 novembre 2016 à 12:37.
J'ai oublié d'ajouter ssh-add après chaque génération de clés
Si un modo pouvait l'ajouter après chaque génération de clés svp
Ajoutez vos nouvelles clés au trousseau de votre utilisateur
Vous pouvez aussi supprimer les sections "Accorder les bons droits à notre point de montage" dans les deux méthodes de montage :)
Merci d'avance :)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: manipulations inutiles
Posté par EauFroide . En réponse au journal [Tuto/HowTo] SSHFS : mises en place et montage. Évalué à 2.
Merci pour l'infos, je confirme (je viens d'essayer), ça va permettre de diminuer le nombre de procédure :)
Ne pas utiliser celles par défaut qui pourraient être trop faible :)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Merci pour le partage
Posté par EauFroide . En réponse au journal [Tuto/HowTo] SSHFS : mises en place et montage. Évalué à -1.
Il me semble (d'après mes souvenirs peut-être faussé) que RSA est moins solide que edDSA. Hors pour une raison que j'ignore edDSA ne fonctionne pas toujours sur raspbian.
Donc dans le doute je propose une de chaque mais en effet l'utilisateur peut n'en générer qu'une seule ou 50 c'est au choix (le paramètre -i PathDeLaKey.pub permet de spécifier quelle clés utiliser).
Ça me fait penser que j'ai oublié d'ajouter ssh-add dans le tuto.
Peut-être quelqu'un aura-t-il une réponse. Ma liste est originellement récupérée sur le net en recherchant "sécuriser ssh".
Il y a deux générations de clés pour le client dans le tuto : une pour l'utilisateur courant et une pour root. Pour un montage au boot avec fstab l'utilisateur est root. Note que je n'ai pas vérifié si root est nécessaire pour le montage via script.
Elle n'est pas complexe (6 points pour le montage via fstab et 9 point pour le montage via script).
C'est juste que j'explique deux méthodes différentes de montage avec leurs avantages&inconvénients :
Par contre dans ma mise en page les retours chariot que j'ai mis entre les différentes section/chapitre ont été supprimé automatiquement se qui donne cette impression d'un tas un peu indigeste
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Correction
Posté par EauFroide . En réponse au journal [Tuto/HowTo] SSHFS : mises en place et montage. Évalué à 0.
Désolé je ne me suis pas encore complètement adapté aux balises ^ ^ Je n'ai pas réussi à utiliser la liste à puce numérotée non plus (elle restait à 1. alors j'ai mis des puces normales) ^ ^
Merci pour tes corrections :)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
# En Bonus
Posté par EauFroide . En réponse au journal [Tuto/HowTo] SSHFS : mises en place et montage. Évalué à -1. Dernière modification le 02 novembre 2016 à 00:50.
Je le rajoute en commentaire si non on va me dire que je fais encore trop long ^ ^
Vous pouvez augmenter la sécurité de votre installation en supprimant les algo déjà cassé et en désactivant UseRoaming (source) :
Côté client
Désactiver la feature UseRoaming
Éditez le fichier de configuration générale du client ssh /etc/ssh/sshconfig_
N'autoriser que les algorithmes de chiffrement symétrique sûr (non cracké actuellement)
Éditez le fichier de configuration du client ssh /etc/ssh/sshconfig_
Côté server
Supprimez les algorithmes de chiffrement symétrique déjà crackés en ajoutant dedans notre petite liste des algo autorisé *1
Supprimez les algorithmes de hashage trop fragile *1 qui sont utilisé pour la vérification d'intégrité en ajoutant aussi ces lignes
Entrez CTRL+X pour sauver & quitter.
*1 : n'hésitez pas à partager toute amélioration que vous connaîtriez :)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
# Correction
Posté par EauFroide . En réponse au journal [Tuto/HowTo] SSHFS : mises en place et montage. Évalué à -1.
Aaaah je peux même pas m'éditer juste après poste :D
bon pour ssh-copy-id -i ~/.ssh/id_ed25519 userCommunSFTP@adresseServerSSH il manque le .pub comme suit
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Utilisateur et Administrateur
Posté par EauFroide . En réponse au message [CLI] Arrêter la machine en utilisateur. Évalué à 1. Dernière modification le 01 novembre 2016 à 21:12.
J'ai eu le même problème lorsque j'ai voulu coder une API de contrôle à distance de mes RPI.
Il y a moyen d'autoriser des commandes réservées à root en chipotant avec sudoers. Je saurais pas t'en dire plus, les tuto ne m'ont pas aidé quand j'ai voulu tenter cette solution ^ ^ (mais tout le monde m'a dit de passer par ce truc pour autoriser non pas la commande d’arrêt (par sécurité) mais un script dans lequel je lance la commande d’arrêt)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: mes pistes, sans rien connaitre à glusterfs
Posté par EauFroide . En réponse au message Problème de montage de volume glusterfs après reboot. Évalué à 1. Dernière modification le 01 novembre 2016 à 11:38.
J"ai reposté un fichier log (/var/log/glusterfs/bricks/media-Seagate3To1-gfs.log) montrant le redemarrage d'un bricks. Dedans on peut y voir le port utilisé (--brick-port 49156).
Mais le port utilisé n'est ni signalé dans volume status (port N/A) ni dans nmap.
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: mes pistes, sans rien connaitre à glusterfs
Posté par EauFroide . En réponse au message Problème de montage de volume glusterfs après reboot. Évalué à 1.
J'ai lancé un scan des ports et rien ne semble apparaître (gluster utilise 111, 24007, 24008 et un ports par bricks à partir de 49152)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: mes pistes, sans rien connaitre à glusterfs
Posté par EauFroide . En réponse au message Problème de montage de volume glusterfs après reboot. Évalué à 1.
Merci pour ton aide.
Oui glusterd semble bien lancé. (commande lancée après un reboot)
ps -aux | grep "gluster" | grep -v "grep"
je l'ai vu mais ça ne m'a pas aidé
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: rien de neuf
Posté par EauFroide . En réponse au journal Vie privée et appel téléphonique. Évalué à 2. Dernière modification le 31 octobre 2016 à 17:46.
En Belgiques les communes*1 aussi se permettent de revendre les informations de leur "usagers". (encore une preuve que se soit payant ou gratuit on est le produit)
*1 note que les autres entités institutionnelles doivent être aussi corrompues
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Attends quelques années. :)
Posté par EauFroide . En réponse au message SSD dans un serveur ?. Évalué à 1. Dernière modification le 30 octobre 2016 à 18:54.
Viens où j'habite, les flamands pensent a peu près ce genre de chose à propos de tout les non neerlandophones…
Perso plus tôt que de m'exclure je préfère avancer. Trop facile de dire "tu parle pas anglais, va jouer aux billes".
Le sujet de la langue est très, très, très sensible pour les belges*1, vaut mieux éviter ce sujet sur LinuxFR (mon point de vue est qu'on devrait virer le français et le néerlandais des écoles/lieux publique en Europe et imposer l'américain et le chinois en immersion obligatoire, apprendre une langue natale inutile a des gosses je suis un bon exemple du résultat*2 ;) ).
*1 ce sujet est est encore plus chaud que l'immigration (note que c'est lié, le français est "la langue de l'envahisseur" d'après les flamands)
*2 comme tout le monde j'ai eu cours d'anglais à l'école avec des profs peu motivant
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Attends quelques années. :)
Posté par EauFroide . En réponse au message SSD dans un serveur ?. Évalué à 1.
Merci pour tes informations, je pense mieux comprendre la différence de paradigme.
A mon avis je vais essayer de me tourner vers du tout Glusterfs.
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Attends quelques années. :)
Posté par EauFroide . En réponse au message SSD dans un serveur ?. Évalué à 1.
C'est le fonctionnement de glusterfs-server et mhddfs : tu t'occupes toi-même du montage/partitionnement de tes disques. Ensuite tu crées un dossier sur chaque disque et lors de la création de ton raid/jbod avec glusterfs ou mhddfs, tu indiques le path des dossiers. En cas de panne du logiciel ou de disque, les datas sont toujours accessible via le filesystem que ton raid/jbod soit monté ou non :) (note que ça ne doit pas fonctionner si tu strip les données ou passes par un raid supérieur à 1).
Ma question va vous sembler peut-être idiote mais :
glusterfs-server est axé réseau, si je lui donne plusieurs disques d'une même machine je dois les indiquer comme si chaque disque était un pair. Cela signifie-t-il qu'en cas de lecture/écriture sur la même machine les données transitent par la carte réseau (ça utilise localhost)?
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat