Thursday, September 30, 2010
Cannot log in to web Albums from picasa while using fedora 12. "Login failied please try again later"
I clicked on the "Sign In to Web Albums" and entered my gmail username and password and got log in failure message. The log in window returned immediately showing "Login failed - Please try again later". The error was thrown in less than a second which was ample reason for me to believe that that this is a problem at my end, not at gmail end.
Searched the web and got the solution suggesting to install "openssl-devel" package on my laptop.
# yum install openssl-devel
Tried to sign in to the web album again, but unfortunately still getting the same error message.
Banged on my head for a couple of minutes and finally realized that Fedora 13 running on my laptop was x86_64 and picasa is a 32 bit application and I must install openssl-devel.i686.
# yum install openssl-devel.i686
I was really happy after that. Everything worked as expected and my engagement photos are now live on picasa.
Sunday, August 8, 2010
Shell scripting gives great advantage to system Administrators and I often use bash in my daily work. Though my work now involves less scripting but for a specific task, i wanted to write a script on my own. The script will take a Project Name as argument, which will would automatically take to that particular Project directory on an NFS share.
For example: Assume that I am working on a Project named MCP1516, then I want my script to take me to that directory. Now you may ask what's the need for a script, just cd command would suffice. But i wanted to do some other things also,
1. If the nfs share is not mounted , then mount the NFS share under /mnt/projects
2. If the project directory doesn't exist, create the Project directory.
3. Reuse this script with other tasks (probably as a function).
Now the script looked like this:
/bin/mount | grep nfs | grep nfs-server 1> /dev/null
if [ $result -eq 0 ]
sudo /bin/mount -t nfs nfs-server:/share/projects /mnt/projects
Seems pretty simple script, Now i call the above script as "takemeto"
Assuming that the directory already exists , the above script when run should change my "pwd" to /mnt/projects/mcp1516, but (un)fortunately it doesn't.
Now the problem is not in the script but the way bash works and the command "cd" .
First of all, when the script is called, the script is run in a new shell , so the command cd is being run in the "Newly created shell", the parent shell, i.e the shell which called the script has no idea about the commands run in the new shell, next cd is not an external command but it's a bash in-built command . So to execute the bash built commands in the current shell or also called Parent shell, use "source" command.
So if you call the same script using source command , it would change the directory in the current shell
$source takemeto mcp1516
So happy scripting :)
Monday, April 12, 2010
Me had a case where an administrator installed a system with just 5GB allocated to /. Later he figured out the log files in /var is quickly growing up and / will fill up very soon. So far /var has logs of size 2GB. He just created another 10GB partition, copied the current contents of /var to it, then mounted the new partition on /var without deleting the current contents in /var.
This administrator did never document this event and quit the company. A new guy stepped in. Later, when he scanned the / filesystem (may be when the / was 100% next time) he found df and du output of / is different. (showing 2GB difference). You can imagine what is the cause?
The worst question is how a Technical Support Engineer figure this out? Wild guesses? But I had to.
Tuesday, February 9, 2010
# gs -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=merged.pdf -dBATCH first.pdf second.pdf
I got this solution through a search in the web.
Wednesday, January 20, 2010
-rw-r-xr--+ 1 root root 151 Jul 31 20:38 test.sh
I had no idea what this "+" indicates about the file or directory. I just searched google to find out without any luck. Every docuemnt that I referred speaks about all other fields displayed in the output, but kept silent about "+". "man ls" has nothing to say about it. But I was not ready to give up, I found out myself what that field indicates. You may already know what is meant by this +, but this blog is intended to explain how did I find it out myself which may be useful for you also if you face a similar situation in future. Below is the method that I followed.
I created a file in /tmp named file.txt. When I did "ls -l" on that file, I didn't see the "+" in the output. Now I have a file which has a + in the "ls -l" output and one which doesn't have.
Now I did strace on "ls -l" while listing both the files. Strace was executed as below.
# strace -fvvv -s 1024 -o
Analyzed both straces and compared them. This comparison helped me to see what is different between these two files.
For the file which has + in its output, I found the below system call in strace.
29608 getxattr("/root/test.sh", "system.posix_acl_access", 0x0, 0) = 44
For the file which doesn't have + in the output, I found the same system call as below.
29616 getxattr("/tmp/file.txt", "system.posix_acl_access", 0x0, 0) = -1 ENODATA (No data available)
29616 getxattr("/tmp/file.txt", "system.posix_acl_default", 0x0, 0) = -1 ENODATA (No data available)
The difference in the output of getxattr() told me that the file which has a "+" in the output has a filesystem acl on it where as the file which doesn't have a "+" in the output has no acls set on it (This is indicated by the "-1 ENODATA (No data available").
I verified this by running "getfacl
"For files that have a default ACL or an access ACL that contains more than the three required ACL entries, the ls(1) utility in the long form produced by ls -l displays a plus sign (+) after the permission string."
Is "man acl" the right place to have this info?