During the LiveCD installation and afterwards, the best resolution I could get on the screen was 1600×1200@60 which isn’t bad, but looks slightly wider than it should given that in Windows XP & Vista (setup on different partitions) it displays at 1920×1200@60.  I used the Restricted Drivers Manager to install fglrx for the Radeon, but that didn’t help.

All my google searches related to the video card and the monitor inevitably led me to instructions dealing with installing the fglrx driver and running Beryl etc. Nothing told me how to get my screen resolution bigger. Basic edits to the Xorg file led me to several changes that didn’t work (and some that completely broke X, let that be a lesson to always backup before making changes…lucky for me I did).

I finally stumbled upon a bug that had been logged with a link to this article at WiredFool. I followed the tips he had including cutting out a lot of the fluff in the Xorg file and used the Modeline calculator that the article linked to. I tried a few different runs through before I found one that displayed the way I wanted it.

I skipped everything in the “Monitor Configuration” section. Filled in my Visible Resolution and Refresh Rate in the “Basic Configuration” section, and also checked the 16:9 Constrain Aspect Ratio box. I left everything else the same and hit the calculate button at the bottom. The Modeline is displayed at the top of the screen.

Your mileage may vary, but if perhaps you’re hardware is exactly the same as mine, here are the relevant portions of my xorg.conf file (although not formatted very well…you can add the tabs back in if you want).

Section “Monitor”
Identifier “DELL 2407WFP”
Option “DPMS”
Modeline “1920×1080@60″ 182.28 1920 1952 2640 2672 1080 1102 1113 1135
EndSection

Section “Screen”
Identifier “Default Screen”
Device “Generic Video Card”
Monitor “DELL 2407WFP”
Defaultdepth 24
SubSection “Display”
Depth 1
Modes “1920×1200″
EndSubSection
SubSection “Display”
Depth 24
Modes “1920×1200″
EndSubSection
EndSection

Good luck in all your Feisty adventures.

I saw in the news a month or so ago that Ubuntu was not going to make proprietary drivers available in Feisty. This is what drove my whole gentoo experiment in the first place. The whole reason that I loved Ubuntu was the steady release and that everything worked.

You’ve all seen the tutorials floating around for getting XGL, AIGLX, Beryl, Compiz, etc. running on your favorite distro, but this is too much for me. I consider myself a geek, but I don’t like wasting my time. I’m pretty familiar with an apache.conf file, but beyond that, if it involves opening conf files or shell text editors, I’m done. I’ll find something else. I digress.

Ubuntu’s latest Feisty beta then came as a surprise. Inside System > Administration > Restricted Drivers Manager you control what restricted drivers your system uses. This is an auto-install of the proprietary drivers with an auto-detect included. You can also control Desktop Effects grom the gui (I forget where). If you use restricted drivers, Ubuntu will warn you that they do not support them, but they are available if you want to use them.

You can see my VMWare drivers in the Restricted Drivers Manager here.

What do you have that might need proprietary drivers? Graphics cards and wireless cards are at the top of my list, and apparently, Ubuntu is good at getting the right ones.

Then as I began posting this, I heard another bit of news that makes this even better. ATI has released their Catalyst Control Center for Linux. If you like hating on Microsoft and can’t afford Apple Computers, Linux is starting to shape up as a decent (and still free) option.

This is good news for Linux.

Gentoo
I figured I’d give it a try. I will say this for Gentoo. There is some excellent documentation available and my knowledge of Linux and operating systems in general was greatly enriched, but it’s not for me. I booted off their mini install CD, downloaded the stage3 tarball, unpacked it along with portage. I partitioned disks with fdisk, I formatted partitions and put the ext2, ext3, and reiser filesystems on them. I compiled kernels from source, and recompiled them when my ethernet drivers weren’t detected properly. I manually configured IP addresses, I compiled X11 and got the graphical environment working.

I had two problems. Problem 1: Despite excellent documentation, I still didn’t really know what to do when errors happened. The documentation (while very good) gives you many options, but I still ran into errors that just weren’t accounted for. Problem 2: Everything takes so long to compile. X took hours.

Having done this, I can see why Gentoo could be (and probably is) much quicker than the other mainstream distros because every piece of software on the system is compiled for the exact hardware it’s running on. If you hate software bloat, then Gentoo is the system for you, but after a weekend of experimentation, Gentoo is not for me.

Others
I also gave Mandriva a run. I downloaded the Mini iso of the 2007 distribution which promptly errored out in the install (it couldn’t find it’s own built in video drivers for my old nVidia GeForce4). I went back to Ubuntu. Sure it’s got a general kernel that still supports the i386 architecture, which means it doesn’t get top notch performance from my i686 processor, but it works. It installed with no problems, updated itself, and let me configure it to work remarkably like my MacBook Pro.

So when it all came down in the end. I still haven’t found a distribution that works for me as well as Ubuntu. I don’t have the time to spend to do upkeep on a Gentoo system, and all those other mainstream distros are just so full of stuff (I’m not going to burn 4 cds just to test it out). Ubuntu pulls through for me once again.

I’m sorry Ubuntu. It won’t happen again.

After doing all my installing, I then installed VMWare’s now free VMWare Server. I downloaded the Ubuntu Server distro and decided on the 6.10 release dubbed Edgy Eft. It doesn’t have the LTS, but is perfect for my needs because the repositories include everything I need for my Ruby on Rails setup (including Lighttpd).

