Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Ben Johnson
    @cbj4074
    What I find so strange is that if I omit the mount_options altogether, and simply enter my credentials when prompted, mounting fails! So, what is it about providing these mount options that allows mounting to work correctly, even though I'm still prompted for them? The behavior makes no sense at all.
    Ben Johnson
    @cbj4074
    :laughing: Yeah, Vagrant totally ignores the credentials I enter on the CLI when prompted and uses the ones in the Vagrantfile. So why ask for them???
    Hongde Liu
    @enginespot
    Hi @cbj4074 I did not use VirtualBox , I will try to test it in recent days:)
    Ben Johnson
    @cbj4074
    @enginespot :thumbsup:
    Michael C.
    @sk1u
    Hi All! I had a best practices question.
    I use vagrant + virtualbox to test my ansible playbooks locally.
    Do you normally commit Vagrantfile and .vagrantinto the same repo as the ansible setup?
    Ben Johnson
    @cbj4074
    @sk1u You should definitely commit Vagrantfile, but I don't believe there's any reason to commit .vagrant.
    (as the latter would simply be recreated upon vagrant up)
    Provider-specific information resides in .vagrant, and your end-user may be using a different provider, for example.
    Michael C.
    @sk1u
    so anyone else whom would like to use my Vagrantfile, would still need to init their own .vagrant with vagrant init ?
    Ben Johnson
    @cbj4074
    Yep
    Michael C.
    @sk1u
    i guess vagrant init will not overwrite the Vagrantfile they're supposed to be using.
    Ben Johnson
    @cbj4074

    That's correct. From the docs:

    creating an initial Vagrantfile if one does not already exist.

    Michael C.
    @sk1u
    Thank you :)
    Ben Johnson
    @cbj4074
    In fact, I'm not even sure init is necessary. I think they can just vagrant up.
    Jopacari
    @Jopacari
    Hi :)
    I found an issue with the vagrant salt provisioner
    When provisioning salt on a windows server it fails to download the installer.
    This is happening because the bootstrap is in powershell language that use TLS1.0 by default
    Salt changed the repos to only allow TLS1.2 since a few days ago.
    Salt team had the same issue with their bootstrap a few months ago and they rolled back the move to TLS1.2 by that time.
    They fixed their bootstrap and now they are enforcing TLS1.2 again.
    Jopacari
    @Jopacari
    I locally fixed the vagrant bootstrap easily using the same approach they used.
    What will be the next step to contribute?
    This issue should be preventing vagrant salt provisioning of any windows servers - I know that just a few people deal with salt on windows but still, it is currently broken.
    Comments?
    Jopacari
    @Jopacari
    ?
    Ben Johnson
    @cbj4074
    @Jopacari Seems appropriate to open an Issue on the GitHub tracker if no such issue exists.
    (or just fix it yourself and propose a PR)

    Unrelated, I'm wrestling with an issue, too... I'm attempting to execute Powershell commands during provisioning (on a Windows host, obviously), but it seems like Vagrant treat it as a shells script and runs it against the guest.

    Vagrantfile snippet:

    Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
        config.trigger.after :reload do |trigger|
            config.vm.provision "shell", privileged: "true", powershell_elevated_interactive: "true", inline: <<-SHELL
    
            Get-VM "homestead" | Get-VMNetworkAdapter | Connect-VMNetworkAdapter -SwitchName "NATSwitch"
    
            SHELL
        end
    end

    When the provisioner gets this far, the output is:

    ==> homestead: Running provisioner: shell...
        homestead: Running: inline script
        homestead: /tmp/vagrant-shell: line 2: Get-VM: command not found
        homestead: /tmp/vagrant-shell: line 2: Get-VMNetworkAdapter: command not found
        homestead: /tmp/vagrant-shell: line 2: Connect-VMNetworkAdapter: command not found
    The SSH command responded with a non-zero exit status. Vagrant
    assumes that this means the command failed. The output for this command
    should be in the log above. Please read the output to determine what
    went wrong.
    Jopacari
    @Jopacari
    @cbj4074 Can you please just try to use this instead:
    inline: "Get-VM 'homestead' | Get-VMNetworkAdapter | Connect-VMNetworkAdapter -SwitchName 'NATSwitch'"
    Just to see if it works
    If I have the oportunity I will try your approach to see if I get the same error.
    Ben Johnson
    @cbj4074
    @Jopacari Hey, thanks for taking a look. I meant to follow-up yesterday... it was entirely my bad, the documentation makes it clear that inline scripts are always executed on the guest. I ended-up doing this, and it works:
        config.trigger.before :reload do |trigger|
            trigger.info = "Setting Hyper-V switch to 'NATSwitch' now that static IP is configured in VM..."
    
            trigger.run = {privileged: "true", powershell_elevated_interactive: "true", path: "./scripts-custom/resources/utility-scripts/set-hyperv-switch.ps1"}
        end
    Ben Johnson
    @cbj4074
    I'm finding it surprisingly difficult to determine whether or not it's possible to call certain provisioning scripts in the Vagrantfile depending on the provider that is in use. This seems like much-needed functionality but doesn't appear to be possible.

    Currently, I'm setting an environment variable in the host OS and doing something like this, which feels super hacky:

    if ENV['VAGRANT_PROVIDER'] == 'hyperv'

    Obviously, if this is not set or if it's set to a different provider than the one I'm actually using, it won't function reliably.

    Ben Johnson
    @cbj4074
    Actually, config.vm.provider "hyperv" do |hyperv| ...end does seem to work, yet I notice that the content of that block seems to be executed at the very end of the provisioning process, despite appearing near the top of the Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| ... end block.
    Ahh, and it is run every time the machine is booted, not just during provisioning. So, I suppose my original question still stands.
    Sai K K
    @saikksub
    Can we install vagrant in silent mode?
    Gilles Cornu
    @gildegoma
    @briancain or @chrisroberts when do you plan to release vagrant 2.2.7 ?
    I'd like to test + enhance stuff proposed in hashicorp/vagrant#11148 but won't have time to work on it until November 1st.
    @saikksub on what platform? on macOS (and maybe more operating systems), the homebrew cask is pretty handy: brew cask install vagrant
    (on Arch Linux, the default package is almost always up to date, per "community definition" ;-) )
    Chris Roberts
    @chrisroberts
    gildegoma: hi! it will be at least 2 weeks as we are working through packaging updates (especially on macos)
    Gilles Cornu
    @gildegoma
    @chrisroberts ok, good to know. it was indeed because of seeing your activity on the packaging repo, that I got worried things could run very fast ;-)
    I'll do my best to be on time, then.
    Chris Roberts
    @chrisroberts
    yeah, no worries. 2 weeks will be the fastest. we've got other things we're working on as well to get merged in before the next release so i'm sure it will be a little longer :)
    Arindam Mondal
    @Arindam-Mondal

    I am getting the below error
    Failed to mount folders in Linux guest. This is usually because
    the "vboxsf" file system is not available. Please verify that
    the guest additions are properly installed in the guest and
    can work properly. The command attempted was:

    mount -t cifs -o vers=2.0,credentials=/etc/smb_creds_vgt-18791af46561bf3104c65671dfdfc0f9-6ad5fdbcbf2eaa93bd62f92333a2e6e5,5,uid=1000,gid=1000 //10.13.62.142/vgt-18791af46561bf3104c65671dfdfc0f9-6ad5fdbcbf2eaa93bd62f92333a2e6e5 /vagrant

    The error output from the last command was:

    mount error(115): Operation now in progress
    Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
    Can Anyone please help..It was working fine..Suddenly it is not working anymore...I am using windows 10..Thanks

    Ben Johnson
    @cbj4074
    @Arindam-Mondal Have you tried rebooting the Windows host?
    Ben Johnson
    @cbj4074

    Not sure if this is the appropriate place to discuss Packer, but I'm wondering why it seems to ignore the switch_name environment variable when using the Hyper-V Builder. This used to work as expected for me, but now, even if I specify it like

    $env:switch_name = 'Default Switch'

    and then confirm that it's set correctly with

    > Get-ChildItem Env:switch_name
    
    Name                           Value
    ----                           -----
    switch_name                    Default Switch

    Packer still forges right on ahead with creating a new packer-hyperv-iso switch:

    > packer build -only=hyperv-iso .\ubuntu-18.04-amd64.json
    hyperv-iso output will be in this color.
    
    ==> hyperv-iso: Creating build directory...
    ==> hyperv-iso: Retrieving ISO
    ...
    ==> hyperv-iso: Creating switch 'packer-hyperv-iso' if required...
    ==> hyperv-iso:     switch 'packer-hyperv-iso' already exists. Will not delete on cleanup...

    Ahh, my bad. It looks like Bento is overriding that behavior for whatever reason. In digging-around my Bento configuration, I notice that it contains

    "hyperv_switch": "{{env `hyperv_switch`}}",

    and so setting $env:hyperv_switch = 'Default Switch' does the job.

    Ben Johnson
    @cbj4074
    Oddly, the VM freezes during the early statges of Ubuntu setup when I use the Default Switch, so I just created another External switch, told Packer to use that, and it works fine. Sigh. Always something with Hyper-V's networking stack...