Friday, August 5, 2011

Fedora yum update slow symptom

I have my netbook installed with Fedora 14 which has been fine-tuned to have better wide-screen display driver, faster start-up and so on. Finally, it takes me more than an hour to do the first "yum update" process which should be finished in 10 minutes in Ubuntu Netbook edition.

People suggest using a yum plugin called fastestmirror:
$
$su -c 'yum install yum-plugin-fastestmirror'


After the installation, it does not really help to boost up the download speed. It is suspected that it takes slow mirror sites for downloading.

Digging into the details of /etc/yum/pluginconf.d/fastestmirror.conf, I found one useful option called "include_only". And then I uncomment one line and change it to:

#
include_only=mirror.aarnet.edu.au

AARNET supposed to be fastest mirror in Australia, so you might want to add your fastest mirror in your own country.

Before executing yum update, it is better to remove the cache file timedhosts.txt which was used for time checking from previous actions:

$
$su -c 'rm /var/cache/yum/i386/14/timedhosts.txt'


Now, run:

$
$su -c 'yum update'

You should be able to pull things from the repository mirror at top speed.

RBAC, pitfall or challenge?

A funny meeting has been held a few days ago while a topic has raised clinical researcher's interest in making good clinical software by using proper role based access control model. It seems to me that RBAC model has been a traditional topic among university students in CS Faculty. It could be a never-ending story when people are trying to find a way to create a generic model for general clinical applications.

When talking about managing tons of various e-health projects, people are always excited in finding an ultimate way to replicate existing model and turn it into a new one. This seems to be a revolution. They might imagine there should be plug-in available for all those web projects they have been working on. A gadget like this might cause those developers to scratch the hairs out of their heads. People might call it generic authentication module or generic adapter for user authentication.

On typical Active Directory based authentication model, local users are authenticated against a central AD server within the domain. How can we apply similar concept of this to make it working among various clinical applications?

We may see those applications as middle clients who need to authenticate the down-stream users for giving out access right and assigning user privilege. The central authentication module can be simply a database instance which stores all those user privileges and functional access rights while the popular webapps hosting on Apache server can make use of the database for central authentication. Different webapps will need different set of data tables to uniquely identify a user particularly for them. The good thing is that we can manage the authentication module at a central location while all other webapps will need to contact this module to collect necessary information for authentication and assigning proper access right to all kinds of features and functions provided locally in the webapps.

I can only tell this is not a new concept but people will realize the convenience of constructing new web projects with an easy way to incorporate user authentication from a third-party database server. Furthermore, we can construct API to bridge those applications developed on Java, C# or Python. This makes me aware of the term called "User Master Index". Similar to managing those patient records, it is more likely for the developers to construct something like "Patient Master Index". They serve the same purpose for a central management of user/patient identity which would be sharing among the applications. Also, the process of constructing the webapps becomes much more efficient.