Cannot log in to web Albums from picasa while using fedora 12. "Login failied please try again later"

Couple of days back, I had to sync some photos from my laptop to Picasa web albums. This was the first time I used Picasa app after installing Fedora 12 in my laptop.

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.

Bash and CD

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,

$cd /mnt/projects/*/mcp1516

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/bash
/bin/mount | grep nfs | grep nfs-server 1> /dev/null
result=`echo $?`

if [ $result -eq 0 ]
then
cd /mnt/projects/*/$1
else
sudo /bin/mount -t nfs nfs-server:/share/projects /mnt/projects
cd /mnt/projects/*/$1
fi

Seems pretty simple script, Now i call the above script as "takemeto"

$takemeto mcp1516

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 :)

Niranjan

Difference in the output du and df?

Found a nice write up here. Just thought it's worth sharing as most people are unaware of this. There is one more nasty reason for df and du to show different output which is not discussed there. May not be worth discussing there.

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.

How to merge pdf files in Linux?

I was about to submit claims for my expenses. I had to scan the receipts and email them to blah blah blah. The scanner gave me multiple pdfs and I preferred to send only one pdf. I had to merge the pdfs and did that by using the below command in my Fedora 10 box.

# gs -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=merged.pdf -dBATCH first.pdf second.pdf

I got this solution through a search in the web.

"+" in the output of "ls -l" stands for what?

Today when I logged into one of my test system and did "ls -l /root", I found a "+" in the output against each file and directory immediately after the permission bits are displayed. One example is given below.

-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 output-file ls -l file-name

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 " on both files. Then I did "man acl" and started reading that and found the below details.

"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?