Setting up enterprise software can be complicated, especially considering all the unknown variables that can exist in different operating systems and with software installed on that operating system. At xTuple, we've determined the best way to ensure a successful and consistent setup is to make sure every installation is configured the same way, regardless of the local operating system. The easiest way to provide an isolated, reproducible “sandbox” for software development is through the creation of a virtual environment. Virtualization software, such as Oracle’s open-source VirtualBox, allow users to host “guest” operating systems within a virtual machine on their native operating system. This means even Windows and Mac users can run an instance of Ubuntu Linux on their machine. Standardizing on a single environment can prevent many software problems by eliminating operating system inconsistencies. Project-specific versions of development tools can also then be installed without the concern of dependency conflicts, or contaminating any installations on the the native Operating System, because it is truly an isolated environment.

Although creating and maintaining virtual environments is relatively straightforward, provisioning more complex software projects can make the process much more complicated. Even the most systematic processes involving installation scripts and detailed documentation can still leave some room for small inconsistencies in setup and require more work overall. The solution to providing a process for creating an effortless virtual development environment, and that which has been adopted by the xTuple development team, is Vagrant.

Vagrant is an open-source project that acts as a “wrapper” for virtualization software like VirtualBox. Vagrant can create, configure, provision, and destroy virtual machines with the use of its own terminal commands. Not only does this simplify the configuration of virtual environments, but it make it so that the user never has to access VirtualBox directly. Vagrant also manages shared folders so that files edited on the native operating system are then automatically synchronized to the location on the virtual machine. This allows developers to use Sublime Text on OSX or Visual Studio on Windows 7 and immediately see their changes inside of the virtual machine running Ubuntu 12.04.

Using Vagrant for the first time is as simple as placing the Vagrantfile, the configuration file which describes how a virtual environment should be set up, in a folder and using the one command, “vagrant up.” We have standardized our development environment on the 64-bit Ubuntu 12.04 operating system and have built install scripts and to set up the entire development environment. In order to use Vagrant to manage the creation of this required environment, we also created a Vagrantfile in a dedicated public Github repository that contains the correct Ubuntu machine image and the path of the provisioning scripts for the virtual machine. Now all developers who contribute to the project can use this same Vagrantfile and thus create identical development environments, containing identical software configurations. Regardless of their host operating system, this process allows them to create a development environment and begin coding in the time it would normally take to read through the environment setup documentation.

I need a pointer on what else needs to be done in order to bring the 4.3.0 DEMO database into the Vagrant environment.

1st off: I moved the DEMO database in the Vagrant PostgreSQL with no problems. The 'proof' that I did so is that I can fire up the xTuple QT Desktop client and access the DEMO database within the Vagrant environment (IP: 192.168.10.33).

2nd: I ran build_app.js successfully.

3rd: I then fired up the web client to login. I now have two database choices on the login dropdown. The choices are DEV and DEMO. I select Demo