Then I just had to figure out how to get traffic from my host to my virtual host. I wanted to use Bridged Ethernet and did that originally, but even though my VM grabbed an IP address on my Lan, when trying to access it from another computer, I was told that there was:

No route to host

If you’re smarter than I am, you can probably figure out a way around this, but I was just trying to get it to work. I turned to NAT. Go to VM > Settings > Ethernet in your VMWare Server Console, select NAT, and click OK.

Now boot your VM log in, and run an

ifconfig

to see what your IP Address is. Again in your server console go to Host > Virtual Network Settings. Select the NAT tab. Make sure to move this window so you can clearly read your VM’s IP address. VMNet8 is the default virtual adapter for NAT, so if this is your only VM go ahead and click the Edit button (if you have others, make sure to select the proper adapter for your VM from the dropdown menu, then click edit). Now click the Port Forwarding button and then the Add button. Fill in the host port, the VM ip address, and the VM port. For me this meant forwarding port 80 from the host to port 80 on the VM. Don’t forget a nice description. Click OK 4 times. Now just forward traffic through your router (as needed) and you’re good to go.

My Ubuntu VM is now serving Apache2+MySql+PHP5 to the world. Soon it will be serving Ruby on Rails.

For a graphical tutorial see:

• The Official VMWare HowTo
• The How-To Geek

Then you find your favorite VNC viewer, and type in the network address of your server. This works fine as long as you’re on the local network, but what happens when you’re not on your local network. You could always forward the VNC port through your firewall (port 5900 by default), but VNC is not a secure protocol. Any password typed in would be transmitted in plain-text, and anyone in the world could intercept, and then control your computer, no hack attack needed.

This is where SSH comes to the rescue. SecureSHell (or SSH) creates an encrypted tunnel between two end-points over the network, and gives you a shell (command prompt for you windows folks) to the remote computer. It’s been around for years, it’s secure, and it continues to prove it’s worth as people come up with more and more uses for it. Tunneling is an example of this.

You can set SSH to accept traffic from a certain port on your computer, send it through an encrypted tunnel, and then end up at a certain port once it gets to the other side of the tunnel – SSH Tunneling.

So when I want to get a graphical interface to my server at home in my office, I can simply open my own shell (Windows users can use Putty) and type

ssh -L 5900:localhost:5900 username@remote.server.address

where the first “5900” represents the local port number and the second represents the remote port number.

You are then prompted for a password like any other SSH connection, and then logged in. Then you simply open your favorite VNC Viewer (I use VNCViewer on my Mac, Chicken of the VNC had serious speed issues) and connect to localhost. Your traffic which would normally be destined for port 5900 is forwarded through the tunnel and instead goes to port 5900 at the other end of the tunnel.

You’ve now got secure VNC.

On the list of things to do after install was to get Ubuntu to start the svnserve daemon at boot. I’ve taken the time to look this up enough times that I figured I’d just add it here. This procedure holds for anything you’d like to do at boot, I’m simply running my svn daemon.

Step 1 – Create your script.
Simply create a new file (I called mine svnserve) and type the command you’d like to run

cd /etc/init.d/ # (thanks Alfonso)
sudo touch svnserve
sudo vi svnserve
svnserve -d -r /usr/local/svn/repository_name

Step 2 – Save the script in the /etc/init.d/ folder

Step 3 – Make the script executable
sudo chmod +x svnserve

Step 4 – Add the script to the boot sequence
sudo update-rc.d svnserve defaults

That’s it. When you’re done you should see some output similar to

Adding system startup for /etc/init.d/svnserve ...
/etc/rc0.d/K20svnserve -> ../init.d/svnserve
/etc/rc1.d/K20svnserve -> ../init.d/svnserve
/etc/rc6.d/K20svnserve -> ../init.d/svnserve
/etc/rc2.d/S20svnserve -> ../init.d/svnserve
/etc/rc3.d/S20svnserve -> ../init.d/svnserve
/etc/rc4.d/S20svnserve -> ../init.d/svnserve
/etc/rc5.d/S20svnserve -> ../init.d/svnserve

Again (like most of my instructions) these instructions are for Ubuntu – currently Edgy Eft.

sudo apt-get install mysql-server

Ubuntu installs Mysql at /etc/mysql/ by default. Now we need to set a root password.

mysql -u root
mysql> SET PASSWORD FOR 'ROOT'@'LOCALHOST"
> = PASSWORD('new_password');

Now while we’re still here, we’ll create a new HOST for root and allow root to login from anywhere.

mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%'
> IDENTIFIED BY 'password' WITH GRANT OPTION;
mysql> FLUSH PRIVILEGES;
mysql> exit

Thanks to Thom for the Flush Privileges comment.  I think it depends on other settings in your MySQL setup, since I didn’t have to, but just in case, I’ve added it here.  We’re almost done now. We just have to tell Mysql to allow remote logins.

sudo vi /etc/mysql/my.cnf

Out-of-the-box, MySQL only allows connections from the localhost identified by the IP Address of 127.0.0.1.  We need to remove that restriction, so find the line that says

bind-address = 127.0.0.1

and comment it out. That’s all there is to it! Now get your favorite MySql client and start developing.