Showing posts with label Troubleshooting. Show all posts
Showing posts with label Troubleshooting. Show all posts

Sunday, October 3, 2010

Trouble Uninstalling IE9?

Just couple of days back I wrote a post on IE9 beta release. I saw it buggy and was wondering if some of you has problem uninstalling this buggy piece from your PC. Let me tell you that - you can't simply go to Add/Remove program and uninstall it easily, like you have been doing it for other piece of software. Well, here is how to do it -

  1. Start -> Run -> appwiz.cpl
  2. Here you won't see any entry for IE9 in the main program list. Click on the 'View installed updates link' in the sidebar to see the installed updates.
  3. Scroll down till you see a section for Microsoft Windows and find "Windows Internet Explorer 9" in it.
  4. Right click on the entry and click on the 'Uninstall' button.
  5. After the update is removed you will be reverted to the last installed version of Internet Explorer on your PC.

This above steps are what I tested in Windows 7 .

Enjoy your earlier favorite(!) version of IE browser!!

-DK

Saturday, October 2, 2010

Script written in Win is not working in *nix environment?

Have you ever copied a bash or any other script written your favorite windows editor to UNIX environment and saw it does not work?

Yeah? Well its a Line terminator issue between windows and Linux environment. The enter key, in windows appends a CR and LF code into the end of the line; where in *nix only CR is appended at the end of the line.

Check the script with cat -v, if it display something ^M at the end of the line, that means this text file was created under windows environment. And CR LF is causing the execution of bash script to fail.


$cat -v WonderScript.sh

Once identified, this issue can easily be fixed with the dos2unix command.

$dos2unix WonderScript.sh
$chmod +x WonderScript.sh
$./WonderScript.sh

That's it !!

Cheers!
DEBU




Wednesday, September 15, 2010

My Favorite netcat(nc) combinations

Netcat(nc) has always been referred to as the legendary Swiss Army Knife of Networking. It is a single binary, which takes up about some KB of space of space on your disk, but yet so handy!! Below are some of my netcat favorite I use time to time.

See which ports are open on a particular server.

#nc -v -w 2 -z 172.16.80.70 1-65535

Checking disk status of a set of server mentioned in a text file wslist.txt


#for i in `cat wslist.txt`; do echo $i; ssh -q $i df -h|grep /data$|awk '{ if($5>=90) {print $5 "->Disk Danger"} else { print "Disk OK"}}' ; done

Check if port 22 is open a list of server mentioned in wslist.txt

#for i in `cat wslist.txt`; do nc -v -w 1 -z $i 22 ; done

Transfer a file from Server A to Server B on a specified port.

Server B
nc -l 1337 > dk.txt

Server A
nc 172.16.80.70 1337 <>

[rick@TestBox ~]# nc -l 1337
Hey Debu,did you know we can chat on the console like this?
@Rick, yeah! It's so cool man..


[debu@c00000005221 ~]$ nc 172.16.80.70 1337

Hey Debu,did you know we can chat on the console like this?
@Rick, yeah! It's so cool man..


Ctrl+d


Network Scan:


range="172.16.80."; port=80; for host in $(seq 1 255); do multi_task=$(result=$(nc -zv $range$host $port 2>&1 | grep succeeded); if [ -n "$result" ]; then echo $range$host":"$port >> "/tmp/pscan"; fi;) & done



Cheers!

DK

Wednesday, July 21, 2010

Identify a set of unresponsive servers!!

Crisis! Outage!! My online server repository is also down. Need to figure out quickly which and all server is Alive. Luckily I have a list of servers, and I know the subnet of quite a few of them. This is how would I go about -

for i in `cat wslist.txt`; do nc -v -w 1 -z $i 22 ; done
for i in `cat wslist.txt`; do nmap -sP -n $i ; done | grep down

