I want to enable drag'n'drop using the Vagrant provisioning file ("Vagrantfile"). Therefore I use the following lines:
vbox.customize ["modifyvm", :id, "--clipboard", "bidirectional"]
vbox.customize ["modifyvm", :id, "--draganddrop", "bidirectional"]
When I look into the settings of Virtual Box the two options are changed, but drag'n'drop still does not work. The Clipboard works in bidirectional way. How can I make drag'n'drop really make work using vagrant provisioning?
I use Virtual Box 5.0.20 and Vagrant 1.8.1
I have tried quickly to grab the full documentation for the mentioned versions, but it is hard since now there are new major versions for both Vagrant 2.X.Y and VirtualBox 6.A.B. So for the mentioned versions you can do the following:
vb.customize ['modifyvm', :id, '--clipboard-mode', 'bidirectional']
vb.customize ['modifyvm', :id, '--draganddrop', 'bidirectional']
You can find all modify VM arguments under Commands overview section in VBoxManage documentation.
I am using Vagrant 2.2.14 and VirtualBox 6.1.22
Related
I am running on Pop!_OS so for most things this is likely an aquivalent of Ubuntu.
KeepassXC is installed and the SSH-Agent is enabled.
There is a keyphrase configured with a key and it works just like a charm when I start keepassxc from the terminal keepassxc log in and then I can see that ssh-add -l lists an additional key. It also vanishes once I close KeePassXC. Perfect!
Now I start keypassXC from the gnome shell, hit the super key, search for keepassXC and log into its vault. Looking at ssh-add -l in the terminal: Nothing. No keys added. 😔
Now I took a look at /usr/share/applications/org.keepassxc.KeePassXC.desktop and changed Terminal=false to true. No, sadly not that easy.
My guess that it has something to do how the gnome shell starts KeePassXC, but can't say for sure what the problem is. Anyone got a clue what that could be or how to take a shot at the problem?
I got the KeepassXC ssh agent working on Ubuntu 16.04.6 with Unity as the window manager.
The issue is that if the SSH_AUTH_SOCK environmental variable is not set before the window manager starts it is not available for programs started in the window manager.
Some distributions have a system for starting programs such as the ssh-agent before the window manager. On my distro I found that /etc/X11/Xsession.d/90x11-common_ssh-agent was starting ssh-agent. See this comment on a user help issue for KeepassXC for more information.
However I also found that GNOME Keyring was starting an ssh agent of its own. I had to disable this in the startup applications. I also checked that no shells startup scripts (ie. .bashrc .bash_profile .profile .config/fish/config.fish were trying to start the ssh-agent, as doing so would replace the one started before the window manager.
An interesting side note, the ttys, that you get to with Ctrl+Alt+F1, Ctrl+AltF2, etc., also do not have the SSH_AUTH_SOCK environmental variable set as they start up before the window manager. If you need it here you can add code to find and set the SSH_AUTH_SOCK. For the fish shell I added the following to ~/.config/fish/config.fish:
# Set SSH_AUTH_SOCK if not set.
if test -z "$SSH_AUTH_SOCK";
set -gx SSH_AUTH_SOCK (find /tmp/ -path "/tmp/ssh-*/agent.*" 2>/dev/null)
end
I also found that in the upcoming 2.6.0 release of KeepassXC (targeted for 3. April 2020), there will be an added settings to allow overriding, or settings the value to use for SSH_AUTH_SOCK. However as this changes each time ssh-agent starts you will either need to keep changing it or set-up a link that would point to the current sock.
I am on a Windows7 machine and I'm trying to get graphic view on the centOS machine to be displayed on my current screen. When typing xclock, gedit... in terminal, I am getting the following error
-bash: xclock: command not found
and This the result of # vi /etc/ssh/sshd_config command
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
#tewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
Also Xming is running on server:0.0 and I turned X11 forwarding on on putty
So what's the problem ?
sudo yum install xorg-x11-apps
Should cover it!
Do you have an .Xauthority file in your home directory?
I've recently found the answer for my issue, which might be similar to yours. I've seen quite a few open questions about this topic without resolution. You may have a few more things to work through, but SELinux settings ended up being my final hurdle. This among many other steps are covered here: ssh X11 forwarding won't work
That aside, you may need to change the Xming settings to match the default DisplayOffset of 10 for Centos. And after any changes to sshd_config, you'll need to restart the service via
/etc/init.d/sshd restart
I would like to emphasize that my situation is a non-critical operation within a (hopefully!) securely-managed intranet. I would NOT suggest turning off SELinux at work, or at home if you're hoping to open ports or configure VPN for your home network. Please consider: http://securityblog.org/2006/05/21/software-not-working-disable-selinux/
I have a situation where I would like to add shared folders to a running Vagrant box (Ubuntu guest) provided by VirtualBox.
According to the docs, these "Synced Folders" should be defined in the configuration file like so:
config.vm.synced_folder "/mnt/plugdrive15", "/synced/plugdrive15"
But what if I need to share directories that are new on my host? I have this often and I cannot predict their names, so I cannot pre-write them beforehand in the configuration file. I want to automate this.
Using VBoxManage sharedfolder add doesn't work, because as soon as you do vagrant up, only the shares specified in the configuration file (and the default vagrant one) are left.
If all else fails (no better solutions), can Vagrantfile parse a configuration file (in which I specify shares right before vagrant up?
You can using virtual box interface, you have a shared folder option in the VM setting and you can add a new folder while the VM is running
[edit]
there is ofc a command line tool associated : http://www.virtualbox.org/manual/ch04.html#sharedfolders
[edit 2]
Setting the vm name is a provider specific operation, so VBoxManage tool will consider it as well.
config.vm.provider :virtualbox do |vb|
vb.name = "barhost"
end
If you don't specify a name vagrant will generated one, see How to change Vagrant 'default' machine name? for precisions.
While building my own cookbooks I find myself constantly within this cycle:
Change cookbook on my local computer
Upload modified cookbook to chef server
Run chef-client on remote machine
Repeat
Since I am new to chef, I repeat that cycle extremely often, but I find rather cumbersome uploading and downloading so frequently from the chef server.
How experienced chef users ease this cycle? I learnt Chef with the free hosted solution, but I am not sure if I should be better off using just Chef-solo and move back later to the hosted version once I have many servers and more experience with chef.
Is there maybe a workflow where I can quickly try changes to my cookbooks directly on my remote machine while using hosted Chef but without uploading them?
I do all my development locally on my laptop, using Vagrant. When the cookbook is ready, it gets pushed to it's new Git repository home and integrated into my production chef server infrastructure.
The following example runs nginx on a virtualbox image.
Example
Install vagrant plugins (only needs to be done once):
vagrant plugin install vagrant-omnibus
vagrant plugin install vagrant-berkshelf
vagrant plugin install vagrant-chef-zero
Use Berkshelf to generate a new application cookbook.
$ berks cookbook demo
create demo/files/default
create demo/templates/default
create demo/attributes
create demo/definitions
create demo/libraries
create demo/providers
create demo/recipes
create demo/resources
create demo/recipes/default.rb
create demo/metadata.rb
create demo/LICENSE
create demo/README.md
create demo/Berksfile
create demo/Thorfile
create demo/chefignore
create demo/.gitignore
run git init from "./demo"
create demo/Gemfile
create demo/Vagrantfile
Edit the following files (Details below):
Vagrantfile <-- Controls vagrant's operation
metadata.rb <-- List community cookbook dependencies
recipes/default.rb <-- Calls to community cookbook recipes and LWRPs
Running vagrant will startup a virtual machine that is provisioned using chef-client. The chef zero plugin will run a local embedded instance of chef-server. The berkself plugin is used to automatically load the cookbook dependencies.
vagrant up
The following command will rerun chef-client (following edits):
vagrant provision
Finally, the really big advantage of doing development, using local virtualization, is that you can tear everything down and build it again from scratch:
vagrant destroy -f && vagrant up
Vagrantfile
Controls vagrant's operation. In this case I'm only starting a single VM, provisioned using chef-client:
Vagrant.require_plugin "vagrant-omnibus"
Vagrant.require_plugin "vagrant-berkshelf"
Vagrant.require_plugin "vagrant-chef-zero"
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
# Box config
config.vm.box = "saucy64"
config.vm.box_url = "http://cloud-images.ubuntu.com/vagrant/saucy/current/saucy-server-cloudimg-amd64-vagrant-disk1.box"
# Virtualbox config
config.vm.provider :virtualbox do |vb|
vb.customize ["modifyvm", :id, "--memory", 1024]
end
# Networking config
config.vm.network "private_network", ip: "10.0.0.10"
# Plugin config
config.omnibus.chef_version = :latest
config.chef_zero.enabled = true
config.berkshelf.enabled = true
# Chef config
config.vm.provision :chef_client do |chef|
chef.add_recipe "demo"
end
end
The omnibus plugin is responsible for installing the desired version of chef. The Berkshelf plugin will download cookbook dependencies and when combined with chef-zero will upload cookbooks during each provision run.
metadata.rb
Add nginx as a cookbook dependency:
name 'demo'
maintainer 'YOUR_NAME'
maintainer_email 'YOUR_EMAIL'
license 'All rights reserved'
description 'Installs/Configures demo'
long_description IO.read(File.join(File.dirname(__FILE__), 'README.md'))
version '0.1.0'
depends "nginx"
The Berksfile is preconfigured to load the cookbook dependencies, listed in the metadata file, from the community cookbook repository.
site :opscode
metadata
recipes/default.rb
Run the default nginx recipe
#
# Cookbook Name:: demo
# Recipe:: default
#
# Copyright (C) 2014 YOUR_NAME
#
# All rights reserved - Do Not Redistribute
#
include_recipe "nginx"
I go through that loop most of the time during my testings. But I also use Chef solo when I need to try several minor changes in a recipe. If you have a test machine with a local copy of your chef repo then you can try making changes there and running chef solo to see the results. This way there's no uploading.
UPDATE (5 Feb, 2014) : This error comes up when machine is restarted without proper shutdown
I am trying to install EdX's open source Learning Management System, through their development vagrant box on a remote machine. However, I get an error related to virtual machine GUI. Is there anything that can be done via CLI/ssh ?
This is the exact error.
The guest machine entered an invalid state while waiting for it
to boot. Valid states are 'starting, running'. The machine is in the
'poweroff' state. Please verify everything is configured
properly and try again.
If the provider you're using has a GUI that comes with it,
it is often helpful to open that and watch the machine, since the
GUI often has more helpful error messages than Vagrant can retrieve.
For example, if you're using VirtualBox, run `vagrant up` while the
VirtualBox GUI is open.
Below are the contents of VagrantFile
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|
config.vm.box = "precise32"
config.vm.box_url = "http://files.vagrantup.com/precise32.box"
config.vm.network :forwarded_port, guest: 8000, host: 9000
config.vm.network :forwarded_port, guest: 8001, host: 9001
# Create a private network, which allows host-only access to the machine
# using a specific IP.
config.vm.network :private_network, ip: "192.168.20.40"
nfs_setting = RUBY_PLATFORM =~ /darwin/ || RUBY_PLATFORM =~ /linux/
config.vm.synced_folder ".", "/opt/edx/edx-platform", id: "vagrant-root", :nfs => nfs_setting
# Make it so that network access from the vagrant guest is able to
# use SSH private keys that are present on the host without copying
# them into the VM.
config.ssh.forward_agent = true
config.vm.provider :virtualbox do |vb|
# Use VBoxManage to customize the VM. For example to change memory:
vb.customize ["modifyvm", :id, "--memory", "2048"]
# This setting makes it so that network access from inside the vagrant guest
# is able to resolve DNS using the hosts VPN connection.
vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
end
config.vm.provision :shell, :path => "scripts/install-acceptance-req.sh"
config.vm.provision :shell, :path => "scripts/vagrant-provisioning.sh"
end
No, there's not much you can do/diagnose using CLI or Ssh at this stage, because the VM fails to initialize properly and is not in a "working" state.
You should follow the advice contained in the error message.
Destroy your current VM:
vagrant destroy
then open VirtualBox GUI, and restart the Vagrant setup with :
vagrant up
You can then watch in the VM Console/Window (from Virtualbox GUI) what fails and prevents the setup from running.
An alternative way to start the VM with a console GUI would be to modify your Vagrantfile:
# You will find this line in the Vagrantfile
Vagrant.configure("2") do |config|
#Add this directive
config.vm.provider "virtualbox" do |v|
v.gui = true
end
end
(destroy your existing and failing VM with vagrant destroyand then run vagrant up)
If the remote machine (where VirtualBox runs) is a Unix box accessed using SSH, you may be able to export the GUI to your local machine using the -Xoption when SSHing to it. See this answer for more details about ssh -X
This message occured with my environment because 2 things:
1 - If your VirtualBox Software GUI have is closed, just open it.
Ps.: Try vagrant destroy then vagrant up again
2 - If the problem persist, just update your VirtualBox GUI.
VirtualBox Downloads
Let me know if it's done.