Laravel Homestead

Related tags

Laravel homestead
Overview

Build Status Total Downloads Latest Stable Version License

Introduction

Laravel Homestead is an official, pre-packaged Vagrant box that provides you a wonderful development environment without requiring you to install PHP, a web server, and any other server software on your local machine. No more worrying about messing up your operating system! Vagrant boxes are completely disposable. If something goes wrong, you can destroy and re-create the box in minutes!

Homestead runs on any Windows, Mac, or Linux system, and includes the Nginx web server, PHP 8.0, MySQL, Postgres, Redis, Memcached, Node, and all of the other goodies you need to develop amazing Laravel applications.

Official documentation is located here.

Ubuntu LTS Settler Version Homestead Version Branch Status
20.04 11.x 12.x main Development/Unstable
20.04 11.x 12.x release Stable

Developing Homestead

To keep any in-development changes separate from other Homestead installations, create a new project and install Homestead from composer, forcing it to use a git checkout.

$ mkdir homestead && \
    cd homestead && \
    composer require --prefer-source laravel/homestead:dev-main

After it's complete, vendor/laravel/homestead will be a git checkout and can be used normally.

Comments
  • Provisioning fails with Hyper-V provider on Windows 10 version 1803

    Provisioning fails with Hyper-V provider on Windows 10 version 1803

    Versions

    • Vagrant: Vagrant 2.2.0
    • Provider: Hyper-V.
    • Homestead: v7.19.2

    Host operating system

    Windows 10 Enterprise Version 1803, build 17134.286.

    Homestead.yaml

    ---
    ip: "192.168.10.10"
    memory: 2048
    cpus: 1
    provider: hyperv
    
    authorize: ~/.ssh/id_rsa.pub
    
    keys:
        - ~/.ssh/id_rsa
    
    folders:
        - map: ~/code
          to: /home/vagrant/code
    
    sites:
        - map: homestead.test
          to: /home/vagrant/code/public
    
    databases:
        - homestead
    

    Vagrant destroy & up output

    https://gist.github.com/cbj4074/01317421b6ce2bf9ea8c610f76ffbecc

    Expected behavior

    Provisioning should succeed.

    I should note that provisioning with Hyper-V succeeds when using https://app.vagrantup.com/generic/boxes/ubuntu1804/versions/1.8.40 , for example, so the issue seems to be box-specific.

    Actual behavior

    Provisioning fails almost immediately, when creating and registering the VM.

    This seems to be related, at least in part, to the issues cited under References.

    However, it seems that some/most/all of these individuals have the opposite problem (as described in the comment https://github.com/hashicorp/vagrant/issues/9317#issuecomment-437025611 ), whereby the box specifies a Hyper-V VMHost version that is greater than what the host OS supports. This seems to be a different issue, because the output on my machine reports version 8.3:

    PS C:\windows\system32> Get-VMHostSupportedVersion -Default
    
    Name                                    Version IsDefault
    ----                                    ------- ---------
    Microsoft Windows 10 Update/Server 1803 8.3     True
    

    The second issue cited below implies that there's a means by which to "validate the host is able to support the [Hyper-V] version". Might anyone know which value would be checked? I'd like to check it manually in the meantime.

    Steps to reproduce

    1. Attempt to provision the latest version of Homestead using the Hyper-V provider on the latest version of Windows 10.

    References

    • https://github.com/hashicorp/vagrant/issues/9317
    • https://github.com/hashicorp/vagrant/issues/10384
    opened by cbj4074 95
  • Composer plugin installation failed

    Composer plugin installation failed

    Versions

    • Vagrant: Just installed
    • Provider: Virtualbox
    • Homestead: You should be on the most recent release branch.

    Host operating system

    Tested on both Window and Mac.

    Homestead.yaml

    ---
    ip: "192.168.10.10"
    memory: 2048
    cpus: 1
    provider: virtualbox
    
    authorize: ~/.ssh/id_rsa.pub
    
    keys:
        - ~/.ssh/id_rsa
    
    folders:
        - map: ../symfony4
          to: /home/vagrant/code
    
    sites:
        - map: symfony4.test
          to: /home/vagrant/code/public
    
    databases:
        - homestead
    
    features:
        - mariadb: false
        - ohmyzsh: false
        - webdriver: false
    

    Expected behavior

    No error during composer install

    Actual behavior

    image

    Steps to reproduce

    This is the repo to reproduce the bug: https://github.com/ak3l/Cours_Symfony4/tree/bug

    Instead following the actual README, do composer install without --no-plugins --no-scripts to get the error.

    When I run composer install -vv, I get

     - Installing ocramius/package-versions (1.4.0): Reading /home/vagrant/.composer/cache/files/ocramius/package-versions/9015316288b55423c693c083934dccb5ab72981d.zip from cache
    Loading from cache
     Extracting archiveExecuting command (CWD): unzip -qq  '/home/vagrant/code/vendor/ocramius/package-versions/200f6a66a0865848df9170ec0fd15921' -d '/home/vagrant/code/vendor/composer/f1785882'
    Plugin installation failed, rolling back
    
    Provider Bug Validated Bug VirtualBox Bug 
    opened by VincentLanglet 74
  • App performing really slow

    App performing really slow

    I tried postponing posting this and trying to figure it out myself but I'm several days in and totally out of ideas so hopefully someone can help.

    Versions

    • Vagrant: 2.1.1
    • Provider: Virtualbox
    • Homestead: 7.12.0

    Host operating system

    macOS High Sierra 10.13.6

    Processor: 2.9 GHz Intel Core i5 Memory: 16 GB 1867 MHz DDR3 Graphics: Intel Iris Graphics 6100 1536 MB

    Homestead.yaml

    ip: 192.168.10.20
    memory: 4096
    cpus: 1
    provider: virtualbox
    authorize: ~/.ssh/id_rsa.pub
    keys:
        - ~/.ssh/id_rsa
    folders:
        - map: /Users/driesvints/Sites/beatswitch-web-app
          to: /home/vagrant/code
    sites:
        - map: beatswitch.test
          to: /home/vagrant/code/public
          php: "7.1"
    databases:
        - homestead
    name: beatswitch
    hostname: beatswitch
    

    Vagrant destroy & up output

    https://gist.github.com/driesvints/26ce2c2ac8cc17f43fde9572b67fcb2a

    Expected behavior

    I expect requests to take 1-3 seconds max.

    I use Homestead for several projects and while performance isn't always "great" it's never terrible slow. However, with this particularly project my Laravel app runs really slow. It's a special setup with Doctrine ORM instead of Eloquent and an extra DynamoDB Local dependency (which I install with after.sh). But that shouldn't affect the performance really.

    Actual behavior

    Requests take 10-20 seconds approximately.

    I tried several things like mysql tuning, different filesystem sync (nfs), memory & cpu increase. But nothing helped. So I'm totally in the dark why this app is performing slow on Homestead while it performs well on the previous custom box and on production.

    Steps to reproduce

    1. vagrant up
    2. Try out the app and everything runs really slow (~10-20s / request)

    Extra info

    My after.sh script might be useful as well:

    #!/bin/sh
    
    ## Install Java if it hasn't been installed yet
    if ! [ -x "$(command -v java)" ]; then
        sudo apt-get install -fy
        sudo add-apt-repository -y ppa:openjdk-r/ppa
        sudo apt-get update -y
        sudo apt-get install -y openjdk-11-jre-headless
        sudo apt-get install -y openjdk-11-jdk
    fi
    
    # Install DynamoDB Local if it hasn't been downloaded yet
    if ! [ -d "./dynamodb" ]; then
        mkdir -p dynamodb && cd dynamodb
        wget http://dynamodb-local.s3-website-us-west-2.amazonaws.com/dynamodb_local_latest.tar.gz
        tar -xvzf dynamodb_local_latest.tar.gz
    fi
    
    opened by driesvints 62
  • Hot Reloading via Port 8080 Connection Refused

    Hot Reloading via Port 8080 Connection Refused

    Versions

    • Vagrant: 2.2.6
    • Provider: Virtualbox
    • Homestead: 8.2.1

    Host operating system

    Windows 10

    Homestead.yaml

    ---
    ip: "192.168.10.10" 
    memory: 2048
    cpus: 1
    provider: virtualbox
    
    authorize: ~/.ssh/id_rsa.pub
    
    keys:
        - ~/.ssh/id_rsa
    
    folders:
        - map: C:\Web_Development\Code
          to: /home/vagrant/Code
    
    sites:
        - map: bogeybrain.test
          to: /home/vagrant/Code/BogeyBrain/public
    
    databases:
        - bogeybrain
        
    features:
        - mariadb: false
        - mysql8: true
    
    ports:
         - send: 8080
           to: 8080
    

    Vagrant destroy & up output

    https://gist.github.com/jfsullivan/8865ea38e4cc47fc878977ae80561cab

    Expected behavior

    I had Hot Module Reloading (HMR) working via Laravel Mix but then updated Homestead so that I could begin using Mysql 8.0. I run yarn hot and reload my browser window. I would expect to get a HMR connection thru port 8080 as I did before.

    Actual behavior

    I get the following errors in the browser console....

    GET http://bogeybrain.test:8080//css/app.css net::ERR_CONNECTION_REFUSED GET http://bogeybrain.test:8080//js/app.js net::ERR_CONNECTION_REFUSED

    I can connect to the site when not using HMR. HMR is setup to access the main page via port 80 and the CSS and JS via port 8080. The main page is loaded but the CSS and JS connections are refused.

    I have the following settings in my webpack.mix.js file to setup HRM

        // For Hot Reloading
        mix.options({
            hmrOptions: {
                host: 'bogeybrain.test',  // site's host name 
                port: 8080,
            }
        });
    
        // // fix css files 404 issue
        mix.webpackConfig({
            // add any webpack dev server config here
            devServer: { 
                proxy: {
                    host: '192.168.10.10',  // host machine ip
                    port: 8080,
                },
                watchOptions:{
                    aggregateTimeout:200,
                    poll:5000
                },
    
            }
        });
    
    opened by jfsullivan 42
  • Homestead & WSL 2 - Windows 10

    Homestead & WSL 2 - Windows 10

    Provision/Configure Ubuntu 20.04

    You must be on the Homestead branch 20.04. Create a new/blank Ubuntu 20.04 WSL Distribution. Run the new distribution and change directories to where you have Homestead cloned. For me this is /mnt/c/Users/halo/Code/homestead. Run the initial provisioning script to install the base Homestead system. The script will ask you for your WSL username and user group. You should use your username for your user group unless you have specific plans or requirements outside of the scope of Homestead.

    $ cd Code/homestead
    $ sudo ./bin/wsl-init
    [sudo] password for halo:
    What is your WSL user name?
    halo
    What is your WSL user group? (Same as username if you're unsure)
    halo
    Get:1 http://security.ubuntu.com/ubuntu focal-security InRelease [107 kB]
    ...
    

    Create Sites from Homestead Configuration

    Add a new top level configuration item in your Homestead.yaml configuration such as:

    wsl_sites:
        -   map: vcdt.test
            to: /mnt/c/Users/halo/Code/vcdt/public
    
    $ ./bin/homestead wsl:create-sites
    

    The sites from wsl_sites will be created.

    Create Databases from Homestead Configuration

    WSL will read from the normal databases configuration in Homestead.yaml

    databases:
        - homestead
        - vcdt
        - laminas
    
    $ ./bin/homestead wsl:create-databases
    mysql: [Warning] Using a password on the command line interface can be insecure.
    mysql: [Warning] Using a password on the command line interface can be insecure.
    mysql: [Warning] Using a password on the command line interface can be insecure.
    mysql: [Warning] Using a password on the command line interface can be insecure.
    mysql: [Warning] Using a password on the command line interface can be insecure.
    mysql: [Warning] Using a password on the command line interface can be insecure.
    WSL Databases have been created!
    

    The databases from databases will be created.

    Installing Optional Features

    WSL will read from the normal features configuration in Homestead.yaml

    features:
        - timescaledb: true
    
    $ ./bin/homestead wsl:apply-features
    Using postgresql.conf at this path:
    /etc/postgresql/12/main/postgresql.conf
    
    Writing backup to:
    /tmp/timescaledb_tune.backup202010041216
    
    Recommendations based on 50.17 GB of available memory and 8 CPUs for PostgreSQL 12
    Saving changes to: /etc/postgresql/12/main/postgresql.conf
    Command output can be found via: sudo cat ~/.homestead-features/timescaledb.log
    WSL features have been configured!
    
    enhancement help wanted 
    opened by svpernova09 40
  • Laravel app throwing Facade Root Exception after running vagrant reload

    Laravel app throwing Facade Root Exception after running vagrant reload

    Posting this per @svpernova09 's advice from a laracasts post (linked at bottom)

    Versions

    • Vagrant:2.2.4
    • Provider: Virtualbox Version 5.2.30
    • Homestead: 8.0.0-alpha2

    Host operating system

    OS X Mojave 10.14.5

    Homestead.yaml

    ip: 192.168.33.50
    memory: 4096
    cpus: 1
    provider: virtualbox
    authorize: ~/.ssh/id_rsa.pub
    keys:
        - ~/.ssh/id_rsa
    folders:
        -
            map: ../
            to: /home/vagrant/code
    sites:
        -
            map: my-app.test
            to: /home/vagrant/code/web/public
    databases:
        - homestead
    name: web
    hostname: web
    

    Vagrant destroy & up output

    vagrant destroy gist

    vagrant up gist

    Expected behavior

    After vagrant --reload or a vagrant halt && vagrant up I should be able to access my web app at my-app.test.

    Actual behavior

    1. After vagrant --reload or a vagrant halt && vagrant up, I get this error screen when trying to navigate to my-app.test: Screen Shot 2019-06-03 at 12 05 26 PM

    If I run (from OUTSIDE the vagrant box): $ php artisan cache:clear $ php artisan route:cache $ php artisan config:cache $ php artisan view:clear I can get "past" this error screen, but then get a new one saying that "[...]/storage/logs" does not exist and could not be built: Permission Denied: Screen Shot 2019-06-03 at 12 11 14 PM

    If I try to run any of those cache clearing commands from INSIDE vagrant (after vagrant ssh), I get this error: Screen Shot 2019-06-03 at 12 12 11 PM

    Permissions seem to be a false flag as I've tried changing permissions, etc and the directory definitely does exist.

    I haven't found anyway to get any further besides doing vagrant destroy && vagrant up again. But, of course, the errors begin again anytime I do a vagrant reload or vagrant halt && vagrant up or restart my machine, etc.

    Steps to reproduce

    1. $ vagrant up to bring box up
    2. Navigate in browser to your box's mapped url
    3. Verify everything is working correctly
    4. Run $ vagrant reload or $ vagrant halt && vagrant up
    5. Navigate in browser to your box's mapped url again.
    6. Facade Root error should appear.

    References

    I arrived here through these links:

    1. https://laracasts.com/discuss/channels/laravel/laravel-app-throwing-exception-after-running-vagrant-reload?page=1
    2. https://github.com/laravel/homestead/issues/1174#issuecomment-498104987
    opened by mccordgh 32
  • php7.3-fpm resulting in bad gateway

    php7.3-fpm resulting in bad gateway

    In the newest version of homestead (8.0.0) the default PHP version is 7.3. However there seems to be a problem on a freshly provisioned install. NGINX returns a 502 bad gateway when provisioned for php-7.3.

    When switching fastcgi_pass unix:/var/run/php/php7.3-fpm.sock; to fastcgi_pass unix:/var/run/php/php7.2-fpm.sock; the site loads fine again.

    Error in NGINX log:

    2019/01/15 09:15:59 [error] 539#539: *15 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.10.1, server: com.nbs.test, request: "GET /wp-admin/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.3-fpm.sock:", host: "com.nbs.test"
    

    Error in PHP-FPM log:

    [15-Jan-2019 09:32:14] WARNING: [pool www] child 904 exited on signal 11 (SIGSEGV - core dumped) after 1006.631644 seconds from start
    [15-Jan-2019 09:32:14] NOTICE: [pool www] child 988 started
    

    Error in /var/log/syslog

    Jan 15 09:32:14 vagrant kernel: [ 1538.380198] php-fpm7.3[904]: segfault at 7ffdc3952ff8 ip 000055e499dad9e0 sp 00007ffdc3953000 error 6 in php-fpm7.3[55e499b2b000+3e6000]
    

    My debugging skills didn't go any further unfortunately.

    Versions

    • Vagrant: 2.2.2
    • Provider: Virtualbox
    • Homestead: 8.0.0
    • Homestead box: 7.0.0 (same issue on 6.4.0)

    Host operating system

    MacOS 10.14.2

    Homestead.yaml

    ---
    ip: "192.168.10.10"
    name: "Vagrant V2"
    hostname: martijn.local
    memory: 2048
    cpus: 1
    provider: virtualbox
    
    authorize: ~/.ssh/id_rsa.pub
    
    keys:
        - ~/.ssh/id_rsa
    
    folders:
        - map: ~/Sites
          to: /home/vagrant/sites
          type: nfs
    
    sites:
        - map: sandbox.test
          to: /home/vagrant/sites/sandbox
        - map: com.nbs.test
          to: /home/vagrant/sites/nbs
    

    Vagrant destroy & up output

    https://gist.github.com/martijn94/8bbd717d0c9b29f49068641589eb1d37

    Expected behavior

    Site loads for a added site

    Actual behavior

    Nginx returns 502 bad gateway

    Steps to reproduce

    Provision fresh box with the latest versions of homestead.

    opened by martijn94 28
  • Apache service does not persist beyond SSH session. Web server does not persist after enabling Apache (via flip command or service start) and logging out of SSH session (or after Homestead halt then reload).

    Apache service does not persist beyond SSH session. Web server does not persist after enabling Apache (via flip command or service start) and logging out of SSH session (or after Homestead halt then reload).

    Versions

    • Vagrant: 2.1.1
    • Provider: Virtualbox (5.2.12)
    • Homestead: 7.6.0

    Host operating system

    Windows 10 64-bit

    Homestead.yaml

    ---
    ip: "192.168.10.10"
    memory: 2048
    cpus: 1
    provider: virtualbox
    
    authorize: ~/.ssh/id_rsa.pub
    
    keys:
        - ~/.ssh/id_rsa
    
    folders:
        - map: C:/Users/adehaven/PW/Sandbox
          to: /var/www/html/Sandbox
    
    sites:
        - map: sandbox.test
          to: /var/www/html/Sandbox
          type: apache
    
    databases:
        - sandbox
    
    # blackfire:
    #     - id: foo
    #       token: bar
    #       client-id: foo
    #       client-token: bar
    
    # ports:
    #     - send: 50000
    #       to: 5000
    #     - send: 7777
    #       to: 777
    #       protocol: udp
    

    Expected behavior

    Apache service should remain enabled (and Nginx remain disabled), even after destroying SSH session, or running vagrant halt and then vagrant reload/up (with or without computer restart).

    Actual behavior

    I SSH into Homestead and run the flip command to stop Nginx and start Apache. All Apache sites run normally (Alternatively, I could SSH into Homestead and stop Nginx and start Apache). If I log out of my SSH session, Apache immediately stops working.

    Steps to reproduce

    1. SSH into Homestead homestead ssh
    2. Run flip command (Alternatively, stop Nginx, and then run sudo service apache2 restart)
    3. Test site running Apache -- everything should work normally.
    4. Log out of the SSH session (Cmd + D)
    5. Apache stops working. Refreshing the browser with the test site running doesn't work.
    6. SSH into Homestead again homestead ssh and see that Apache is not still running.

    According to the docs, the flip command "automatically determines which web server is running, shuts it off, and then starts the other server." It appears that this does not persist longer than the active SSH session.

    Update

    When I SSH into Homestead, if I run sudo service apache2 status I receive the following failure message:

     sudo service apache2 status
    ● apache2.service - The Apache HTTP Server
       Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
      Drop-In: /lib/systemd/system/apache2.service.d
               └─apache2-systemd.conf
       Active: failed (Result: exit-code) since Fri 2018-05-25 01:46:50 UTC; 22s ago
      Process: 2463 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
     Main PID: 2480 (code=exited, status=1/FAILURE)
    
    May 25 01:46:15 homestead systemd[1]: Starting The Apache HTTP Server...
    May 25 01:46:15 homestead apachectl[2463]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 12
    May 25 01:46:15 homestead systemd[1]: Started The Apache HTTP Server.
    May 25 01:46:50 homestead systemd[1]: apache2.service: Main process exited, code=exited, status=1/FAILURE
    May 25 01:46:50 homestead systemd[1]: apache2.service: Failed with result 'exit-code'.
    lines 1-13/13 (END)
    

    If I then run sudo service apache2 restart my sites load normally until I log out of the SSH session, at which point Apache apparently fails again.

    opened by adamdehaven 28
  • Laravel command not found

    Laravel command not found

    Versions

    • Vagrant: 2.0.1
    • Provider: Virtualbox
    • Homestead: Latest? (Adding box 'laravel/homestead' (v5.0.1) for provider: virtualbox)

    Host operating system

    Windows 7 Ultimate 64bit, Windows 10 Pro 64bit - both fresh installs.

    Expected behavior

    After successfully installing Virtualbox, Vagrant and Homestead...

    vagrant ssh cd code composer global require "laravel/installer" laravel new test Expect new laravel installation

    Actual behavior

    laravel command not found

    Workaround:

    export PATH="~/.composer/vendor/bin:$PATH"

    Never had to do this before on many other Homestead installs.

    Needs PR/Fixing 
    opened by sitesense 27
  • Slower migrations and phpunit after moving to v7.9.0 and v7.10.0

    Slower migrations and phpunit after moving to v7.9.0 and v7.10.0

    Please note that the Homestead issue tracker is reserved for bug reports and enhancements. We are not always able to debug Vagrant, Provider or Operating System issues, but will do our best to help. Thank you!

    Versions

    • Virtualbox: 5.2.14 r123301
    • Vagrant: 2.1.2
    • Provider: Virtualbox
    • Homestead: 7.6.2 | 7.9.0 | 7.10.0

    A lot of issues can be resolved by simply updating vagrant, provider or homestead.

    Note: Virtualbox users, please upgrade to ~5.2. You will show as up-to-date from the ~5.0 version when you About -> Check for Updates. You'll need to download a newer version of Virtualbox.

    Host operating system

    This is the operating system that you run locally.

    Homestead.yaml

    ---
    ip: "192.168.10.10"
    memory: 2048
    cpus: 2
    provider: virtualbox
    mariadb: true
    ssl: true
    
    authorize: ~/.ssh/id_rsa.pub
    
    keys:
        - ~/.ssh/id_rsa
    
    folders:
        - map: ~/Code
          to: /home/vagrant/Code
    
    sites:
        - map: homestead.test
          to: /home/vagrant/Code/Laravel/public
    
    databases:
        - testdb
        
    # blackfire:
    #     - id: foo
    #       token: bar
    #       client-id: foo
    #       client-token: bar
    
    # ports:
    #     - send: 50000
    #       to: 5000
    #     - send: 7777
    #       to: 777
    #       protocol: udp
    
    

    Vagrant destroy & up output

    Provide a link to a GitHub Gist containing the complete output of vagrant destroy && vagrant up. Do NOT paste the debug output in the issue, just paste the link to the Gist.

    Expected behavior

    I would expect that after upgrading to unbuntu 18.04 (homestead 7.10.0) that the migration and phpunit run times would not be significantly slower in the newer version. If anything one would expect the run times to be faster in the newer versions.

    Actual behavior

    The migration and phpunit run times dramatically increased after upgrading to the newer version of homestead.

    Steps to reproduce

    1. create a decent about of migrations (I have about 25)
    2. run migrations in homestead v7.6.2 "time php artisan migrate" (note times) repeat for PHPUnit
    3. upgrade homestead to v7.10.0
    4. run migrations in homestead v7.10.0 "time php artisan migrate" (note times) repeat for PHPUnit

    My migration times were 2.647s on homestead v7.6.2 they went up to 17.747s (these times are greatly different with the exact same migrations, the only difference was the homestead version). The times for phpunit test to execute also dramatically increased which I believe is because of the increased times of the migrations. Most of my unit test took 4 seconds to run on 7.6.2 and now take 20-30s on 7.10.0. This issue appears to have introduced after moving to Ubuntu 18.04

    I could reproduce this one two different system (MacBook Pro & Hackintosh) Both running High Serria.

    I did not test this in Homestead v7.7.0 or v7.8.0 but noticed this a couple of weeks ago in 7.9.0 but just now was able to get around to testing. Before 7.9.0 I was on 7.6.2.

    opened by scoutman57 26
  • Running vagrant up fails when mounting SMB shared folders. (Windows 10, Hyper-V)

    Running vagrant up fails when mounting SMB shared folders. (Windows 10, Hyper-V)

    Versions

    • Vagrant: 2.0.1
    • Provider: Hyper-V
    • Homestead: 7.0.1 (CLI), 5.0.1 (Box)

    Host operating system

    Windows 10 Pro

    Homestead.yaml

    ---
    ip: "172.21.12.10"
    memory: 2048
    cpus: 1
    provider: hyperv
    mariadb: true
    
    authorize: c:/Users/arbet/.ssh/id_rsa.pub
    
    keys:
        - c:/Users/arbet/.ssh/id_rsa
    
    folders:
        - map: c:/Users/arbet/Documents/Projects
          to: /home/vagrant/code
    
    sites:
        - map: site.test
          to: /home/vagrant/code/site/public
    
    databases:
        - homestead
    
    # blackfire:
    #     - id: foo
    #       token: bar
    #       client-id: foo
    #       client-token: bar
    
    # ports:
    #     - send: 50000
    #       to: 5000
    #     - send: 7777
    #       to: 777
    #       protocol: udp
    

    Vagrant destroy & up output

    GitHub Gist

    Expected behavior

    It should boot up and create the whole virtual machine, mounting SMB shared folders and provisioning.

    Actual behavior

    It fails after it tries to mount SMB shared folders. I suspect it can be because of bad SMB username, because I am using a Microsoft account and I don't know what should be the proper SMB username. However the output also says mount error(112): Host is down

    Steps to reproduce

    1. Enable HyperV on Windows 10 Pro
    2. Install Vagrant
    3. Add homestead Vagrant box
    4. Run vagrant up

    References

    No.

    opened by KubqoA 26
  • By use the feature MariaDB get error

    By use the feature MariaDB get error "Access denied for user 'root'@'localhost'"

    Please note that the Homestead issue tracker is reserved for bug reports and enhancements. We are not always able to debug Vagrant, Provider or Operating System issues, but will do our best to help. Thank you!

    Versions

    • Vagrant: 2.2.19
    • Provider: Virtualbox 6.1
    • Homestead: 13.3.2

    Host operating system

    macOS Big Sure 11.7.1

    Homestead.yaml

    ip: 192.168.56.56
    memory: 2048
    cpus: 2
    provider: virtualbox
    authorize: ~/.ssh/id_ed25519.pub
    keys:
        - ~/.ssh/id_ed25519
    folders:
        -
            map: /Users/p4rad0xus/Developer/github_issue
            to: /home/vagrant/code
    sites:
        -
            map: homestead.test
            to: /home/vagrant/code/public
    databases:
        - homestead
    features:
        -
            mysql: false
        -
            mariadb: true
        -
            postgresql: false
        -
            ohmyzsh: false
        -
            webdriver: false
    services:
        -
            enabled: [mysql]
    name: github-issue
    hostname: github-issue
    

    Vagrant destroy & up output

    vagrant up https://gist.github.com/p4rad0xus/411623f39b83aaf449f7c85e207a282a#file-vagrant_up

    vagrant destroy https://gist.github.com/p4rad0xus/9f0e5bd46f844cd0d9cc8b17553332fb#file-vagrant_destroy

    Expected behavior

    The command vagrant up should proceed successful and create the named database in the Homestead.yaml.

    Actual behavior

    The script stoped at the point when the database should be created with the error "Access denied for user 'root'@'localhost'".

    Steps to reproduce

    1. Create a new Homestead project
    2. Set the feature mysql to false and mariadb to true
    3. Run vagrant up

    MySQL-User-Table

    It looks like a password for root@localhost is never set.

    MariaDB [(none)]> Select User, Host, Password from mysql.user;

    +-------------+-----------+-------------------------------------------+
    | User        | Host      | Password                                  |
    +-------------+-----------+-------------------------------------------+
    | mariadb.sys | localhost |                                           |
    | root        | localhost | invalid                                   |
    | mysql       | localhost | invalid                                   |
    | root        | 0.0.0.0   | *14E65567ABDB5135D0CFD9A70B3032C179A49EE7 |
    | homestead   | 0.0.0.0   | *14E65567ABDB5135D0CFD9A70B3032C179A49EE7 |
    | homestead   | %         | *14E65567ABDB5135D0CFD9A70B3032C179A49EE7 |
    +-------------+-----------+-------------------------------------------+
    
    opened by p4rad0xus 0
  • Request for libvirt provider

    Request for libvirt provider

    Hi guys,

    Apologies if this has been asked and dismissed before, but I was wondering how much work it would be to have a libvirt provider in additional to parallels and virtualbox?

    I ask because if Linux users want to run a Homestead box, they currently have no alternative but to pollute their beautiful freedom-respecting distributions with Oracle's Virtualbox. As we all know, Oracle holds the top three positions in Time's Most Hated Software Companies On The Planet.

    So, please consider adding a libvirt provider for us Linux users, and help us ward off the return of Lucifer.

    opened by paktsardines 0
  • Web Requests not being handled correctly

    Web Requests not being handled correctly

    Versions

    • Vagrant: Vagrant 2.3.2
    • Provider: Virtualbox 7.0.2 r154219 (Qt5.15.2)
    • Homestead: laravel/homestead@dev-main (for Virtualbox 7 support)

    Host operating system

    MacOS Ventura 13.0 (22A380)

    My Process

    I created a script to stand up boxes, called vbmake.

    I run vbmake testing, and the script handles a lot of the boilerplate for me. The resulting "box" file structure looks like this:

    testing.box/
      box/
        vendor
        after.sh
        aliases
        composer.json
        composer.lock
        homestead.testing.crt
        Homestead.yaml
        Vagrantfile
      databases/
      sites/
        test.local/
          index.html
    

    I've never run into any of the issues I'll describe in this ticket using this method until after upgrading my Mac to Ventura.

    The script generates the Homestead.yml file below.

    Homestead.yaml

    name: testing.box
    hostname: testing
    
    ip: 192.168.56.0
    memory: 2048
    cpus: 2
    provider: virtualbox
    
    ssl: true
    authorize: ~/.ssh/id_rsa.pub
    keys:
        - ~/.ssh/id_rsa
    
    folders:
        - map: ../sites/test.local
          to: /home/vagrant/sites/test.local
    
    sites:
        - map: test.local
          to: /home/vagrant/sites/test.local
    
    # databases:
    #     - homestead
    
    features:
        - mysql:        false
        - mariadb:      false
        - postgresql:   false
        - ohmyzsh:      false
        - webdriver:    false
    

    Hostfile

    192.168.56.0    test.local
    

    Vagrant destroy & up output

    Gist

    Expected behavior

    I expect browsing test.local to display the contents of index.html: <h1>Hello World!</h1>

    Actual behavior

    Browser times out. ping test.local times out.

    Things I've tried to debug / More Info

    vagrant ssh -> flip -- I thought potentially the box was starting in apache mode instead of nginx, but I was wrong. Neither load the test.local site.

    Then I thought that maybe something in the nginx configuration was borked, but it looks ok.

    The Network tab of the Virtualbox says Adapter 1 is NAT, and Adapter 2 is Internal Network.

    Thank you for looking at this!

    Provider Bug VirtualBox Bug 
    opened by ethanbeyer 1
Releases(v13.3.2)
  • v13.3.2(Nov 6, 2022)

  • v13.3.1(Oct 26, 2022)

  • v13.3.0(Oct 26, 2022)

    • Update golang version to 1.17.7 (#1762) @ricardoseriani
    • Update golang version to 1.17.8 (#1771) @ricardoseriani
    • Update golang version to 1.18 (#1776) @ricardoseriani
    • Fix overriding multiple provisioners in loops (#1772) @DRogueRonin
    • feat: add new site type for fastadmin framework (#1779) @emptyrealm
    • Update golang version to 1.18.2 (#1783) @ricardoseriani
    • Update golang version to 1.18.3 (#1785) @ricardoseriani
    • Update golang version to 1.18.4 (#1787) @ricardoseriani
    • Update golang version to 1.18.5 (#1790) @ricardoseriani
    • Update golang version to 1.19 (#1791) @ricardoseriani
    • Update tests.yml (#1795) @sashashura
    • Update golang version to 1.19.1 (#1796) @ricardoseriani
    • mongodb.sh: bump PHP driver to 1.14.1 version (#1800) @themaric
    • Feature oh my zsh : set theme and plugins from config (#1798) @UnSeulT
    • Update golang version to 1.19.2 (#1805) @ricardoseriani
    • Adding 8.2 to CICD (#1806) @svpernova09
    • add Laravel Pint alias (#1808) @browner12
    • Dockstead (#1809) @svpernova09
    • Add aliases for 8.2 @svpernova09
    Source code(tar.gz)
    Source code(zip)
  • v13.2.1(Feb 2, 2022)

  • v13.2.0(Jan 29, 2022)

  • v13.1.1(Jan 26, 2022)

  • v13.1.0(Jan 25, 2022)

  • v13.0.2(Dec 21, 2021)

    • WordPress - Enable debug mode automatically (#1747) @dominiccarrington
    • add MongoDB backup (#1746) @li9ht
    • Make MongoDB install aware of CPU Arch being used (#1749) @svpernova09
    Source code(tar.gz)
    Source code(zip)
  • v13.0.1(Dec 17, 2021)

    • Update golang version to 1.17.5 (#1742) @ricardoseriani
    • Bump MongoDB PHP driver to v1.12.0 (#1743) @themaric
    • add mongodb.so to php8.1 php.ini (#1745) @li9ht
    Source code(tar.gz)
    Source code(zip)
  • v13.0.0(Dec 8, 2021)

    • Default to PHP 8.1
    • Tagging v13.0.0 and update constraints
    • Update minio feature to be aware of CPU arch (#1734)
    • Update cpu arch conditional check for minio
    • Add test aliases for both Pest and PHPunit dynamically (#1738)
    • Update localized aliases
    Source code(tar.gz)
    Source code(zip)
  • v12.8.0(Nov 7, 2021)

    • Remove docker feature, since it's already on homestead base image (#1716) @ricardoseriani
    • Update golang feature to be aware of CPU arch (#1723) @svpernova09
    • Fix cpu detection for golang install @svpernova09
    • mongodb.sh: bump PHP driver to 1.11.0 (#1725) @themaric
    • Update MongoDB to v1.11.1 @svpernova09
    • Update golang version to 1.17.3 (#1727) @ricardoseriani
    • Use 192.168.56.56 as the default IP for Homestead @svpernova09
    Source code(tar.gz)
    Source code(zip)
  • v12.7.1(Oct 15, 2021)

  • v12.7.0(Oct 4, 2021)

    • Add a preflight script to do some questionable things to the operating system.
    • To resolve #1707 add in-flight-service: true to Homestead.yaml and run vagrant destroy, vagrant up
    Source code(tar.gz)
    Source code(zip)
  • v12.6.1(Oct 2, 2021)

  • v12.6.0(Sep 22, 2021)

    • Site option feature parity for PHP from Ruby @svpernova09
    • pass all our params to create site @svpernova09
    • Fix shebang for php81.sh script (#1690) @om4csaba
    • feat(php) enable php-fpm on box startup (#1691) @irineujunior
    • Move services configuration after feature installation #1694 @svpernova09
    • Update golang version to 1.17.1 (#1699) @ricardoseriani
    • Process headers & rewrites for wsl:create-sites @svpernova09
    • Change logo to work on Dark Theme (#1703) @xiCO2k
    Source code(tar.gz)
    Source code(zip)
  • v12.5.0(Sep 2, 2021)

    • Adding support for PHP 8.1

    To test PHP 8.1 add php: "8.1" to any site configuration such as:

    sites:
        - map: laravel.test
          to: /home/vagrant/laravel/public
          php: "8.1"
    

    Then run vagrant provision

    Source code(tar.gz)
    Source code(zip)
  • v12.4.2(Sep 2, 2021)

  • v12.4.1(Aug 20, 2021)

  • v12.4.0(Aug 17, 2021)

    • mongodb: update PHP driver to PHP8 compatible v1.9.0 @themaric
    • Update golang version to 1.16.6 (#1673) @ricardoseriani
    • Update after.sh (#1672) @stebogit
    • Bump MongoDB PHP driver to 1.10.0 (#1675) @themaric
    • Adding/Tweaking PHP version scripts
    • Reduce number of default ports Add old defaults to ports example
    • Mongo install should check for php version existence before installing
    • Ensure we purge the entire contents of lib mysql
    • Update golang version to 1.16.7 (#1678) @ricardoseriani
    • Update Installation for TimescaleDB
    • Update Go to 1.17
    Source code(tar.gz)
    Source code(zip)
  • v12.3.2(Jul 13, 2021)

  • v12.3.1(Jul 8, 2021)

    Note to Flyway & Heroku Users

    Flyway and Heroki CLI tools have been moved to feature scripts and will no longer be installed unless you add flyway: true or heroku:true to your features: array in Homestead.yaml.

    Notes

    • Update golang version to 1.16.5 (#1660) @ricardoseriani
    • Debugging inline provisioners (#1663)
    • Removed PostgreSQL < 13 for WSL & TimescaleDB
    • Update Readme to remove reference to 20.04 branch.
    • Adding Flyway & Heroku CLI as feature scripts
    • TimescaleDB Should use PostgreSQL 13
    • Adding old PHP versions as feature scripts
    • When clearing variables, check if the file exists first.
    • Add feature scripts for old PHP versions. Enable easy site to feature
    • add support for vagrant-goodhosts (#1667) @thedavidthomas
    • Update Blackfire to v2 (#1671) @DieterHolvoet
    Source code(tar.gz)
    Source code(zip)
  • v12.3.0(May 29, 2021)

    • Update meilisearch.sh (#1643) @RemCom
    • Added swoole for Octane (#1642) @litan1106
    • Remove usage of bintray for rabbitmq (#1646) @@Simoneu01
    • Update golang version to 1.16.4 (#1649) @ricardoseriani
    • Adding feature 'r-base' (#1653)
    • Updates to fix mariadb
    • Update aliases for Xdebug 3
    Source code(tar.gz)
    Source code(zip)
  • v12.2.0(Apr 7, 2021)

    • Removed trailing slash from apache config (#1630) @firojghimire-sk
    • Update timescaledb2 to support postgres 13 (#1635) @yazeed
    • Update golang version to 1.16.3 (#1637) @ricardoseriani
    • Add executable path and default homestead IP on ExecStart (#1636) @andreia
    • Fix Minio Buckets Being Setup Incorrectly (#1633) @vpillinger
    • Support Site types in WSL (#1640)
    Source code(tar.gz)
    Source code(zip)
  • v12.1.1(Mar 17, 2021)

    • When creating WSL Sites, clear any existing nginx sites
    • Update golang version to 1.16.1 (#1628) @ricardoseriani
    • Update golang version to 1.16.2 (#1629) @ricardoseriani
    • Default MySQL to be true
    Source code(tar.gz)
    Source code(zip)
  • v12.1.0(Feb 26, 2021)

    • Trader PHP extension (#1608) @yazeed
    • Update golang version to 1.15.8 (#1609) @ricardoseriani
    • Added query logging for MariaDB (#1601) @RitamDey
    • Allow specifying a full proxy_pass value with the to key in the homes… @andresayej
    • Update golang version to 1.16 (#1616) @ricardoseriani
    • Update readme for supported versions
    • remove client_max_body_size from site types so FPM takes priority
    • Standardize on client_max_body_size at 100M
    • Adding Meilisearch feature, thanks to CorruptedCyborg for the gist
    • Updates for WSL2
    Source code(tar.gz)
    Source code(zip)
  • v12.0.0(Feb 2, 2021)

    The 12.x releases of Homestead bring Ubuntu 20.04 to the primary release branch. If you've previously been using Homestead 11.x, vagrant box 10.x this is a very minor upgrade.

    If you have been using the release branch note this is a major version bump. Homestead is now built on Ubuntu 20.04 with defaults: MySQL 8.0, PHP 8.0, Node 14. You should review the Homestead v11.0.0 Release notes.

    Source code(tar.gz)
    Source code(zip)
  • v10.17.0(Dec 1, 2020)

    Homestead v10.17.0

    • Updating magento template to support params (#1557) @minioak
    • Add Elasticsearch repositories only once to sources.list (#1554) @DieterHolvoet
    • Add function to switch to PHP 8.0 (#1553) @DieterHolvoet
    • Update Composer config path
    • Tagging v10.17.0
    • Composer 2 now defaults. If you're not using vagrant box v9.7.2 you will see an error on vagrant up regarding Composer. Update the vagrant box to resolve.

    Vagrant box version v9.7.2

    https://github.com/laravel/settler/releases/tag/v9.7.2

    • Add PostgreSQL 13 and set as default
    • drop hirak/prestissimo (#225) @browner12
    • Default to PHP 8.0 (#226)
    • Set permission on .config
    • update motd-news path
    • fix motd issues from upstream

    Note on Versioning

    Homestead currently maintains support for 18.04 LTS via master branch, vagrant box version 9.x, Homestead Repo version 10.x, and 20.04 LTS via 20.04, vagrant box version 10.x. Homestead Repo version 11.x. To maintain this somewhat clear versioning separation while we continue to support both LTS versions instead of this PHP default change triggering a major version change, will only be a minor version change so that users can always rely on 9.x. This also allows us to avoid the ridiculous confusion releasing different LTS versions along the same box version numbers would bring.

    As always: Homestead's support policy is to support the latest major Ubuntu LTS versions and supported PHP versions. This project relies heavily on chef/bento and Ondřej Surý's Ubuntu PPA. Please support these projects as much as you're able.

    Apple Silicon Support

    See the discussion https://github.com/laravel/homestead/issues/1552

    TL;DR

    PHP 8.0 now default. Support chef/bento and Ondřej Surý!

    Source code(tar.gz)
    Source code(zip)
  • v11.4.0(Nov 24, 2020)

    • [20.04] Add support for php 8 (#1537) @chris-doehring
    • Add PostgreSQL 13 and default to it for WSL
    • Update golang version to 1.15.4 (#1542) @ricardoseriani
    • Only create databases for features enabled. Update DB backup path
    • Update golang version to 1.15.5 (#1543) @ricardoseriani
    • Create Mysql8 Databases if Mysql8 feature enabled (#1544) @evanrthompson
    • add PostgreSQL as a default feature (#1545) @iDuriel
    Source code(tar.gz)
    Source code(zip)
  • v10.16.0(Nov 24, 2020)

    • Update golang version to 1.15.4 (#1542) @ricardoseriani
    • Only create databases for features enabled. Update DB backup path
    • Update golang version to 1.15.5 (#1543) @ricardoseriani
    • Create Mysql8 Databases if Mysql8 feature enabled (#1544) @evanrthompson
    • add PostgreSQL as a default feature (#1545) @iDuriel
    Source code(tar.gz)
    Source code(zip)
  • v11.3.3(Nov 1, 2020)

Owner
The Laravel Framework
The Laravel Framework
List of 77 languages for Laravel Framework 4, 5, 6, 7 and 8, Laravel Jetstream , Laravel Fortify, Laravel Breeze, Laravel Cashier, Laravel Nova and Laravel Spark.

Laravel Lang In this repository, you can find the lang files for the Laravel Framework 4/5/6/7/8, Laravel Jetstream , Laravel Fortify, Laravel Cashier

Laravel Lang 6.9k Jan 2, 2023
⚡ Laravel Charts — Build charts using laravel. The laravel adapter for Chartisan.

What is laravel charts? Charts is a Laravel library used to create Charts using Chartisan. Chartisan does already have a PHP adapter. However, this li

Erik C. Forés 31 Dec 18, 2022
Laravel Kickstart is a Laravel starter configuration that helps you build Laravel websites faster.

Laravel Kickstart What is Laravel Kickstart? Laravel Kickstart is a Laravel starter configuration that helps you build Laravel websites faster. It com

Sam Rapaport 46 Oct 1, 2022
Laravel User Activity Log - a package for Laravel 8.x that provides easy to use features to log the activities of the users of your Laravel app

Laravel User Activity Log - a package for Laravel 8.x that provides easy to use features to log the activities of the users of your Laravel app

null 9 Dec 14, 2022
Laravel Segment is an opinionated, approach to integrating Segment into your Laravel application.

Laravel Segment Laravel Segment is an opinionated, approach to integrating Segment into your Laravel application. Installation You can install the pac

Octohook 13 May 16, 2022
Laravel Sanctum support for Laravel Lighthouse

Lighthouse Sanctum Add Laravel Sanctum support to Lighthouse Requirements Installation Usage Login Logout Register Email Verification Forgot Password

Daniël de Wit 43 Dec 21, 2022
Bring Laravel 8's cursor pagination to Laravel 6, 7

Laravel Cursor Paginate for laravel 6,7 Installation You can install the package via composer: composer require vanthao03596/laravel-cursor-paginate U

Pham Thao 9 Nov 10, 2022
A package that uses blade templates to control how markdown is converted to HTML inside Laravel, as well as providing support for markdown files to Laravel views.

Install Install via composer. $ composer require olliecodes/laravel-etched-blade Once installed you'll want to publish the config. $ php artisan vendo

Ollie Codes 19 Jul 5, 2021
A light weight laravel package that facilitates dealing with arabic concepts using a set of classes and methods to make laravel speaks arabic

A light weight laravel package that facilitates dealing with arabic concepts using a set of classes and methods to make laravel speaks arabic! concepts like , Hijri Dates & Arabic strings and so on ..

Adnane Kadri 49 Jun 22, 2022
Jetstrap is a lightweight laravel 8 package that focuses on the VIEW side of Jetstream / Breeze package installed in your Laravel application

A Laravel 8 package to easily switch TailwindCSS resources generated by Laravel Jetstream and Breeze to Bootstrap 4.

null 686 Dec 28, 2022
Laravel Jetstream is a beautifully designed application scaffolding for Laravel.

Laravel Jetstream is a beautifully designed application scaffolding for Laravel. Jetstream provides the perfect starting point for your next Laravel application and includes login, registration, email verification, two-factor authentication, session management, API support via Laravel Sanctum, and optional team management.

The Laravel Framework 3.5k Jan 8, 2023
Laravel Larex lets you translate your whole Laravel application from a single CSV file.

Laravel Larex Translate Laravel Apps from a CSV File Laravel Larex lets you translate your whole Laravel application from a single CSV file. You can i

Luca Patera 68 Dec 12, 2022
A Laravel package that adds a simple image functionality to any Laravel model

Laraimage A Laravel package that adds a simple image functionality to any Laravel model Introduction Laraimage served four use cases when using images

Hussein Feras 52 Jul 17, 2022
A Laravel extension for using a laravel application on a multi domain setting

Laravel Multi Domain An extension for using Laravel in a multi domain setting Description This package allows a single Laravel installation to work wi

null 658 Jan 6, 2023
Example of using abrouter/abrouter-laravel-bridge in Laravel

ABRouter Laravel Example It's a example of using (ABRouter Laravel Client)[https://github.com/abrouter/abrouter-laravel-bridge] Set up locally First o

ABRouter 1 Oct 14, 2021
Laravel router extension to easily use Laravel's paginator without the query string

?? THIS PACKAGE HAS BEEN ABANDONED ?? We don't use this package anymore in our own projects and cannot justify the time needed to maintain it anymore.

Spatie 307 Sep 23, 2022
Laravel application project as Sheina Online Store backend to be built with Laravel and VueJS

About Laravel Laravel is a web application framework with expressive, elegant syntax. We believe development must be an enjoyable and creative experie

Boas Aditya Christian 1 Jan 11, 2022
Postgis extensions for laravel. Aims to make it easy to work with geometries from laravel models.

Laravel Wrapper for PostgreSQL's Geo-Extension Postgis Features Work with geometry classes instead of arrays. $model->myPoint = new Point(1,2); //lat

Max 340 Jan 6, 2023
laravel - Potion is a pure PHP asset manager for Laravel 5 based off of Assetic.

laravel-potion Potion is a pure PHP asset manager for Laravel based off of Assetic. Description Laravel 5 comes with a great asset manager called Elix

Matthew R. Miller 61 Mar 1, 2022