Le serveur web pour les snuls (nginx): les grandes connaissances de base dans l'optique de faire tourner par exemple un projet Ruby on Rails sur la toile.
Notes publiques.

La branche des "réseaux et communications" en informatique est probablement passionnante, mais elle est complexe (personnellement ça me passionne pas des masses). Cela dit, voici quelques notions théoriques générales très basiques pour pouvoir gérer son propre serveur. On passe ensuite à la pratique avec la mise en production d'un projet rails.

Cette page de note est une sythèse des informations que j'ai récolté à ce propos. Infos qui sont souvent absconces à mon gout, dispersées que j'ai récolté… Gloubiboulga c'être.

Ici sont exposé les notions de base pour créer un serveur NGINX sur son Raspberry Pi pour faire tourner son projet RoR sur la toile. L'idée est de comprendre vulgairement le fonctionnement global d'un serveur, des réseaux.

Un serveur n'est rien de plus qu'un ordinateur; mais une partie de son contenu est laissé volontairement publique pour que n'importe qui y puisse acceder depuis un ordinateur munie d'une connexion internet. EN GROS. Un site n'est donc rien de plus qu'un dossier de fichiers (html, css, javascript, php, autre…) qui se situe dans un serveur. Les données de ce site (comptes admins, messages, commentaires…) y sont stockés, et certaines informations sont "cachées", "privées" par des manipulation habiles de cryptage des données.

L'interet d'avoir un serveur chez soi est :

•Didactique --> ça rend le virtuel "physique", concret. Ça matérialise les données, cette boite noire. renvoie aux infrastrutures. ("livre : à nos amis)
•Politique --> Le processus de délocalisation des données est un acte citoyen, le monopole des moyens de productions et de diffusion pas seulement aux mains des sociétés hégémoniques, voir Framasoft, la quadrature du net, flossmanuals, etc. On est le seul propriétaire de nos données.
•Économique --> Le cout d'un hébergeur comme OVH est d'environ 30€ par an.

etc.

Un webdoc sur les données : http://worldbrain.arte.tv/#/ qui donne de bonnes raisons de faire un tit serveur à la zonmai.

Degooglisons l'internet --> https://degooglisons-internet.org/

"Le projet « Dégooglisons Internet » - qui ne concerne d’ailleurs pas que Google - consiste à proposer des services alternatifs face à un maximum de services que nous évaluons comme menaçants pour nos vies numériques."

Manuels libres --> http://www.flossmanualsfr.net/

Quadrature du Net --> https://www.laquadrature.net/fr

LA NOTION DE RESEAU: pour une définition molle

Lorsqu'on va sur Google un moteur de recherche lambda, on fonce sur le réseau internet, on peut acceder à des milliards d'ordinateurs (euh serveurs) qui livrent des données. Tous les sites trouvés par un moteur de recherche nous donnent une liste de sites les plus pertinants par rapport à notre recherche. Ces sites existent bel et bien sur ce méga- réseau puisque chaque site est hébergé sur un serveur.

photo baie de serveurci-contre: des tas de serveurs qui doivent héberger des centaines de sites, avec des milliers de GigaOctets en capacité de stockage. Mais nous notre serveur, ça peut être juste ça (et tant mieux ça va couter moins cher en électricité):

photo raspberry pi

Pour nous, utilisateur, on accède à l'internet grace à notre Fournisseur d'Acces Internet (FAI), comme SFR, FREE, Orange, Etc… Ces entreprises nous emprunte une box (routeur) qui possède un adresse IP fixe ou dynamique. On se connecte sur la box, et la box nous envoie sur l'internet. euh voila.

>> On verra plus tard à quoi sert cette fameuse adresse IP. L'adresse URL d'un site n'est ni plus ni moins qu'une adresse IP déguisée: ce déguisement, c'est le nom de domaine. On verra plus tard les histoires de nom de domaine aussi. Gardons ça dans un coin de notre tête: tout ce qui participe à faire transiter une information est identifiable.

BREF. La box à une adresse IP, et les ordinateurs qui y sont connectés aussi, de nature un peu différente. Si on n'est connecté à rien du tout, on peut donc logiciement acceder à rien, à part aux données de notre propre ordinateur: on est dans du "local très local" ahah. Ce local très local, cet adresse strictement personnelle, c'est 127.0.0.1 ou "localhost". Si on entre cette adresse ip dans un navigateur et qu'on a un serveur activé, on pourra y acceder, mais j'insiste, seulement avec SON ordinateur. Quand je dis "serveur activé" je veux dire "rendre publique une partie de son ordinateurs à".

Revenons un coup à la box livré par notre FAI. C'est cette box qui nous relie au super-réseau, cette box fait le pont entre notre ordinateur et la masse rhizomique de tous les serveurs qui sont d'ssus.

Si des ordinateurs partagent le même réseau (via la même box par exemple) on pourrait acceder au contenu de tous les ordinateurs qui y sont connectés via l'un d'eux pour peu qu'une "porte" soit laissée ouverte. C'est l'intranet.
Mais un utilisateur exterieur, avec une autre connexion, ne pourrait pas fouiller chez vous. Ce ne sont pas ses affaires. Chacun chez soi merde.
Attention ce réseau en local peut être crée sans connexion internet: un routeur suffit. Il faut juste qu'ils y soient tous connectés, par wifi, cable ou intravéneuse. Un ordinateur ou même un téléphone portable peuvent faire office de routeur.

Ici l'idée est de dissocier le réseau local et le super-réseau, qu'on pourrait qualifier de global: l'internet. La notion du réseau, sa portée, est stratifiable. Le "très local" (son ordinateur), le local (les ordinateurs connectés sur un même routeur, par wifi, ethernet pas forcément avec une connexion internet… on appelle ça aussi l'intranet ou bien LAN), et l'internet, bien connu.

