Laravel Die IP-Adresse des Homestead funktioniert nicht

Question

Ich verwende Laravel Homestead 2.0 für meine VM und versuche, meine Sites mit der Standard-IP-Adresse in der YAML-Datei 192.168.10.10 zu bedienen

Meine/etc/hosts-Datei sieht folgendermaßen aus:

# Homestead 192.168.10.10 beta.dev 192.168.10.10 deploy.dev

Meine Homestead.yaml-Datei sieht folgendermaßen aus:

--- 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 ...

Die Sites werden angezeigt, wenn ich meine Domains mit 127.0.0.1 verlinke, aber ich muss Port 8000 an das Ende der URL anhängen (was keine große Sache ist, ich möchte nur, dass die angegebene IP-Adresse funktioniert).

Weiß jemand, warum ich keine Verbindung zum Server herstellen kann, wenn meine Domains auf 192.168.10.10 verweisen?

AKTUALISIEREN:

Beim Ping von deploy.dev wird die richtige IP-Adresse angezeigt, aber mein Browser kann immer noch keine Verbindung zum Server herstellen. Ich denke, es hat etwas mit DNS-Problemen in Yosemite zu tun.

Nick · Accepted Answer

Ich hatte vor einigen Wochen die gleichen Probleme.

Zuerst: Vergewissern Sie sich, dass Ihre Ordnerpfade korrekt sind, und überprüfen Sie sie gegebenenfalls

Als Nächstes: Homestead destroy und Homestead ausführen, um die VM neu zu initialisieren

wenn dies nicht funktioniert hat: Überprüfen Sie, ob Sie zu Hause Geräte haben, die möglicherweise auch auf 192.168.10.10 stehen.

Wenn das alles nicht funktioniert hat, ist es wahrscheinlich schwieriger, das Problem zu beheben, und ich würde vorschlagen, ein Github-Problem zu machen.

Logan Graba · Answer

Hey, ich hatte genau das gleiche Problem. Ich habe es schließlich durch die Installation des veralteten net-tools-Pakets zum Laufen gebracht: Sudo apt-get update und Sudo apt-get install gnome-nettool

Danach, Homestead destroy und Homestead up

Dies ermöglichte mir den Zugriff auf die Websites meiner virtuellen Maschinen über den Browser meines lokalen Computers über die in der hosts-Datei angegebenen "Domänen" - in Ihrem Fall beta.dev und deploy.dev - ohne -, die sich auf localhost oder port 8000 beziehen Glück, hoffe das hilft.

neethumol · Answer

Dies ist die Lösung, die ich für meinen Windows 10-Computer gemacht habe:

Vergewissern Sie sich, dass Sie Ihrer Vagrant-Box eine dauerhafte Route hinzufügen. Geben Sie in der Administrator-Eingabeaufforderung route -p add 192.168.10.0 mask 255.255.255.0 192.168.10.1 ein

Und stellen Sie sicher, dass Sie in der Lage sind ping 192.168.10.1

Überprüfen Sie auch, ob die IP-Adresse für den Nur-Host-Adapter der Virtualbox 192.168.10.1 mit der Maske 255.255.255.0 konfiguriert ist

navamario · Answer

Ich hatte die gleiche Situation, aber ich habe eine Änderung vorgenommen.

Ich habe meine/etc/hosts-Datei mit dieser IP 127.0.0.1 geändert.

crishoj · Answer

In meinem Fall wurde das Problem dadurch gelöst, dass vagrant up die Gastzusätze installiert hat:

~/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

Nach diesem Punkt erhielt ich eine neue Schnittstelle mit der erwarteten IP-Adresse:

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)

Giovanni S · Answer

Die Installation von Net-Tools auf Ubuntu hat dieses Problem behoben

$ Sudo install net-tools $ vagrant destroy $ vagrant up

Nate Flink · Answer

Ich hatte gestern ein ähnliches Problem für Homestead 5. Es stellte sich heraus, dass die Ursache meines Problems darin lag, dass ich das falsche Vagrantfile lief.

Eine Instanz sollte eine Antwort auf die IP-Adresse geben: 192.168.10.10

Um das Problem in meinem Fall zu beheben, befolgte ich folgende Anweisungen: http://laravel.com/docs/5.0/Homestead

Um es zusammenzufassen:

Im Terminallauf:

vagrant box add laravel/Homestead

dann

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

dann

cd ./Homestead

und führen Sie diesen Befehl FROM INSIDE im neuen "Homestead" -Ordner aus

bash init.sh

führen Sie dann die Befehle vagrant up und vagrant provision für diese Vagrant-Datei aus, die in ./Homestead erstellt werden sollte.

So sieht die Ausgabe des vagrant provision-Befehls auf meinem System aus:

 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

Josh Maag · Answer

Ich hatte dieses Problem auf meinem Windows-Computer aufgetaucht und es stellte sich heraus, dass ich versehentlich den Ordner "map" und "to" umgekehrt hatte. Als ich herausfand, dass sich der Ordner in der vagrant-ssh-Sitzung nicht unterhalb von ~/code/befand, war es offensichtlich, dass er nicht richtig funktionierte, aber das Überprüfen der Pfade ergab nichts.

So ordnen Sie den Ordnerabschnitt auf Ihrem Windows-Computer richtig zu:

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

So ordnen Sie den Ordnerabschnitt auf Ihrem Windows-Computer richtig zu:

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

PeloNZ · Answer

Ich hatte genau dieses Problem und es stellte sich heraus, dass Nginx aufgrund eines Fehlers beim Laden der TLS-Zertifikate nicht gestartet werden konnte. Der Befehl vagrant up meldet nicht, dass Nginx nicht gestartet wurde oder dass Ports nicht gebunden wurden.

Um dies zu diagnostizieren, habe ich Folgendes getan:

$ 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

Es gibt keinen Port 80 in der Liste. Lassen Sie uns Port 80 noch einmal überprüfen.

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

So ist es sicherlich geschlossen. Was sagen die Gastprotokolle? vagrant ssh und ...

 $ 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 konnte aufgrund eines Fehlers in der Konfiguration nicht gestartet werden. Der PEM_read_bio_X509_AUX-Fehler verweist auf die /etc/nginx/ssl/Homestead.app.crt-Datei. Wo wird diese Datei in der Konfiguration verwendet?

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

Ich habe die entsprechenden Zeilen auskommentiert:

@@ -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; }

Starten Sie nginx mit $ Sudo service start nginx und führen Sie nmap erneut vom Host aus aus.

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

Port 80 ist offen und sollte jetzt unter http://Homestead.app zugänglich sein. Natürlich funktioniert TLS nicht, aber Sie sollten das Problem beheben können, indem Sie neue Zertifikate erstellen. Ich bin mir nicht sicher, warum die Zertifikate überhaupt nicht geladen wurden.