Saturday, December 8, 2007
That day it snowed very heavily; so much that on the way back to home I had to drive no more than 40 MPH while usually I do no less than 75 MPH!
Saturday, September 8, 2007
# yum install mplayer
I don't like the default skin though. So I installed the mplayer skins package:
# yum install mplayer-skins
After installing the skins package, I opened the mplayer skin browser and bang! No skin except the default one was available!! Research revealed that it's a small, but annoying, bug in the skins package which installs skins in a wrong directory. Check out details of this bug here.
Luckily, the resolution is very simple. All you need to do is execute this:
# cd /usr/share/mplayer/skins/
# ln -s ../Skin/* .
After executing these commands, restart mplayer, launch the skin browser and it should have a fairly long list of available skins listed. That's it!
Saturday, September 1, 2007
I am using CentOS 5 with KDE. I use the Kate editor for scripting and programming. Until I started getting insane errors whenever I would try to execute any of my recently developed shell scripts, Kate was configured to save files with Windows end of line format. Now that I changed the end of line format back to UNIX, bash is happy as ever!
Friday, August 24, 2007
After three weeks of stay in NJ, and enjoying a very calm and cool work environment at Macrosoft, I got placed at a client's (Autoweb) site in Rochester Hills, MI. They are developing the new generation of a well-known product for the automotive industry. The main function of this product is providing a platform for sharing intellectual property data and collaboration among first tier automotive vendors like General Motors and Ford, and their suppliers.
My role in the development of this project is v. critical. In a nutshell, I am developing a component that would enable the old product and its new incarnation to work together seamlessly. This component's ultimate goal is to gradually migrate all clients from the old product to the new one and to enable vendors and suppliers to continue IP collaboration in the mean time regardless of which product they are using.
As you can see, this component which I am developing for my client is v. important for the success of the new product. And because we have almost run out of time-to-deadline, we're working not only long hours but weekends as well. And it's been like this for a month, non-stop. Man, this tough schedule! I didn't have to work like that even in Pakistan.
This is for you Pakis who always complaint that we have but unorganized software development industry where every other project is a chaos. Trust me, it's no better here either. In fact, software development is such a challenging and complex task that if it's not exercised with due caution and expertise, you're almost guaranteed to end up with a project that is a nightmare to develop, maintain, and evolve.
Stay tuned for more updates.
Tuesday, June 26, 2007
New Jersey is a very green and calm state. It's really an ideal place to live in. It's been a week since I'm living and working in NJ and I'm really lovin' it!
Saturday, June 2, 2007
New_Face failed. Maybe the font path is wrong. Please supply the text font file (~/.mplayer/subfont.ttfThe player also failed to play any media files. Any attempt to play an audio or video would result in a player crash. This later problem was resolved by following the instructions in the mplayer FAQs. Please note that this problem is specific to Fedora, RHEL, and CentOS.
The earlier font problem caused no issues as the player was able to play any media files. However, as you would expect, it was very, very annoying. Research revealed that solving this problem was as simple as copying any font file to the ~/.mplayer/ directory and renaming it to subfont.ttf. You can see the fonts available on your system by navigating to fonts:/ in your file browser (nautilus or konqueror).
Sunday, May 13, 2007
On Linux systems, you use the crontab tool to schedule tasks that you want carried out on a certain time. Scheduled tasks are called cron jobs. The Linux Task Scheduler (read cron) has several parts to it:
1. The crond Daemon
crond is the workhorse that carries out the real job: executing specified tasks at the specified time. It's a daemon that runs calmly in the background and checks crontab files once every minute and executes tasks whose scheduled time matches the current time.
2. The crontab Tool
crontab is the tool that you use for editing your crontab file.
3. The crontab File
crontab files contain scheduling information of tasks.
The following sections examine each component of the cron system in detail.
The crond Daemon
The crond daemon is responsible for executing tasks at their scheduled time. It gets started automatically by rc scripts at system startup. So, you don't need to mess with it. But there might be times when you want to interact directly with the daemon. Here are a few useful commands to interact with the crond daemon or any other daemon for that matter:
To query status of crond:
# service crond status
To stop crond:
# service crond stop
To start crond:
# service crond start
To stop and start crond in one fell swoop:
# service crond restart
Please note that the service command resides in /sbin directory. On some Linux distros, notably Fedora Core, RHEL, and CentOS, this directory is not referenced in the PATH environment variables. To work around this, you need either to modify the PATH variable in your ~/.bash_profile file to reference /sbin or you need to specify the full path to the service command, i.e., /sbin/service.
The crond daemon executes cron jobs using the /bin/sh shell. Therefore, any environment variables that are available in /bin/sh shell are also available to cron jobs when they are executing.
The crontab Tool
crontab files are not meant to be edited directly. They are edited using the crontab tool. An important thing to note is that crontab files are created on a per-user basis. Whether or not a user can create crontab files is determined by cron.allow and cron.deny files in the /etc directory. Here's how the crontab tool determines permissions:
If neither cron.allow nor cron.deny files exist, only the root user can create crontab files.
If only cron.allow exists, the crontab tool allows a user to create crontab files if and only if her name is listed explicitly in the file. Other users are denied to create crontab files.
If only cron.deny exists, the crontab tool doesn't allow a user to create crontab files if her name is listed explicitly in the file. Other users are allowed to create crontab files.
If both cron.allow and cron.deny exist, the crontab tool doesn't allow a user
to create crontab files unless her name is explicitly listed in the cron.allow file. Other users are denied to create crontab file irrespective of whether their name is listed in the cron.deny file or not.
By default, the crontab tool executes for the user who is issuing the command. If you want to execute a command for a particular user, you'll need to specify the -u option followed by the user name whose crontab file you want to manipulate.
To edit your crontab file:
$ crontab -e
It will open your crontab file in an editor (usually vi) specified by the VISUAL or EDITOR environment variables. You'll need to edit the crontab file and save it. The crontab tool will take care of placing the file in an appropriate location.
To list contents of your crontab file:
$ crontab -l
To remove your crontab file:
$ crontab -r
If you need to list contents of the crontab file of a particular user, say jdoe, you'll execute the following command:
# crontab -u jdoe -l
The crontab file
Here is the format of the crontab file:
Minute Hour Day Month Day-Of-Week Command-To-Execute
Please note that you specify time in military format. Day-Of-Week runs from 0 through 6 representing Sunday through Saturday. Here are some examples of cron jobs:
If you want to shutdown your system at 23:59 every day except Saturday and Sunday, here's how you do it:
# 59 23 * * 1,2,3,4,5 shutdown "now"
Please note that if you want to specify multiple values for a given parameter, you separate them using commas (,) just as I did to specify Monday through Friday using 1,2,3,4,5.
Here's a cron job that executes every 5 minutes and appends current time to a file in the home directory of user jdoe:
# */5 * * * * echo "cron job executed at " $(date) >> /home/ejan/cron.out
Please note how we specified */5 to specify "every five minutes" rather than entering 0,5,10,15,...,55. If you want to execute your cron job at a regular interval like every five minutes, you can simply specify it using */5.
I hope his article will get you up to speed with scheduling tasks in Linux.
Sunday, May 6, 2007
I've seen no other book that is more easy to follow, complete, practical, and fun to read than this one. If you hear someone saying administering Linux is difficult, just ask them to have a copy of this text. And I bet they'll be recommending it to *every* head interested in learning to administer Linux.
Have fun reading the book!
Friday, May 4, 2007
The following syntax works perfect for mounting samba shares:
|mount -t cifs -o user=username //servername/sharename mountpoint|
1. For the -t parameter smbfs *won't* work. That value for the -t parameter has retired and no longer supported.
2. If you specify a user whose password is *blank*, you'll need to press enter when prompted for password. In this case, mount will fail with a permission denied error. So always specify a user who does have a password.
then you can mount nothing but the directory RootShare. Trying to mount any of the sub-directories will result in the following error:
| retrying with upper case share name |
mount error 6 = No such device or address
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
I hope this makes up for a crystal clear solution to a *very* common problem. Try googling for it and you'll see it seems like everyone on this planet has gone through this problem