web-dev-qa-db-fra.com

Laravel Homestead adresse IP ne fonctionne pas

J'utilise Laravel Homestead 2.0 pour mon VM et j'essaie de servir mes sites avec l'adresse IP par défaut du fichier YAML 192.168.10.10.

Mon fichier/etc/hosts ressemble à ceci:

# Homestead
192.168.10.10   beta.dev
192.168.10.10   deploy.dev

Mon fichier Homestead.yaml ressemble à ceci:

---
ip: "192.168.10.10"
memory: 2048
cpus: 1

authorize: ~/.ssh/id_rsa.pub

keys:
    - ~/.ssh/id_rsa

folders:
    - map: ~/Projects
      to: /home/vagrant/Projects

sites:
    - map: beta.dev
      to: /home/vagrant/Projects/emorybeta/public
    - map: deploy.dev
      to: /home/vagrant/Projects/deploy/public

...

Les sites apparaissent lorsque je lie mes domaines à 127.0.0.1 mais je dois ajouter le port 8000 à la fin de l'URL (ce n'est pas grave, je souhaite simplement que l'adresse IP spécifiée fonctionne). 

Est-ce que quelqu'un sait pourquoi je ne peux pas me connecter au serveur lorsque mes domaines sont pointés vers 192.168.10.10?


METTRE À JOUR: 

Lorsque je lance un ping sur deploy.dev, la bonne adresse IP apparaît, mais mon navigateur ne peut toujours pas se connecter au serveur. Je pense que cela pourrait avoir quelque chose à voir avec les problèmes de DNS dans Yosemite.

14
evcohen

J'ai eu les mêmes problèmes il y a quelques semaines.

Premièrement: Assurez-vous que les chemins de vos dossiers sont corrects, le cas échéant, revérifier

Suivant: Exécutez Homestead destroy et Homestead pour réinitialiser la machine virtuelle.

si tout cela ne fonctionne pas: Vérifiez si vous avez un appareil chez vous qui pourrait aussi être sous 192.168.10.10.

Si tout cela ne fonctionne pas, votre problème est probablement beaucoup plus difficile à résoudre et je vous conseillerais de créer un problème avec github.

5
Nick

Hey j'ai eu exactement le même problème. Je l'ai finalement fait fonctionner en installant le paquet obsolète de net-tools: Sudo apt-get update et Sudo apt-get install gnome-nettool

Après cela, Homestead destroy et Homestead up

Cela m'a permis d'accéder aux sites de mes machines virtuelles à partir du navigateur de ma machine locale en utilisant les "domaines" spécifiés dans le fichier hosts - dans votre cas beta.dev et deploy.dev - sans en faisant référence à localhost ou au port 8000. Bon chance, espérons que cela aide.

3
Logan Graba

Voici la solution que j'ai faite pour ma machine Windows 10:

Assurez-vous d’ajouter un itinéraire persistant à votre zone vagabondeDans la commande administrateur Invite entrez route -p add 192.168.10.0 masque 255.255.255.0 192.168.10.1

Et assurez-vous que vous êtes en mesure de ping 192.168.10.10

Vérifiez également que l'adresse IP configurée pour l'adaptateur d'hôte uniquement de virtualbox est 192.168.10.1 avec le masque 255.255.255.0.

3
neethumol

J'ai eu la même situation, mais j'ai fait un changement.

J'ai changé mon fichier/etc/hosts avec cet IP 127.0.0.1

1
navamario

Dans mon cas, le problème a été résolu en laissant vagrant up installer les ajouts invités:

~/Homestead (master|✔) $ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'laravel/Homestead' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
[...]
GuestAdditions versions on your Host (5.0.26) and guest (5.0.20) do not match.
[...]
Copy iso file /Applications/VirtualBox.app/Contents/MacOS/VBoxGuestAdditions.iso into the box /tmp/VBoxGuestAdditions.iso
mount: /dev/loop0 is write-protected, mounting read-only
Installing Virtualbox Guest Additions 5.0.26 - guest version is 5.0.20
Verifying archive integrity... All good.
Uncompressing VirtualBox 5.0.26 Guest Additions for Linux............
VirtualBox Guest Additions installer
Removing installed version 5.0.20 of VirtualBox Guest Additions...
Removing existing VirtualBox DKMS kernel modules ...done.
Removing existing VirtualBox non-DKMS kernel modules ...done.
Copying additional installer modules ...
Installing additional modules ...
Removing existing VirtualBox DKMS kernel modules ...done.
Removing existing VirtualBox non-DKMS kernel modules ...done.
Building the VirtualBox Guest Additions kernel modules ...done.
Doing non-kernel setup of the Guest Additions ...done.
You should restart your guest to make sure the new modules are actually used