DU LOCAL TRÈS LOCAL

Avant de relier son serveur à l'internet, nous allons simuler le fonctionnement sur une échelle plus petite, et élargir sa portée d'accessibilité si l'on peut dire de plus en plus. D'abord sur son ordinateur propre, puis sur son réseau local et enfin sur internet.

Le local "très local", on sait déjà faire: lorsqu'on bidouille avec rails ou avec du php, on ouvre un serveur local avec soit une commande (rails s) ou bien avec MAMP/WAMP ou bien pour php une commande comme "php -S localhost:1234". 1234 étant un paramètre à modifier selon le port que l'on choisit d'ouvrir…Bref, nous ouvrons via une couche logicielle notre serveur "très local." On tape localhost:1234 ou bien 127.0.0.1:1234 et on accède à la partie rendue publique de notre ordinateur.

DU LOCAL PARTAGÉ: EXPERIMENTER L'INTRANET

Par ailleurs, lorsqu'on lance un rails s, on rend publique notre application, accessible par conséquant si on tape l'adresse ip de l'ordinateur qui "héberge" son projet + le numéro du port. Pour connaitre son adresse ip: commande ifconfig.

l'adresse ip local des diffénts ordinateurs ressemblera à un truc kommça: 192.168.1.xx.

[exemple explicite]

Donc si on tape sur un ordinateur lambda 192.168.1.xx:3000 (pour rails) on accède au site partagé sur le réseau intranet. C'est un bon début.

SUIVRE LE PROTOCOLE

Lorsqu'on lance un serveur, en local ou en ligne, nous utilisons des logiciels servant des requêtes respectant le protocole de communication client-serveur HyperText Transfer Protocol (HTTP). Lorsqu'on accède à un site, on demande de nous envoyer des informations du serveur. L'information renvoyée est traitée puis renvoyé au client (le visiteur du site).

En local, c'est Apache pour php, et pour rails, c'est WEBrick, même si il est recommandé d'en utiliser d'autre pour sa mise en ligne (= mise en production ou bien déploiement).

Pour le web, nous allons avoir besoin (au choix) de nginx, node.js, apache selon ce qu'on veut… Il y a plusieurs logiciels comme on le voit, mais leur fonctionnement diffère. Ngnix semble plus judicieux pour faire tourner un serveur sur rapsberry pi, il est plus rapide, plus adéquat pour des petits ordinateurs (il semblerait) et d'origine russe: par ailleurs, il a été conçu par le célèbre homme politique Mikhaïl Gourbatchev qui avait des compétances en informatique, à l'instar de ses détracteurs mais en fait non c'est faux hein ahah.

gourbatchev

Ce logiciel c'est une couche qui nous permet de pas avoir à foutre trop les pieds dans les questions techniques à propos de la gestion du transit des données entre deux occurences. On l'installe, et pof, y a plus qu'à le lancer.

TESTER NGNIX (ou lancer un serveur web…et toujours en intranet hein)

On va oublier rails, php et compagnie. Sur notre Raspberry Pi, on va juste installer notre logiciel de serveur web: nginx.

