Posts Tagged ‘arch’
Setting up a virtual development server
As a web developer, I often come up with interesting new concepts that I want to try out. Occasionally, these require more than simply HTML, CSS and JavaScript, at which point I need to begin uploading my PHP (my language of choice) files to a remote server running apache, test the page there, make adjustments in my local code, upload and test again. This is quite slow compared to the very efficient development cycle of plain old HTML where you can preview what you’re doing instantly in the browser.
Whilst some IDEs have support for FTP uploading directly from the editor, this still means you have to wait for the upload to complete. Also, If you want to delete files or rename folders, it often requires you to start up a separate FTP client anyway. Wouldn’t it be great if you could work with your PHP (or whatever server-side language you prefer) files directly on your computer, and access them directly through your browser without any intermediate steps? Just as if it was static HTML…
There are two ways you can do this; one is to install all the server-side software on your own computer and set it up so that it points to the directory you work from as its directory root. The other, which I will be telling you how to set up, is to run a virtual server on your box. The reason I prefer this approach is that it keeps a separation between your own computer and the server, and at the same time allows you to set up your server to match the server you will be deploying your application on.
So, first of all, grab a copy of Sun’s VirtualBox. This piece of software allows you to set up virtual computers running whatever OS you want it to. Next, download the ISO containing your favorite server OS (I have chosen Arch Linux, but this guide should apply to most Linux-based OSs, and the guiding principles should be applicable to any server OS). After installing VirtualBox, create a new Virtual Machine (VM). You can name it anything you want, and set how much RAM it should have, its hard-drive size and various other parameters. Usually the defaults are fine. When your OS has finished downloading, right-click your newly created VM in VirtualBox and select settings → Storage → Click the image with a CD icon → Click on the small folder icon with a green flick on it (The Virtual Media Manager) → Click add in the new window that pops up and select your ISO → Select the image that appears in the list and click “Select” → Click OK
Next, we need to do some low-level dirty stuff to make the host OS (Your computer) can connect to the guest OS (The server) through for instance port 80 (HTTP) and port 22 (SSH).
- Select “Network” in the settings dialog for your VM
- In “Adapter 1″, make sure the drop-down has “NAT” selected.
- Click advanced
- Set the adapter type to PCnet-PCI II
- Click OK and close VirtualBox completely
- Open up the VirtualBox configuration file for your VM in notepad or similar (On my Windows 7 install, it is located in C:\Users\<username>\.VirtualBox\Machines\<Name of VM>\<Name of VM>.xml)
- At the top where it says: “<ExtraData>”, append the following code:
<ExtraDataItem name="VBoxInternal/Devices/pcnet/0/LUN#0/Config/apache/GuestPort" value="80"/> <ExtraDataItem name="VBoxInternal/Devices/pcnet/0/LUN#0/Config/apache/HostPort" value="8888"/> <ExtraDataItem name="VBoxInternal/Devices/pcnet/0/LUN#0/Config/apache/Protocol" value="TCP"/> <ExtraDataItem name="VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/GuestPort" value="22"/> <ExtraDataItem name="VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/HostPort" value="2222"/> <ExtraDataItem name="VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/Protocol" value="TCP"/>
- Save the file
What we just did was to tell VirtualBox that we want to forward the port “8888″ on the host to port 80 on the guest, and similarly port 2222 to port 22. The reason we had to change the network adapter type to PCnet-PCI II in step 4 was that, as you can see from the strings you added to the XML, they reference “/pcnet/” which only works on the PCnet-type cards. If you use the intel-based ones, you need to find the shorthand for those (shouldn’t be too much of a hassle).
Allright, so now we have the VM itself sorted out, next we need the server up an running. Time to start up your VM for the first time. This guide will not go through the actual OS install as it is way outside its scope, but generally, you don’t need any GUI stuff, and should select any server software you’ll need if you get the choice.
Next, you should install the VirtualBox guest OS additions. Under “Devices” in the VM window, select Install Guest Additions. This will download and mount an ISO image with the install files for most guest OSs. For a more in-depth explanation see this link. From Linux, mount the CD and “cd” to the CD directory (pun actually not intended…), then run “sudo sh ./<script-relevant-for-your-architecture>” – for example “sudo sh ./VBoxLinuxAdditions-x86.run”. This should compile and install the relevant modules. You will also have to add two modules to your startup process: “vboxadd” and “vboxvfs”. The first is the base system for the VirtualBox Guest Additions, and the second one is the file system controller that allows you to access the shared folders set by the host. Some OSs also have these things available through repositories. In Arch for instance, the relevant packages are in the package “virtualbox-additions” in community. To install, just type “pacman -S virtualbox-additions”.
Under Arch, edit “/etc/rc.conf” and add the two said modules to the MODULES array (i.e. “MODULES = (vboxadd vboxvfs)”. Since your there, you might want to add “httpd” and “sshd” to your DAEMONS list as well. You should also add the following to your “/etc/hosts.allow”: “httpd: ALL” and “sshd: ALL”. This allows the host to connect on those ports.
So now that the guest has its additions, we need to install the server software. I won’t go through the specifics here, but in my case, I installed Apache2 with PHP and PostgreSQL.
And so, to tie it all together: At this point, you have a working server, and after a reboot going to “http://locahost:8888/” on your host should take you to the default start page in whatever web server you’ve set up. You should also be able to connect to SSH if you’ve set that up. Thus far though, you will still have to transfer your files to the server to test them there. This is where VirtualBox’s shared folders come in.
In the VM window, select “Devices” → “Shared Folders”. Here, add your development folder as a new shared folder with full access and click OK. If you run a GUI guest you should now be able to access the folder as a network drive. If not, however, you need to do some more console magic. To get the folder to mount automatically in Linux, all you have to do is add the following line to “/etc/fstab”
"<Name of shared folder> /srv/http/ vboxsf defaults 0 0"
The name of the shared folder is stated in the Shared Folders dialog we opened earlier.
Next, run “sudo mount -a” to mount the new folder. This should allow you to navigate to “/srv/http” on your guest OS and see all the files in your development folder. Finally, set up your web server to have “/srv/http/” as its document root, and you should be able to access any of your projects at “http://localhost:8888/path/to/file/from/development/folder/” from your host the instant you save a file with all the bells and whistles of a fully-fledged web server.
If you experience Apache serving you old versions of a file even though you KNOW you’ve made a change, edit the Apache config (“/etc/httpd/conf/httpd.conf” on Arch), and uncomment the line saying “EnableSendFile off” and restart Apache.
Enjoy your new upload-free development environment!
References:
Dual booting Windows 7 and (Arch) Linux, and the hassels involved
This week I have been setting up my new computer – a complete beast with Intel Quad Core i7 processor, 12 GB memory, 4 * 1TB drives in RAID 1+0, etc. On this computer, I decided to put both Windows 7, which is provided for free through the MSDN Academic Alliance and Arch Linux ( which I fell in love with the first time I tried it ).
Since getting an account with MSDN took a while, I decided to put Arch on the box first, even though the Windows bootloader is known to foul up GRUB and make it impossible to boot into linux.
First step was installing Arch.. Usually, this is quite hassle free, but because of the slow internet at the accomodation center at Bond University, I downloaded the Net Install CD so that I could install and download only what I needed. Sounds logical, right? Well, not when I tell you that, as I discovered, you have to login to access the wired network. When opening a browser, you’re presented with a login screen though HTTPS, that has to be completed every time your IP changes. Problem is, the netinstall CD has no browser installed as it is command-line only, and as such, I had no way of authenticating with the network, which again lead me to being unable to download any packages for my system. So, what do you do?
Logging into an HTTPS proxy through command line tools
My first though was to use links or lynx ( text-based unix browsers ), however neither were available on the netinstall CD, and I couldn’t compile either from source since the build tools and dependencies were not there. At this point, I was certain I would have to download the full Arch install CD, and start all over again, however, I was not prepared to give up that easily. There is a reason I use Arch – to understand how things work from the ground up, and to force myself into exploring Linux.
At first, the only solution I could think of was to telnet into the login server over HTTPS, send the proper POST headers by hand, and thereby become authenticated. Finding the correct headers on my laptop was not a problem, however hand-typing them onto the linux shell posed a problem. Not in getting it right, but because the HTTPS connection of the login server had a timeout for requests at about 10 seconds… The end request looked something like this:
POST /login.pl HTTP/1.1 Host: login.bond.edu.au Connection-type: keep-alive Keep-alive: 300 Content-type: application/x-www-form-urlencoded Content-length: 112 _FORM_SUBMIT=1&which_form=reg&source=<my IP>&destination=&error=&bs_name=<Student ID>&bs_password=<URL encoded password>
As you can probably imagine, hand-typing that in 10 seconds is not an easy task. Evidently it was not going to work, which was why I started exploring the unix philosophy of separation of tasks. Why should I type all that text, why couldn’t the computer type it for me? I created a file with the request, and used the unix command “cat” to print the file. I then piped the output through my telnet connection as such:
cat request | telnet login.bond.edu.au 443
To my surprise, this just caused the connection to time out without any error message… After trying a multitude of alternative versions of the above, I concluded that parts of the request was probably printed to the server before the connection was actually established, which caused the server to disconnect the session.
I felt quite lost, and was very close to getting a full Arch install ( and thereby have to wait for about 5-6 hours for the download to complete… ), when I remembered the “wget” command. This is a command that allows you to download files from the web through HTTP/HTTPS/SCP/SFTP/FTP. Maybe it could also send a POST request?
Not only was wget included in the netinstall CD, but after looking at the manpages, I also found the argument “–post-file”, which allows you to send urlencoded data through POST when submitting the request. I was saved! I stripped everything except the data from my request file, and issued the following command:
wget --post-file request --save-cookies s.cookie https://login.bond.edu.au/login.pl
Looking at the downloaded HTML file, I soon found that I had successfully been logged in, and I could start the actual installation!
Both the installation, and the subsequent configuration ( installation of GNOME, setting up drivers, etc.. ) posed no problem as usual, though it all took quite a while having to download it all though the 1 Mbit/s throttled connection at the student residences. Next morning however, my computer was up and running just the way I wanted it. Windows 7 next…
Windows 7
First of all, I had to download Windows 7 from MSDN, which proved to be impossible from linux. It provided a downloader, which, when run through wine, simply refused to download the file properly.. In the end, I had to download the ISO on my laptop ( running Vista ), and burn the DVD from there. From here, the ride was smooth. Installation of Windows 7 was both painless and fast, and I was up and running in 30 minutes. Great!
Next was getting GRUB back on the MBR, since Windows overrides all other bootloades when installed. At first, I tried looking for a windows installer that could restore GRUB to the MBR, but this does not seem to be available, so I had to get down and dirty with the unix command line again. Hooray! =D
I rebooted, and started up from the Arch installation CD. From there, you have two options to restore the grub. Both involve getting your original Linux partition mounted, and then running grub-install from there.
1. Boot the Arch Linux Live CD, mount your linux partition using “mount /dev/sd** /media/fl” where ** is the device and partition of your Linux boot partition. Next, you have to run: “grub-install –root-directory=/media/fl /dev/sd*” where * is the device you wish to boot from..
2. Open the “More Options” selection on the boot screen of the CD, and then highlight the option “[EDIT ME] Boot Linux Directly”. Next, press ‘e’ to edit the line. Here, edit the line “root (hd0,0)” to match your device and partition. Next, edit the two other lines, and change /vmlinuz and /kernel ( can’t remember the exact filenames ) to read “/boot/vmlinuz” and “/boot/kernel” respectively. Due note that these are the default paths, but yours might differ. Also, you might have to change the line that contains “root=/dev/sda3″ to fit your setup. Finally, press ‘b’ to boot the linux partition. You will now find yourself in your normal Linux install. From there, you can run “grub-install /dev/sd**” as in 1.
Why the two options? For some reason I didn’t think of the first option until after I did #2. Maybe it will come in useful at some time…?
Now, to get Windows available from GRUB, edit “/boot/grub/menu.lst”, and uncomment the Windows lines at the bottom, and input the correct device and partition.
And then, you’re done! Congratulations! You’re dual-booting Windows 7 and Linux
