Mettre en place son VPS

-

ache a marqué ce sujet comme résolu.

Tout le monde se secoue ! :D

J’ai commencé (mardi 21 août 2018 à 22h15) la rédaction d’un tutoriel au doux nom de « Participer au développement de ZDS n’importe où, même en déplacement » et j’ai pour objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limites pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l’adresse suivante :

Merci !

Je souhaite un avis sur la forme avant que ça soit trop tard. :lol:

+0 -0

J’adore l’initiative, mais je note que le début du tutoriel est beaucoup plus générique que juste avoir quelque chose pour le ZDS. Le séparer me paraît une bonne idée et permettra de faire d’autres variantes (Scaleway, gandi, etc, sauf si ZDS a un partenariat surprise avec Ovh maintenant). D’autant plus que personnellement je ne payerai pas un serveur pour participer à un projet, je préfèrerai l’installer moi-même sur ma machine. Éventuellement montrer comment monter un LXC avec le projet serait plus intéressant.

Pour le tutoriel en lui-même, j’ai un peu peur que ça empiète sur la documentation (ie. que ce soit plus à jour ou moins à jour que la documentation) et que le tutoriel devienne soit une barrière au projet, soit obsolète, mais après tout ça peut permettre de motiver d’autres personnes. Aussi, c’est possible de le simplifier en utilisant nano au lieu de vim (ça évite de faire un tutoriel dans un tutoriel).

Après ça aurait une très bonne tête en article ou billet je pense. Si ça demande un tutoriel de plusieurs chapitres pour installer une bêta, c’est que c’est pas le tutoriel qui est bloquant à mon avis.

+3 -0

J’ai ce passage qui empiète sur la doc mais il est différent de la doc, avec plus de détail. Je pars du principe que si changement il y a, il sera répercuté sur le makefile.

Commençons par mettre à jour toutes les applications : apt-get update && apt-get upgrade

1. Créer un nouvel utilisateur

Avant de commencer l’installation de l’espace de développement, créez un utilisateur.

  1. Connectez-vous en root : su ou su root.
  2. Pour créer un nouvel utilisateur, utilisez la commande adduser a312 où a312 est votre username.

Installer sudo

Profitons d’être toujours connecté en root, pour installer sudo. Nous aurons besoin du package sudo pour la commande makefile.

  1. Installez sudo : apt-get install sudo.
  2. Puis ajoutez l’utilisateur username (ici : a312) : usermod -aG sudo a312.

Sauf indication contraire vous ne devez pas utiliser sudo avec les commandes qui suivent.

2. Télécharger le dépôt du zds avec git

Avant de pouvoir télécharger le dépôt, vous devez forker le dépôt en cliquant sur fork.

  1. Vous êtes encore connecté au compte root, profitez-en pour installer git : apt-get install git.
  2. Connectez-vous au compte username précédemment créé : su a312.
  3. Allez dans votre répertoire : cd ~ et créez un dossier mkdir zds puis allez dans le dossier cd zds.
  4. Pour télécharger le dépôt : git clone https://github.com/VOUS/zds-site. Pour moi, VOUS est le nom de mon compte donc A-312. Plus de détails ici mais vous aurez l’occasion de le lire plus tard.

Configurer git

Avant de continuer vous devez être dans le répertoire git : cd ~/zds/zds-site.

  1. Si vous faites git remote vous devriez avoir origin.
  2. Ajoutez le remote : git remote add upstream https://github.com/zestedesavoir/zds-site et téléchargez la copie locale : git fetch upstream.
  3. Désormais, la commande git remote doit afficher deux lignes : origin et upstream.

3. Commencer à installer le back-end

Dans le répertoire zds-site, faites make install-debian. Pour les autres distributions de linux c’est ici.

Configurer un environnement virtuel :

Assurez-vous d’être dans le bon répertoire : cd ~/zds/zds-site.

  1. Installez python-venv : sudo apt-get install python3-venv.
  2. Puis créez l’environnement zdsenv avec : python3 -m venv zdsenv.
  • Commandes pour utiliser l’environnement virtuel : source zdsenv/bin/activate.
  • Commandes pour en sortir : deactivate.

