freeVSD Enables Safe Experimentation
The freeVSD dæmon follows the Sysvinit startup conventions and can be controlled via:
/etc/rc.d/init.d/vsd start /etc/rc.d/init.d/vsd stop /etc/rc.d/init.d/vsd restart /etc/rc.d/init.d/vsd status
(though this may not yield accurate results).
Several options are configurable through the file /etc/vsd.conf. You may also start or restart a given virtual server with the /usr/sbin/vsboot command.
The /usr/sbin/vsdadm command, introduced during the installation process, can be used to create and delete virtual machines and to manage user accounts. It works by issuing commands to the vsd dæmon that runs on port 1725. This approach enables alternative front ends to manage freeVSD. This includes the administration suite, which consist of tools developed by Idaya, Ltd., some of which run in a web browser or under Microsoft Windows.
The program /usr/bin/bevs (become a virtual server) allows a user on the host to quickly assume the role of root on the virtual machine, without Telneting or otherwise connecting to the virtual machine. Most notably useful is the ability to set the Admin password initially or manage files not owned by Admin or a virtual user.
The following scripts, while useful during install, may become liabilities afterward. You may wish to issue the command chmod a-x on them to avoid inadvertently executing them again:
The program /usr/sbin/vsd-refreshskel.pl will update the freeVSD skeleton and then relink files in the root filesystems on each virtual machine. This enables you to add, remove or update applications available to the virtual servers. Be sure to read the documentation or scan the source code before trying this command. Packages you wish to make available to the virtuals, but not to the host, may be installed with the command
rpm -ivh --force --root=/home/vsd/skel/ file.rpmSimilarly, you may use
rpm -ivh --force --root=/home/vsd/vs/some-vs file.rpmto install an RPM into a single virtual server. Unfortunately, since the bulk of the skeleton is created by copying files and not from RPM installations, the RPM database will not accurately reflect the installed packages, so the force option is necessary.
Since /usr/sbin/vsd-refreshskel.pl will refresh the skeleton, it's useful to propagate upgrades to system software on every virtual machine. Please note that this utility seems to be broken for Red Hat 7.x in freeVSD version 1.4.6.
The /usr/share/doc/freevsd-1.4.6/ directory contains documentation and is made available to each virtual machine by default. Finally, /usr/share/freevsd/ contains scripts useful for site customization.
Giving superuser capabilities to regular users is serious business. We frequently see root exploits via shell accounts, so one must wonder if these problems could be compounded in the chroot environment provided by freeVSD.
On the other hand, one operating system patch can instantly improve security for up to 250 web site administrators. Further, having dedicated httpd processes prevents many of the problems usually present in a typical shell environment, where one user's actions could inadvertently disrupt another user's service.
An ordinary user on the host can see the processes of every user on every virtual machine. Further, using the bevs -r command, they can become root on any of the virtual servers by default! The bevs command is suid root, so apparently this is intentional. I recommend changing the permissions in order to disable this (e.g., chmod o-xr /usr/bin/bevs will do the trick), while still enabling members of the root group to run bevs.
The virtual server administrative dæmon /usr/sbin/vsd listens on port 1725. Out of the box, it is a trivial task to query a virtual server for user lists, change user privileges—in effect, fully control the vsd dæmon remotely, with no authentication. As suggested in the file security.txt, it is imperative that you control this with commands on the host, such as these (which should be placed in rc.local):
ipchains -A input -p tcp -s W.X.Y.Z <@cont_arrow>å<@$P>--dport 1725 -j ACCEPT ipchains -A input -p tcp -s 0/0 --dport 1725 -j REJECT
Because of the complexity of propagating operating system updates to the virtual machines, it is prudent to run a stable distribution.
Perhaps the simplest way to test out a new application is to keep a spare machine around on which you can safely format the drive and re-install it. While reinstallation can be a good experience builder, continually installing and tweaking becomes a nuisance.
Another option is to create disk images. After you have freshly installed the operating system and have it configured to your satisfaction, a command such as
dd if=/dev/hda1 of=/tmp/image
can create an image file that can be used to restore the operating system at a later date. Beware of the 2GB file size limitation if using this strategy—the split utility will be helpful.
The commercial application, VMware, fully simulates an x86 PC, right down to a full-featured Phoenix BIOS. For maximum performance, VMware directly utilizes the host processor to execute most instructions, instead of emulating the CPU. The VMware approach is not particularly efficient from a disk utilization standpoint: each session must have the operating system completely installed. VMware can create virtual disks from files, so multiple drives are not necessary. In addition to being disk-intensive, memory must be dedicated to each running virtual. However, with VMware, you are not limited to a single Linux distribution or even to the Linux operating system. It offers a more complete virtual server environment but is more resource-intensive, including the need to administer and update each operating system separately. Note that Plex86 (http://www.plex86.org/) is a free alternative to VMware under development.
User Mode Linux offers yet another means. In short, the Linux kernel has been ported to another architecture—a process running inside a regular Linux kernel. Full details are available at http://user-mode-linux.sourceforge.net/.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Home Automation with Raspberry Pi
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- Purism Librem 13 Review