How to build a virtual test server

Stringent testing of a new web application in the same environment it will be deployed in is an important part of the development life cycle. Running a local web stack on a Windows development workstation (e.g. XAMPP, AMPPS, etc.) may be convenient for debugging and unit testing, but the production environment will likely differ in at least the versions of the stack components, and perhaps even the OS technology and source. The simplest way to create a Test server that is for all practical purposes identical to the production server is to clone the production server in a virtual environment.


 * It is critical that all passwords are changed and all confidential data is deleted when creating the virtual test server. If this is not possible or practical, based on the business processes, system configuration and data involved, create a new test server from scratch with same system software versions as the production server, and with different passwords for users, databases, etc.

Create Bootstrap DevTest Server
A basic system must be first be created in order to have a system for copying the Production server backup to.

Assumptions

 * A Windows PC is used for Maestro development, called the Dev workstation. The virtualized DevTest server running on the Dev workstation is called the DevTest server.
 * Oracle VirtualBox is used to provide the virtualization environment for the DevTest server, and is installed on the Dev workstation.
 * A FreeBSD install DVD ISO has been copied to the Dev workstation.
 * The VirtualBox DevTest VM name will be "firefly", which will also be the DevTest server hostname (Firefly is a 2-seater aircraft Tom Swift invented in Book 17).

Procedure

 * Start VirtualBox and create a new virtual machine:
 * VM name: firefly (OS: BSD, Version: FreeBSD) VirtualBox virtual machine names are case sensitive, any commands which reference a vm name must use the correct case.
 * System: base memory: 128MB, Boot Order: CD/DVD-ROM, Hard Disk)
 * Display: defaults (text-only will be used)
 * Storage: 2 drives: 20GB IDE Primary Master (e.g. "firefly-sys.vdi"), 20GB IDE Primary Slave (e.g. "firefly-bkup.vdi")
 * Audio: defaults (will not be used)
 * Network: Intel Pro/1000 MT Desktop, attached to NAT (the "hostonly" network adapter mode may appear attractive to isolate the DevTest vm from the local LAN, but enterprise local security policies may not allow access to the forwarded ports).
 * Serial Ports: defaults (will not be used)
 * USB: defaults (will not be used)
 * Shared Folders: defaults (will not be used)
 * Extensions: none (extensions are not currently available for a FreeBSD guest OS)


 * Forward Dev workstation ports to the guest VM ports in order to access the DevTest guest VM locally.

Issue the following commands in a Windows CLI session to forward ports as desired. Port forwarding rules can also be set manually in a table using the VirtualBox Virtual Machine Manager.

> vboxmanage modifyvm "firefly" --natpf1 "guestssh,tcp,,2222,,22" > vboxmanage modifyvm "firefly" --natpf1 "guestftp,tcp,,2221,,21" > vboxmanage modifyvm "firefly" --natpf1 "guesthttp,tcp,,8880,,80" > vboxmanage modifyvm "firefly" --natpf1 "guestmysqltcp,tcp,,3336,,3306" > vboxmanage modifyvm "firefly" --natpf1 "guestmysqludp,udp,,3336,,3306"


 * Boot the firefly vm from the FreeBSD release DVD ISO (e.g. 8.2-RELEASE) and perform a basic system install on the system drive.
 * The root password itself is not important (it will be changed shortly by recovering the DevTest server from a backup of the production server).
 * Creating a user account is not necessary.


 * Reboot the firefly vm after the system has been installed, login as root and use sysinstall to configure and mount the backup drive (Fdisk to create slice on the backup drive, Label to create partition, initialize file system, and mount the drive as /backup). Set full permission on /backup (# chmod 777 /backup), and finally add the backup drive to /etc/fstab so it mounts automatically after reboot.

Assumptions

 * DevTest hostname: firefly
 * DevTest root password: appleton
 * DevTest username: maestro (password: appleton) This account will be used for user access to the DevTest server, including uploading code for testing, and test code uploaded into the maestro user ~/www directory).