Bien, sur notre serveur expérimental (donc notre ordinateur, oui c'est bon je rabache) nous allons installer ce logiciel. Je choisis donc NGINX. On pourrait mettre Apache, mais c'est vous qui voir.

sudo aptitude install nginx

Ok. Il y a nginx d'installé. ok pour le lancer c'est:

sudo service nginx start

…puis on active la configuration par défaut:

sudo service nginx configtest

Bien, si on tape depuis n'importe quel ordinateur l'adresse ip de notre serveur expérimental on tombe sur une page ou il y a écrit "welcome to nginx". Depuis l'ordinateur-serveur-expérimental, un 127.0.0.1 ou un localhost suffira, c'est logique. Pour l'arrêter c'est :

sudo service nginx stop

… Logique aussi.

Les fichiers de configuration de notre serveur se situent par défaut dans /etc/nginx. On s'y place (cd /etc/nginx) et on affiche (ls) ce qui s'y trouve. Il y a un certain nombre de fichiers et de dossiers.

"""On y retrouve (entre autres):

""""" SOURCE : http://blog.nicolargo.com/2011/01/installation-et-test-de-nginx-sous-ubuntu.html

(les lignes qui vont suivre vont reprendre quasi-littérallement cet article).

Si on regarde le dossier sites-availables, nous y trouvons un fichier "default". On l'ouvre. Pour l'instant, on va ignorer toutes les lignes qui commencent par "#". Ce sont des commentaires.

Les lignes remarquables à partir de "serveur{":

listen 80 default_server: on écoute sur le port TCP. TCP, est un protocole de transport fiable, en mode connecté. (On s'en fiche pour l'instant).

root /var/www/html

C'est l'emplacement du dossier qui sera rendue publique (ça peut varier). Votre site, il est ici. On peut même vérifier: on s'y rend et on affiche le contenu du ficher html. C'est bien ce qui est affiché lorsqu'on arrive sur le serveur via l'adresse ip. Le "root" sert à pointer l'emplacer du dossier qui sera accessible publiquement.

On va le changer. On va créer un dossier de test:

mkdir /home/labo/www

On y crée une page html de test "index.html" (mettez y ce que vous voulez, c'est pour voir). On va avoir besoin de faire ça en sudo alors ce sera plus pratique de le faire par vi, qui est très casse-couille à utiliser quand on a pas l'habitude.

sudo vi index.html

Maintenant on va configurer notre serveur en créant le fichier adéquat:

sudo vi /etc/nginx/sites-available/monsite

  server {
  
listen 80;
root /home/labo/www;
index index.html index.htm;
server_name localhost;

location / {
try_files $uri $uri/ /index.html;
}
}

SANS FAUTES HEIN. MOUAIS.

Bon. Pour l'instant le site actif, c'est un truc comme "défaut". Pour le desactiver, on pourrait… le supprimer.

cd /etc/nginx/sites-enabled

sudo rm default

sudo ln -s ../sites-available/monsite

(Et on y copie au passage à la place notre fichier de configuration).

Allez on relance le serveur;

sudo service nginx restart

Si il n'y a pas de messages pessimistes, c'est que c'est bon. On peut s'y connecte soit directement via localhost, soit pour les autres ordis sur le réseau en passant par l'intranet, via l'adresse ip du serveur.

L'article cité plus haut conclut cet victoire par:

""""Pour rendre le site "visible depuis l'extérieur", il faut changer la ligne:

server_name localhost;

Puis la remplacer par:

server_name www.mondomaine.com;

Il faut bien sur que le nom www.mondomaine.com pointe sur l'adresse IP de votre serveur Nginx...""""

Et là, il est temps qu'un autre chapitre s'ouvre à propos des noms de domaine, DNS, et adresses IP…

Noms de domaine, DNS et adresses IP…

On commence à saisir très globablement le fonctionnement d'un serveur… Mais ça ne marche qu'en local… et quid le nom de domaine? Par intuition, qu'est-ce qui pourrait nous faire passer du local au global?

photo box internet

SFR, Bouygues, Free, Orange et compagnie sont des Fournisseurs d'Accès Internet (FAI). C'est eux qui nous fournissent la possibilité de trainer sur l'internetosphère, et notamment sur le Figaro Magazine. C'est eux qui nous fournissent un accès à tous les ordinateurs et serveurs du monde entier qui y sont connectés. Une box est un pont entre le local et le global, c'est un aussi un routeur et un petit serveur de configuration. Routeur, on a déjà vu, il nous permet de faire un réseau intranet. Serveur, en revanche, c'est moi évident. Sans configuration, c'est à dire par défaut, si on accède à l'IP de la box (qu'on peut récupérer en allant sur monippublique.com) on accède au panneau de configuration de la box si on est connecté sur le réseau de cette dernière. (Cette dernière phrase nous apprend par ailleurs quelque chose: lorsqu'on va sur un site, on y accède avec un certain identifiant, c'est l'ip de la box, qui est géolocalisable. Selon le fAI, l'ip peut changer régulièrement (on parle d'ip dynamique) ou une ip fixe (c'est le cas pour Free)).
Quoiqu'il arrive, dynamique ou pas, cette ip est identifiable. Toute chose qui participe à faire transiter des données est identifiable.

Si on accède à l'ip de la box depuis une autre connexion, la box, par défaut, refusera l'accès, ça va mouliner. Et là, peut-être que ça fait tilt dans les caboches: et si on autorisait la possibilté à autrui d'acceder à ce serveur?

Alors pour commencer, le serveur de la box n'est pas fait pour héberger un site. C'est juste un serveur de configuration qui nous permet de bricoler un réseau local par exemple. En revanche on pourra renvoyer balle sur un serveur qui est sur la connexion. On va rediriger les requetes de la box vers un serveur approprié. On appelle ça redirection ou translation de ports. Côté serveur, on vérifie que son adresse ip local est fixe pour qu'on puisse renvoyer les requetes vers cette adresse. Chaque FAI à son interface propre, l'endroit ou il faut bidouiller s'appelle "NAT, translation ou redirection de ports"… ou qq chose comme ça…Maintenant, si on lance le serveur avec une configruration adaptée qq comme:

server{
 
listen 80;
root /home/www;
index index.html index.htm;
server_name 234.24.10.47;
 
[…]
 
}

Si on tape l'adresse ip, on tombe sur notre site. Si on veut un site qui s'appelle "trou-normand.com" il faut acheter un nom de domaine (là on a pas le choix). Il faut que ce nom de domaine pointe bien sur notre ip, c'est une redirection.
On peut réserver un nom de domaine pendant 10 ans. En France, c'est l'AFNIC (une association/institution) qui gère ça. En qq sorte, ce nom de domaine va nous permettre de "déguiser" une adresse ip en quelque chose de cette forme: con.fr, zobi.alsace, etc. Sans entrer dans des détails techniques qui n'ont pas bcp d'importance ici, un nom de domaine, par un service DNS, nous permet de "traduire" notre adresse ip en nom de domaine. Pour les adresse ip dynamiques, on utilise le service DynDNS, on peut le faire via DynDNS.com ou encore "no-ip.com" ou bien encore par OVH (ce qui nous permet de choisir le nom de domaine qu'on veut). On peut faire cette redirection via un service OVH, dynDNS, etc, ou bien manuellement, ce que personnellement, je ne juge pas nécessaire.

Pour en savoir plus sur le service DNS >> https://openclassrooms.com/courses/gerer-son-nom-de-domaine

Configurer dynDNS via OVH >>http://p3ter.fr/gestion-du-dyndns-sous-linux-avec-ovh.html

Un souci de cohérence, la brique internet à la rescousse.

On se dit super, on est enfin vraiment propriétaire de ses données, puisque le serveur qui contiendra le contenu de nos sites/services est chez nous, à nos pieds, avec un ordinateur qui tourne sur Linux. Ça y est, on se dit qu'on est un libertaire 3.0. Mais il y a quelque chose qui cloche. Hé oui, notre FAI regarde et sauvegarde tout ce qu'on fait par le biais de l'accès que leur box nous donne. Il pourrait même vendre des informations qu'il a récolté à des entreprises privées. Le maillon traitre est donc notre box. Heuresement, des hackers ont mis au point cette fameuse brique internet qui cache le parcours nos balades connectées.

 

 

 

AUTRES SOURCES

 

http://blog.nicolargo.com/2011/01/installation-et-test-de-nginx-sous-ubuntu.html

http://raspbian-france.fr/installer-serveur-web-raspberry/

http://raspbian-france.fr/installer-nginx-raspbian-raspberry/

http://raspbian-france.fr/mettre-en-ligne-serveur-web-raspbian-dydns-port-forwarding/

https://www.phusionpassenger.com/library/walkthroughs/deploy/ruby/ownserver/nginx/oss/install_language_runtime.html

http://p3ter.fr/gestion-du-dyndns-sous-linux-avec-ovh.html

https://openclassrooms.com/forum/sujet/serveur-nginx-raspberry-pi

https://labriqueinter.net/