With the help of Broadcast address,
# ifconfig | grep Bcast
inet addr:172.19.17.143 Bcast:172.19.17.255 Mask:255.255.254.0
and then,
# ping -b 172.19.17.255

Note: Please remember, some/most of the routers are configured to filter broadcast and multicast packets to prevent broadcast storm, if so, broadcast is useless.

for ((i=1;i<255;i++)); href="http://fping.sourceforge.net/">fping and netdiscover is also used by some gurus.
Do share, your way of quickest discovery of unresponsive hosts.

Cheers!
DEBU

Tuesday, June 22, 2010

Linux - SSH Login Slow

I am probably just going to shed some light on one aspect which recently I saw in one of the servers. But I strongly feel that one should have a very good understanding of how SSH works before even starting to troubleshoot anything on SSH.

Recently I got a complain about one server 'being slow'. I just opened the server and went to grab a cup of coffee. I came back to seat, did some general health check up, logs checking etc. but could not find the box behaving odd. I replied the guy back to recheck if things has settled downed and I logged out. Surprisingly enough he again complains that 'server is slow'. I again logged in. What i saw was server was taking some 15-30 sec, after you provide the password to give the shell. And that was what the user was saying 'server is slow'. When you actually understand the problem(WHAT) - solution(HOW) is easy!!

Luckily my first doubt on network settings was correct. DNS was out of my radar as i am trying to connect with raw ip and not any hostname. Yes! I was correct! It was a wrong gateway issue.

On the problematic server i did try to figure out the default GW and surprisingly i found two entry there -

[root@server5 ~]# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 192.168.2.7 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.2.6 0.0.0.0 UG 0 0 0 eth0

[root@server5 ~]# ping 192.168.2.7
PING 192.168.2.7 (192.168.2.7) 56(84) bytes of data.

--- 192.168.2.7 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms

So first GW it self is wrong, and does not exist.

[root@server5 ~]# ping 192.168.2.6
PING 192.168.2.6 (192.168.2.6) 56(84) bytes of data.
64 bytes from 192.168.2.6: icmp_seq=1 ttl=255 time=1.48 ms
64 bytes from 192.168.2.6: icmp_seq=2 ttl=255 time=1.53 ms


I quickly validate the correct GW on some other server and found that none of these two are actually a valid one, which our network team confirmed. So decided to change Default GW on the problematic server.

[root@server5 ~]# route del default

[root@server5 ~]# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 192.168.2.6 0.0.0.0 UG 0 0 0 eth0

[root@server5 ~]# route del default

[root@server5 ~]# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0

Added a new valid gateway:

[root@leserver5 ~]# route add default gw 192.168.2.8

[root@server5 ~]# route
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
169.254.0.0 * 255.255.0.0 U 0 0 0 eth0
default 192.168.2.8 0.0.0.0 UG 0 0 0 eth0

SSH login looks OK now.

My writing of this post was not to end up here, at this point. Rather, to analyze what was the blockade the wrong GW had posed to make the login process slow and revisit how SSH actually works and how much imp. it is - to have a right gateway, even though you might have multiple (kinda) capable GW in your network. I was accessing these server from outside. Saying so what i meant was, for the reverse packet to flow back, default gateway was needed as i was on other subnet/network. So this server was actually trying to get through the first gateway i.e. 192.168.2.7, which was giving us a RTO on ping. The second one i.e. 192.168.2.6 was somehow capable of, but this has a NAT to a already expired contract ISP vendor, which could have gone anytime in a day or two, and somehow the right gateway was not added to this server. I could not test and validate BUT i am almost sure that, this issue would not be faced if i am doing a ssh from the local network.

Earlier I found SSH slow login issue on two more occasions - once it was a X-Forwarding issue and the other was DNS look-up issue.Do leave some comment below if you have faced this issue for some other factor.



Cheers!!!

  🔭 First Impression: Exploring Grafana Mimir              ... After Years with Thanos! Not an observability( OE ) purist, but I do appreci...