Créer un alias pour accéder directement au répertoire et à l’environnement virtuel :

Pour créer un alias, vous devez ajouter une ligne au fichier ~/.bash_aliases avec la commande : echo "alias zdsenv=\"cd ~/zds/zds-site && source zdsenv/bin/activate\"" >> ~/.bash_aliases.

5. Préparer le terrain pour le front-end

Pour utiliser le front end, il faut : node et yarn. Pour gérer différentes versions de nodejs, nous allons devoir installer nvm.

Installer nvm :

  1. Commencez par installer curl : sudo apt install curl.
  2. Récupérez la commande de téléchargement sur cette page qui commence par curl et exécutez-là.
  3. Pour activer nvm, vous devez soit relancer votre terminal, soit copier/coller le script indiqué en dessous de « run the following to use it now: » pour pouvoir utiliser la commande immédiatement. (Bien qu’un simple source ~/.bashrc devrait suffire, à confirmer).
  4. La commande nvm devrait afficher l’aide.

Installer nodejs :

  1. Vous devez vérifier la version actuellement utilisée sur cette page avant de continuer, actuellement c’est la version 8 donc : nvm install 8.0.0.
  2. Nodejs est installé ! Vérifiez avec : node -v qui indique v8.0.0.

Installer yarn :

  1. Installez yarn : npm install -g yarn.
  2. Vous pouvez vérifier l’installation avec yarn -v.

6. Installer le front-end

Activez l’environnement virtuel avant de commencer : zdsenv.

  1. Confirmez l’utilisation de node 8.0.0 : nvm use 8.0.0.
  2. Installez le front-end avec : yarn, cette commande va exécuter make install-front.
  3. Profitez-en pour build le front avec : yarn build.

7. Finir l’installation du back-end

Pour finir l’installation du back-end (en étant dans l’espace virtuel zdsenv), faites : make install-back && make migrate. Vous pouvez tester l’installation avec : make run-back et en allant sur http://127.0.0.1:8000/.

L’installation n’est pas encore prête pour un usage intensif, faites CTRL + C. ;)

Pour aller plus loin : Suivez ces instructions

Ensuite il y a la configuration d’apache2 en temps que proxy. + L’explication pour Q/A et tout.

+0 -0

Ce tuto est le bienvenue, et c’est un sacré euphémisme.

Mais j’avoue que certains points me dérangent. Par-exemple, seul le système Windows est présenté, et même pire. Linux est présenté comme s’il n’y avait que des pros de l’informatique qui l’utilisait et que du coup pour eux le tutoriel est inutile.

Ou encore, la sécurisation de la connexion SSH. >_<"

Non changer le port ne sert pas à grand chose :/
Présenter l’utilisation des clés SSH comme minoritaire est assez osé :/
C’est l’un des premiers trucs à faire normalement. À la limite, je peux comprendre que l’on souhaite utiliser un mot-de-passe plutôt qu’une clé (de là à dire que c’est uniquement pour des raisons de portabilité :s). Mais alors que reprocher à la méthode des initiales ? Elle est très simple, pour des phrases pas trop courtes, elle fonctionne assez bien. Conseiller la méthode des piquets ou imagée me semble bien trop compliqué (même si elles sont simples, elles demandent de la pratique).

Bref, je me rends compte que ce n’est pas le tutoriel qui me dérange. Mais plus les choix qui ont été fait. Ce n’est bien-sûr que mon avis.

Après, l’initiative est excellente et si tu as la moindre question je serais ravis de pouvoir aider.

+0 -0

Mais j’avoue que certains points me dérangent. Par-exemple, seul le système Windows est présenté, et même pire.

Je ne connais plus l’alternative de PuTTY sur Linux. Si quelqu’un à ce passage, je le rajoute.

Linux est présenté comme s’il n’y avait que des pros de l’informatique qui l’utilisait et que du coup pour eux le tutoriel est inutile.

Je vois de quel passage tu parles. J’ai rajouté ce passage avant de le mettre en Bêta.

