Filed under: *Nix, IRL, Ubuntu, life on the wired | Tags: gutsy, LEAP, network manager, Ubuntu, wireless
I’m currently attending a 4 days training on IBM’ Websphere Application Server. They provide us with a Windows XP loaded laptop. Being a Linux zealot, I ask whether I can use my own laptop.
They also provide a wireless connection (which also connected to the internet) secured by CISCO’s LEAP protocol.
After a lil bit of tinkering, I was able to “extract” the credential used to connect to the wireless connection, and use it on my laptop. Gutsy’s Network Manager applet is able to recognize that it’s a LEAP wireless connection, and properly provided me the option to input the correct username and password.
Day 2
As usual, I boot up my laptop, and logged in. The Network Manager applet immediately tried to connect to the LEAP secured wireless network, but somehow seems to b stuck somewhere. When I hover the mouse over the network manager icon it says “waiting for network key for wireless network xyz..” but it did not show me the windows dialog for entering the LEAP credential.
My immediate suspicion went to the the Gnome Keyring manager. Opened the keyring manager, and check the entry related to the said wireless network. I found out that instead storing the LEAP credential that I provided earlier, the keyring saved the WEP keys that the LEAP protocol provides after authenticating. I decided to delete the keyring which was related to the said wireless connection. No go. Delete all of the keyrings. Nope.
I then created a new user account, and used it to connect to the wireless connection. It worked flawlessly. I was able to choose the right wireless connection, and choose LEAP as the authentication method. This, and the way the keyring behaves when storing credential for LEAP secured wireless connection led me to the conclusion that the reconnection failed due to the Network Manager Applet was unable to automatically determine whether the stored LEAP connection requires LEAP credential. It instead assumes that the wireless connection is secured using only WEP.
I currently haven’t found a solution that can fix the way network manager applet stores the correct information when handling a LEAP authenticated wireless network. The only thing that I can do is to delete any information stored by Network Manager applet, so that it will recognize that wireless connection as a new one, and provides me with the network key window dialog. To delete the stored information do the following on a terminal:
surfer@M5Mobile:~$ cd /home/surfer/.gconf/system/networking/wireless/networks/
surfer@M5Mobile:~/.gconf/system/networking/wireless/networks$ ls -la
total 16
drwx—— 4 surfer surfer 4096 2008-10-29 11:45 .
drwx—— 3 surfer surfer 4096 2008-06-22 21:05 ..
-rw——- 1 surfer surfer 0 2008-10-29 11:41 %gconf.xml
drwx—— 2 surfer surfer 4096 2008-10-29 11:45 xyz
drwx—— 2 surfer surfer 4096 2008-10-29 11:41 MWifo1
Notice that the information for the network xyz which was secured with LEAP was stored on it’s own folder. To delete the information, simply remove the folder.
surfer@M5Mobile:~/.gconf/system/networking/wireless/networks$rm -rf xyz
Restart the laptop. After that you will be provided with the network key dialoga to choose LEAP as the authentication method, and enter the correct username and password. For convenience, you can delete the information before logging out of your laptop.
Filed under: K100D, Pentax, Photography, time out | Tags: Bayu's Wedding, K100D
So the Collection Department of the company that I work for (whose primary task is to collect payment from our clients) have decided to take a drastic turn and deploy a new approach on payment collecting, by hiring a new kind of collector team. They are told not even to smile to our customer!
Rela deh Kalo Debt Collectornya kaya gini 
Kidding 
These fine ladies are a friend of mine from the company that I work for. The pic was taken at Bayu’s wedding reception.
Some time ago, I was asked to setup a public key authentication for SCP session betwen 2 *nix servers. The process should be straight forward, as mentioned on my previous post regarding this subject.
But somehow the login process keep on asking me to enter the correct password, and ignoring the public key that I have copied to the remote server. I start the process in verbose mode, so that I can get meaningful output that can help me solve the issue:
[surfer@kazekiri ~]$ ssh -v mach5@avenger
and this is snipped from the output that I get:
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/surfer/.ssh/identity
debug1: Trying private key: /home/surfer/.ssh/id_rsa
debug1: Offering public key: /home/surfer/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
This means the private key is recognized, and was offered as a mean for authentication by the local server, but somehow the login process still require me to type-in the password for the remote user.
After some reading, I found out the culprit was the access restriction to the key stored on each server. The login process requires that the private key (id_dsa) and the public key stored on the remote server (authorized_keys) are stored on a folder that can only be accessed by the corresponding users. So I need to do the following:
[surfer@kazekiri ~]$ chmod -R 700 .ssh
and, also on the remote server:
[mach5@avenger ~]$ chmod -R 700 .ssh
Aaand, voila! The public key authetication should works.
Filed under: *Nix, HP-UX, Red Hat, Ubuntu | Tags: *Nix, HP-UX, SCP, shell script, unix
So I need to automate a process where an oracle dump file is moved to a remote server, and the existing loacl file is then permanently removed. I have to make sure that:
- the status of copy process is reported, whether successful, or not
- The remove process will only start if the copy process is successful
- The copy process is unattended, so a public key authentication must be available between the local and remote server. I have guide regarding a public key authentication for ssh/scp somewhere around here
This is how the script looked like:
#!/sbin/sh
date >> /backup/movedump.log
tgl=$(date +”%y-%m-%d-%M”)
cd /backup
if [ -f /backup/dumpf* ];
then
scp dumpf* kirim@172.16.2.15:/opt/data/dump/backup/
STAT=$?
echo “$tgl-S1:dump file succesfuly moved” >> /backup/movedump.log
else
STAT=1
fi
if [ $STAT -eq 0 ];
then
rm dumpf*
echo “$tgl-S2:local dump file deleted” >> /backup/movedump.log
else
if [ $STAT -eq 1 ];
then
echo “$tgl-E1:no dump file on source directory, no action taken” >> /backup/movedump.log
else
echo “$tgl-E2:dump file move process exit with code $STAT, remove process not executed” >> /backup/movedump.log
fi
fi
The code above will check whether the dumpfile exists or not. If the file doesn’t exist, the variable STAT will be given a value of 1. If the file exist, it will begin scp process to the remote server. Scp process provide us with several report codes that is stored on “$?”. If the copy process is successful, the value of “$?” is 0, other if it’s not. That value is then stored on the variable STAT
The process then proceed based on the value inserted to the variable STAT
- If STAT=0, the copy process is successful, the script will proceed to remove the dump file on the local server
- if STAT=1, the script did not find a dump file to transfer to remote server
- if STAT value is other than 1 and 0, the transfer process has failed
All of the step taken by the script is logged on file movedump.log
The next step is to make sure the script is executed everyday, automatically. For me, it is scheduled to run 4 pm, everyday:.
$crontab -e
Then put this line:
00 16 * * * /backup/movedump.sh
With this, the script will be executed every day at 4 pm sharp.
Done!
Filed under: time out
fancy busway ticket you got there...
Too bad the EO did not allow camera into the concert hall 
Great show btw..
Filed under: time out
I got tired at looking at my picture looking at me (heh). So I decided that it is time for a new banner!
Filed under: time out
ketupat vs Gulai Nangka vs Opor vs Sambal goreng Hati & Udang
Selamat Hari Raya Idul Fitri, Mohon maaf lahir dan batin. Semoga kita diberi kesempatan untuk bertemu Ramadhan lagi di tahun depan. Nyam!