Restore from Backup
A Production server typically contains confidential data, which must be deleted before the DevTest VM can be distributed to developers and used for development.


 * copy a backup dump file set from the live server to the Windows Dev workstation (e.g., using WinSCP)
 * start VirtualBox and boot firefly VM
 * copy the set of dump files to /backup on firefly (e.g., using WinSCP) (Via ssh using root user? Is a creating a user account necessary in order to have remote ssh login access with default system install?)
 * reboot the firefly vm from the FreeBSD DVD ISO (use the Devices -> CD/DVD Devices menu to attach the ISO file)
 * destroy and re-create an empty file system on the system drive
 * sysinstall Main Menu -> Configuration Menu -> Fdisk
 * select ad0 (system drive), select slice and delete (D), create new slice using automatic settings (A), select and set as bootable (S), quit (Q)
 * install standard boot manager
 * press ESC to escape from Select Drive menu back to Configuration menu
 * Configuration Menu -> Label
 * Automatically create partitions automatically (A), write changes (W) (override warning), quit (Q)
 * Configuration Menu -> Exit (returning to the sysinstall Main Menu)


 * use Fixit to restore the dump files
 * sysinstall main menu -> Fixit
 * select CDROM/DVD
 * mount backup drive and restore file systems (the dump filenames may vary depending on the configuration of the SCC Production server):


 * 1) mount /dev/ad1s1d /tmp
 * 2) cd /mnt
 * 3) restore -r -f /tmp/root.ad4s1a.dump
 * 4) cd /mnt/var
 * 5) restore -r -f /tmp/var.ad4s1d.dump
 * 6) cd /mnt/usr
 * 7) restore -r -f /tmp/usr.ad4s1f.dump


 * (still within Fixit)
 * set permissions on /tmp (/mnt/tmp) in order for MySQL server to start


 * 1) chown root:wheel /tmp only if system has been booted normally
 * 2) chmod 777 /mnt/tmp
 * 3) chmod =t /mnt/tmp


 * (still within Fixit)
 * edit /etc/fstab (/mnt/etc/fstab) and change drive/slice/partition designations as necessary (due to the server configuration if necessary (due to a different configuration on the server the dump files were created on).
 * edit /etc/rc.conf (/mnt/etc/rc.conf) and change the hostname to "stumbo" and use DHCP instead of a static IP address (if necessary). Also disable the NTP daemon if enabled.

hostname="firefly.ghostlytrio.local" ifconfig_em0="DHCP" NTPD-ENABLE="NO"


 * (still within Fixit)
 * edit /etc/hosts (/mnt/etc/hosts) and change the hostname to "stumbo" and specify the default IP address served by the VirtualBox DHCP server.

127.0.0.1        localhost firefly.scc.local 10.0.2.15        firefly.scc.local


 * (still within Fixit)
 * no action is required, but for your information, /etc/resolv.conf (/mnt/etc/resolv.conf) will be overwritten with new values provided via DHCP

nameserver 10.72.1.200 nameserver 10.64.1.200


 * (still within Fixit)
 * edit /usr/local/etc/apache22/httpd.conf (/mnt/usr/local/etc/apache22/httpd.conf) for correct operation when running a a virtual machine:

ServerAdmin      you@example.com ServerName       10.0.2.15                (default IP served by VirtualBox DHCP)


 * (still within Fixit)
 * edit /etc/crontab (/mnt/etc/crontab) and remove daily backup


 * exit from Fixit shell


 * 1) exit


 * exit from Fixit menu (select Exit), exit from sysinstall (select Exit Install) and reboot stumbo from system drive. sysinstall should "eject" the FreeBSD ISO from the virtualized CD/DVD drive and the system boot normally from the system drive, if the ISO file is not ejected you may need to disconnect it manually before rebooting.


 * login as root in the console and edit the maestro crontab file to remove undesired periodic tasks


 * 1) crontab -u maestro -e

Remove Confidential Data
Before using or distributing a DevTest VM for development it is important that any confidential information be removed. Although the degree to which this is practical depends on the production server itself, the following steps may be sufficient. Review them carefully for your situation, especially if you reuse the same password to protect multiple resources. No password on the Production server should be used on the DevTest server, even if for a different or non-confidential resource.

