Thursday, February 5, 2015

SSH-No further authentication methods available

F-Secure “No further authentication methods available” Error Message

I was presented with this error:
Server responded “No further authentication methods available.”
No more authentication methods available.
when trying to connect to a  secure site using F-Secure SSH Client 5.3.
F-Secure SSH Client allows you to control a remote Linux machine running SSH (Secure Shell) server using a Windows machine. One of the main differences between F-Secure SSH Client and PUTTY, another popular SSH Client application, is the support for File Transfer over SFTP (Secure File Transfer Protocol)
Some solutions asked for changes in server configuration files, but I knew that was not my problem because my ssh client was working fine just days before.
To solve this problem, or at least the source of the problem, I needed to add “Keyword Interactive” authentication to my profile. To do that follow this steps:
F-Secure SSH Client Authentication screen

F-Secure SSH Client Authentication screen
  1. Open Settings
  2. Profile » Connection » Authentication
  3. On Authentication Methods, click the “New (Insert)” icon
  4. From the drop-down, choose “Keyword Interactive
After that, I was able to go a bit further, enough to get a message from the server that my password had expired and was prompted to change it. After that I had a successful connection.

Tuesday, November 25, 2014



A memory leak is like a virtual oil leak in your computer. It slowly drains the available memory, reducing the amount of free memory the system can use. Most memory leaks are caused by aprogram that unintentionally uses up increasing amounts of memory while it is running. This is typically a gradual process that gets worse as the program remains open. If the leak is bad enough, it can cause the program to crash or even make the whole computer freeze.
The most common reason programs have memory leaks is due to a programming error where unused memory is not allocated back to the system. This means the amount of RAM the program uses is always growing. Therefore, the program is constantly "leaking" memory. A memory leak may also be caused by a program that requests new memory too frequently, instead of using available memory. This means each time more memory is requested, the program takes up additional RAM instead of using memory that has already been made available to the program.
Fortunately, memory leaks are not as messy as oil leaks and can be more easily fixed. Software development applications often include debuggers that can check programs for memory leaks. Once the source of the leak is found, the programmer can modify the code so that the program uses memory more efficiently. If you are using a program that has a memory leak, you can temporarily fix the problem by simply quitting the program and opening it again. Once the program has been quit, the memory is automatically allocated back to the system. Of course, if the leak continues to be a problem, the best solution is to let the developer know about the issue so it can be fixed.

Wednesday, November 19, 2014

Upgrade to Ubuntu 14.04 LTS from Ubuntu 13.04

Upgrading from point release is very easy. However, if you are skipping one or two releases and upgrading to Ubuntu 14.04 it may not be very straight forward if you go the traditional way. 
But, a simple 5 step command line approach can help you overcome that problem. Below are the steps to upgrade from Ubuntu 13.04 (Raring Ringtail) to Ubuntu 14.04(Trusty Tahr).

Before you start, please remember back up all your documents and all other data that you consider important. 

Disclaimer: Please follow the instructions at your own risk. I assume you have some knowledge of Linux and can troubleshoot. I am not responsible if your laptop/desktop goes up in flames!

  1. sudo sed -i 's/raring/trusty/g' /etc/apt/sources.list
  2. Disable third party ppas (optional, see note)
  3. sudo apt-get update && sudo apt-get dist-upgrade
  4. sudo apt-get install --reinstall ubuntu-desktop
  5. sudo update-grub
  6. sudo update-initramfs -u

Note: If you have third party ppas installed, you need to disable them. To do that run the following commands before you run the update command
cd /etc/apt/sources.list.d
sudo rename 's/(.*)/$1.bak/' *
sudo find . -type f -name "*" -print | xargs sed -i 's/raring/trusty/g'

Once all have been completed, reboot the system to login to the new Ubuntu 14.04 release.

If you want to enable the 3rd party ppas, just remove the .bak extension. To do that 

cd /etc/apt/sources.list.d
find . -type f -name "*.bak"  -exec rename 's/.bak//' {} \;

Tuesday, November 18, 2014

10 Yum Exclude Examples to Skip Packages for Linux Yum Update (How to Yum Exclude Kernel Updates)

Yum ExcludeWhen you perform yum update, it will download the latest version of all the packages that are installed on your system, and upgrade them to the latest version.
You may be in situation where you might not want yum to automatically update one (or more) specific package.
In those situations, use the yum exclude option as shown in the examples below.

1. Exclude a Single Package using option -x