Après cela, j'ai eu une nouvelle interface avec l'adresse IP attendue:

enp0s8    Link encap:Ethernet  HWaddr 08:00:27:e8:04:04
          inet addr:192.168.8.10  Bcast:192.168.8.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fee8:404/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:996 (996.0 B)
1
crishoj

L'installation de net-tools sur Ubuntu a résolu ce problème pour moi.

$ Sudo install net-tools
$ vagrant destroy
$ vagrant up
1
Giovanni S

Hier, j'ai eu un problème similaire pour Homestead 5. Il s'est avéré que la cause de mon problème était que je courais avec le mauvais fichier Vagrant.

Une instance devrait donner une réponse à l'adresse ip: 192.168.10.10

Pour corriger le problème dans mon cas, j’ai suivi les instructions suivantes: http://laravel.com/docs/5.0/Homestead

Récapituler:

En terminal: 

vagrant box add laravel/Homestead

puis 

git clone https://github.com/laravel/Homestead.git Homestead

puis 

cd ./Homestead  

et exécutez cette commande DE L'INTERIEUR du nouveau dossier "Homestead"

bash init.sh

puis exécutez les commandes vagrant up et vagrant provision dans ce fichier Vagrant, qui aurait dû être créé dans ./Homestead

Voici à quoi ressemble la sortie de la commande vagrant provision sur mon système:

    vagrant provision
==> default: Running provisioner: file...
==> default: Running provisioner: Shell...
    default: Running: inline script
==> default: Running provisioner: Shell...
    default: Running: inline script
==> default: Running provisioner: Shell...
    default: Running: /var/folders/q6/pgygb1ln4rg7_nvv0p8n1v300000gn/T/vagrant-Shell20150714-94163-17xwlzk.sh
==> default: Running provisioner: Shell...
    default: Running: /var/folders/q6/pgygb1ln4rg7_nvv0p8n1v300000gn/T/vagrant-Shell20150714-94163-rncs6l.sh
==> default: nginx stop/waiting
==> default: nginx start/running, process 1751
==> default: php5-fpm stop/waiting
==> default: php5-fpm start/running, process 1766
==> default: Running provisioner: Shell...
    default: Running: /var/folders/q6/pgygb1ln4rg7_nvv0p8n1v300000gn/T/vagrant-Shell20150714-94163-e9qxwn.sh
==> default: Warning: Using a password on the command line interface can be insecure.
==> default: Warning: Using a password on the command line interface can be insecure.
==> default: Running provisioner: Shell...
    default: Running: /var/folders/q6/pgygb1ln4rg7_nvv0p8n1v300000gn/T/vagrant-Shell20150714-94163-14rlz2c.sh
==> default: Running provisioner: Shell...
    default: Running: /var/folders/q6/pgygb1ln4rg7_nvv0p8n1v300000gn/T/vagrant-Shell20150714-94163-16ethaq.sh
==> default: Running provisioner: Shell...
    default: Running: inline script
==> default: Running provisioner: Shell...
    default: Running: inline script
==> default: Running provisioner: Shell...
    default: Running: inline script
==> default: php5-fpm stop/waiting
==> default: php5-fpm start/running, process 1861
==> default: Running provisioner: Shell...
    default: Running: inline script
==> default: You are already using composer version 92faf1c7a83a73794fb914a990be435e1df373ca.
==> default: Running provisioner: Shell...
    default: Running: /var/folders/q6/pgygb1ln4rg7_nvv0p8n1v300000gn/T/vagrant-Shell20150714-94163-btuuhg.sh
1
Nate Flink