System

 * Change the system root password (# passwd)
 * Change the maestro user password (# passwd maestro)
 * Remove users except maestro and samba from system (# rmuser username) (examine /etc/passwd file or subdirectores in /home/ to determine users)
 * Remove users except maestro from sshd_config (# vi /etc/ssh/sshd_config)
 * Add maestro user to wheel group (# vi /etc/group) (maestro will be the only user account on the system and needs root access as root can only be logged in when using the console, and not when connecting remotely using ssh)
 * Disable sending or receiving mail from network (# vi /usr/local/etc/postfix/main.cf)
 * Remove any mail aliases (# vi /etc/mail/aliases)

MySQL Server

 * Change the MySQL root password


 * 1) mysqladmin -u root -p password "newpassword"  (enter current Production server password when prompted)


 * Drop MySQL databases (other than MySQL internal operation databases "mysql" and "test", and phpMyAdmin database "phpmyadmin").


 * Recreate maestro, partvendor and partloc databases and populate with sample data using SCC scripts.

Other Issues
Potential Issues


 * If both a dump file CD/DVD and a FreeBSD live file system CD/DVD are connected to the vm, the vm will not boot from the FreeBSD live file system CD/DVD - even if the drive is identified as the boot drive in the vm BIOS (must be a cabling or jumper issue!)


 * Depending on your virtual machine drive configuration, you may need to not mount the /backup file system (ad1s1d is mounted as /backup through the /etc/fstab file). If a second drive isn't available in the vm when FreeBSD boots, a file system error will occur because fstab specifies a file system that isn't present, and FreeBSD will boot into single user mode.
 * /etc/fstab can be edited during the fixit phase of creating the new system from the dump files.
 * if FreeBSD boots into single user mode, use the "ed" editor to edit fstab (other editors, such as vi, will not be available). Refer to the FreeBSD ED(1) man page .
 * AFAIR, "10p" will move the line pointer to the end of buffer (the file is only ~8 lines long), "d" will then delete the last line (referring to the missing drive and the /backup file system), and "w" will write the buffer to disk (but that may not even be close, better check with the ed(1) man page if you are in this position)


 * Edit /etc/rc.conf and comment the startup of the No-IP.com DDNS client and delete /usr/local/etc/no-ip2.conf (even if the virtualized server is not connected to the internet, it is best to delete this information anyway as it contains a hashed login to the No-IP.com DDNS server).


 * Edit /etc/rc.conf and comment startup of the NTP client (again, the virtualized server may not be connected to the internet anyway but it will also prevent error messages from the NTP client).


 * Remember to change the permissions on /tmp (as per Hong), otherwise MySQL cannot start correctly.

Localize the Devtest Server
It is necessary to localize the reference design server to some degree for correct behavior. The changes listed here are necessary for a server that will be accessible from the internet, not all changes are necessary to host a devtest server which is inaccessible beyond the host computer.

Server Localization


 * edit root user password (ref. Hong, p. 244)
 * edit hostname in /etc/rc.conf (ref. Hong, p. 18)
 * create new security certificates (ref. Hong)
 * edit /etc/hosts (ref. Hong, p. 19)
 * unclear why ip address is needed here for server as it must be updated should the server's DHCP-served IP address change (perhaps "localhost maestro.no-ip.org"?)
 * edit /etc/resolv.conf (ref. Hong, p. 19)
 * disable or reconfigure the DNS client (the reference design server uses the No-IP.com Dynamic DNS update client, ref. /usr/ports/dns/noip)
 * create new sysadmin and normal user accounts as needed, and add the sysadmin accounts to the wheel group (ref. Hong, p. 241-245, p. 126)
 * edit /etc/ssh/sshd_config to control user ssh access (ref. Hong, p. 126)
 * edit /etc/mail/aliases to change the email address to which mail to the root user is sent (ref. Hong, p.167).
 * It may be desirable to copy mail sent to the SCC system administrator mnestor to the real system administrator.

Apache/MySQL/PHP Localization


 * Apache (/usr/local/etc/apache22/httpd.conf)
 * ServerAdmin
 * ServerName


 * MySQL (/var/db/mysql/my.cnf)
 * (none)


 * PHP (/usr/local/etc/php.ini)
 * (none)

Component Project Localization


 * Launchpage (/usr/local/www/apache22/data/index.html)
 * Update iamge map area tag URLs for site new URL


 * Achievo (/usr/local/www/achievo/config.inc.php)
 * $config_db["default"]["password"] Only if user password changed on MySQL server
 * $config_administratorpassword


 * MantisBT (/usr/local/www/mantis/config_inc.php)
 * $g_db_password Only if user password changed on MySQL server
 * $g_administrator_email
 * $g_webmaster_email
 * $g_from_email
 * $g_return_path_email


 * MediaWiki
 * $wgEmergencyContact
 * $wgPasswordSender
 * $wgDBpassword Only if user password changed on MySQL server


 * Moodle
 * $CFG->dbpass Only if user password changed on MySQL server
 * $CFG->wwwroot Moodle URL


 * OpenDocMan
 * $GLOBALS['pass'] Only if user password changed on MySQL server
 * edit config_local.php
 * change base_url for site default http://localhost/opendocman will not work correctly!
 * change site_mail (sendto address when user clicks site title link at bottom of page)


 * webERP
 * $dbpassword Only if user password changed on MySQL server
 * change all user e-mail addresses

Miscellaneous


 * Remove any Google Analytics code if used on the root page page