Maxis broadband "disconnected"

While browsing web in my office as a Maxis broadband service subscriber (fyi, Sri Hartamas is a Maxis territory), once in a while we may get "The page cannot be displayed." error. From there on, all WWW is no longer accessible and the common solution for this is to restart and router. But what happened if u need to restart every 30 mins or less? That is simply too much a effort.

A quick ping testing indeed explains everything. As for my analysis, i took www.yahoo.com as example. This is done before get "disconnected".
ping www.yahoo.com
Pinging www.yahoo-ht3.akadns.net [87.248.113.14] with 32 bytes of data:

From the pinging output, we can derives that domain name is actually translated to the following IP via DNS server.
www.yahoo.com=87.248.113.14

In order to determine the DNS server is the real culprit, i did a separate ping on the domain name and the translated IP when the error page returned.
ping www.yahoo.com - Negative result
ping 87.248.113.14 - Positive result

As a result, it clearly shows the internet connection is up but the DNS server failed to translate the domain name to the corresponding IP. In other words, you can still access to yahoo web site if you hit the site IP directly. Eg, http://87.248.113.14

According to Maxis, all the broadband user DNS settings should be set as automatically. The problem is sometimes the DNS settings might lost in the space and hence "disconnecting" the user. In fact, this also affects Streamyx subscriber frequently. Thank to Google, i managed to find a Maxis DNS IP that revitalize my browser. Apparently this DNS settings is meant for the GPRS service, but as long as it works:D

These are the one and only Maxis DNS server found in the net:
Primary DNS: 202.75.129.101
Alternate DNS: 202.75.129.102

Alternatively, should you run out of idea what DNS IP to use, you can always opt for the public DNS server. Check it out at http://www.opendns.com/

Hope this could help some of the desperate Maxis broadband subcriber out there;)

Forbidden. You don't have permission to access /.. on this server.

Finding the root cause of this issue took me 1 day. Without talking much nonsense, let us have a look on the problem and resolution.

Problem:
We have a new web application deployed into Websphere application server (WAS). Similar to the standard production environment, we have a IBM HTTP web server that routes all the request to application server. Problem arises when we try to access the application via web server and get the error page as mentioned. However, the application is accessible if we hit the app server IP directly.

Diagnosis:
Normally for any issue related to web server, there are only 2 config files that need to be looked into: httpd.conf and plugin-cfg.xml. From the httpd.conf, we can find the path of plugin-cfg.xml the web server referred. As for my case, this is the one i get
WebSpherePluginConfig /usr/IBM/HTTPServer/Plugins1/config/webserver1/plugin-cfg.xml.
Therefore we need to make sure we are modifying the correct plugin-cfg.xml in order for the changes to get reflected. A thorough check on the plugin-cfg.xml revealed the new application context path is missing. There is a portion in the file where we need to configure all application context path. For example, i have a web application with context "ABC", this would need to be included as below
UriGroup Name="default_host_server1_AppSvrNode01_Cluster_URIs"
Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/ABC/*"/

Resolution:
If your application is deployed into WAS, you can conveniently retrieve the plugin-cfg.xml from the WAS admin console, web server portion. Right after u click on the web server link, there will be a link forward you to the plugin configuration. Another click on the view button will show you the file content that supposed to be referred in web server. A simple step to replace the web server plugin-cfg.xml with the one from application server will solve the "Forbidden" issue. You can also add this new line directly to the web server plugin-cfg.xml without referring to the WAS admin console provided you know the application context path.
Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/ABC/*"/

In the end, the whole issue is because of the missing 1 liner in the config file. Well, i think the time spent on troubleshooting is well worth it. At least i have learned more on the web and app server configuration. Special thank to my sifu, Jenny :).

CVS: creating repository from existing config

Quick guide to create new CVS repository in the existing server setup.

--create new directory in CVS server, the path should be your new repository dir location
mkdir /var/cvsroot

--we need to grant access to all user who have access to the server, R implies recursive into all subdir
chown -R cvsuser:cvsgroup /var/cvsroot
--the cvsgroup could differ in the server setup

--without this, user couldn't check in code cos of short of privilege, change to dir mode to read&write
chmod g+rwxs /var/cvsroot

--initialise the cvs repository, which will populate all cvs related config into the directory
cvs -d /var/cvsroot init