Ce problème est survenu sur ma machine Windows et il s’est avéré que j’avais accidentellement inversé la section des dossiers "map" et "to". Lorsque j’ai trouvé que le dossier ne se trouvait pas sous ~/code/dans la session SSH vagabonde, il était évident que cela ne fonctionnait pas correctement, mais une double vérification des chemins ne donnait rien. 

Voici la manière correcte de mapper la section de dossier sur votre ordinateur Windows:

folders:
    - map: D:/Development/PHP/projects/
      to: /home/vagrant/code
1
Josh Maag

J'ai eu exactement ce problème, et il s'est avéré que nginx ne parvenait pas à démarrer en raison d'une erreur lors du chargement des certificats TLS. La commande vagrant up ne signale pas que nginx n'a pas pu démarrer ou que tous les ports n'ont pas été liés.

Pour diagnostiquer cela, j'ai fait ce qui suit:

$ nmap Homestead.app
Starting Nmap 7.01 ( https://nmap.org ) at 2017-10-03 16:16 NZDT
Nmap scan report for Homestead.app (192.168.10.10)
Host is up (0.00077s latency).
Not shown: 995 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
1025/tcp open  NFS-or-IIS
3306/tcp open  mysql
5432/tcp open  postgresql

Il n'y a pas de port 80 dans la liste. Vérifions de nouveau le port 80.

$ nmap Homestead.app -p 80
...
Host is up (0.00020s latency).
PORT   STATE  SERVICE
80/tcp closed http

Donc, c'est certainement fermé. Que disent les journaux d'invités? vagrant ssh et ...

    $ systemctl status nginx.service
    ...
    Active: failed (Result: exit-code) since Tue 2017-10-03 03:06:12 UTC; 1min 30s ago
    ...
 Homestead systemd[1]: Starting A high performance web server and a reverse proxy server...
 Homestead nginx[1250]: nginx: [emerg] PEM_read_bio_X509_AUX("/etc/nginx/ssl/Homestead.app.crt") failed (SSL: error:0906D06C:PEM routines:PEM_read_bio:no start line:Expecting: TRUSTED CERTIFICA
 Homestead nginx[1250]: nginx: configuration file /etc/nginx/nginx.conf test failed
 Homestead systemd[1]: nginx.service: Control process exited, code=exited status=1
 Homestead systemd[1]: Failed to start A high performance web server and a reverse proxy server.
 Homestead systemd[1]: nginx.service: Unit entered failed state.
Homestead systemd[1]: nginx.service: Failed with result 'exit-code'.

Nginx n'a pas pu démarrer en raison d'une erreur dans sa configuration. L'erreur PEM_read_bio_X509_AUX pointe vers le fichier /etc/nginx/ssl/Homestead.app.crt. Où ce fichier est-il utilisé dans la configuration?

$ Sudo vim /etc/nginx/sites-enabled/Homestead.app

J'ai commenté les lignes liées:

@@ -1,6 +1,6 @@
 server {
     listen 80;
-    listen 443 ssl http2;
+#    listen 443 ssl http2;
     server_name Homestead.app;
     root "/home/vagrant/Code/public";

@@ -42,7 +42,7 @@ server {
         deny all;
     }

-    ssl_certificate     /etc/nginx/ssl/Homestead.app.crt;
-    ssl_certificate_key /etc/nginx/ssl/Homestead.app.key;
+#    ssl_certificate     /etc/nginx/ssl/Homestead.app.crt;
+#    ssl_certificate_key /etc/nginx/ssl/Homestead.app.key;
 }

Démarrez nginx avec $ Sudo service start nginx et exécutez à nouveau nmap à partir de l'hôte.

$ nmap Homestead.app -p 80,443
...
PORT   STATE SERVICE
80/tcp open  http
443/tcp closed https

Le port 80 est ouvert et devrait maintenant être accessible à partir de http://Homestead.app . Bien sûr, TLS ne fonctionnera pas, mais vous devriez pouvoir le réparer en générant de nouveaux certificats. Je ne suis pas sûr de la raison pour laquelle les certificats n'ont pas pu être chargés en premier lieu.

0
PeloNZ