...
The Sandbox is a friendly environment for developers to edit, compile, build, and debug the application. It is specifically not designed to duplicate the runtime configuration of production. For that you have DEV and TEST.
That's not how I do it!
The Sandbox does not try to run the best operating system. It does not put applications in the correct directories. The problem is that no two people have the same opinion about how to arrange a system. The Sandbox provides a good default for the large number of people who don't care, but it allows you to do as much customization as you insist on doing. You can use Ubuntu, Fedora, Centos, Windows, or even Mac as the runtime operating system. No matter what version of Java or JBoss you prefer, you have to run the release that the application uses in production.
A separate copy of the Sandbox may have been archived by the last person who worked with a particular application. If you pick it up and use it as is, then you can get right into development. If you only have a few changes to make, you can be done before you would have had a chance to make any system configurations.
However, if you feel strongly about KDE or Gnome or the version of Eclipse that was released last week, then an alternative is to keep your own personal optimized system disk. Then you only swap the SandboxData disk that contains the application, workspace, and JBoss. Because every SandboxData disk contains the same directories in the same places, the OS disk can have symlinks to the various components that remain valid even when you change disks. It is conventions like this that make the Sandbox a concept and strategy rather than a single image.
Thanks to Java, you can develop CAS on Windows, then run it on Linux without a problem. Therefore the choice of the OS is only an issue if the application requires a particular library or interface that isn't available on specific systems. GSSAPI, for example, behaves differently on Windows and Linux even though it is a standard Java API.
Ubuntu and Red Hat put the same component or application in different directories, and if you go to the original developer you will get an entirely different layout. Different applications at Yale run on different releases of Java, and it makes no sense to change the default version of Java in the system let alone care what directory Java is installed into. So the SanboxData disk contains its own versions of Java. When you start Eclipse, the version of Java can be selected by the eclipse.ini file in the Eclipse directory. Then once Eclipse is running it has one or more Java Runtimes configured both as to version and location on disk. Because the Sandbox developer starts Eclipse and never leaves it, the location and identity of the default Java on the OS disk doesn't matter.
When you work in the Sandbox you work with a "second copy" of Java, JBoss, Tomcat, or Eclipse completely separate from any version of the same system you have installed with a package manager into the OS directories. This means that the Sandbox is independent of any controversy about where things go. No matter where you think applications should normally be installed, the Sandbox puts its stuff someplace else. That means, however, that you can switch from one application to the next seamlessly.
In production, applications run under a Tomcat or JBoss that has been installed as a service and is started (and configured) from /etc or the Windows Registry. In the Sandbox everything is run from Eclipse, and everything is configured in Eclipse and in the Workspace. The Sandbox makes no changes to /etc or the Registry. Of course, this means that JBoss, Tomcat, and the applications all run interactively under the default userid (casdev). Casdev must have write access to any directories used by the application, typically because it has been made the owner of those directories. If you need to verify that things work with normal directory ownership rules, wait until you get to DEV.
It would be great if there was only one set of Sandbox files for all operating systems. Unfortunately, Eclipse tends to automatically insert a disk letter when it configures the path to JAR libraries on Windows. So an Eclipse Workspace has to be reconfigured when you move it between Linux and Windows. In addition, executable programs like java and javac are different on different systems (and different between 32 bit and 64 bit versions of the same system). So the Sandbox has identical directory structures and equivalent configurations, but there is generally a Windows version separate from the Java version.
There may be a different Sandbox for every application, or there may be a Sandbox that combines applications. For example, the Expired Password function runs partly in CAS (on JBoss) and partly in the Netid application (on Tomcat). If you need to test both, then with enough memory you can run two JVMs, but you can also install both JBoss and Tomcat and have both applications in the same Eclipse workspace. Of course, to run both JBoss and Tomcat on the same machine means that only one can be configured to use port 8080 and the other must be configured to a different port number.
Typically applications are debugged without SSL even if they run SSL in production.
Some applications have a custom log4j.xml or Spring configuration XML that references a cache directory or a file path explicitly. In this one type of case it is probably better to arrange the operating system and Sandbox so that the same file path can be used in development and production. Therefore, no matter what version of the OS you use, you will need to make "/var/log/jbossas/standalone" (or R:\var\log\jbossas\standalone in Windows) writable, and maybe owned, by the casdev userid.
Sandbox is not Production
The Sandbox does not have to run at maximum efficiency. It will not be up 24x7 for months, so rock solid reliability and stability are not a requirement. Therefore, you have more flexibility choosing a VM host, Guest OS, Java runtime, and version of JBoss.
For example, while a particular application will be designed to run in a particular version of Java (1.6, 1.7, or 1.8) it doesn't matter for development if you are using OpenJDK or the Sun JVM. At various times in the past, the OpenJDK has a bad reputation for slow memory leaks that are a for applications that run for weeks without being restarted in production. OpenJDK is fine for debugging a program that you restart every few minutes.
To fully exercise every part of an application you may have to install optional libraries in the system. Nominally the Netid application requires the kadmin Kerberos library to run, but it exposes a parameter and if you install it with "kadm5_activation=false" then it doesn't use that library and can even run on Windows. When a particular system service is only marginally important and can be bypassed or mocked out, this is a best practice.
Two "Disks"
The core of the Sandbox is a separate disk image (named "SandboxData") that contains the Java, Eclipse, JBoss, Maven, database drivers, and so on. This disk can be cloned or checkpointed so it can be shared between multiple virtual machines, even with different Linux distributions.
There will generally be a VM and a system disk that comes with a particular Sandbox instance, but it it comes with Fedora and you prefer Ubuntu, then switching the OS generally requires just a small amount of network reconfiguration.
There is a different version of SandboxData for Windows and Linux. Eclipse saves disk letters when it configures directly locations on Windows. Therefore, it is difficult to move the Eclipse workspace between Windows and Linux. It is better to keep the workspace directory for the system you are using but to import new projects into that directory if you want to change the development platform for an application from one OS to the other.
Linux doesn't have disk letters, but there are several different system mount points that have been proposed and replaced through the years for a second disk.
Fedora maintains the original view that Unix is a multi-user operating system and it regards mountable disks as owned by a user (as USB sticks tend to be). So Fedora prefers a very transient mount point and defaults to /run/media/[userid]/SandboxData.
Ubuntu, however, still uses the old model that no matter how many users share the machine, mountable disks are hardware devices like the CD. So it mounts disks as /media/SandboxData.
Of course there are other options, but the fact that two well known distributions make different choices frees us from expecting that there is one right answer to this question. Therefore, the system will put the disk where it wants to, and any further conventions we create will be symlinks to that system mount point.
However, the rule that the Sandbox is absolutely separate from the RPM or apt-get installed versions of the same program would prohibit configuring symlinks so /opt/eclipse points to /media/SandboxData/opt/eclipse. That could collide with the real OS install of Eclipse. So the Sandbox on linux needs a path that works on all systems, and /media/SandboxData seems to be a middle of the road choice. It implies a degree of impermanance (so you can eject one disk and mount a different one if you want to work on a different project) but also a degree of durability (so you can make symlinks to a specific path).
The Sandbox OS may be more current than the production system. Java applications don't care if they run on Windows or Linux, so they clearly don't care about the difference between Centos 7 and Fedora 22. You may find the lastest system features more convenient, or you may prefer the old version of the desktop and hate the changes in the latest version of Gnome.
The SandboxData disk, however, has to make old versions of Java and JBoss available because the applications really do care about those options. If you work on one application at a time, then you may have a SandboxData optimized for just that one application. However, development on CAS sometimes requires changes to Shibboleth and to Netid, and those three applications run on different versions of Java, and while CAS runs on JBoss 6, Shibboleth runs in production on JBoss 5 (although it can run on 6), and Netid requires Tomcat. So you may use a SandboxData disk with all of the versions needed by all of the systems.
The Sandbox system allows to to edit, compile, and debug the program. After debugging, the Sandbox commits source changes back to Subversion. To move those changes even into DEV requires a Jenkins Build job that checks the source out of Subversion, reruns the compile, and stores the JAR or WAR on the Artifactory server. So the only external consequences of the Sandbox development are the source changes in Subversion. Except for that, everything that happens in the Sandbox is private and doesn't matter.
Installation
Conceptually the Sandbox can run on VMWare Player or Hyper-V, but the disk format has to be converted and if you intend to use the supplied OS disks, then their drivers should be updated. Generally speaking, VirtualBox turns out to be the tool everyone points to when they want to convert a virtual hard disk file from one vendor format to another. So you may need to install VirtualBox as a tool even if you want to try to use a different VM host software.
Download and install the current version of Virtualbox from virtualbox.org. Unfortunately, this is a moving target because virtualbox itself is changing and the operating systems it hosts are changing. However, you only need a version that is reasonably stable and has the convenience features you need. It is a hard problem to choose a system for 24x7 production servers with the ability to dynamically migrate them across systems. On desktop machines, it is a hard problem to do 3D video acceleration or play YouTube from the VM. The Sandbox doesn't have any of these problems. It needs to run Eclipse, and that is a fairly simple requirement to meet.
It is possible to put the SandboxData files on your native laptop OS and do without the VM entirely. This is a good choice if you have only one software project that you develop full time. If you have to jump from application to application, then setting up each new application may be too much trouble. So doing the Sandbox on you native laptop is an advanced configuration that you try later, rather than a choice you make initially.
Each Sandbox OS defines a user named "casdev" with admin privileges who is the owner of SandboxData and some other directories on disk. It is an objective that this user have a specific userid number shared on all Unix hosts, so the disk file ownership transfers when the disk is moved from one OS disk to another. If that did not happen, then even though the user is named "casdev" on both systems, the SandboxData disk moved to a new system will appear to be owned by an unknown user and you have to reassign it with the chown command.
Once you have the OS system disk and the SandboxData disk sorted out, there is still a requirement to define the parameters of the VM. You must assign a number of processors, size of memory, type of disk controller, and so on. In VirtualBox this is done with an XML file with an extension of *.vbox.
Virtual Machines are an advanced feature, and people who use them need the ability to specify some advanced options. For example, the host computer can have more than one LAN adapter. One LAN adapter could be connected to the public internet, while the second adapter would be connected to a "lab" network that only includes in one room belonging to your group. When you define a VM, you need to configure its virtual LAN adapter. It could be entirely imaginary and exist only inside your machine, or it could be "connected" to one of the two real LANs. Is it going to be connected to the Internet or to the Lab network? The VirtualBox configuration tool allows you to make the choice.
Now I want to give you a copy of this VM. Your machine may also have two LAN adapters connected to the same two networks, but your machine will not be identical to my original machine. Not only might you have different hardware, but I may be running Windows and you might be running a Mac, so everything has different names. There is no way to create a VirtualBox or any other software that is smart enough on its own to automatically reconfigure the VM. A person is going to have to rename and reconfigure "dangling" devices that on the new machine no longer connect to hardware features that are identical to those on the original machine.
A VirtualBox VM is a directory on disk with an XML configuration file with an extension of *.vbox. You can try to copy the directory from one machine to another, but VirtualBox is not designed to make this easy or reliable. For example, the *.vbox file contains an explicit fully qualified path reference to any *.iso CD/DVD images that were ever used by the machine, even if they are not currently mounted in the drive. Move the VM directory to another computer that does not have an identical *.iso file in the exact same place, and VirtualBox will complain about the VM being broken.
The Sandbox is distributed as a Exported *.ova file. This is an open standard form of zip file that contains both the machine configuration and the disk image. It can be loaded into VirtualBox (or VMWare for that matter) to create the virtual machine. During installation, or any time before you start the VM, you may need to configure features that are potentially dependent on your local machine configuration. VirtualBox has a feature called "Shared Directory" that allows the host operating system to share one of its directories with the VM (like a network share, but implemented without the network). When the distribution was built, the shared directory was "D:\sandbox", but you may want to turn this off (it is a convenience) or change the host directory path, especially if you do not have a D: drive or are not running Windows on your host computer.
You may be asked to reconfigure things that you forgot to change when you start the VM for the first time. For example, on the computer that created the Sandbox there was a specific physical Ethernet adapter with a specific name assigned by Windows. Your computer will also have an Ethernet adapter, but it will have a different name. VirtualBox will ask you when it goes to replace the old name with the local name on your computer. If you only have one LAN adapter it hardly seems necessary, but in theory you could have two LAN adapters and then it would be important to choose the right one.
It is easy to go back and fix things, but do not rush to install the Sandbox image before you have read the rest of these instructions so you know what the configuration means.
casdev
There is one user named "casdev" with admin (sudo) privileges. You login, run Eclipse, and do all your development as this user. The /home/casdev directory holds the Eclipse workspace and all the casual files. Because JBoss is started from Eclipse, it also runs as casdev. Therefore, the JBoss and Eclipse directories are owned by casdev even though they are installed elsewhere in the file system.
The password for user casdev is not particularly secure, since it can only be used by the developer on the host machine. However, it will not be published here. Ask someone for it.
Where
Oracle Java comes in a standard Red Hat distribution format called an "RPM" that contains both the files and instructions where to put them. Oracle puts a JVM in /usr/local/java. Red Hat official RPMs for JBoss are not available without a subscription, and RPMs for Eclipse are typically several releases behind the current verison. So JBoss comes from http://jbossas.jboss.org/downloads.html and Eclipse comes from http://www.eclipse.org/downloads/ and they are unzipped into subdirectories of /opt.
Then ownership of the directories is assigned to the "casdev" user instead of "root". JBoss contains configuration files and it writes to work directories that are part of the single distribution directory tree, and Eclipse has to change itself whenever you add new software. Eclipse and JBoss could have been put in the casdev HOME directory, but putting them in /opt seems cleaner. They are not, after all, part of your normal development workfiles. The Eclipse workspace that you are using goes in the casdev home.
There are a few things that have to go in the same place in the Sandbox and production. For example, the log files should be written to /var/log/jbossas on the Sandbox because that is where they go in production and that specific path has to go into log4j.xml. The JBoss Server configuration in Eclipse is modified to add -Djboss.server.log.dir=... onto the end of the JBoss start command.If you take a strong stand that programmers should all do something in one common way, you almost guarantee that your efforts will be subverted by people who believe that your choice is wrong. The Sandbox is not a single choice but rather a family of almost identically configured mix and match components that almost anyone can live with.
Hypervisor
Oracle Virtualbox is free, powerful, easy to use, and can be installed on all Windows, Mac, and Linux computers. Other options (Hyper-V, Xen, VMWare Player) run on single operating systems so you have to convert VMs from one to the other (and it turns out that Virtualbox is the recommended utility for a lot of the conversions). It is a desktop tool friendly to developers rather than a production server deployment tool like Hyper-V. VMWare has been around longer and goes through more extensive testing before much more infrequent releases, but if a feature breaks when there is a new release of Windows or Ubuntu, then you have to wait a long time for the next release to fix it. Virtualbox has frequent releases as an open source project and adapts more quickly.
Although Virtualbox aspires to be something you could use for production servers in a machine room, it is not yet something one would recommend over an alternative like Hyper-V. However, for simple desktop edit, compile, and debug it is simple, reliable, and convenient. It may be that the drivers for the emulated video card don't support modern features, and that the passthrough of USB 3 hardware devices to the VM has problems. You don't need that stuff to run Eclipse.
Desktop
Originally the Production Services group at Yale tried to convince use to use the same VM in development that they use in production. However, that VM only has the character terminal user interface, and most people these days do not want to write code using only the vi editor. So to use that machine you would have to use Eclipse on another computer, then install onto the VM and remotely debug. It is a possible model, but it turns out that Production Service never provided the tools needed to actually create and maintain accurate versions of their VMs.
It is much simpler to upgrade the VM to include a real desktop and run Eclipse on the VM itself instead of on a separate machine. Given that any user interface is an addition, there was no particular reason to prefer Gnome to KDE to Unity or any of the other choices you make from one Linux distribution to another. Eclipse will work under any Linux "desktop" system. If you feel strongly about it, switch to whichever one you want.
Cutting and pasting text with the "clipboard" function and dragging and dropping files are functions actually performed with the user interface and not the Linux OS. Virtualbox has had a lot of trouble getting drag and drop of files to work across systems, in part because it is different for KDE and Gnome and so on. If you get it working, there is no guarantee that the next release of Linux won't break it again. Even if you accept the default Gnome desktop that comes default with your preferred distribution, if the Gnome drag and drop is broken and the KDE drag and drop works, then you may want to install just the KDE File Management utility (Dolphin). It will drag along 100 megabytes of KDE lib files, but then you have two file managers and can drag and drop files to whichever one works.
Virtual USB Stick
Even if Eclipse is not automatically installed in your distribution, you can find it in the Software tool. It is almost always one or two releases (years) out of date and generally you don't want to run something that old. However, if you do choose to install it, there is some directory where the package manager tool (yum or apt-get) wants to install that particular program. Feel free to use the standard tools to install Eclipse or Java or JBoss where the distribution wants to put them.
The Sandbox comes with its own copy of everything, and it puts that stuff somewhere that no distribution would normally install Java or Eclipse. It puts them where a Linux system mounts CDs and USB Sticks (the /media directory). In that sense, the Sandbox puts all its files on a "virtual USB stick" although actually it looks to the VM like a small additional hard disk. This has two advantages. First, the Sandbox cannot conflict with any OS convention for where stuff is supposed to go. Second, this is a more natural way to arrange things if you want to work with the Sandbox files for Shibboleth, then "eject" the disk with those files and mount the disk with Sandbox files for IIQ.
You may want to move the Eclipse workspace to your real Home directory (or the /home/casdev directory since you login as user "casdev") if you are doing something experimental and don't want to mess up the original workspace in the Sandbox.
This way we avoid the eternal argument between /opt and /usr/local and other places where different people believe stuff should go.
One from Column A
Generally speaking the Sandbox VM environment involves choosing two separate components.
- You need an OS VM. Typically it will run CentOS, Fedora, or Unbuntu. You can just pick up the OS configuration last used for the software you are planning to develop, or you can choose one specific OS VM to use for all your development and customize it to your preferences.
- You need the SandboxData disk/directory-tree for the particular software package you are planning to work on . By separating out the CAS project files on one virtual disk, and the Netid project files on another virtual disk, you can keep the same OS VM with your customizations and switch from one software development project to another by switching mounted disks.
Eclipse, not /etc
In the operating system servers are configured in /etc or the registry, but in the Sandbox you configure every Java Runtime, every JBoss or Tomcat server, and every Maven instance in Eclipse. In the system Java and JBoss are started at as background processes at boot time, but in the Sandbox your run Maven or start JBoss in debugging mode by clicking the task bar in Eclipse.If you have installed a J2EE server in the OS, then you have to stop it before starting JBoss under Eclipse or else you have to configure the Sandbox JBoss to use a different port that the 8080 default.
Of course, if you have a version of the Sandbox configured to work on both CAS and Netid (because they interact) and CAS runs on JBoss and Netid runs on Tomcat then you may have to configure two port numbers anyway. You just don't want the OS servers adding to the complexity.
1001
There is a generic developer userid named "casdev" (because the Sandbox was first created for CAS, but it can be used for any application). This user must be configured to the OS as Linux user 1001 because it is the userid number that is stored in the SandboxData disk directory as the owner of all the directoriesand files. The Sandbox OS is typically configured to log this userid in when you boot the VM. Typically "casdev" starts Eclipse and then everything is managed and started from Eclipse as part of this interactive login. So everything runs under the "casdev" user, and that user must have read and write access to the small number of OS directories that may be used during execution (specific subdirectories of /var/log and /media for example). Any directory permission problems will not show up until you run the code in DEV, but that is typically soon enough to deal with them.
Because it is 1001 and not "casdev" that is used in all Linux rules, it would be fairly simple to rename "casdev" to a different name if you object to it. Just keep the 1001 number.
R:\
The Sandbox OS can be Fedora or Ubuntu, but it can also be Windows. Java is system independent and all the tools (Eclipse, JBoss, Maven) are written in Java. You can develop CAS in Windows and then deploy it to production Linux servers and everything works.
Unfortunately, the SandboxData disk cannot be moved between Linux and Windows. While Java can be stored in the same directory on the disk for both systems, the Java executable is either a Linux program or a java.exe Windows program. Eclipse also inserts the disk letter when it configures an external file in Windows, while disk letters do not exist in Linux. So there have to be separate SandboxData images for Linux and Windows even though the component (Java, Eclipse, JBoss, or Maven) is in the same relative directory on each image.
Misc
CAS, Shibboleth, and Netid are examples of programs that run under SSL in production but run normal HTTP on port 8080 during development in the Sandbox.
Some files have to have explict fully qualified path names to a log, cache, or configuration directory. The Shibboleth WAR needs to know where /usr/local/shibboleth-idp is, and the log4j.xml file has to point to the /var/log/jbossas/standalone directory. You have two choices. You can use the standard OS file (strongly recommended for /var/log/jbossas/standalone) and on Windows you can create the C:\var\log\jbossas\standaone directory. Alternately you can create symlinks in the system that redirect the path to somewhere in the SandboxData disk. Remember, the the casdev user has to have write access to such directories.
Sandbox is not Production
The Sandbox does not have to run at maximum efficiency. It will not be up 24x7 for months, so rock solid reliability and stability are not a requirement. Therefore, you have more flexibility choosing a VM host, Guest OS, Java runtime, and version of JBoss.
For example, while a particular application will be designed to run in a particular version of Java (1.6, 1.7, or 1.8) it doesn't matter for development if you are using OpenJDK or the Sun JVM. At various times in the past, the OpenJDK has a bad reputation for slow memory leaks that accumulate in applications that run for weeks without being restarted, but that is not a problem for code you debug and restart every few minutes. Developers frequently prefer being on the latest and greatest version of Fedora rather than running an older Linux Kernel in Centos just because that is what Red Hat supports for production.
To fully exercise every part of an application you may have to install optional libraries in the system. For example, the Netid application uses the Kerberos 5 administration libraries that would have to be installed with yum or apt-get. However, unless this additional function is an essential part of your debugging, then you open a big can of worms trying to get the Sandbox to support this sort of function. You will never get the Netid application to actually do Kerberos 5 administration in the Sandbox because it turns out that the Java native code that provides that interface only works in 32 bit mode and only on an older version of the library. It is much better to do what Netid does and have a install parameter "kadm5_activation=false" that turns all Kerberos administration calls into noops since you are almost never actually testing that particular function of the application.
Two "Disks"
The core of the Sandbox is a separate disk image (named "SandboxData") that contains the Java, Eclipse, JBoss, Maven, database drivers, and so on. This disk can be cloned or the VM manager (VirtualBox) can create a fixed base disk shared by multiple machines with separate difference files that hold the changes each VM makes.
The last programmer to work on an application will leave a VM with a particular version of a particular OS that was last used in development. Try to live with it. If you can't, then you can switch to another OS Sandbox disk, but then you will have to connect it back to the SandboxData disk that contains the development files.
The SandboxData disk files are owned by user 1001 group 1001. The operating system you boot should have configured this user number to be "casdev" for sanity sake.
This is a three step process in Linux:
- You have to configure the VM (the *.vbox XML file) using the Virtualbox Manager to have two SATA disks, one for the OS and one for the SandboxData.
- You then have to boot the OS and configure it to mount the SandboxData disk and its file system as a directory in a well known path. Search for the "Disks" GNOME utility which is an easy to use way of changing the /etc/fstab file. The smaller "VBOX HARDDISK" that is device /dev/sdb1 should be configured to mount at boot time. Edit Mount Options and curiously turn "Automatic Mount Options" OFF and then type in a mount point. This will create a line in fstab of the form "/dev/disk/by-uuid/6a61a74b-df34-4038-bc70-ee6cf02d5cf0 /media/SandboxData auto ..."
- It is probably not a best practice to choose the system mount point as the explicit path used to configure something in Eclipse. So a simpler directory should be symlinked to the mount point and that should be used in application configuration.
There are several ways to mount disks in Windows and Linux. The choices all derive from two ambiguities:
- Linux and Windows both support multiple users, but in practice only one person typically logs on. Still the system has provision for there to be another user and that has an effect on disk mounts.
- Some disks are transient (USB flash drives) and some are permanent (a SATA hard disk installed inside the computer).
Since Linux cannot automatically decide if a disk belongs to one user or is supposed to be shared, and whether it can be dismounted and replaced or is mounted permanently, it is up to the users and administrators to configure things appropriately. Generally Linux will default in favor of the single user transient model (the USB flash drive) unless it is told otherwise.
While it is possible to switch from one software project to another by keeping the same OS disk and changing SandboxData disks, it is unreasonable to expect to do this without rebooting. That is, we do not intend to configure the Sandbox VMs to believe that SandboxData is a USB disk that you can eject and replace with another disk on a running system.
In Fedora, if user "casdev" mounts a disk then the mount point defaults to being something in the transient "/run" directory that is tied to the userid that mounted it. Specifically, the default location is /run/media/casdev/SandboxData. Ubuntu, however, uses a somewhat older standard where mounted CD drives were associated with /media/cdrom and so it wants to mount the same disk as /media/SandboxData. It is difficult to change the defaults of the system, and for this purpose it is unnecessary. So we adopt the Ubuntu default as the configured behavior on all Linux systems.
However, having decided that the mount point of the disk will be /media/SandboxData, that does not mean that we should use that path in Eclipse configuration windows. The option is then to symlink something simple like "/SandboxData" or "/home/casdev/SandboxData" (a.k.a. ~/SandboxData) to the mount point.
In Windows, mounting a disk typically generates a disk letter. The convention for the Sandbox is to use letter R: simply because it is unlikely to be used by anyone for something else. However, there are several ways to create a disk letter in Windows. In some cases the mapping is visible only to the user who does it, while in other cases the disk letter is global and is seen by all users on the machine. So Windows has some of the same problems as Linux, but the system details are different.
There is one more problem to mention. When a disk is initialized, it is given a unique identifier (a UUID) written in the disk label. This allows external disks to be uniquely identified no matter which USB port you plug them into. It also helps identify internal hard disks when the SATA cables become disconnected and are then reconnected to different ports. The Linux /etc/fstab file and the Windows Registry identify disks by the UUID and not by their label. So if you reconfigure a VM replacing one SandboxData disk with another, then when you boot it up again the system will know it is a different disk and will not automatically mount it. You have to use the Disks tool to add an additional line in fstab to mount the new UUID.
Obviously, although this discussion has assumed that the SandboxData files are all collected on a mountable hard disk image (a best practice), nothing prevents you from creating a Sandbox configuration where the files that would be on the second hard disk are instead copied or unzipped into a directory tree on disk. This is particularly attractive if you have decided to promote your sandbox development to the native operating system on your laptop, and now that you are not using a VM it is harder to mount a virtual disk file.
Installation
The Sandbox conventions do not depend on the software that creates and manages the virtual machines. Since this is not a production environment, the best choice is the one that is easiest to use. VirtualBox is free, can be installed on Windows, Linux, or Mac, and has convenience features for the developer. If you were creating virtual machines that you would immediately deploy into a IaaS cloud environment, then VMWare Workstation might be the best choice when developing for a VMWare fabric, and Hyper-V might be the best choice for a Microsoft fabric. The Sandbox, however, isn't going anywhere. The end result of all your work is source checked into Subversion that will get built and installed with Jenkins.
However, it is not a good idea to mix hypervisors on the same machine. They get into conflicts over the CPU VM support (VT-x, Nested Paging, etc.). So while you would never install VMWare or Hyper-V just in order to run the Sandbox, if you already have them installed for other projects then it is not necessary to rip them out and replace them with VirtualBox. Running a Sandbox OS disk on VMWare or Microsoft requires changing the hard disk format, creating a VM configuration (number of processors, size of memory, etc.), and then after the OS boots up you have to install the vendor specific Guest Support services and drivers. If you do not know how to do this, ask someone for help.
It turns out that VirtualBox is generally regarded as the best tool to convert one virtual hard disk format to another (VDI, VMDK, VHD). So even if you are not going to use it to run virtual machines, you may need to install it somewhere to do the conversion.
Download and install the current version of Virtualbox from virtualbox.org (at least 5.0.0). Run the installer. Launch the VirtualBox Manager.
A Virtualbox VM is a directory on disk. There is a xxx.vbox file that configures the memory, processors, network, and options of the VM, and a large xxx.vdi file that is the virtual disk.
A VM can become slightly attached to the environment in which it last ran. For example, by default a VM remembers the fully qualified path to any *.iso DVD image files that were previously mounted in its virtual DVD reader. It also may be connected to a virtual network that was configured with a name ("natnet1") on the previous system. If you copy a Virtualbox directory from another computer, you may have to flush the history of previously mounted DVD images and reconnect it to the name of a network that exists on your host computer before it will start up properly.
Sometimes the virtual machine has to be associated with a particular device on the real machine. Your computer may have more than one Audio adapter, and the virtual audio of the VM has to be associated with one of the real audio drivers on your computer. Similarly, you computer may have multiple LAN adapters (wired, wireless, etc.) and in certain network configurations (like "Bridged") the VM has to be associated with one of these adapters. However, if the VM is moved from one computer to another, then the new computer may not have the same type of audio or LAN adapter and the device name of the association has to be changed.
A VM can be archived in OVA format. This is a semi-standard zip file that contains a special version of the configuration data and a compressed version of the disks. Virtualbox will read an OVA and explode it into a real VM directory. You still may have to go back and change the network names.
There is also a very convenient feature called a "Shared Directory". This allows the host computer to share a directory or an entire disk with the Sandbox VM. It is very much like a disk shared over the network, except that the connection is directly between the host computer and the one VM so there is no extra security environment. Windows users may recognize this arrangement because it is exactly the same as a Remote Desktop Client sharing a disk with your own terminal session on another computer. Because you are the real user on both ends, there is no need for additional authentication and security. However, the directory to be shared is part of the VM configuration and it will break if you shared the D:\ drive on one computer and then move the VM to another computer that doesn't have a D:\ drive. You may have to redefine or delete the Shared Directory before you can start the VM.
casdev
There is one user named "casdev" with admin (sudo) privileges. You login, run Eclipse, and do all your development as this user. The /home/casdev directory holds the Eclipse workspace and all the casual files. Because JBoss is started from Eclipse, it also runs as casdev. Therefore, the JBoss and Eclipse directories are owned by casdev even though they are installed elsewhere in the file system.
The password for user casdev is not particularly secure, since it can only be used by the developer on the host machine. However, it will not be published here. Ask someone for it.
The VM
The VM is a standard Virtualbox 64 bit Linux configuration. With JBoss running the used memory only gos up to does not exceed 1.3 GB, so the amount of virtual RAM for the VM could be reduced to 1.5 or 2 GB if you need to run two VMs on an 8G laptop.
...