For example, on this system, we are using PHP 5.1, and the custom php application running on this system is not tested with any other new versions of PHP yet.
# rpm -q php
So, in this case when we do a update, we want to exclude only one specific package, which is php. As we see below, the following indicates that php package will be updated to ver 5.3.3 when we perform the ‘yum update’ command.
# yum check-update php
php.x86_64    5.3.3-40.el6_6      updates
The following will exclude only one package (php) during the yum update.
# yum -x php update

2. Exclude Multiple Packages using option -x

You can exclude multiple packages by specifying multiple -x options as shown below:
yum -x php -x httpd update
You can also exclude more than one package by specifying the list of packages separated by comma. The following will behave exactly same as above.
yum -x php,httpd update

3. Exclude Multiple Packages (e.g. Kernel packages) using Wildcard

In most situations you might not want yum update to automatically upgrade the kernel.
Before you do the real yum update, you can perform yum check-update, which will display all the packages that it will upgrade during the yum update.
As you see below, in this example, there are three kernel related packages that will be upgraded by yum update.
# yum check-update | grep -i kernel
kernel.x86_64            2.6.32-504.1.3.el6  updates
kernel-firmware.noarch   2.6.32-504.1.3.el6  updates
kernel-headers.x86_64    2.6.32-504.1.3.el6  updates
Instead of specifying all the individual package names in the -x exclude list, we can simply use the shell glob wildcards as shown below. The following will exclude all kernel related packages form begin upgraded during the yum update.
yum -x kernel* update

4. Multiple Wildcard Lists in the -x Option

You can also specify multiple wildcard lists in the -x option.
As you see below, the following indicates that there are multiple php packages that will be upgraded during next yum update.
# yum check-update | grep -i php
php.x86_64         5.3.3-40.el6_6   updates
php-cli.x86_64     5.3.3-40.el6_6   updates
php-common.x86_64  5.3.3-40.el6_6   updates
php-xml.x86_64     5.3.3-40.el6_6   updates
If you want to exclude all php and kernel related packages during the next yum update, you can use the following. Please note that you should use ‘ ‘ in this example.
yum -x 'php*' -x 'kernel*' update

5. Using –exclude instead of -x

You can also use –exclude instead of -x as shown below:
yum --exclude php update
yum --exclude httpd update
yum --exclude kernel update

yum -exclude php*,httpd*,kernel* update

6. Exclude Packages Using yum.conf File

Instead of specifying the packages to be excluded in the command line, you can specify them in the /etc/yum.conf file.
For example, to exclude all the php, httpd and kernel packages to be excluded from the yum update, add the following line:
exclude=php* httpd* kernel*
Or, execute the following command:
echo "exclude=php* httpd* kernel*" >> /etc/yum.conf

7. Use Comma Separated List

You can also exclude more than one package by specifying the list of wildcard packages separated by comma. The following will behave exactly same as above.
yum -x php*,kernel* update
To be consistent with the way how we showed the other examples using the -x option above, you can also use comma (instead of just space) to separate the multiple packages as shown below:
# vi /etc/yum.conf

8. Exclude Parameter inside Custom Repo File

Instead of specifying the exclude parameter in the main yum.conf file, you can also specify it in the individual repository file.
For example, if you’ave installed mongodb, you’ll have mongodb.repo under /etc/yum.repos.d directory. You can specify the exclude package list for the mongodb repository inside this mongodb.repo file.
# vi /etc/yum.repos.d/mongodb.repo

9. Simulate Yum Exclude Check using check-update (Dry-run -x)

You can specify the -x option along with check-update also. This helps to you check whether the -x option you’ve specified either in the command line or in the yum.conf file is working as expected.
For example, the following indicates that the kernel will be upgraded during yum update.
# yum check-update | grep -i kernel
kernel.x86_64                        2.6.32-504.1.3.el6                  updates
kernel-firmware.noarch               2.6.32-504.1.3.el6                  updates
kernel-headers.x86_64                2.6.32-504.1.3.el6                  updates
The following indicates that the -x flag will work as expected as it didn’t return anything in the result.
# yum -x kernel* check-update | grep -i kernel
For example, let us say the following exclude line in present in the yum.conf file.
# grep exclude /etc/yum.conf
Then, the following indicates that the exclude list specified in the above /etc/yum.conf will work as expected as check-update didn’t show those packages (including kernel) in the following output.
# yum check-update | egrep 'php|httpd|kernel'

10. Ignore the Exclude from yum.conf File