Ou encore, la sécurisation de la connexion SSH. >_<"

ache

Le vocabulaire est mal choisi ? (En dessous je parle de fail2ban).

Non changer le port ne sert pas à grand chose :/

Juste à avoir moins de log de bot qui tente des choses.

Présenter l’utilisation des clés SSH comme minoritaire est assez osé :/
C’est l’un des premiers trucs à faire normalement. À la limite, je peux comprendre que l’on souhaite utiliser un mot-de-passe plutôt qu’une clé (de là à dire que c’est uniquement pour des raisons de portabilité :s). Mais alors que reprocher à la méthode des initiales ? Elle est très simple, pour des phrases pas trop courtes, elle fonctionne assez bien. Conseiller la méthode des piquets ou imagée me semble bien trop compliqué (même si elles sont simples, elles demandent de la pratique).

Je peux modifier le passage sur le mot de passe. Je souhaite proposer une solution clé en main et qui correspond à des déplacements fréquents, comme je stock la clé SSH et je l’utilise ? Dans la pratique je ne sais pas comment on rend ça pratique et sûr.

Mais plus les choix qui ont été fait. Ce n’est bien-sûr que mon avis.

J’ai pris ce qui fonctionnais et me semblais sûr d’un aspect mise en place/documentation/mise en place. A chaque fois que j’essaye un outil, je passe 2 heures à essayer de le régler alors que je fais exactement ce que dis la documentation… (Je n’ai même pas encore réussi à faire fonctionner FocedCommand, il faut que je regarde plus attentivement, heureusement que le KVM d’OVH est là…).

Mais j’avoue que certains points me dérangent. Par-exemple, seul le système Windows est présenté, et même pire.

Je ne connais plus l’alternative de PuTTY sur Linux. Si quelqu’un à ce passage, je le rajoute.

Ça s’appelle SSH sous linux.

(En dessous je parle de fail2ban).

Je pense que tout ça, c’est très très largement overkill. Si tu veux donner des conseils de sécurité basiques, écris un tuto sur les gestionnaires de mot de passe.

On parle pas d’un serveur beta de ZdS ici, on parle juste d’une instance perso.

Expliquer comment sortir tout l’arsenal, c’est bien, mais dans un tuto qui parle de comment sécuriser un serveur linux, ici c’est pas le sujet et c’est pas nécessaire. On fait pas un tuto sur les meilleures façon de tuer à main nue quand le sujet c’est créer un château de sable. Ok tu préfères que personne marche accidentellement dessus, mais faut pas exagérer…

Tu peux très bien activer le debug de django, faire tourner ça sur le port 80 sans déployer fail2ban, iptables, mettre des mots de passe de partout et faire que ton toy project soit accessible que par port knocking, tout va bien se passer.

+1 -0

Mais j’avoue que certains points me dérangent. Par-exemple, seul le système Windows est présenté, et même pire.

Je ne connais plus l’alternative de PuTTY sur Linux. Si quelqu’un à ce passage, je le rajoute.

A-312

PuTTY est également disponible sous Linux (au moins sous ArchLinux et Debian, ainsi que leurs dérivés a priori). ;)
Sinon, reste la possibilité d’utiliser la console tout simplement.
Il est vrai que ce serait dommage d’exclure Linux de ce tutoriel.

Pour ce qui est de la sécurisation de la connexion via SSH, je ne pense pas qu’il s’agisse d’un souci de vocabulaire.
D’après ce que je comprends, @ache trouve préférable d’utiliser une paire de clés SSH, ou au moins évoquer cette méthode, en précisant qu’elle est assez courante.
Par ailleurs, les techniques de mémoire que tu préconises pour les mots de passe lui paraissent trop compliquées, la méthode des initiales d’une phrase, que tu déconseilles, lui semble au moins aussi légitime et plus accessible. C’est en rapport à ce passage :

Il doit être long, unique, ne pas être évident, contenir différents types de : caractères, ponctuations, chiffres, majuscules, minuscules… Évitez d’utiliser l’astuce des initiales d’une phrase, cela raccourcit le mot de passe et sa complexité donc sa durée de vie. Utilisez des techniques de visualisation et du palais de la mémoire pour le retenir. Où utiliser un logiciel coffre fort spécialisé avec un master password. ↩

