You know those websites that are able to have a little icon in the address bar? That's pretty cool huh? I thought so too, so I decided to add one.
Apparently, IE seems to have managed to screw it up... surprise surprise.
According to W3C, it's very simple to add one:
http://www.w3.org/2005/10/howto-favicon
Works like a charm in better browsers. However, in IE, they seem to mess everything up. Funny how IE is the one that first introduced this too! Anyways, to get around the IE problem, just create a favicon.ico in your root directory. This will definitely not look as nice as the PNG... but for compatibility, too bad! :P
IE is really screwing their users over... sigh...
W
Thursday, May 8, 2008
Wednesday, May 7, 2008
Ubuntu + Ekiga
Ubuntu comes bundled with Ekiga, which is a VoIP program. It is something like Skype. I wanted to test this out and see how well it worked. I had a little bit of a problem configuring it though and would like to share my solution.
When using the configuration assistant, I was stuck at step 5, which told me that I had a symmetric NAT. If you don't run into this problem, then the configuration should go smoothly and you should have no problems. Anyways, back to my problem. Ekiga cannot run with a symmetric NAT. If you find any scripts to run in order to get Ekiga working, DO NOT run it. I tried one that I found on a wiki, and I lost my internet connection. It basically changed my iptables. No worries though if you did... just reboot your machine and everything will be reset back to a working state.
The script was made for older versions of Ekiga (much older) and is now of no use. The easiest way to get Ekiga working is to use port triggering on your router:
Service Name: STUN (or anything you like)
Triggering Port: 3478 (UDP)
Inbound Ports: 5000-5100 (UDP)
This should do it. Rerun step 5, and it should not report a Cone NAT. This is now acceptable and you can continue with the configuration.
Enjoy!
W
When using the configuration assistant, I was stuck at step 5, which told me that I had a symmetric NAT. If you don't run into this problem, then the configuration should go smoothly and you should have no problems. Anyways, back to my problem. Ekiga cannot run with a symmetric NAT. If you find any scripts to run in order to get Ekiga working, DO NOT run it. I tried one that I found on a wiki, and I lost my internet connection. It basically changed my iptables. No worries though if you did... just reboot your machine and everything will be reset back to a working state.
The script was made for older versions of Ekiga (much older) and is now of no use. The easiest way to get Ekiga working is to use port triggering on your router:
Service Name: STUN (or anything you like)
Triggering Port: 3478 (UDP)
Inbound Ports: 5000-5100 (UDP)
This should do it. Rerun step 5, and it should not report a Cone NAT. This is now acceptable and you can continue with the configuration.
Enjoy!
W
Tuesday, May 6, 2008
CSS: z-index
I ran into this problem with stacking order. It seems pretty simple to me, but Internet Explorer has managed to screw it up... again! I don't blame them if IE6 has problems, but for goodness sakes, fix it in IE7!! But alas, that's not to be and I'm stuck here with some crappy options. Actually, I don't mind... my users will though.
Basically, I have a few divs, and they're going to overlap. With proper z-index, everything is fine. However, without it, I can't implement what I want to do. So in the end, it's the users who suffer... that is if they use IE. I ended up using conditional comments (awesome stuff!) to do what I want to do if the user is not on IE.
Apparently, they say that IE8 fixes this and that it will be completely standards compliant, but my question is when will that be released and when will all the users no longer be using anything earlier than IE8... it's definitely going to be a long wait...
Damn IE sucks!
W
Basically, I have a few divs, and they're going to overlap. With proper z-index, everything is fine. However, without it, I can't implement what I want to do. So in the end, it's the users who suffer... that is if they use IE. I ended up using conditional comments (awesome stuff!) to do what I want to do if the user is not on IE.
Apparently, they say that IE8 fixes this and that it will be completely standards compliant, but my question is when will that be released and when will all the users no longer be using anything earlier than IE8... it's definitely going to be a long wait...
Damn IE sucks!
W
Saturday, May 3, 2008
Deployment: Part 3
We finally have everything up and running... at least the basics. However, we needed something more, such as starting/stopping/restarting our other servers. This was easily achieved using our own custom tasks in deploy.rb.
However, there was one odd one, which was backgrounDRb. To start the server, you must use:
./script/backgroundrb start -e production
The first problem we encountered was that after Capistrano had finished executing, the backgrounDRb daemon would disappear. After some research, an easy fix was found, which was to run the script through the nohup function:
nohup ./script/backgroundrb start -e production
This enabled backgroundrb to exist after Capistrano was complete. There was also another oddity that I found through research which I also implemented, which was to cd to the root directory before executing the script:
cd path/to/root && nohup ./script/backgroundrb start -e production
I never tested whether or not I could run the script without cd-ing... but the above command works for me without a problem, so why fix something that's not broken?
Next came environment problems. Backgroundrb was, for some odd reason, accessing the database in the development environment. However, I was clearly running the script in production!
Looking through the code, I realized that in bdrb_config.rb, it was setting the ENV["RAIL_ENV"] using the -e flag (which I stated production). However, when the master and meta workers were initialized, they were loading the rails environment without checking the ENV["RAILS_ENV"]. They were using the config file instead!
To fix this problem, simply change line 262 of master_worker.rb and line 350 of meta_worker.rb from:
run_env = CONFIG_FILE[:backgroundrb][:environment] || 'development'
to:
run_env = ENV["RAILS_ENV"] || CONFIG_FILE[:backgroundrb][:environment] || 'development'
This should check all the possible places that the environment could have been set and now everything should be running in the production environment!
Hope this helps anyone that was just as stumped as I was!
W
However, there was one odd one, which was backgrounDRb. To start the server, you must use:
./script/backgroundrb start -e production
The first problem we encountered was that after Capistrano had finished executing, the backgrounDRb daemon would disappear. After some research, an easy fix was found, which was to run the script through the nohup function:
nohup ./script/backgroundrb start -e production
This enabled backgroundrb to exist after Capistrano was complete. There was also another oddity that I found through research which I also implemented, which was to cd to the root directory before executing the script:
cd path/to/root && nohup ./script/backgroundrb start -e production
I never tested whether or not I could run the script without cd-ing... but the above command works for me without a problem, so why fix something that's not broken?
Next came environment problems. Backgroundrb was, for some odd reason, accessing the database in the development environment. However, I was clearly running the script in production!
Looking through the code, I realized that in bdrb_config.rb, it was setting the ENV["RAIL_ENV"] using the -e flag (which I stated production). However, when the master and meta workers were initialized, they were loading the rails environment without checking the ENV["RAILS_ENV"]. They were using the config file instead!
To fix this problem, simply change line 262 of master_worker.rb and line 350 of meta_worker.rb from:
run_env = CONFIG_FILE[:backgroundrb][:environment] || 'development'
to:
run_env = ENV["RAILS_ENV"] || CONFIG_FILE[:backgroundrb][:environment] || 'development'
This should check all the possible places that the environment could have been set and now everything should be running in the production environment!
Hope this helps anyone that was just as stumped as I was!
W
Friday, May 2, 2008
VMware on Hardy
There is currently no vmware package for hardy (DAMNIT!!). So we gotta do it the hard way.
1. apt-get the following
sudo apt-get install build-essential linux-headers-`uname -r`
sudo apt-get install xinetd
2. download the vmware tarball
just goto the website, it's constantly changing so I wouldn't bother posting it.
3. Get your FREE registration number (this used to cost a fortune, lucky us)
http://register.vmware.com/content/registration.html
4. Extract the tarball somewhere and run it by doing
tar -zxvf xxx.tar.gz
go into the directory
sudo ./vmware-install.pl
5. Now it'll ask you bunch of questions, just keep pressing enter. After awhile, it'll start compiling and fail :)
6. This has something to do with hardy's kernel, but don't worry, there's a patch for it.
wget http://uruz.org/files/vmware-any-any-update-116.tgz
tar -xvzf vmware-any-any-update116.tgz
cd vmware-any-any-update116
sudo ./runme.pl
7. VMware should start compiling and asks you more questions after (just keep pressing enter)
8. Once you've configured your vmware server, you need to link up some libraries
sudo ln -sf /lib/libgcc_s.so.1 /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1
sudo ln -sf /usr/lib/libpng12.so.0 /usr/lib/vmware/lib/libpng12.so.0/libpng12.so.0
9. And that's it, you can launch it by typing vmware on your console
J
1. apt-get the following
sudo apt-get install build-essential linux-headers-`uname -r`
sudo apt-get install xinetd
2. download the vmware tarball
just goto the website, it's constantly changing so I wouldn't bother posting it.
3. Get your FREE registration number (this used to cost a fortune, lucky us)
http://register.vmware.com/content/registration.html
4. Extract the tarball somewhere and run it by doing
tar -zxvf xxx.tar.gz
go into the directory
sudo ./vmware-install.pl
5. Now it'll ask you bunch of questions, just keep pressing enter. After awhile, it'll start compiling and fail :)
6. This has something to do with hardy's kernel, but don't worry, there's a patch for it.
wget http://uruz.org/files/vmware-any-any-update-116.tgz
tar -xvzf vmware-any-any-update116.tgz
cd vmware-any-any-update116
sudo ./runme.pl
7. VMware should start compiling and asks you more questions after (just keep pressing enter)
8. Once you've configured your vmware server, you need to link up some libraries
sudo ln -sf /lib/libgcc_s.so.1 /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1
sudo ln -sf /usr/lib/libpng12.so.0 /usr/lib/vmware/lib/libpng12.so.0/libpng12.so.0
9. And that's it, you can launch it by typing vmware on your console
J
Monday, April 28, 2008
Hardy Heron Connection Problem
Just upgraded to Hardy two days ago. Is it nice? Yes. Is there any problems with it? Yes.
Installation was fast as usual, took around 20 mins. Video settings, sound card, network card ... are all setup and ready to go after the system rebooted itself. Firefox 3 looks better than ever, however, I can't seem to get a connection?!?
What's more weird is that I can actually goto google.com, but everything else will time out on me!
After hours of searching, some dude suggested that I should decrease the MTU (maximum transmission unit) from 1500 (standard for ethernet) to 1492 by typing the following command
sudo ifconfig eth0 mtu 1492
amazingly, my connection is back to normal! (if anyone know why that is, can you please educate me on this issue? I really like to know the reason behind this!)
J
Installation was fast as usual, took around 20 mins. Video settings, sound card, network card ... are all setup and ready to go after the system rebooted itself. Firefox 3 looks better than ever, however, I can't seem to get a connection?!?
What's more weird is that I can actually goto google.com, but everything else will time out on me!
After hours of searching, some dude suggested that I should decrease the MTU (maximum transmission unit) from 1500 (standard for ethernet) to 1492 by typing the following command
sudo ifconfig eth0 mtu 1492
amazingly, my connection is back to normal! (if anyone know why that is, can you please educate me on this issue? I really like to know the reason behind this!)
J
Deployment: Part 2
As I mentioned in the last post, we got past SVN.
We finally came to Mongrel Cluster. This was a major headache. Apparently, Capistrano is broken when it comes to handling Mongrel Cluster. Simply following the Capistrano's site tutorial will not work.
The first step around this was to get the Palm Tree gem on the local machine:
>sudo gem install palmtree
This will include some recipes that we can use with our deploy.rb that you need to run Capistrano.
Next, add this to the top:
require 'palmtree/recipes/mongrel_cluster'
This will include the recipe needed to fix the deployment scripts. Basically, it rewrites the deploy script that comes with Capistrano. All you really need to know is that it works ;)
Next, generate a mongrel_cluster.yml by following the "Mongrel Cluster Setup" in this wiki. Check this into your repository as we'll need it.
Add this line to your deploy.rb:
set :mongrel_conf, "root_of_the_app/config/mongrel_cluster.yml"
Last thing we need to add is to tell Capistrano not to use sudo:
set :use_sudo, false
When all this is finally done, make sure that everything is in your repository. We can now attemtp a deploy:
cap deploy:cold
Make sure you use cold, as this should be the first time you're deploying. A deploy:cold is different than a simple deploy because it assumes that your servers are not running yet. Hopefully everything went right here. This should get you past Mongrel Cluster.
The next would be take a look at how to customize your deploy, such as starting other servers that you would potentially need.
We found the "after_stop", "after_start", and "after_restart" helpful for handling our other servers. Make sure that you put them in the deploy namespace ;)
Good luck!
W
We finally came to Mongrel Cluster. This was a major headache. Apparently, Capistrano is broken when it comes to handling Mongrel Cluster. Simply following the Capistrano's site tutorial will not work.
The first step around this was to get the Palm Tree gem on the local machine:
>sudo gem install palmtree
This will include some recipes that we can use with our deploy.rb that you need to run Capistrano.
Next, add this to the top:
require 'palmtree/recipes/mongrel_cluster'
This will include the recipe needed to fix the deployment scripts. Basically, it rewrites the deploy script that comes with Capistrano. All you really need to know is that it works ;)
Next, generate a mongrel_cluster.yml by following the "Mongrel Cluster Setup" in this wiki. Check this into your repository as we'll need it.
Add this line to your deploy.rb:
set :mongrel_conf, "root_of_the_app/config/mongrel_cluster.yml"
Last thing we need to add is to tell Capistrano not to use sudo:
set :use_sudo, false
When all this is finally done, make sure that everything is in your repository. We can now attemtp a deploy:
cap deploy:cold
Make sure you use cold, as this should be the first time you're deploying. A deploy:cold is different than a simple deploy because it assumes that your servers are not running yet. Hopefully everything went right here. This should get you past Mongrel Cluster.
The next would be take a look at how to customize your deploy, such as starting other servers that you would potentially need.
We found the "after_stop", "after_start", and "after_restart" helpful for handling our other servers. Make sure that you put them in the deploy namespace ;)
Good luck!
W
Subscribe to:
Posts (Atom)