If you like to disable the excludes mentioned in the yum.conf file. i.e If you don’t want yum update to consider the exclude list that is specified in the yum.conf file, you can use the –disableexcludes option from the command line.
In our previous example, we’ve excluded php, httpd and kernel packages to be updated by the yum update.
But, if you want yum to ignore that exclude list (i.e disable the exclude) and continue to upgrade the php, httpd and kernel as part of the regular yum update command, execute the following:
yum --disableexcludes=all update
The following are the three possible values that you can specify to the disableexcludes
  • all Disable all excludes
  • main Disable excludes specified in the main section of the yum.conf file
  • repoid Disable excludes specified for the given repo id
If you want to disable the excludes only for a specific custom repository, you can specify the repo id (which is the 1st column in the yum repolist command as shown below).
# yum repolist
repo id   repo name           status
mongodb   MongoDB Repository    240
base      CentOS-6 - Base     6,518
extras    CentOS-6 - Extras      35
updates   CentOS-6 - Updates    315
The following will disable (ignore) the exclude list specified in the mongodb.repo file under /etc/yum.repos.d directory.
yum --disableexcludes=mongodb update

Tuesday, July 15, 2014

Linux: Check inode usage in folders from High to Low

Inodes are temporarily files stored on your server which are currently in use and not closed. They could be cache, temporary files or anything related and could be created in several different ways.
Your server most likely has an inode usage quota (especially on VPS and shared hosting accounts) and if you exceed this it has a very similar effect to exceeding your actual disk space or random access memory (ram). The server locks up and services start failing one by one in a random fashion.
Below is a command to see the directories with the highest to lowest inode usage on your server, in the current directory. Doing this in your server root might take very long so best is to CD into the folder/directory where you expect the high inode usage might be and then execute this command:
List of top 10 inodes
[root@root]# find -maxdepth 1 -mindepth 1 -type d |while read dir ; do echo -n "$dir - " ; find "$dir" |wc -l; done|sed 's|^./||'|column -t|sort -rnk3|head -n10
List of All inodes 
[root@root]# find -maxdepth 1 -mindepth 1 -type d |while read dir ; do echo -n "$dir - " ; find "$dir" |wc -l; done|sed 's|^./||'|column -t|sort -rnk3

Once you see which folders/directories have the highest inode usage, you can cd into them until you find the folder with the actual problem. It could be a cache folder or a folder storing temporary images or something related.

Monday, July 14, 2014

Freeing up Inodes - Cleaning Inodes

Today I run into a weird problem. When I tried to open my (Serendipity) blog I got this strange error:

Query failed: 

 ORDER BY timestamp DESC