Bref, c’est essentiellement des désaccords sur la manière de présenter les choses et les choix que tu as pu faire.

Ce que dit @cepus n’est pas insensé, même si personnellement je préfère quand même l’approche qui consiste à détailler l’ensemble de la procédure visant à sécuriser le serveur (a minima à l’évoquer accompagnée de liens vers des ressources complémentaires) comme tu le fais actuellement.
Créer un article / tutoriel séparé pourrait également être une solution.

D’après ce que je comprends, @ache trouve préférable d’utiliser une paire de clés SSH, ou au moins évoquer cette méthode, en précisant qu’elle est assez courante.

Mysterri1

Tout-à-fait ! Pas besoin d’en parler en détail, c’est pas le sujet mais au moins pas le présenter comme la mauvaise façon de faire.

Par ailleurs, les techniques de mémoire que tu préconises pour les mots de passe lui paraissent trop compliquées, la méthode des initiales d’une phrase, que tu déconseilles, lui semble au moins aussi légitime et plus accessible. C’est en rapport à ce passage :

Il doit être long, unique, ne pas être évident, contenir différents types de : caractères, ponctuations, chiffres, majuscules, minuscules… Évitez d’utiliser l’astuce des initiales d’une phrase, cela raccourcit le mot de passe et sa complexité donc sa durée de vie. Utilisez des techniques de visualisation et du palais de la mémoire pour le retenir. Où utiliser un logiciel coffre fort spécialisé avec un master password.

Mysterri1

Tout à fait encore ! Par-contre, je suis 100% pour l’utilisation d’un gestionnaire de mot de passe. (Mais là, c’est très bien fait, c’est évoqué sans entré dans les détails). (Tiens en passant Ou utiliser et pas Où utiliser)

Bref, c’est essentiellement des désaccords sur la manière de présenter les choses et les choix que tu as pu faire.

Mysterri1

Yep !

PS: T’abuse pour ForceCommand. Tiens un exemple, la fin de mon sshd_config :

Match Address 54.37.13.71
        ForceCommand /usr/bin/tks.sh

Et tks.sh :

#!/bin/bash

echo "Ahahaha ! Tu ne pourras trouver mon mdp secret ! 🦝"

read mdp

if [ "$mdp" = 'floesttropbo' ];  then
        echo 'Ahahahah ! Tu connais mon secret ! 😳'
        `getent passwd $(id -un) | cut -d':' -f 7`
fi

Je tiens à préciser que j’utilise fish et que du coup, j’ai changé de langage de script juste pour que ce soit bash et que tu sois pas dépayser. 💕

Et les droits du fichier /usr/bin/tks.sh :

$ ls -l /usr/bin/tks.sh 
-rwxr-xr-x 1 root root 215 28 août  00:05 /usr/bin/tks.sh*

Normalement avec ça t’as même pas besoin de la doc. ;)

PPS: J’ai mis tant de temps que ça à écrire ce message /o\

J’aimezestedesavoirc’estgenial est plus plus sûr que jzdscg.

Certes. Mais le mdp devrait être : "J’azds,c’eg!" Qui est déjà bien mieux. Mais bref, l’idée est que cette discutions n’a rien à faire dans le tutoriel.

+0 -0

J’aimezestedesavoirc’estgenial est plus plus sûr que jzdscg.

Certes. Mais le mdp devrait être : "J’azds,c’eg!" Qui est déjà bien mieux.

ache

Nope…

  • J’aimezestedesavoirc’estgenial 185 bits d’entropie
  • J’azds,c’eg! 76 bits d’entropie
  • (jzdscg 22 bits)
+0 -0

Pour moi tu n’as pas un tuto, mais une collection de tutos qui devraient être indépendants.

De plus, pense à l’effet obtenu sur le nouveau de bonne volonté s’il voit qu’il y a un big-tuto complet juste pour installe une bêta. Personnellement je m’enfuirais.

Ce sujet est verrouillé.