Showing posts with label VirtualBox. Show all posts
Showing posts with label VirtualBox. Show all posts

Tuesday, 15 January 2013

Virtual machine with persistence in VirtualBox

Now that I have a nice Multiboot USB stick (http://angel-de-vicente.blogspot.com.es/2012/11/multi-boot-usb-stick.html), I have been asked a couple of times to show it to someone. This involves re-booting a machine, so I looked for a way to try one of the distros installed in the USB inside VirtualBox. This is only a quick hack, and there is plenty of room for improvement, but it worked OK (with ideas from https://help.ubuntu.com/community/LiveCD/Persistence).

The steps were:

1.- Create a new virtual machine (with 8GB of hard disk in a .vdi file), and attach to it the xubuntu CD.


2.- Create an ext3 partition in the .vdi file (the virtual machine's hard disk) and label it casper-rw:


3.- Try it.

When starting the virtual machine, type F6 to get into the LiveCD options, then with F6 again, include "persistent". (Also useful to change the keymap with F3). Every time we want to access the persistent partition, we will need to add "persistent" to the boot options (there are ways to modify the .ISO file so we don't need to do this, but I'm only using this option rarely, so it is not worth it).



4.- Transfer one of my LiveCD with persistent file to the VirtualBox.

Since this is almost only for demo purposes of my multiboot stick, when I don't want to reboot a PC, I want to be able to load one of my existing LiveCD distros (which use a casper-rw file instead of a casper-rw partition) in VirtualBox (somehow I only got the persistent mode to work inside VirtualBox with a casper-rw partition, not with a casper-rw file as I do it now with the Multiboot USB stick).


At my desktop I have the casper-rw file with all the required modifications at: /home/angelv/Desktop/xubuntu-casper-rw


I start Xubuntu in VirtualBox (without the persistent option), and then I want to copy the contents of the casper-rw file into the casper-rw partition. If you have shared folders or USB support for VirtualBox this is easier, but since I don't right now, I just do it through ssh to the VirtualBox host (192.168.1.12 in my case).


That's it. Now we have a copy of our LiveCD with the persitent changes, that we can use from within VirtualBox.

(In my case, and to match the experience in my Multiboot USB stick, I not only add persistent to the boot options, but I add: persistent hostname=nomada username=angelv userfullname=AngeldeVicente)



Friday, 15 October 2010

Private Repository with Fedora 13 (part 1)

At my work we are considering ways to efficiently allow users to install/remove software in their Fedora workstations, but without requiring the root password, and in a controlled way (which basically means allowing them to install/remove only some packages and not others).

So I set up to try the following:
  • a Fedora13 workstation which downloads software from the standard repositories, to which regular users have no permission
  • to create a private repository in another local server, in which we can have all the software local to our workplace, and from which users can install/remove software without requiring administration privileges

So I start by downloading the 32bits Fedora 13 Desktop Edition, and installing it in a VirtualBox Virtual Machine. The Live System comes up OK inside VirtualBox, but for some reason, the "Install to Hard Drive" option does not seem to work... I'm not the first one to have this problem, and setting the "Base Memory" for the Virtual Machine to 1GB seems to solve the problem, and the installation to hard disk starts OK. Apparently after installation we don't need so much memory, so I change it back to 512MB and Fedora13 boots without any trouble:


So, we do the same for another virtual machine, the one that will act as the private repository. Next, we need to be able to boot both machines at the same time and configure networking so that they will see each other. After reading the VirtualBox instructions I decide configure each machine to have two adapters, one with NAT, and the other one as an internal network (which they will use to see each other):


And inside the guests, I configure eth1 manually with the addresses 192.168.0.1 and 192.168.0.2


 Then we add two lines to the file /etc/hosts in both guests:


[root@ws ~]# head -n 2 /etc/hosts
192.168.0.2 repo
192.168.0.1 ws


And both machines can see each other without trouble:


Since we haven't changed any configuration regarding the Fedora repositories, right now both machines will get all the software upgrades from the standard repositories, and only root can do them.

So now, we have to be able to create a local repository in the machine repo and use it as an additional repository in machine ws, but one from which a regular user can install software.

In order to create a local repository, we follow more or less these instructions:

yum install httpd
chkconfig --levels 235 httpd on
/etc/init.d/httpd start


But we cannot contact the web server at http://repo, since the firewall is preventing it. We open it by running the command  system-config-firewall and selecting "http" as trusted. Then, from ws there is no problem to load the default Apache webpage.

Then we create the local directories:

mkdir /var/www/html/yum/SIE/fedora-13/i386


In that directory we copy the following RPM xzgv-0.9.1-2.fc13.i686.rpm and then run the createrepo command:

createrepo /var/www/html/yum/SIE/fedora-13/i386


Then we test in ws whether it is working. First we create the file SIE.repo:


(Modify to whatever metadata_expire suits you: see http://forums.fedoraforum.org/showthread.php?t=216398)

And we see that a simple install would work:


But when I really try to install something, then I see that we get problems with permissions. By default Apache simply does not list the .rpm files, and we cannot download them directly (if we rename a .rpm file to a file without extension, then there is no problem...). This has something to do with SELinux! Temporarily running "setenforce 0" solves the problem (see http://www.crypt.gen.nz/selinux/disable_selinux.html).

Installing something as root is then no problem. In order to be able to run it as a regular user, I create a script:



and add the following in the /etc/sudoers of ws (see sudoers documentation):

ALL ALL=(ALL) NOPASSWD: /usr/bin/SIE.install


This is not ideal. The user can install but cannot remove the package. We should find a better way to make sure that a regular user can do all the usual tasks with yum, but only if they affect a package coming from our local repository (search packages, install them, remove them, be informed automatically of any updates...), but for the moment we leave it like this. Later on, we have to have a good read of PackageKit to see if it provides better control for this (it uses PolicyKit).

So now we have (an alpha version!) most of the staff in place, and we should just document how to create a RPM package out of our local software, and how to make sure that users get notified of updates to our software. This will have to go in another post...