/ Can't create/write to file '/tmp/#sql_6ee_0.MYI' (Errcode: 28)
I was kind of puzzled. All other sites were working fine (such us wiki and list of pim prototypes). I sshed to a server and checked the disk usage:
myusername@pim:~$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             3.8G  3.0G  685M  82% / 
Everything fine here. I checked the /tmp folder
myusername@pim:/tmp# ls -la 
total 32
drwxrwxrwt  4 root root 20480 Apr 18 12:42 .
drwxr-xr-x 22 root root  4096 Apr 18 11:20 ..
drwxrwxrwt  2 root root  4096 Mar 24 22:42 .ICE-unix
Nothing strange here either. I tried to login to mysql:
myusername@pim:/tmp$ mysql -u myusername -p
Enter password: 
Welcome to the MySQL monitor
Everything worked fine. So I checked the ERROR 28 the web page was giving me
myusername@pim:/tmp$ perror 28
OS error code  28:  No space left on device
tried to create a file with no success:
myusername@pim:/tmp$ touch bla.txt
touch: cannot touch `bla.txt': No space left on device
Then I googled a bit and found out that I might be running out of inodes.
myusername@pim:/tmp$ df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1             250976  250957      19  100% /
Yep, that was it. Now I had to find which folder had a lot of files that were taking up the inodes (as root). Not all results are shown in the below output.
myusername@pim:/var$ cd /
myusername@pim:/$ sudo bash 
root@pim:/$ for i in /*; do echo $i; find $i -type f | wc -l; done
/bin 91
/boot 23
/dev 346
/etc 745
/home 5
/lib 1709
/media 0
/proc 11435
/root 5
/sbin 103
/sys 3863
/tmp 0
/usr 45188
/var    186774
went to /var and run the same command
root@pim:/var$ for i in ; do echo $i; find $i -type f | wc -l ;done
backups 1
cache 55
lib 173682
log 47
mail 2
run 16
spool 19
www 12950
So I needed to check /var/lib
mkljun@pim:/var/lib$ for i in ; do echo $i; sudo find $i -type f | wc -l ;done
apt 9
doc-base 37
dpkg 2342
misc 2
mlocate 1
mysql 665
php5 170453
screen-profiles 21
ucf 23
xml-core 2
The folder /var/lib/php5 contained 170k files! It was kind of strange why all these files were not deleted after a session timeout. I certainly did not have 170k users visiting my pages (I wished this to be true though).
root@pim:/var/lib# cd php5
root@pim:/var/lib/php5# ls -l | wc -l
checked the maximum time set for a php5 sessions to live.
root@pim:/var/lib/php5# /usr/lib/php5/maxlifetime
24 minutes. I decided to delete older files.
root@pim:/var/lib/php5# find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 -exec rm {} \;
root@pim:/var/lib/php5# ls -la
total 11768
drwx-wx-wt  2 root     root     12017664 Apr 18 12:35 .
drwxr-xr-x 38 root     root         4096 Sep 22  2010 ..
-rw-------  1 www-data www-data      168 Apr 18 12:23 sess_389b8191e2563e8bb43c41e20e015c0d
-rw-------  1 www-data www-data      118 Apr 18 12:11 sess_52c9acc7779f5cfd7e7e92a900fe7f19
-rw-------  1 www-data www-data      160 Apr 18 12:27 sess_bb8cfa842ceb0027cc9e4082ad8b0419
checked the inodes usage.
root@pim:/tmp# df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1             250976   80524  170452   33% /
That was it. 

Why PHP is not deleting expired sessions is another question. I went to my php.ini file and found this:
; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440

; NOTE: If you are using the subdirectory option for storing session files
;       (see session.save_path above), then garbage collection does not
;       happen automatically.  You will need to do your own garbage
;       collection through a shell script, cron entry, or some other method.
So all I needed to do was to create a cron job (I decided to rut it every hour as root)
root@pim:/tmp# crontab -e 

0      /usr/bin/find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 -exec /bin/rm {} \;

Hopefully this will help some other soul out there.

Clean up inodes in linux

root@server1:/var/www/ df -i
Filesystem      Inodes   IUsed  IFree IUse% Mounted on
/dev/sda       1966080 1957683   8397  100% /
udev            126290     405 125885    1% /dev
tmpfs           127451     320 127131    1% /run
none            127451       4 127447    1% /run/lock
none            127451       1 127450    1% /run/shm

Lets find which folder has the most inodes
root@server1:/var/www/ cd /; for i in *; do echo -n $i,; find $i -print | wc -l; done

We see that that was VAR folder, run the same command under var.

In our case it was spool/postfix and deferred emails. Here what I did to clean up.
I don’t use postfix at all, so I will basically clear it and disable.

Lets Flush postfix mail queue
postsuper -d ALL
postsuper -d ALL deferred

And now we have
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda       1966080 201470 1764610   11% /
udev            126290    405  125885    1% /dev
tmpfs           127451    320  127131    1% /run
none            127451      4  127447    1% /run/lock
none            127451      1  127450    1% /run/shm
Yappp, now we have enough space.

Tuesday, March 11, 2014

Covert Huawei E3131 USB Storage Mode to Modem Mode in Linux

This is just a quick note on how to get a Huawei E352s-5 working under Linux.  If you buy hardware without researching the internet thoroughly, you'll almost always need some effort to get it working with Linux. Especially if you aren't on the latest distribution. 

Switching  Storage Mode to Modem Mode

If you have inserted your SIM card, plugged in the Huawei E352s-5 stick and your distribution recognized it... you can stop reading here. But if you are on an old distribution like I am, you'll probably need to use usb_modeswitch to get it working. First of all, let's see what dmesg says after inserting the stick:$ dmesg
[   48.220072] usb 2-5: new high speed USB device using ehci_hcd and address 4
[   48.362048] scsi5 : usb-storage 2-5:1.4
[   48.367660] scsi6 : usb-storage 2-5:1.5
[   49.365716] scsi 5:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
[   49.368325] sr1: scsi-1 drive
[   49.368854] sr 5:0:0:0: Attached scsi CD-ROM sr1
[   49.369011] sr 5:0:0:0: Attached scsi generic sg2 type 5
[   49.372964] scsi 6:0:0:0: Direct-Access     HUAWEI   SD Storage       2.31 PQ: 0 ANSI: 2
[   49.374988] sd 6:0:0:0: Attached scsi generic sg3 type 0
[   49.380995] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[   49.511962] ISO 9660 Extensions: Microsoft Joliet Level 1
[   49.542715] ISOFS: changing to secondary root
So the device seems to register as an USB Mass Storage device, running lsusb shows us the the Vendor and Product ID:$ lsusb
Bus 002 Device 008: ID 12d1:14fe Huawei Technologies Co., Ltd. 
Great! So let's see how to switch the device into its Modem mode. There is a nice open source project calledusb_modeswitch, which does the job. The usb_modeswitch coming with my Ubuntu 10.10 is rather outdated, so I'll build it from source. You'll need libusb-dev to build it, so if you haven't installed it yet you can simply install it via apt-get (or your distributions package manager). usb_modeswitch seems to play fine with most of the libusb-dev versions:
sudo apt-get install libusb-dev
Next we'll download, unpack and install the most recent versions of usb_modeswitch and its usb_modeswitch-data, available at:
Installing is easy, I guess you are familiar with the commands (if not comment below):
# Download sources:
# Extract the source:
tar xjf usb-modeswitch-1.2.5.tar.bz2
# Change directory:
cd usb-modeswitch-1.2.5
# Install it:
sudo make install
Do the same for the usb_modeswitch-data, which contains a lot of udev scripts, that might cover your hardware already:
tar xjf usb-modeswitch-data-20121109.tar.bz2
cd usb-modeswitch-data-20121109
sudo make install
The new usb_modeswitch overrides the old version, so there's no need to take care about old installations! Withusb_modeswitch it's easy to switch the Huawei E352-s into the Modem mode. A quick research reveals the switching command, I guess it's the packet Windows sends to the device in order to switch modes. I really don't feel the need to sniff it by myself (you have to run the commands as root):
usb_modeswitch -v 12d1 -p 14fe -M '55534243123456780000000000000011062000000100000000000000000000' 
Now running lsusb reveals a new Product ID:$ lsusb
Bus 002 Device 022: ID 12d1:1506 Huawei Technologies Co., Ltd
Using the option module should register the modem:
modprobe option
echo "12d1 1506" > /sys/bus/usb-serial/drivers/option1/new_id
Running dmesg (or looking at /var/log/messages if you prefer) reveals:$ dmesg
[ 1471.905063] usb 2-5: new high speed USB device using ehci_hcd and address 12
[ 1472.039036] option 2-5:1.0: GSM modem (1-port) converter detected
[ 1472.039214] usb 2-5: GSM modem (1-port) converter now attached to ttyUSB0
[ 1472.039374] option 2-5:1.1: GSM modem (1-port) converter detected
[ 1472.039522] usb 2-5: GSM modem (1-port) converter now attached to ttyUSB1
[ 1472.039647] option 2-5:1.2: GSM modem (1-port) converter detected
[ 1472.039751] usb 2-5: GSM modem (1-port) converter now attached to ttyUSB2
[ 1472.039893] option 2-5:1.3: GSM modem (1-port) converter detected
[ 1472.039997] usb 2-5: GSM modem (1-port) converter now attached to ttyUSB3
[ 1472.040173] option 2-5:1.4: GSM modem (1-port) converter detected
[ 1472.040268] usb 2-5: GSM modem (1-port) converter now attached to ttyUSB4
[ 1472.040404] option 2-5:1.5: GSM modem (1-port) converter detected
[ 1472.040496] usb 2-5: GSM modem (1-port) converter now attached to ttyUSB5
The modem should be usable by now and your network-manager should ask you for the PIN to unlock the device. Congratulations!

udev rules

If you don't want to impress people by remembering these cryptic lines, you could write two udev rules to execute these commands whenever the device is added to the USB subsystem. Store it to /etc/udev/rules.d/70-huawei_e352.rules for example.
Filename /etc/udev/rules.d/70-huawei_e352.rules:
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="14fe", RUN+="/usr/sbin/usb_modeswitch -v 12d1 -p 14fe -M '55534243123456780000000000000011062000000100000000000000000000'"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="14fe", RUN+="/bin/bash -c 'modprobe option && echo 12d1 1506 > /sys/bus/usb-serial/drivers/option1/new_id'"
And reload the rules:
udevadm control --reload-rules
And that's it basically! Your stick should now be put into Modem mode automatically, whenever you plug it in.

final note

I have noticed, that my Ubuntu 10.10 modem-manager sometimes has problems to recognize the device after reattaching it. This happens especially after restoring my system from hibernation. Restarting the network-managerservice doesn't help here either. I know it doesn't sound great, but killing the modem-manager process works great for me:$ ps ax | grep modem-manager
 3914 ?        S      0:00 /usr/sbin/modem-manager$ sudo kill 3914
It is automatically restarted by the network-manager and the magic happens. If I have some time, I might take a look at it. But I guess it has been fixed in recent versions or doesn't apply to the Unity-based Ubuntu distributions at all.

useful links

Friday, February 21, 2014

Google Chrome can not be run as root in Linux(Centos/Ubuntu)


First and foremost, you should never run a web browser as root, in fact you should not run any software as root when you don’t have to. If you still wish to run chrome as a root nobody can stop you

How to run Google Chrome as root.

Right click on the launch icon and select properties.  Append the following to the command in the launcher --user-data-dir
This is what it will look like

/opt/google/chrome/google-chrome %U

just change it to be

/opt/google/chrome/google-chrome --user-data-dir %U

If you can’t find the launcher then you have to add it to panel or to your desktop. Select Applications-->Internet-->Google Chrome, right click on it and select Add this launcher to panel or Add this launcher to Desktop. Once you find the launcher icons, follow the steps above to run Chrome as a root user.

Command : /usr/bin/google-chrome-stable %U

[root@localhost ]# /usr/bin/google-chrome-stable --user-data-dir %U

Wednesday, February 19, 2014

How to detect IP address conflicts in Linux

IP addresses are a scarce resource that is shared by different users and devices. Having an IP address conflict means that there are more than one network device or computer that claims the same IP address. IP address conflict may occur when a DHCP server has assigned an IP address to one computer, and the same IP address happens to be statically assigned to another network device by someone.

IP address conflict can also happen when there are more than one DHCP server (typically built in a router) hooked up to the local network, autonomously giving out IP addresses from the same subnet. If you are having flaky network connectivity, and suspect it is due to IP address conflicts, you can use a tool called arp-scan to detect IP address conflicts in Linux.
arp-scan sends out ARP packets on local network to collect (IP address, Ethernet MAC address). If there is more than one Ethernet MAC address claiming the same IP address, it means there is an IP conflict.
To install arp-scan on Ubuntu or Debian:
$ sudo apt-get install arp-scan
To install arp-scan on CentOS, Fedora or Redhat:
$ sudo yum install arp-scan
To detect IP address conflicts with arp-scan, run the following.
$ sudo arp-scan -I eth0 -l   00:1b:a9:63:a2:4c       BROTHER INDUSTRIES, LTD.   00:1e:8f:58:ec:49       CANON INC.   00:25:4b:1b:10:20       Apple, Inc   10:9a:dd:55:d7:95       Apple Inc   20:c9:d0:27:8d:56       (Unknown)   d4:85:64:4d:35:be       Hewlett Packard   00:0b:46:e4:8e:6d       Cisco (DUP: 2)   90:2b:34:18:59:c0       (Unknown)
According to the example output shown above, IP address is in conflict, where two different MAC addresses are claiming the same IP address.

Friday, February 14, 2014

Diffrence between .bash_profile vs .bashrc

HEN working with Linux, Unix, and Mac OS X, I always forget which bash config file to edit when I want to set my PATH and other environmental variables for my shell. Should you edit .bash_profile or .bashrc in your home directory?
You can put configurations in either file, and you can create either if it doesn’t exist. But why two different files? What is the difference?
According to the bash man page.bash_profile is executed for login shells, while .bashrc is executed for interactive non-login shells.

What is a login or non-login shell?

When you login (type username and password) via console, either sitting at the machine, or remotely via ssh:.bash_profile is executed to configure your shell before the initial command prompt.
But, if you’ve already logged into your machine and open a new terminal window (xterm) inside Gnome or KDE, then .bashrc is executed before the window command prompt. .bashrc is also run when you start a new bash instance by typing /bin/bash in a terminal.

Why two different files?

Say, you’d like to print some lengthy diagnostic information about your machine each time you login (load average, memory usage, current users, etc). You only want to see it on login, so you only want to place this in your.bash_profile. If you put it in your .bashrc, you’d see it every time you open a new terminal window.
      .bashrc------->after login GNOME/KDE