Gallery 2.x virtual machine (vmware appliance)

Is there any interest in a Gallery2 virtual machine (which would run in vmware player/server)? I used Ubuntu server 6.06, their LAMP installation, added ssh (for remote admin) and ftp (for non-web based image uploads) as well as configured all the modules (except the nokia one) to work. I was looking for a VM image when I first wanted to try Gallery2, so now that I've made one I'm willing to share it.

It's about 402MB zipped and 1.1GB unzipped, so I don't know how I'm going to share it yet, but if there's interest we'll figure it out.

Christopher.

I have no personal hosting space that can have a 400MB file. All the large free file hosts I looked at let you upload the file, but limited the download to 300MB at a time. The easiest thing I could do was use Bittorrent. I have the file at http://www.mininova.org/tor/387630 so it can be downloaded (hope it works).

Hi h0bbel,

Yes, I must admit that I didn't remember to remove the CD source from the apt-sources list. Doh. I was more concerned if I could get it to you guys at all. Heh. One more mistake I made. . The ftp server is enabled and configured, but you need to enable writing for it to allow the uploads in /etc/vsftpd.conf (uncomment write_enable=YES). *arg*. To make it a bit nicer before you re-distribute you can also put the following line just before exit 0 in your /etc/rc.local file and it'll print a nice URL message on boot of where to go to see the gallery.

ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print "* Open a web browser at http://" $1 "/ to access the Gallery" }'

The admin password to the gallery is admin/admin (in case someone reading this thread happens to wonder).

Ubuntu is designed not to have a root password. It confuses most Linux folk accustomed to root having a password. Instead, you have accounts that can call sudo, use their password and then execute the command as if they were root. So if I logged in as gallery2 and executed,

And entered the gallery2 password from the resulting prompt then the machine would shut down because gallery2's account is in the sudoer's list.

For persons who don't want to keep sudo-ing all the time and want a root prompt:

should do the trick. If I was gallery2 when I executed this, I would have entered gallery2's password and it would have worked.

Christopher.

Well, remember that all of the modules are configured, so it's kinda big, but not above the average size for a LAMP virtual machine. I picked Ubuntu because the updates are really easy (apt-get update, apt-get upgrade) once all Gallery2's dependencies (GD, Imagamagick etc.) are installed using the apt system. I must admit that I was going more for ease of maintainability than size.

I noticed that when copying the VM you might not have eth0 (the network) activated. This is due to the way ubuntu-server ties the ethernet devices to mac addresses. You can fix this using a small script I found at http://www.vmware.com/community/thread.jspa?threadID=46069&tstart=0. Save the script (for example "fixmac") and put into /usr/sbin/ on your gallery2 vm. Execute "fixmac" as root and reboot the gallery2 vm.

---- Start Script ----

mac=`ifconfig -a | grep "HWaddr" | cut -d " " -f 11`
echo "eth0 mac $mac arp 1" > /etc/iftab

---- End Script ----

I think you should also be able to just comment out any incorrect eth0 entry in the /etc/iftab , reboot and that would also work.

Christopher.

if necessary i can host this file as i currently have over 1.6tb of bandwith usage and a fair bit of diskspace going to waste. if this is what you are after, please let me know

I'd suggest that vmware isn't the way to go but rather a live cd would be a better approach.

Actually, the rPath linux the appliance is based on *can* generate a LiveCD and there *should* be one on the site. Of course, it is *much* harder to be sure it works, since there is such a huge variety of hardware. Or maybe it was an install CD? I'll check it out.
_________________________________
Support & Documentation || Donate to Gallery || My Website

What h0bbel was saying is that we would need to find a solution that did not involve us maintaining the non-gallery portions of a livecd. Ie, we would take an already existing and working livecd and place gallery on top of it.

Of course the point of a live cd is to support tons of hardware, but that also brings in *tons* of different problems which can bring in *tons* of support issues and *tons* of problems, issues and bugs to resolve. With a VMware image, the "environment" the appiance in is virtually fixed at a certain set of hardware, so in *theory* most of the problems that arrise will be gallery based and not the OS.

Do you want the Gallery support and dev team to waste even more time supporting something that is far, far off tangent from gallery? I know I don't. If I were interested in LiveCDs I would be part of a team *doing* LiveCDs
_________________________________
Support & Documentation || Donate to Gallery || My Website

Chill down, no need to respond like that. But in essence, the maintenance involved with doing this as a LiveCD would be too much for us to handle.

As far as hosting is concerned, VMWare seems to be happy to host any community appliance. And even though VMWare doesn't encourage it, there is a way to link directly to an individual appliance.