4th: the xTuple web client properly fires up and shows me (at the top/left of the screen) that I am ADMIN in the DEMO database but.....there are no menu choices running down the left hand panel. (See Linked Image: https://www.dropbox.com/s/homhdq7ld5mg42r/Vagrant_Demo_Issue.png).

What am I doing wrong here?

Thanks much!

Adding another database

You may want to add other xTuple databases to your environment. To do this first create your database on PostgreSQL and restore a copy of the xTuple database you are interested in using with the PostgreSQL administration utility of your choice.

Next edit the config.js file in the node-datasource directory of your repository by adding the name of the database you want to add to the "databases" array property in the file.

Re-run the build routine from the scripts directory. It will be faster if you only run it against your new database:

./scripts/build_app.js -c /path/to/config.js -d dbname

Stop and restart your node service. Your new database should now be available. Be advised the first thing you will need to do is log into your new database as the admin, grant yourself all available extensions, then refresh the application.

There is also a nice one line technique to drop and restore a database in one step with the application builder like this:

You need to go to setup > user accounts, select the user account, and grant that user access to all the applicable extensions you want them to have. That user will need to logout and back in again to refresh with the new extension permissions.

You shouldn't have to change anything to see your local application on a mobile device. Your Vagrantfile has port-forwarding turned on by default, so you can reach the application from the host by going to localhost:8888, or from a mobile device on the same network by going to [your_host_computer_ip]:8888.

The default password to your virtual machine is "vagrant." Vagrant has many built-in commands that are designed to replace the need to open the VM from VirtualBox. Whenever you want to boot it up, just use "vagrant up" from the Administrator command prompt, and "vagrant ssh" to access the shell. When you want to reboot or shutdown, you can use "vagrant reload" or "vagrant halt." The Vagrantfile takes care of many of the VirtualBox configuration settings for you as well.

When you need to upgrade to a new version, we have some instructions here to walk you through getting the latest release.

We've just made a change to the Vagrantfile configuration that should resolve this error. Please get the latest updates for the xtuple-vagrant repository and try "vagrant up" again. Let us know if you need help with the update or have any other installation issues.

We are new to this entire project and have no idea how to do what your post suggests. I'm thinking I need to "somehow" update my forked repository in github and then reclone back to my local drive in order to get the changes you made...but as I said...no clue how to do all that.

It do not work, I have tested twice and it fails all times. After all the installation is done and the machine start Y ssh to it. All that works, I also fixed myself the timeout error but when you run the node main.js if shows an error that can't find backbone

There is a breaking change in the Node Packaged Modules install as of this morning (http://blog.npmjs.org/post/78085451721/npms-self-signed-certificate-is-n...) which is causing this error. We just committed a work-around for this problem, so please try the install again after you have updated your xtuple repository with the latest code. Please also first destroy the incomplete virtual machine by using "vagrant destroy" in the xtuple-vagrant directory. This way, you'll start again with a fresh virtual machine for the install.

I did it 3 more times, removing everything and updating my forked repositories to the last version. All the times I got the same problem with the backbone error.

I am too tired to keep going, I tried 10 times already without a single success. And I still need to edit Vagrantfile to comment (#) the ssh timeout in order to make it work. If I try to run the vagrant up without adding the comment to the vagrantfile it just don't work. But fixing it is easy.

When you're getting the latest code from xtuple, make sure you're getting what is currently on master and not the latest tagged version. After you use "git fetch XTUPLE", just use "git merge XTUPLE/master" without checking out the latest tag. Also, when you run "vagrant up," make sure that you're doing so from a Windows Administrator console.

What happens if you try the link to your Vagrant remote in your browser? The only update that you need from xtuple-vagrant is the removal of the ssh.timeout value, so in the meantime, you can remove that line and then git commit your changes locally. After that, you shouldn't have to make the change again and it will clear up part of the problem you're having.

If you try this again and it still doesn't work, please copy and paste your error message in a comment here so I can keep trying to help you troubleshoot.

I still can't make it work. The backbone error still show up. The installations of the virtual machine reports no errors when if ends, vagrant ssh works fine is just that after changing to node-dataasource and run the node main.js it always answer the same error.

I am attaching the image, John suggest maybe a gotomeeting session to check.

I tried a different way, this time I setup an ubuntu server machine from scratch, I coned the repository as instructions said, I run the install_xtuple.sh with no error return. When I get into the node-datasource and try to run node main.js I got the exact same error about backbone.

So if I get the same result by cloning the xtuple repository with the vagrant virtual machine than coping the xtuple repository with my ubuntu server, I must think is the xtuple repository the problem. Can you test this or can we get in touch to check what is wrong? The only thing I can imagine with my machine is that my virtual box is last version because everything else is coming from the github repositories and all are up to date and also I tried making the copy directly from the xtuple repository to test that is not my repository out of date.

What can it be?

As an additional note I have an old CentOS 6.4 virtual machine that I installed with the old procedure shown in the web page to setup the mobile environment manually. That machine I upgraded to the newest version of mobile client and it run without that error, so I imagine that between that procedure and the new vagrant machine there has been a change to the repository that is creating this problem.

We're still extremely new so forgive me if I'm asking stupid questions;

1. We have successfully brought up the Vagrant/VirtualBox environment.

2. We have successfully launched the Web Client, in the Vagrant/VirtualBox environment and logged into the PostgreSQL xTuple DEV database. All working fine. No problems.

3. We also have a locally installed/deployed xTuple DEMO database, hosted on one of our Mac's, that we successfully logged into with the xTuple DeskTop client. No problems.

4. So, of course, when you're climbing trees you ALWAYS reach for the next branch.....and this 'next' branch seems to be out of my reach;

5. I have been trying, with no success, to do the following; A. Use the Vagrant/VirtualBox web client to log into our locally hosted PostgreSQL xTuple DEMO database B. Use the xTuple desktop client to log into the Vagrant/VirtualBox PostgreSQL xTuple DEV database

I KNOW this is do-able (at least what I've learned so far tells me that this should be possible) but nothing I have done gets it to work.

I'm wondering if it's a PORT conflict issue since the locally hosted PostgreSQL database is listening on Port #5432 and, so is the out-of-the-box Vagrant/VirtualBox PostgreSQL. However I changed the listening port on 1st the Vagrant/VirtualBox system, still no-go, and then changed the listening port on the locally hosted PostgreSQL system, also no-go.

I know I'm doing someting wrong (duh, right?) but for the life of me can't figure it out. I'm sure it'll turn out to be something so simple that it's probably staring me in the face!

HELP! (and thanks!)

FollowUp Question: When we 1st installed the Vagrant/VirtualBox system the web client was correctly listening on 192.168.33.10. We would access the client, via Safari, with; http://192.168.33.10:8888. Today, about a week later, the web client is listening on localhost (127.0.0.1) for some reason. When running the node main.js startup script you actually see the IP address that is being listened to is "0.0.0.0". Not sure what changed between last week and today (except a couple of reboots of the host computer).

You should be able to access the application using http://192.168.33.10:8888 or http://localhost:8888 (port-forwarding is automatically setup on for 8888 and 8443 in the Vagrantfile). The 0.0.0.0 that you're seeing is correct, that's the bind address that is set in the configuration. You can access the dev database running on Vagrant from the xTuple Desktop client on the host by using 192.168.33.10 as the server, port 5432, and dev as the name of the database. Just make sure that you've configured Postgres as John suggested in his comment.

I know, from personal 1st hand experience, that nobody wants to hear the following when providing support; "...but I did all that". None the less.......I did all that.

The postgreSQL database is setup exactly as described in the document referenced by John, including modifying the pg_hba.conf, on the Vagrant/VirtualBox system, with the entry for the computer attempting to access the DEV database via the desktop client. This is actually the document I've used as I setup the Vagrant system.

I wouldn't have posted this request for help if I hadn't already fired up the desktop client and attempted to access the Vagrant/VirtualBox DEV database with a login of; admin, password of admin; server of 192.168.33.10 and port 5432. It will not allow access. The weird part about this is that the message panel that xTuple comes back with refers to an IP address that is NOT in play here; 192.168.33.1 stating that there is no entry in the pg_hba.conf file for this ip address, user/login.

That, though, was the secondary problem. The REAL problem was trying to use the Vagrant/VirtualBox web client to access the DEMO postgreSQL database that we are hosting locally. I haven't found any doc that explains what needs to be setup on the Vagrant/VirtualBox system to allow THAT to occur.

The FUP question, that I posted yesterday, explained that for some reason I can no longer access the Vagrant/VirtualBox web client (via Safari) with: http://192.168.33.10:8888. I it just 'hangs'.

If I try to access with the resolved name that has been added to the etc/hosts file; http://xtuple-vagrant:8888 I get the following

Unknown Host

Description: Unable to locate the server named "xtuple-vagrant (2)" --- the server does not have a DNS entry. Perhaps there is a misspelling in the server name, or the server no longer exists. Double-check the name and try again.

Of course, as I said above, I have the etc/hosts file setup properly to resolve xtuple-vagrant to 192.168.33.10.

Try changing your entry in the pg_hba.conf file for the address it is giving you in that error message: 192.168.33.1. I just tried using the default gateway on my setup locally and that seems to work for me.

I haven't seen the issue that you're having with the static IP address, so I'm still looking into that. Just to be sure, can you verify in your Vagrantfile that this line matches the IP address that you're using?

The best way to use the demo database with the application running in Vagrant is going to be to setup the demo database inside of Vagrant as well. We have some instructions in the wiki here on how best to do that. It's technically possible to talk to a database running on the host machine from inside of the VM, but it won't be properly configured to work with the application so you'll run into problems there.

OK. That makes sense. However our goal here was to use the web client to access a locally hosted postgreSQL xTuple database. In our conference call with Danielle, Wally and John we were told this was possible and that the 'key' was the Vagrant system. Maybe we misunderstood something.

The goal still remains; can the web client be used to access a locally hosted postgreSQL xTuple database? If so.....how?

Also - we resolved one of the above issues; the issue where we could only access the web client via http://localhost:8888 and not via http://xtuple-vagrant:888 or http://192.168.33.10:8888. It turns out we deployed a proxy server over the weekend and the proxy server was interfering with the ip address resolution. Turning off the proxy server resolved THAT issue.

Also - we've finally resolved WHY the desktop client can't login to the Vagrant/VirtualBox DEV database. However now we are getting stopped because the desktop client we are running is 4.2.1 and NOW we aren't being allowed to login to the DEV database because it requires a different version of the xTuple Desktop client. So I have two NEW questions: 1) which version of the xTuple desktop client is req'd for the DEV database and 2) where can I get THAT xTuple desktop client.

If there is an expectation that you can run the web services against a database outside of the environment managed by Vagrant, then that is a miscommunication or misunderstanding. In order for the web services to operate PostgreSQL must be configured with the PLV8 extension installed, which by itself is not a simple task. We have attempted to make it as simple as possible by wrapping the whole thing up in this Vagrant install.

You should, however, be able to access the database running in the VM with a Desktop client, PG Admin or any other client on your host machine. The the pg_hba.conf file is the ticket. We just updated the wiki page concerning this to be more specific: Set the address to 0.0.0.0/0 to allow all connections: