I have the last Vagrant+Homestead installation. Nginx+Laravel+php7
I've addedd hhvm: true to yaml file like this
- map: example.local
to: /home/vagrant/Code/example/public
hhvm: true
and issued vagrant reload. No error messages on startup.
However when I show phpinfo() on a page in example.local I still see PHP Version 7.0.8-2
It's there something else to do?
I removed the php config in nginx block.
in /etc/nginx/sites-available/example.local, the config starting with
location ~ \.php$ {...
was clearly pointing to
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
I removed that whole part and replaced with
include hhvm.conf;
and restarted nginx
Related
I have a Homestead VM with multiple nginx sites and a couple of apache sites too, everything configured through the Homestead.yaml file (short example below):
sites:
- map: site1.local
to: /home/vagrant/site1
php: "7.1"
#type: "apache <= (commented on purpose, not an error)
- map: site2.local
to: /home/vagrant/site2
php: "7.1"
I've been working turning On and Off the type: "apache" setting so the VM starts running apache (instead of nginx) or not, depending on the site that I need to work on at the specific moment.
My Issue now is that, after upgrading Vagrant and Homestead, it always keeps starting apache by default, no matter if it is specified or not, ALWAYS!; so everytime I start the machine, I need to ssh-it and flip the server.
I even tried using the services config directive as follows, without luck:
services:
- enabled:
- "nginx"
- disabled:
- "apache2"
Any thoughts? Please help!
Versions I am using:
Vagrant 2.2.7
Homestead 10.8.0
I had a similar issue. It turned out that I needed to log in the VM through SSH, and run the following command:
sudo systemctl enable nginx.service
When you look at restart-webserver.sh in the Homestead scripts directory, you will see that it verifies whether nginx is enabled, otherwise it always tries to restart Apache.
How can I create a laravel 5 dev site with DDEV ? (see https://github.com/drud/ddev/issues/898#issuecomment-463203604)
I created a Laravel 5 dev site on Win10 using DDEV and Docker Desktop with Linux containers. Note that it was not necessary to install composer on Win10 since composer installed by DDEV in the web container was used instead.
Here are the steps:
Created a d:\laravel5 folder
Opened a PowerShell window as administrator and switched to this folder
Ran ddev config and selected the default "php" project type:
PS D:\laravel5> ddev config
Creating a new ddev project config in the current directory (D:\laravel5)
Once completed, your configuration will be written to D:\laravel5\.ddev\config.yaml
Project name (laravel5):
The docroot is the directory from which your site is served.
This is a relative path from your project root at D:\laravel5
You may leave this value blank if your site files are in the project root
Docroot Location (current directory):
Found a php codebase at D:\laravel5.
Project Type [drupal6, drupal7, drupal8, wordpress, typo3, backdrop, php] (php):
Project type has no settings paths configured, so not creating settings file.
Configuration complete. You may now run 'ddev start'.
Instrumentation is opted in, but SentryDSN is not available.
Instrumentation is opted in, but SegmentKey is not available.
PS D:\laravel5>
DDEV created a d:\laravel5\.ddev folder that will be modified with the addition of 4 files before running the ddev start command.
Note that for the DDEV "php" project type, the Laravel 5 PHP prerequisites are all satisfied
PHP >= 7.2.0
BCMath PHP Extension
Ctype PHP Extension
JSON PHP Extension
Mbstring PHP Extension
OpenSSL PHP Extension
PDO PHP Extension
Tokenizer PHP Extension
XML PHP Extension
Created the file .ddev\config.laravel5.yaml with content
docroot: blog/public
Created the file .ddev\docker-compose.laravel5.yaml with content
version: '3.6'
services:
web:
environment:
- DB_HOST=db
- DB_PORT=3306
- DB_DATABASE=db
- DB_USERNAME=db
- DB_PASSWORD=db
Created the file .ddev\nginx-site.conf with content
# ddev default config
# You can override ddev's configuration by placing an edited copy
# of this config (or one of the other ones) in .ddev/nginx-site.conf
# See https://ddev.readthedocs.io/en/stable/users/extend/customization-extendibility/#providing-custom-nginx-configuration
## Set https to 'on' if x-forwarded-proto is https
#map $http_x_forwarded_proto $fcgi_https {
# default off;
# https on;
#}
server {
listen 80;
server_name laravel5.ddev.site;
# The WEBSERVER_DOCROOT variable is substituted with
# its value when the container is started.
root $WEBSERVER_DOCROOT;
include /etc/nginx/monitoring.conf;
include /mnt/ddev_config/nginx/*.conf;
}
Created the file .ddev\nginx\laravel5.conf with content:
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff";
index index.html index.htm index.php;
## Disable sendfile as per https://docs.vagrantup.com/v2/synced-folders/virtualbox.html
#sendfile off;
error_log /dev/stdout info;
access_log /var/log/nginx/access.log;
charset utf-8;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location = /favicon.ico { access_log off; log_not_found off; }
location = /robots.txt { access_log off; log_not_found off; }
error_page 404 /index.php;
location ~ \.php$ {
#fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
include fastcgi_params;
}
location ~ /\.(?!well-known).* {
deny all;
}
Ran ddev start:
PS D:\laravel5> ddev start
Starting laravel5...
Using custom nginx configuration in nginx-site.conf
Using custom nginx partial configuration: [D:\laravel5\.ddev\nginx\laravel5.conf]
Custom configuration takes effect when container is created,
usually on start, use 'ddev restart' if you're not seeing it take effect.
Creating volume "laravel5-mariadb" with default driver
Building db
Building web
Creating ddev-laravel5-db ... done Creating ddev-laravel5-dba ... done Creating ddev-laravel5-web ... done
ddev-router is up-to-date
Successfully started laravel5
Project can be reached at https://laravel5.ddev.site https://127.0.0.1:32789
Instrumentation is opted in, but SentryDSN is not available.
Instrumentation is opted in, but SegmentKey is not available.
PS D:\laravel5>
Ran ddev ssh and executed the following shell commands in the web container
cd /var/www/html
composer create-project --prefer-dist laravel/laravel blog "5.8.*"
The output was as follows:
freefall322#laravel5-web:/var/www/html$ cd /var/www/html
freefall322#laravel5-web:/var/www/html$ composer create-project --prefer-dist laravel/laravel blog "5.8.*"
Installing laravel/laravel (v5.8.35)
- Installing laravel/laravel (v5.8.35): Loading from cache
Created project in blog
> #php -r "file_exists('.env') || copy('.env.example', '.env');"
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 80 installs, 0 updates, 0 removals
- Installing symfony/polyfill-ctype (v1.12.0): Loading from cache
- Installing phpoption/phpoption (1.5.0): Loading from cache
- Installing vlucas/phpdotenv (v3.6.0): Loading from cache
- Installing symfony/css-selector (v4.3.4): Loading from cache
- Installing tijsverkoyen/css-to-inline-styles (2.2.1): Loading from cache
- Installing symfony/polyfill-php72 (v1.12.0): Loading from cache
- Installing symfony/polyfill-mbstring (v1.12.0): Loading from cache
- Installing symfony/var-dumper (v4.3.4): Loading from cache
...
(skipping many lines of output)
...
phpunit/phpunit suggests installing phpunit/php-invoker (^2.0)
phpunit/phpunit suggests installing ext-xdebug (*)
Writing lock file
Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> #php artisan package:discover --ansi
Discovered Package: beyondcode/laravel-dump-server
Discovered Package: fideloper/proxy
Discovered Package: laravel/tinker
Discovered Package: nesbot/carbon
Discovered Package: nunomaduro/collision
Package manifest generated successfully.
> #php artisan key:generate --ansi
Application key set successfully.
freefall322#laravel5-web:/var/www/html$
Navigated to the newly created Laravel 5 dev site
Added a route to blog/routes/web.php in order test the database connection (code was from https://stackoverflow.com/a/44004752)
Route::get('/foo', function () {
//
try {
DB::connection()->getPdo();
if(DB::connection()->getDatabaseName()){
echo "Yes! Successfully connected to the DB: " . DB::connection()->getDatabaseName();
}else{
die("Could not find the database. Please check your configuration.");
}
} catch (\Exception $e) {
die("Could not open connection to database server. Please check your configuration.");
}
});
The result was Yes! Successfully connected to the DB: db
Note: to install latest version of Laravel, instead of
composer create-project --prefer-dist laravel/laravel blog "5.8.*"
remove the version specifier and just use
composer create-project --prefer-dist laravel/laravel blog
I tried this today and it installed Laravel 6.0
You can create a Laravel 5 dev site using ddev as below:
mkdir projectName
cd projectName
ddev config --project-type=laravel --docroot=public --create-docroot
ddev start
ddev composer create --prefer-dist laravel/laravel:5.8.*
ddev exec "cat .env.example | sed -E 's/DB_(HOST|DATABASE|USERNAME|PASSWORD)=(.*)/DB_\1=db/g' > .env"
ddev exec "php artisan key:generate"
ddev launch
See the ddev Laravel quick start documentation.
Everytime i go to my project I get a 502 bad gateway. When I refresh, the page works.. If I click a link to another page I get 502 bad gateway again. After the refresh the page loads. What could be the problem here.
Homestead.yaml
---
ip: "192.168.10.10"
memory: 2048
cpus: 1
provider: virtualbox
authorize: c:/Users/MyNameHere/.ssh/id_rsa.pub
keys:
- c:/Users/MyNameHere/.ssh/id_rsa
folders:
- map: c:/Users/MyNameHere/Desktop/sites
to: /home/vagrant/code
sites:
- map: spa.test
to: /home/vagrant/code/spa/public
databases:
- homestead
Got the latest version for virtualbox and vagrant.
My spa folder contains the newest version laravel.
Login to Laravel Homestead Server with PuTTY and Private Key File.
then...
cd /etc/php/7.4/mods-available
sudo nano xdebug.ini
Comment out the first line
;zend_extension=xdebug.so
xdebug.remote_enable = 0
xdebug.remote_connect_back = 1
xdebug.remote_port = 9000
xdebug.max_nesting_level = 512
Then restart PHP-FPM
sudo service php7.4-fpm restart
Had the same issue with the latest version of homestead.
After digging in log files and then github issues for homestead, I found this this.
There's an issue with xdebug that they're waiting for a fix for. The solution is to disable xdebug or use php 7.2. I opted for the latter. In that case, make the following change in your homestead.yaml and then running vagrant reload --provision will fix this.
sites:
- map: spa.test
to: /home/vagrant/code/spa/public
php: "7.2"
I was having the same problem and I couldn't change the PHP version or disable xdebug, but I could and did change for the Apache server.
sites:
- map: spa.test
to: /home/vagrant/code/spa/public
type: "apache"
I had a similar issue, got the 502 error. Refreshing the browser or reloading the virtual machine had no effect.
I solved disabling the Xdebug. Found the solution here: https://christattum.com/disabling-xdebug-in-laravel-homestead/
On prompt:
cd /etc/php/7.4/mods-available
sudo vi xdebug.ini
Commented all the lines of the file with ;
Run the vagrant reload --provision command to the Homestead file in the virtual machine, and then after vagrant up, enter with vagrant ssh. Your problem will be solved :)
You can change your ip post adress and write 127.0.0.1 in your host file.
You can enter it by adding 8000 next to the project name in the search engine.
For example spa.test:8000 and then running vagrant reload --provision will fix this.
I lost 3 days trying to solve the same issue.
My mistake was to have defined in my host file something like:
127.0.0.1 spa.test
The solution is to add instead, the same IP you specified in Homestead.yaml.
192.168.10.10 spa.test
to /etc/host (In case of Mac)
to C:\Windows\System32\drivers\etc\hosts (in case of Windows)
Even if you have multiple hosts defined in your global Homestead.yaml file.
For instance
folders:
- map: /Users/davidecasiraghi/Projects/my_laravel_project
to: /home/vagrant/code/my_laravel_project
- map: /Users/davidecasiraghi/Projects/spa
to: /home/vagrant/code/spa
sites:
- map: my_laravel_project.test
to: /home/vagrant/code/my_laravel_project/public
- map: spa.test
to: /home/vagrant/code/spa/public
Then in the host file:
192.168.10.10 spa.test
192.168.10.10 my_laravel_project.test
Then when you will do vagrant up you will be able to access to both of them.
For me this was related to Xdebug, which doesn't seem to yet be compatible with PHP 7.3.
To continue using 7.3, you can turn Xdebug off with
sudo phpdismod xdebug
restart php service
sudo service php7.3-fpm reload
For Chinese,
if you are using Clash for Windows,
then edit "Bypass Domain".
It's not relevant to this question,
but Google lead me here,
Do this inside your Homestead VM vagrant ssh
Check your php version
$ php -v
Edit your website config file
$ sudo nano /etc/nginx/sites-available/<laravel.app>
line
fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
change according to your php version
mine was php8.2-fpm.sock; then I change it to php8.1-fpm.sock; press ctrl+x to save, then
$ sudo service nginx restart
$ sudo service php<ver>-fpm restart
reload the page
I'm trying to install magento php ecommerce on a virtual server that previously did not have php. When I put simple php pages into a directory they run (for example I have index.php run phpinfo). But when I try to run the magento setup scripts they bomb out without outputting an error. I have two other virtual servers through a different service (running apache) and when I drop the magento files into them the setup pages light up right away and start checking requirements. On my nginx server the only output is a small grey box, but no error output.
My best guess is that I have not configured nginx virtual hosts properly for php.
I am on php5.5 using fpm on Ubuntu 12.04. I don't run a default file in sites-enabled, just two vhost files. Here's the vhost in question (the other site is working fine, but it's python):
server {
listen 80;
listen [::]:80;
#
server_name magento.mydomain.com;
#
root /var/www/magento.mydomain.com/public_html;
index index.php index.html index.htm;
#
# location / {
# try_files $uri $uri/ /index.php =404;
# }
# location / {
# /index.php;
# }
location ~ \.php$ {
include /etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:8070;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/magento.mydomain.com/public_html/$fastcgi_script_name;
}
}
You can see my commented out location / directives. I have tried those is various fashion. My hunch was that magento was calling php with directory names only (instead of somedir/index.php) so I was messing with those, but it seems like that would be handled by the index directive before the locations.
I'm pretty green with nginx. Does anyone see anything obvious?
My nginx site root points to a symlink. If I alter the symlink (aka deploy a new version of the website) the old version of the php script keeps showing up.
That smells like cache, or a bug.
First it looked like Nginx was caching the symlinked dir, but reloading/restarting/killing and starting nginx didn't fix it, so I restarted php5-fpm - this fix my issue.
But I dont want to restart nginx and/or php5-fpm after a deploy - I want to know why there is such a cache (or bug), and why it didn't work properly.
Usefull information:
OS: Ubuntu 13.10 (GNU/Linux 3.8.0-19-generic x86_64)
Nginx: via ppa:nginx/stable
PHP: via ppa:ondrej/php5 (php5-fpm)
Nginx site config:
root /home/rob/sandbox/deploy/public/;
index index.php index.html index.htm;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass php;
}
Nginx server config (partly, rest is default):
http {
sendfile off;
upstream php {
server unix:/var/run/php5-fpm.sock;
}
}
Tree for /home/rob/sandbox:
├── deploy -> web2
├── web1
│ └── public
│ └── index.php (echo ONE)
└── web2
└── public
└── index.php (echo TWO)
request: http://localhost/index.php
expected response: TWO
actual response: ONE
Part of the output from realpath_cache_get()
[/home/rob/sandbox/deploy/public/index.php] => Array (
[key] => 1.4538996210143E+19
[is_dir] =>
[realpath] => /home/rob/sandbox/web2/public/index.php
[expires] => 1383730041
)
So this means deploy/public/index.php is properly linked to web2/public/index.php, right?
Well, even with the correct paths in the realpath_cache list, the respone still is ONE.
After rm deploy and ln -s web2 deploy Nginx was restarted, no effect.
Restarting php5-fpm after this gives the expected response of 'TWO'.
It's good to know that beside the index.php files, I did some test with .css and .js files.
After removing and recreating the symlink from/to web1 and web2, nginx will respond with the correct contents of the files.
What did I miss, what am I not seeing?
Configure your nginx using $realpath_root. It should help.
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;
Kudos go to Vitaly Chirkov (https://stackoverflow.com/a/23904770/219272).
Once I altered the realpath_cache_ttl to '2' (That should fix it) the incorrect content was still showing.
After some digging in the loaded mods for php-fpm, I discovered that opcache was up and running. Disabling that will clear the cached realpath's when the ttl is over.
I don't wanna lower the realpath cache ttl to much,so I will settle in with a reload of php-fpm, since it is graceful.
I hope this thread and my answers will help others ;)
I had exactly same problem and none of the tricks did help. Beside all tricks listed on this page I ensured opcache is disabled then nginx cache was also disabled. I set
sendfile off;
It was described somewhere on stackoverflow.
I started to strace the php and nginx and it turned out that some libraries are read new location but also some were read from OLD location that symlink does not point to anymore.
On top of that updating the php script inside OLD directory was always showing properly - so that did not look like cache to me.
To make it more confusing command line worked fine and followed the symlink to NEW location.
I was pulling hair from my head over this!
It turned out that responsible for all this was the composer cache - it was caching some libraries.
I know not everyone uses it, but if you do and have similar problem it is worth checking.
I have vendor at the same level as the deployment scripts and I assume composer cache was causing a lot of confusion which location should be used.
After cleaning it up with
composer clear-cache
System started to behave as expected.
I hope it will help someone.