Page tree
Skip to end of metadata
Go to start of metadata

Here is a list of common (and some uncommon) issues that can get in the way of a quick and easy XNAT deployment via Vagrant in Windows. 

Before You Start

1: Make sure your versions of Vagrant and VirtualBox are up to date. 

As of the workshop, Vagrant should be updated to version 1.8.1, and VirtualBox should be updated to version 5.0.20 r106931. 

 

2: Use Cygwin or Git Bash in place of the default Windows command line terminal

Important!

Make sure you are running your command line app (Cygwin, Git Bash, MobaXTerm etc) as an administrator! (See Sanket's comment thread below.)

For whatever reason, the default command line terminal in Windows does not play well with Vagrant and VirtualBox, even when run as an administrator. Fortunately, there are third party command line tools that are free to use that do. We recommend using Cygwin, which can be downloaded and installed as a stand-alone app, or Git Bash, which comes with Git (which you will need to install in just a moment here). If you want a more full-featured GUI wrapped around your command line app, you can use MobaXterm – however, there is a workaround in MobaXterm that must be followed to enable Vagrant to SSH into your VirtualBox VM. 

Notes on Installing Cygwin

If you're using Cygwin, there are several dialogs that must be configured. Make sure your installer is set to pull down every available package. The best way to do this is to select "Install From Internet" as your installation method, then select the topmost mirror (http://cygwin.mirror.constant.com) as your download source. This should ensure that all required packages (OpenSSH in particular) are included.

When you run Cygwin, it creates a new (empty) home directory. It is simple, if a bit unintuitive, to navigate out to your file system. Enter the following to navigate to your C: drive. 

Cygwin Terminal
USER@COMPUTERNAME ~
$ cd C:

You can also create a shortcut within Cygwin to your Repos directory by entering something like the following, substituting your actual directory path for "/path/to/your/Repos".

Cygwin Terminal
 $ ln -s C:/path/to/your/Repos /repos

 

Before You Clone The xnat-vagrant Repo

3: Download Git and use it to clone the xnat-vagrant repository instead of SourceTree or any other GUI tools

There is a '.gitattributes' file included in the xnat-vagrant repo that should force UNIX line endings. If you would prefer to set this globally for all Git repos, during installation of Git, select the option to "Checkout as-is, commit Unix-style Line Endings."

You can download Git here: https://git-scm.com/downloads

Downloading Git directly and using it to clone repos from Github will help you get around pernicious differences between Unix-style and Windows-style line-endings in code. This is particularly bad in code that is downloaded to a Windows machine, but is meant to be run inside of a Linux VM.  

SourceTree can be particularly troublesome, as it comes with its own pre-downloaded and pre-configured version of Git, and its default configuration gets these line-endings wrong. If you start seeing problems when running "setup.sh" that look like the following, then you need to convert the line endings of affected files (Notepad++ can do this easily), or you can delete your repo and re-clone it (make sure you back up any local configuration files first).

Common Errors With Windows-style Line Endings
 $ sh setup.sh
setup.sh: line 2: $'\r': command not found
setup.sh: line 4: $'\r': command not found
setup.sh: line 6: $'\r': command not found
setup.sh: line 36: syntax error: unexpected end of file

Cloning the xnat-vagrant repo with git is simple. Open Cygwin and navigate to your repos directory, then run the following command. The process should take just a few seconds. 

Cygwin Terminal - Git Clone
USER@COMPUTERNAME /repos
$ git clone https://github.com/NrgXnat/xnat-vagrant.git

 

Before You Run setup.sh

4: Make sure your vagrant xnatstack box is up-to-date

First, you'll need to navigate to one of the configuration directories in your newly-downloaded repo. ( xnat-vagrant/configs/xnat is the default.) Then, you'll run the following command: 

Cygwin Terminal
USER@COMPUTERNAME /repos/xnat-vagrant/configs/xnat
$ vagrant box add nrgxnat/xnatstack-ubuntu1404-docker --provider virtualbox 

If you get an error because you already have a previous version of the xnatstack box installed, you can update it with the following command. 

Cygwin Terminal
USER@COMPUTERNAME /repos/xnat-vagrant/configs/xnat
$ vagrant box update --box nrgxnat/xnatstack-ubuntu1404-docker 

We will be distributing the most up-to-date xnatstack box on a USB drive at the start of the workshop, if you are unable to download and update this rather large file before you arrive.

 

Okay, Try It Now!

From this same config folder, run the setup.sh script in your xterminal. Then sit back and have a nice cup of coffee for the next five minutes or so as your XNAT builds for you. 

Cygwin Terminal
USER@COMPUTERNAME /repos/xnat-vagrant/configs/xnat
$ sh setup.sh 

 

Other Uncommon Issues

Do you need to allow virtualization in BIOS? 

In some Windows machines with Intel processors, virtualization may be turned off by default. This can be changed in BIOS. Here's a quick tutorial: http://www.howtogeek.com/213795/how-to-enable-intel-vt-x-in-your-computers-bios-or-uefi-firmware/

Do you have conflicting versions of Java installed? 

Although Java is not required to run XNAT in a Vagrant VM, if you wish to do XNAT development or perform your own builds on your local desktop, you'll need the Java 8 JDK, and a text editor or IDE like IntelliJ IDEA (recommended) or Eclipse.

Do you have Windows firewall enabled?

You may have trouble getting your vagrant box to run if you have the Windows firewall enabled.  To disable:  http://windows.microsoft.com/en-us/windows/turn-windows-firewall-on-off#turn-windows-firewall-on-off=windows-7.

Hey! My terminal is telling me it can't find vagrant, even though I installed it earlier. What gives?

You will need to add vagrant to your path in order to use it. For either MobaXterm, or Cygwin, you will need to add the vagrant installation location to your path and source your .bashrc file to get it to take effect. You can do this as follows:

In MobaXterm
echo 'export PATH=$PATH:/drives/c/HashiCorp/Vagrant/bin' >> ~/.bashrc
source ~/.bashrc

...or...

In Cygwin
echo 'export PATH=$PATH:/cygdrive/c/HashiCorp/Vagrant/bin' >> ~/.bashrc
source ~/.bashrc

Alternatively, you can simply restart your terminal instead of running the second lines above.

 

  • No labels

43 Comments

  1. I have a lot of uncommon issues.

    So far,

    Problem:

    Bash CodeBlock
    $ vagrant up
    Loading C:/Users/guptess/Documents/XnatWorkshop/VagrantRepos/xnat-vagrant/configs/xnat/config.yaml for Vagrant configuratio       n...
    Bringing machine 'xnat' up with 'virtualbox' provider...
    ==> xnat: Checking if box 'nrgxnat/xnatstack-ubuntu1404-docker' is up to date...
    ==> xnat: Clearing any previously set network interfaces...
    There was an error while executing `VBoxManage`, a CLI used by Vagrant
    for controlling VirtualBox. The command and stderr is shown below.
    Command: ["hostonlyif", "create"]
    Stderr: 0%...
    Progress state: E_FAIL
    VBoxManage.exe: error: Failed to create the host-only adapter
    VBoxManage.exe: error: SetupDiCreateDeviceInfo failed (0x00000005)
    VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component HostNetworkInterfaceWrap, interface IHostNetworkInterfa       ce
    VBoxManage.exe: error: Context: "enum RTEXITCODE __cdecl handleCreate(struct HandlerArg *)" at line 71 of file VBoxManageHo       stonly.cpp

     

    Solution:

    VirtualBox -> Preferences -> Network -> Hostonly Networks -> New

    IPv4 192.168.10.1

    IPv4 Network Mask: 255.255.255.0

     

    Edit the local.yaml file and change the 10.x.x.x IP address  to 192.168.10.x , where x could be your favorite number .

    (Or do it the other way round, not edit the IP in yaml file, just make the Network Adapter IP to be the 10.x address, ending with a 1.

    Run "vagrant up" again.

     

    Then next error:

    Bash CodeBlock
    There was an error while executing `VBoxManage`, a CLI used by Vagrant
    for controlling VirtualBox. The command and stderr is shown below.
    Command: ["startvm", "03872ec4-bee2-4ae5-947a-c10255acdbba", "--type", "headless"]
    Stderr: VBoxManage.exe: error: The virtual machine 'xnat' has terminated unexpectedly during startup with exit code 1 (0x1).  More details may be available in 'C:\Users\guptess\Documents\XnatWorkshop\xnat\Logs\VBoxHardening.log'
    VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MachineWrap, interface IMachine
    Running build provision to build and deploy XNAT on the VM...
    Loading C:/Users/guptess/Documents/XnatWorkshop/VagrantRepos/xnat-vagrant/configs/xnat/config.yaml for Vagrant configuration...
    ==> xnat: VM is not currently running. Please, first bring it up with `vagrant up` then run this command.

    Log File Says

    LogFile

    604.2118: supR3HardenedVmProcessInit: Opening vboxdrv stub...

    604.2118: Error opening VBoxDrvStub:  STATUS_OBJECT_NAME_NOT_FOUND

    604.2118: supR3HardenedWinReadErrorInfoDevice: NtCreateFile -> 0xc0000034

    604.2118: Error -101 in supR3HardenedWinReSpawn! (enmWhat=3)

    604.2118: NtCreateFile(\Device\VBoxDrvStub) failed: 0xc0000034 STATUS_OBJECT_NAME_NOT_FOUND (0 retries)

    Driver is probably stuck stopping/starting. Try 'sc.exe query vboxdrv' to get more information about its state. Rebooting may actually help.

    410.1e28: supR3HardenedWinCheckChild: enmRequest=2 rc=-101 enmWhat=3 supR3HardenedWinReSpawn: NtCreateFile(\Device\VBoxDrvStub) failed: 0xc0000034 STATUS_OBJECT_NAME_NOT_FOUND (0 retries)

     

    Solution: http://superuser.com/questions/851227/virtualbox-4-3-20-stops-working-after-windows-update

     

    Problem 3:  The files aren't getting scp'd to the VM. Permissions Issues. (Using Non-admin user on Windows)

    Bash CodeBlock
    ==> xnat: Attempting graceful shutdown of VM...
    The following SSH command responded with a non-zero exit status.
    Vagrant assumes that this means the command failed!
    shutdown -h now
    Stdout from the command:
    Stderr from the command:
    sudo: no tty present and no askpass program specified
    Running build provision to build and deploy XNAT on the VM...
    Loading C:/Users/guptess/Documents/XnatWorkshop/VagrantRepos/xnat-vagrant/configs/xnat/config.yaml for Vagrant configuration...
    ==> xnat: Running provisioner: build (shell)...
    Failed to upload a file to the guest VM via SCP due to a permissions
    error. This is normally because the SSH user doesn't have permission
    to write to the destination location. Alternately, the user running
    Vagrant on the host machine may not have permission to read the file.
    Source: C:/Users/guptess/AppData/Local/Temp/1/vagrant-shell20160601-4856-14ks2sw.sh
    Dest: /tmp/vagrant-shell

     

    Solution: Unknown . (sad)

    1. Sanket, I'll give you points for uncommonness. It is certainly unusual that you would have to manually add those Host-only network connections to VirtualBox. I just looked in my preferences on my Windows 7 machine, and those are getting set automatically during the configuration process. It's possible you're running into permissions issues. For whatever app you're using to run the setup.sh shell script (i.e. Moba, Cygwin, etc), are you running that app as an administrator? That may help. 

      1. Yeah, not running as an Administrator.

        I am using the work computer, and I recently did a Training Refresher of how not to abuse your right as an admin user on a Government Computer, so was trying to do as much as I could as a normal user.

        I guess it's not meant to be that way. I'll run everything as admin.

    2. Will is Right. Install everything as Admin user and you would not have any issues, like the ones above.

      For those who really want to run as non-admin user - Give the user full read/write permissions "/tmp" directory  on the VM as well as the host side.

      And it all runs perfectly.

      But again, Running as Admin is much must easier.

      1. My user is an admin and I'm running into those issues.

  2. BTW when you install Git, it comes with Mingw .(They call it "Git Bash" ) You probably dont have to install cygwin or Moba.

    But I love MobaXterm.

    1. I'm using Git Bash (MINGW64) and it's working fine - I'd recommend that first for anyone who doesn't already have a bash terminal program installed, since it's an option when installing Git.

  3. Hi all.  I'm getting the following when trying the getting started on vagrant.  Vagrant up seems to work but complains about Guest Additions version.  Then when I try vagrant ssh I get the following errors.  Any thoughts? Thanks.  I'm using Mobaxterm, Windows 7, and running Mobaxterm as an admin.  

     

    [jwestadm.IN-RADY-10848] ➤ vagrant up
    Bringing machine 'default' up with 'virtualbox' provider...
    ==> default: Importing base box 'hashicorp/precise64'...
    ==> default: Matching MAC address for NAT networking...
    ==> default: Checking if box 'hashicorp/precise64' is up to date...
    ==> default: Setting the name of the VM: home_default_1464873945924_14851
    ==> default: Clearing any previously set network interfaces...
    ==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    ==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
    ==> default: Booting VM...
    ==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Remote connection disconnect. Retrying...
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
    ==> default: Machine booted and ready!
    ==> default: Checking for guest additions in VM...
    default: The guest additions on this VM do not match the installed version of
    default: VirtualBox! In most cases this is fine, but in rare cases it can
    default: prevent things such as shared folders from working properly. If you see
    default: shared folder errors, please make sure the guest additions within the
    default: virtual machine match the version of VirtualBox you have installed on
    default: your host and reload your VM.
    default:
    default: Guest Additions Version: 4.2.0
    default: VirtualBox Version: 5.0
    ==> default: Mounting shared folders...
    default: /vagrant => C:/Users/jwestadm/Documents/MobaXterm/home

    ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
    [2016-06-02 09:26.16] ~
    [jwestadm.IN-RADY-10848] ➤ vagrant ssh
    C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/subprocess.rb:127:in `rescue in execute': (216) (Vagrant::Util::Subprocess::LaunchError)
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/subprocess.rb:120:in `execute'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/subprocess.rb:22:in `execute'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/ssh.rb:85:in `exec'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/ssh_exec.rb:39:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/action/check_running.rb:16:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/action/check_created.rb:16:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builder.rb:116:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `block in run'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/busy.rb:19:in `busy'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `run'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:224:in `action_raw'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:199:in `block in action'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:181:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:181:in `block in action'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:185:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:185:in `action'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/commands/ssh/command.rb:59:in `block in execute'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:235:in `block in with_target_vms'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:229:in `each'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:229:in `with_target_vms'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/commands/ssh/command.rb:41:in `execute'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/cli.rb:42:in `execute'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:302:in `cli'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/bin/vagrant:174:in `<main>'

    1. I am having this same problem when I try to run the vagrant from the mobaxterm window.  I just tried using the Git-Bash app that installed when I installed Git.  The vagrant ssh command works in that window. I have no idea why it is working there and not in mobaxterm.

      1. If you want to get it working in MobaXterm, you can use this tip that I stole from our first practical:

        Windows Users

        Assuming you are using MobaXterm as instructed on Part 1 Installing XNAT 'vagrant ssh' will not find the ssh key.

        Substitute {username} for your windows profile directory. Type "echo $USERPROFILE" if you do not know what this is.

        Do this only once:

        cp /drives/c/Users/{username}/.vagrant.d/boxes/nrgxnat-VAGRANTSLASH-xnatstack-ubuntu1404-docker/1.0.1/virtualbox/vagrant_private_key ~/xnat_private_key

         

        Each time you want SSH to your instance type:

        ssh -i ~/xnat_private_key vagrant@10.1.1.170
        1. I followed your advice and I can now connect from the mobaxterm window.  I noticed it says X11 forwarding failed when I connect.  Is that going to be a problem down the road?

          1. Mike, I ran through the Day 1 Session 1 Practical yesterday and had similar SSH issues confound me with MobaXTerm. I eventually gave up and switched back to Cygwin, and it has worked perfectly for me. Git Bash has also worked for folks on our side.

    2. John, this is something going very wrong in Vagrant itself. In this case, you're not even doing anything specific to XNAT, since you're using a standard Vagrant box, hashicorp/precise64. I'd suggest looking on the Vagrant issues site. This search turns up a number of issues with that "(Vagrant::Util::Subprocess::LaunchError)" message. In fact, it looks very similar to this issue: the line numbering is off a bit, but that's probably just changes in the code. What resolved it seemed to be this comment:

      VBoxManage.exe was terminating with an error message since it strangely had only 0 bytes length. It is strange since my SSD works perfectly and I have just recently installed VirtualBox without any errors at all. Thus simply running a repair on my VirtualBox installation fixed the problem for me.

      1. Rick, what I mean is that the "(Vagrant::Util::Subprocess::LaunchError)" error happens in MobaXterm since it can't find your ssh key. Using Chip's tip that I put above worked for me to get ssh working.

    3. Thanks for the help all.  I also tried git bash and that seems to "just work" for the vagrant getting started test.  I'll probably try to get XNAT running now on that as I'm certainly not married to Mobaxterm by means.

      One question I had is, is there a way once I successfully run the setup.sh file to test to make sure things are working correclty?  Sorry if I am missing that in the instructions.

      1. The vagrant makes a host-only network connection with the host. So, if you installed everything successfully, without changing anything, you now have a 10.1.1.170 IP for the VM, that you can access only thorough the host.

        So, from your host, open up a browser and type http://10.1.1.170  and it should lead you to the xnat website. Username and Password, is both 'admin' .

        If you got that , then I guess all tests succeeded (smile) 

        1. Thanks Sanket.  I didn't go through the Practical Day 1 exercise so XNAT is not installed yet, but I did follow that IP and got to a Welcome to nginx page so I think we are good.

          For others having issues still I second the Git-Bash recommendation.  That seemed to work really well for me.  I may try the mobaxterm fix if I'm feeling ambitious.  (smile)

    4. Ok.  Guess I spoke too soon.  My colleague did get an XNAT prompt, but I only get the Welcome to nginx prompt.  I think it is because of the SCP error I am getting that I didn't notice before when running setup.sh.  

      Loading C:/Users/jwestadm/XNAT_workshop/repos/xnat-vagrant/configs/xnat/config.yaml for Vagrant configuration...
      ==> xnat: Running provisioner: build (shell)...
      Failed to upload a file to the guest VM via SCP due to a permissions
      error. This is normally because the SSH user doesn't have permission
      to write to the destination location. Alternately, the user running
      Vagrant on the host machine may not have permission to read the file.

      Source: C:/Users/jwestadm/AppData/Local/Temp/vagrant-shell20160602-3336-vegbzp.sh
      Dest: /tmp/vagrant-shell

      Provisioning completed.

      Not sure what the issue is now as I am running git-bash as an administrator before running the setup.sh.  Any thoughts?

      Thanks.

      -John

      1. Just some more info.  This is definitely an issue with copying files to the VM.  For some reason I have no permissions to copy files to many places on the VM itself.  I proved this by deleting the file it complained about above by su'ing to the vagrant user once on the VM as xnat.  When I did that it got further, but I still ran into a lot of permission errors as the rest ran.

        I'm not sure what the issue is.  EDIT:  My only guess is that the xnat user for some reason does not have permission to overwrite many files on the VM?

        1. Not to confuse things but I have the same behavior as John ( i just get the nginx greeting screen) but I looked thru my setup logs and do not see the scp error that he is seeing.   I have done a complete restart - deleting everything - several times and still end up with a running system with no xnat screen and no scp error messages.  I am running as admin and using git bash (mingw64).

          1. Mike, Are you and John walking through Rick's 7-step Day 1 practical instructions, or are you simply running setup.sh from the xnat-vagrant repo?

            The process of deploying the XNAT can be silent and mysterious. One thing that can help debug that last step is to SSH into your vagrant, if you haven't already, and run the following command: 

            tail -f /var/log/tomcat7/catalina.out

             

            I restarted an older instance of my Vagrant VM that I had set up two days ago, and ran that command once the vagrant instance was up. Here is what I saw:

            INFO: Starting service Catalina
            Jun 02, 2016 6:40:39 PM org.apache.catalina.core.StandardEngine startInternal
            INFO: Starting Servlet Engine: Apache Tomcat/7.0.52 (Ubuntu)
            Jun 02, 2016 6:40:39 PM org.apache.catalina.startup.HostConfig deployDescriptor
            INFO: Deploying configuration descriptor /etc/tomcat7/Catalina/localhost/host-manager.xml
            Jun 02, 2016 6:40:40 PM org.apache.catalina.startup.HostConfig deployDescriptor
            INFO: Deploying configuration descriptor /etc/tomcat7/Catalina/localhost/manager.xml
            Jun 02, 2016 6:40:40 PM org.apache.catalina.startup.HostConfig deployWAR
            INFO: Deploying web application archive /var/lib/tomcat7/webapps/ROOT.war
            SOURCE: /var/lib/tomcat7/webapps/ROOT/
            Database up to date.
            Jun 02, 2016 6:42:22 PM org.apache.catalina.startup.HostConfig deployDirectory
            INFO: Deploying web application directory /var/lib/tomcat7/webapps/default
            Jun 02, 2016 6:42:23 PM org.apache.coyote.AbstractProtocol start
            INFO: Starting ProtocolHandler ["http-bio-8080"]
            Jun 02, 2016 6:42:23 PM org.apache.catalina.startup.Catalina start
            INFO: Server startup in 104332 ms
            1. Well I have got the XNAT web interface working now but I did not do anything really different than I had been doing.  I have only been trying to install the vagrant vm and run setup.sh.   I have been deleting and cleaning up the vagrant repo and then trying again and after many attempts, it just started to work. I have no explanation -  I followed the instructions you give each time (tho I was starting to memorize them from doing them so many times:) ).   I rebooted my computer and after it came back up, the vm and xnat are still working.

            2. Hi Will.

              I'm using setup.sh.  I tried the tail, but got permission denied.  Whenever I boot using vagrant up, I'm automatically logged in as user xnat.  That user seems to not have permission to do very much.  I'm wondering if that is my problem.

              To test though, I check this after su'ing into vagrant user.  THere is no catalina.out for me.

              -John

              1. Did you change the Tomcat user and group in /etc/default/tomcat7.conf and the file/folder ownership via chmod before restarting Tomcat? It sounds like everything’s running as root or some other user, which would cause xnat to not be able to view or edit the file.

                Try running this:

                $ ps aux | fgrep org.apache.catalina.startup.Bootstrap | fgrep -v fgrep | cut -f 1 -d " "
                xnat
                $ xnat@xnatdev:/var/lib/tomcat7/webapps$ ls -ld /var/log/tomcat7/
                drwxr-x--- 2 xnat xnat 4096 Jun 2 19:53 /var/log/tomcat7/

                The response to the first command, in this case xnat, should be the same as the user and group in the second command.

                1. Hi Rick.

                  From what I can tell, tomcat hasn't even started.  Also, I have a file tomcat7 in /etc/default but not tomcat7.conf.  I'm pretty sure some of the commands running through the setup.sh failed and the XNAT installation and configuration are incomplete, but I'm not sure what parts.

                  -John

                  1. Also, the tomcat7 file I found has tomcat7 as the user and group.  However, I cannot change it as you need to be root to edit the file.  Also, is this something we were supposed to do ahead of the setup.sh run?  I think I missed that.

                    1. Okay.  I tried changing some things and it definitely got further.  I think for some strange reason the setup.sh is not working for me correctly.  I'll see if I can try the steps i the Practical Session as doing some of that seemed to help.  However, if I don't get the time I'll just install with everyone else at the session on Monday. Thanks for all the info!

                      1. Yes, /etc/default/tomcat7. On CentOS it's /etc/tomcat7/tomcat7.conf. I get confused sometimes (smile)

                        All setup.sh does in the xnat-vagrant project is launch vagrant a few times (for technical reasons involving the way we're using YAML files, setting the vagrant user, and setting up the file sharing folders, we can't just do it once). All of the work creating the user, setting the Tomcat user, setting file and folder ownership, and setting up the war and pipeline engine are done by the provisioning scripts located in the scripts folder of the xnat-vagrant project.

                        If something's going wrong in that process, that would be interesting. Developers on the XNAT team are using that Vagrant project a lot and we haven't seen any issues where things are crashing that hard.

                        Can you try destroying your current VM, making sure you have the latest code from that xnat-vagrant repo, and running setup.sh again and see if your VM is nerfed again? If so, we'll probably want to get the full debug output from the build process to see if we can figure out what's failing in there.

                      2. I meant to add as well...

                        It's a good idea to go through the practical session, although you can wait for Monday afternoon as well. The point of the practical is to learn the specific steps required to get the VM configured for XNAT. The xnat-vagrant project does all that stuff for you (or at least is supposed to do all that stuff for you) so you just end up with a working XNAT at the end.

                        1. I can understand that.  I'll see what I can do.  Part of the problem is I'm trying to do this in between getting other things done since I'm away next week.  I do want to learn about the install process as although we have a running instance of XNAT working here, it's good to know what it takes to do it.  Also, our folks here are setting up XNAT in somewhat different fashion (using RedHat, having an Apache front end for SSL) due to University restrictions so learning some of the ins and outs may help them as well.  I'm expecting them to give me some questions on SSL issues they've had that I hope to discuss with you all among other things we are interested in.  Looking forward to connecting with all next week!

                          At the very least I'll take one last attempt at the setup.sh and see where I get.  For what you want me to try there, I should do within git-bash:

                          1)got to xnat folder under repos/xnat-vagrant/configs/xnat

                          2)Run vagrant destroy

                          3)Rerun setup.sh

                          Once that is done is there a debug file generated I could send you guys?

                          Thanks again.

                          1. Vagrant is not great about making it easy to capture the debug output. Basically you can just do:

                            setup.sh > output.log

                            Which will be super annoying because you won't be able to see what it's doing, so you should actually do something like this:

                            setup.sh | tee output.log

                            You can also set the logging level:

                            export VAGRANT_LOG=info
                            setup.sh | tee output.log

                            That should give you a pretty verbose level of info.

      2. Just an extension.  Looks like the clean shutdown attempt is not working either?

        ==> xnat: Attempting graceful shutdown of VM...
        The following SSH command responded with a non-zero exit status.
        Vagrant assumes that this means the command failed!

        shutdown -h now

        Stdout from the command:

         

        Stderr from the command:

        sudo: no tty present and no askpass program specified

        Running build provision to build and deploy XNAT on the VM...

        Loading C:/Users/jwestadm/XNAT_workshop/repos/xnat-vagrant/configs/xnat/config.yaml for Vagrant configuration...
        ==> xnat: Running provisioner: build (shell)...
        Failed to upload a file to the guest VM via SCP due to a permissions
        error. This is normally because the SSH user doesn't have permission
        to write to the destination location. Alternately, the user running
        Vagrant on the host machine may not have permission to read the file.

        Source: C:/Users/jwestadm/AppData/Local/Temp/vagrant-shell20160602-3884-1hpc56n.sh
        Dest: /tmp/vagrant-shell

        Provisioning completed.

        1. I used to have this same problem. It was a permissions problem. I installed everything as admin user, and things got very smooth and straightforward after that.

          1. Thanks Sanket.  Yep, I installed everything as a user with admin privileges.  If you meant I should install everything as the user "adminstrator" though I unfortunately cannot do that as this is a work system and I don't have the permission to run as that user.

            1. There's actually an important distinction between working as a user with admin privileges, and actually running a specific app as an administrator. It does not require logging in as someone else... but it does mean that you deliberately right-click on the app you want to run, and select "Run As Administrator" from the contextual menu that pops up.

              1. Hi Will. Yes I've been doing that, though I do get prompted to put in a user name and password for an account that has those privileges. Do you think logging in as an administrative account and then running as an administrator is necessary? Right now I'm logged in as my normal account and then run as administrator and input the username and password for an admin account.
                1. Hmm. That should be all you need to do, at least in my experience. 

                  1. My experience as well. I'm going to unistall vagrant, virtualbox, and git and start from scratch to see if that helps.
                    1. Painful process, but I've had to do it in the past myself. Also, it can be helpful to manually delete any fragments of VMs from the VirtualBox VMs folder that gets created at the root of your user account. Uninstalling VirtualBox normally doesn't do that cleanup for you. 

                      1. Will do. Thanks Will.
                      2. Well, I got further after all the reinstalling but now have the following error:

                        ==> xnat: Starting Tomcat...
                        ==> xnat: Tomcat 7 is running, restarting.
                        ==> xnat: * Starting Tomcat servlet engine tomcat7
                        ==> xnat: ...done.
                        ==> xnat: Did not find requested token in Tomcat 7 startup log: ^INFO: Server startup in. The last lines in the log are:
                        ==> xnat: OpenJDK 64-Bit Server VM warning: Using incremental CMS is deprecated and will likely be removed in a future release
                        ==> xnat: Listening for transport dt_socket at address: 8000
                        ==> xnat: Jun 03, 2016 10:03:02 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
                        ==> xnat: WARNING: Problem with directory [/usr/share/tomcat7/common/classes], exists: [false], isDirectory: [false], canRead: [false]
                        ==> xnat: Jun 03, 2016 10:03:02 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
                        ==> xnat: WARNING: Problem with directory [/usr/share/tomcat7/common], exists: [false], isDirectory: [false], canRead: [false]
                        ==> xnat: Jun 03, 2016 10:03:03 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
                        ==> xnat: WARNING: Problem with directory [/usr/share/tomcat7/server/classes], exists: [false], isDirectory: [false], canRead: [false]
                        ==> xnat: Jun 03, 2016 10:03:03 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
                        ==> xnat: WARNING: Problem with directory [/usr/share/tomcat7/server], exists: [false], isDirectory: [false], canRead: [false]
                        ==> xnat: Jun 03, 2016 10:03:03 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
                        ==> xnat: WARNING: Problem with directory [/usr/share/tomcat7/shared/classes], exists: [false], isDirectory: [false], canRead: [false]
                        ==> xnat: Jun 03, 2016 10:03:03 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
                        ==> xnat: WARNING: Problem with directory [/usr/share/tomcat7/shared], exists: [false], isDirectory: [false], canRead: [false]
                        ==> xnat: Jun 03, 2016 10:03:06 PM org.apache.coyote.AbstractProtocol init
                        ==> xnat: INFO: Initializing ProtocolHandler ["http-bio-8080"]
                        ==> xnat: Jun 03, 2016 10:03:06 PM org.apache.catalina.startup.Catalina load
                        ==> xnat: INFO: Initialization processed in 2792 ms
                        ==> xnat: Jun 03, 2016 10:03:06 PM org.apache.catalina.core.StandardService startInternal
                        ==> xnat: INFO: Starting service Catalina
                        ==> xnat: Jun 03, 2016 10:03:06 PM org.apache.catalina.core.StandardEngine startInternal
                        ==> xnat: INFO: Starting Servlet Engine: Apache Tomcat/7.0.52 (Ubuntu)
                        ==> xnat: Jun 03, 2016 10:03:06 PM org.apache.catalina.startup.HostConfig deployDescriptor
                        ==> xnat: INFO: Deploying configuration descriptor /etc/tomcat7/Catalina/localhost/host-manager.xml
                        ==> xnat: Jun 03, 2016 10:03:08 PM org.apache.catalina.startup.HostConfig deployDescriptor
                        ==> xnat: INFO: Deploying configuration descriptor /etc/tomcat7/Catalina/localhost/manager.xml
                        ==> xnat: Jun 03, 2016 10:03:08 PM org.apache.catalina.startup.HostConfig deployWAR
                        ==> xnat: INFO: Deploying web application archive /var/lib/tomcat7/webapps/ROOT.war
                        ==> xnat: SOURCE: /var/lib/tomcat7/webapps/ROOT/
                        ==> xnat: The application does not appear to have started properly. Status code: 124
                        ==> xnat: The last lines in the log are:
                        ==> xnat: OpenJDK 64-Bit Server VM warning: Using incremental CMS is deprecated and will likely be removed in a future release
                        ==> xnat: Listening for transport dt_socket at address: 8000
                        ==> xnat: Jun 03, 2016 10:03:02 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
                        ==> xnat: WARNING: Problem with directory [/usr/share/tomcat7/common/classes], exists: [false], isDirectory: [false], canRead: [false]
                        ==> xnat: Jun 03, 2016 10:03:02 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
                        ==> xnat: WARNING: Problem with directory [/usr/share/tomcat7/common], exists: [false], isDirectory: [false], canRead: [false]
                        ==> xnat: Jun 03, 2016 10:03:03 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
                        ==> xnat: WARNING: Problem with directory [/usr/share/tomcat7/server/classes], exists: [false], isDirectory: [false], canRead: [false]
                        ==> xnat: Jun 03, 2016 10:03:03 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
                        ==> xnat: WARNING: Problem with directory [/usr/share/tomcat7/server], exists: [false], isDirectory: [false], canRead: [false]
                        ==> xnat: Jun 03, 2016 10:03:03 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
                        ==> xnat: WARNING: Problem with directory [/usr/share/tomcat7/shared/classes], exists: [false], isDirectory: [false], canRead: [false]
                        ==> xnat: Jun 03, 2016 10:03:03 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
                        ==> xnat: WARNING: Problem with directory [/usr/share/tomcat7/shared], exists: [false], isDirectory: [false], canRead: [false]
                        ==> xnat: Jun 03, 2016 10:03:06 PM org.apache.coyote.AbstractProtocol init
                        ==> xnat: INFO: Initializing ProtocolHandler ["http-bio-8080"]
                        ==> xnat: Jun 03, 2016 10:03:06 PM org.apache.catalina.startup.Catalina load
                        ==> xnat: INFO: Initialization processed in 2792 ms
                        ==> xnat: Jun 03, 2016 10:03:06 PM org.apache.catalina.core.StandardService startInternal
                        ==> xnat: INFO: Starting service Catalina
                        ==> xnat: Jun 03, 2016 10:03:06 PM org.apache.catalina.core.StandardEngine startInternal
                        ==> xnat: INFO: Starting Servlet Engine: Apache Tomcat/7.0.52 (Ubuntu)
                        ==> xnat: Jun 03, 2016 10:03:06 PM org.apache.catalina.startup.HostConfig deployDescriptor
                        ==> xnat: INFO: Deploying configuration descriptor /etc/tomcat7/Catalina/localhost/host-manager.xml
                        ==> xnat: Jun 03, 2016 10:03:08 PM org.apache.catalina.startup.HostConfig deployDescriptor
                        ==> xnat: INFO: Deploying configuration descriptor /etc/tomcat7/Catalina/localhost/manager.xml
                        ==> xnat: Jun 03, 2016 10:03:08 PM org.apache.catalina.startup.HostConfig deployWAR
                        ==> xnat: INFO: Deploying web application archive /var/lib/tomcat7/webapps/ROOT.war
                        ==> xnat: SOURCE: /var/lib/tomcat7/webapps/ROOT/
                        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.

                        Provisioning completed.

                        Not sure what is going on there.  Sorry I can't provide more, but I'll try to help debug at the Workshop.

                        1. If you have time/are willing to, I would recommend trying the process again while directly logged in as a user with admin status. I can't guarantee it, but that might make it work.

                          1. Unfortunately, that's what I was doing. It's ok. I have a tendency to have the weird problems.