- App Store
Start Developing for the xTuple Mobile Web with One Command
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.
XTUPLE FOR EVALUATION: How to set up xTuple.
- Key Phrases:
Tue, 03/25/2014 - 14:09#1
Vagrant w/DEMO database
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?
Tue, 03/25/2014 - 16:13#2
You need to go to setup >
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.
Wed, 03/26/2014 - 07:29#3
Thanks John. Of course it
Thanks John. Of course it was something simple. It had to be...right? When all else fails.....remember Occam's Razor! :-)
Thu, 02/13/2014 - 17:11#4
how to connect from phone or tablet
This worked great!
(1) What would need to change here to be able to access xTuple from a phone or tablet (or anything other than the host machine) on the same LAN?
(2) What is the procedure to upgrade as new versions come out?
Thu, 02/13/2014 - 19:37#5
Thanks for trying out the
Thanks for trying out the Vagrant install!
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.
Let us know if you have any other issues.
Fri, 02/14/2014 - 08:35#6
Thanks! I was using the VM
Thanks! I was using the VM IP instead of the host IP.
Thu, 02/13/2014 - 17:39#7
A couple of issues: (1) I had
A couple of issues:
(1) I had to reinstall/repair VirtualBox 4.3.6 (windows 7 64 bit) after this as it would not launch.
(2) What is the Ubuntu username/password to log into the VM when you launch it again within VirtualBox?
Tue, 02/25/2014 - 16:36#8
We're just coming on line with xTuple Development. We've been trying to setup the Vagrant development system and keep getting stopped cold with the following message;
Successfully added box "precise64' with provider 'virtualbox'!
There are errors in the configuration of this machine. Please fix
the following errors and try again:
* The following setting shouldn't exist: timeout
We've been following the Vagrant Installation text, to the letter, and every attempt keeps hitting a brick wall at the same point.
Thanks for your help.
Wed, 02/26/2014 - 10:56#9
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.
Wed, 02/26/2014 - 11:14#10
We are new to this entire
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.
Wed, 02/26/2014 - 12:33#11
Never mind! As usual...when in doubt...R.T.F.M.! :-)
Fri, 02/28/2014 - 01:09#12
It do not work
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
I am using a windows 7 64 bits machine.
Fri, 02/28/2014 - 11:46#13
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.
Tue, 03/04/2014 - 01:15#14
I did it 3 more times
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.
I also tried this: git remote add VAGRANT https://github.com/xtuple/xtuple-vagrant.git
I got an error that repository do not exist. I did it on xtuple and xtuple-extensions to fetch latest changes successfully but the vagrant repository was impossible.
I just don't know what else to do except give up setting up on a windows environment and try to setup the virtual machine inside a linux native machine.
Tue, 03/04/2014 - 10:53#15
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.
Fri, 03/14/2014 - 00:49#16
I still can't make it work
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 appreciate your efforts for this.
Mon, 03/17/2014 - 22:58#17
Same error always
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.
Tue, 03/18/2014 - 07:27#18
I would suggest from
I would suggest from dev/xtuple to delete the node_modules folder (rm -rf node_modules) then run 'npm install'. Hopefully there will be no errors and running main.js will work.
Tue, 03/04/2014 - 12:49#19
Web Client / Locally Hosted xTuple database
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).
Tue, 03/04/2014 - 16:57#20
Did you see this section on
Did you see this section on how to configure postgresql?
Tue, 03/04/2014 - 22:54#21
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.
Wed, 03/05/2014 - 10:18#22
I know, from personal 1st
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
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.
It seems that the only way I can access the web client (via safari) is with http://localhost:8888
Bottom Line: I have a few issues going on here ..............
Wed, 03/05/2014 - 11:10#23
Static IP Address
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?
Wed, 03/05/2014 - 10:32#24
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.
Wed, 03/05/2014 - 11:25#25
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.
We're getting closer here....thanks for the help! :-)
Wed, 03/05/2014 - 11:28#26
If there is an expectation
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:
Wed, 03/05/2014 - 11:35#27
That works! Thanks. (also..we figured out that the Vagrant/DEV postgreSQL xTuple database needs the 4.3 desktop client.).