I'm new to Vagrant and I'm trying out PuPHPet in order to get things up and running. I can get a debian box up and running and ssh into it. It's more the workflow I'm unclear on.
At the moment I'm downloading the PuPHPet config into a folder called vagrant which I can cd/ into and run vagrant up then vagrant ssh. What I'm confused about is am I doing it wrong in terms of where I've placed the files.
Do you download the set up files on a per project basis, directly into the project directory? Or do I download this into a directory, for instance C:/sites/vagrant and then this directory runs my environments and the config files point towards the project folders such as C:/sites/project_one.
In my mind the PuPHPeT setup it what then gets used for all projects if I want it on debian as per what I chose via the GUI. But I'm really confused!
Short Answer
I recommend that you keep your PuPHPet files, the resulting Vagrantfile and its environment in a directory separate from your site (source) files directory because this seems more organized and secure to me. It is perfectly fine to set up a new virtual machine for each project, but I prefer to set up one single Vagrant box and have it service all of my projects at once so I'm not constantly putting boxes up-and-down as I switch between projects.
Explanation
To do this, configure your "Shared Folder Pairs" on PuPHPet.com to map your Folder Source (the /source/code/path/name where your source files are on your main computer) to the Folder Target (the /destination/path/name on the Vagrant-generated virtual machine where your Vagrant-generated web server can find them) for each of your projects (screenshot). Configure the web server (using PuPHPet's Web Servers configuration page) to reference such /destination/path/name directories, which maps those working files to a usable server name, server alias and document root.
As a warning, do NOT use the /var/www folder directly as a Folder Target. In some configurations, this will cause Apache to fail installation when provisioning with Vagrant.
In the config.yaml file created by PuPHPet, you'll see entries like this:
synced_folder:
vflsf_12randomlettersandnumbers:
source: /Users/unrivaled/www-development-source-files
target: /var/www/dev
On PuPHPet.com, where you would configure your environment, there is a section where you configure your "Shared Folder Pairs." This is where you tell Vagrant where your files are now (on your main computer) and where you want them to appear in your Vagrant-generated virtualized environment.
An important concept to grasp here is my use of the words "are" and "appear."
Your files "are" on your computer - the one you are presumably using to edit and debug your projects, and from which you want to run PuPHPet to host a Vagrant-generated web server. This is your "host" operating system, and your development files (source code) will always simply reside here. You will never need to copy them back-and-forth between your main computer and the Vagrant-generated web server.
By contrast, your files "appear" on the Vagrant-generated web server created when you run vagrant up, which generates a "guest" operating system in a Vagrant-generated virtualized environment where the web server, database engines and so forth run. Note that you are not copying files there (onto the "guest" operating system). Instead, Vagrant will cause them to appear there for you, per your use of the "Shared Folder Pairs" mentioned earlier:
Folder Source represents the location on your main computer (the "host" operating system), where your source files reside.
Folder Target represents the location on your virtual computer (the "guest" operating system), where you want Vagrant to make them visible in the guest OS.
In this way, you simply edit your files in your development environment, wherever they happen to be now; and Vagrant will make sure your Vagrant-generated web server sees those files instantly, live, in real time. Even if you vagrant destroy this generated web server environment, your source files will be completely untouched. Simply recreate a new environment (vagrant up), and bam! There you go. Back in business.
Related
I want to place and run my project from the second computer when xampp is installed on first computer, is it possible to map between xampp and my project which are present in two different pc's. If it is possible how to achieve that?
Yes, We can do that. After a lot of research I got it. If we want to access the project from any other external path(shared network) rather than our PC general location where xampp is located, do the following.
1) Connect to a shared network by mapping the path in your PC connecting to a shared folder
If you are using windows7 go to file explorer and check "Map Network Drive" on the top.
2) After that go to xampp control panel-> apache-> config-> search for "c:/xampp/htdocs"(where you are accessing your previous project) -> now change it to the new path where your project currently hosted/placed(shared network/any other folder).
3) stop the sevices and restart the xampp that's it you can now access your project folder which is located in different folder/server.
I have several workstations with a similar setup (home computer, workstation at the office) and also a server that is used as a remote storage. I'm trying to make Ansible to backup and synchronize several application profile directories (Intellij Idea profile dir, my desktop environment profile dir, some applications unpacked from tar.gz distributions and so on) between these devices. I never use all devices at the same time.
The logic for every dir should be:
check local directory modification timestamp
check modification timestamp of a directory on the remote server
if local copy is older, overwrite it with contents of a directory on the remote server. Otherwise, backup contents of local directory to a remote directory (effectively overwriting it).
I'm going to use Ansible with synchronize module. But implementing the logic above using when for every folder in my (rather long) list sounds like inventing a bycicle to me. It should be a better way to accomplish that.
Seems like a common task, maybe there is a third-party Ansible role/plugin that does that? Or maybe a separate application that may be called using command?
Ansible is obviously not the appropriate tool for this.
Why don't you use an online storage service with folder sync capabilities, like Dropbox?
When you download a vagrant box. The first time it has to download from a server. Then it caches that box for future use.
Is there a way to do this for files within a chef script. For example we use wget to pull down a zip file for some software. These usually take 40 minutes. I would like to have this only download one time (for each unique version) and cache the file somewhere for global usage later. So that if I create another vagrant machine that references the same zip file, it will use the cached file instead of downloading again. Is this possible?
Especially if you use remote_file resource, you can use the vagrant-cachier plugin to cache the downloaded files to a synced folder from the host. Even with direct wget calls you could specify a generic bucket and download files there.
Another approach is to use a caching web proxy in your local network, on your host, or even on another VM (see polipo-box for an example), and use the vagrant-proxyconf plugin to automate the configuration of the Vagrant VMs.
I just discovered why Maven doesn't work properly on my machine. For some reason it reads the user configuration from the completely wrong location. And I don't understand why. When I run maven with the -X switch I get the following output in the beginning:
[DEBUG] Reading global settings from D:\dev\maven\active\conf\settings.xml
[DEBUG] Reading user settings from D:\.m2\settings.xml
[DEBUG] Using local repository at D:\dev\maven_repo
Why is it reading user settings from D:\.m2 and not my actual user directory like it normally should? It worked fine on my old computer. Does it have something to do with me having installed maven on a different drive this time? On my old computer it was installed on the C drive.
Where does it get this D:\.m2 from? How can I make it read the user settings file from the actual default location, %userprofile%\.m2?
Finally figured it out. Found the solution in this blog post. To find the home directory in Java you do this:
System.getProperty("user.home");
Problem is, for some dumb reason, Java isn't using Windows environment variables or anything like that to find this path. It actually uses the parent directory of the Desktop directory. Since I like to keep certain main folders in my user directory on a separate drive (documents, downloads, music, desktop, etc) I had moved the desktop directory to D:\Desktop. Java then takes that directory, goes one level up and makes Maven and other java applications think D:\ is my home directory.
Gotta say the more I use Java the more i hate it... anyways, hopefully this might help save some hours of head scratching for someone else too.
Update
The original blog post is gone, but found on the WaybackMachine (the URL has been updated), but here's the gist from that post in case that goes too...
The issue: So how does Java play into all of this? Well, Java
developers sometimes want to store settings for their applications in
a folder within the user’s profile directory. It’s the Linux way, and
Java tends to do things the Linux way. (As mentioned earlier, Windows’
“AppData” folder servers the same purpose, with some extra separation
for data dependent on whether or not it should roam with the user’s
profile.) For some reason, Java does not use the Windows environment
variable to determine the location of the user’s profile, but instead
access a registry key that references the user’s desktop folder. It
then takes the parent directory of the desktop and assumes that is the
user’s profile folder (assuming the user makes use of the default
setup Windows chooses).
Essentially, when a programmer calls the Java command:
System.getProperty("user.home");
Java uses the following idea to determine where my user profile folder
is:
PATH_TO_DESKTOP_FOLDER_AS_SET_IN_THE_REGISTRY + "\..\"
This breaks down when the desktop folder has been modified.
So, with my setup, instead of saving settings at:
c:\users\tim\
Java apps tend to save data to:
t:\tim\
In reality, Java apps should save settings to:
c:\users\tim\AppData\Roaming\
or something like that.
To add insult to injury, the Java apps continue to follow the Linux
way and use a period at the beginning of the folder name in an attempt
to “hide” the folder (as is done on Linux). For Windows users, this
simply ensures these folders are listed first in directory listings.
(Hiding a folder on Windows is achieved through setting the hidden
attribute for the file.)
It looks like NetBeans has addressed the issue for their application,
but the root issue remains an unresolved, low priority bug. Somehow
I’d bet it would get fixed a lot faster if the mechanism for
determining the user’s home path on Linux was wrong.
I have an issue with my new web server. Because it goes across a really slow WAN connection, I've installed VS2012 on the server and pointed the source folder to C:\Src. This way I don't have to publish all my .dll's across the WAN.
It is also running a live IIS server, which points to C:\inetpub\wwwroot.
The VS2012 is really only there so I can get the source files quickly and build/publish. That part works fine.
However, it appears as though IIS is looking under my C:\Src\xxxx\bin folder for the .dll's instead of the c:\inetpub\wwwroot\xxxx\bin.
Any ideas how I can tell IIS to look under it's own bin folder instead of the src one? Would this be a setting in the web.config?
If it points to your Src directory, most likely you've accidentally set up a virtual directory in IIS when debugging.
Go into IIS manager and see if there is any virtual directory pointing to the wrong place.