How to confirm if IPv6 is running on your system

IPv6 is implemented as a kernel module, so you can use the lsmod command to confirm if it's currently running on your Red Hat system:

$ lsmod | grep ip
ipv6                  410913  36

If lsmod doesn't return anything, it confirms that your system isn't running IPv6.

Prevent IPv6 from getting started by modprobe

As you probably know, modprobe command is used for probing modules upon system boot. Probing simply means a module is loaded and an attempt is made to start it up. With any luck, the module starts successfully and its functionality becomes available to the Linux kernel.

For the boot stage, modprobe uses a special config file which helps you control its behavior: /etc/modprobe.conf. For now, let's just concentrate on the IPv6 task at hand. To make sure modprobe doesn't load the actual module next time your OS reboots, add the following line to the top of the /etc/modprobe.conf file (yes, you're going to need root privileges for this):

install ipv6 /bin/true

WHY THIS WORKS: just to quickly explain the line above, here's why we're using the /bin/true command. install is rule of the modprobe config file which overrides the standard way of probing a module. Effectively, it tells modprobe to just run the specified command for starting a module. In the line above, we're telling modprobe to use the /bin/true command for probing the ipv6 module. And as you remember, /bin/true is a command which doesn't do anything but still returns a successful completion code – so in effect we're doing nothing instead of loading the ipv6 module, and we're looking good while doing this too.

Next, add the the following two lines to the same /etc/modprobe.conf file, and they will ensure that common aliases used for starting the IPv6 module are ignored by modprobe:

alias net-pf-10 off
alias ipv6 off

IMPORTANT: These change doesn't immediately disable IPv6 on your system. Being a pretty important module, IPv6 isn't easy to disable on a live system, and so the easiest is to always follow the changes above with a reboot.

Make sure your IPv6 firewall is disabled

The ip6tables service (/etc/init.d/ip6tables sciprt) is responsible for starting IPv6 firewall, and so you probably want to disable it:

# chkconfig ip6tables off

and then confirm that it won't be started next time you reboot or switch to any runlevel:

# chkconfig --list ip6tables
ip6tables       0:off   1:off   2:off   3:off   4:off   5:off   6:off

That's it, there really is nothing else to disabling IPv6. Let me know if you have any questions, otherwise I'll talk to you soon!

Some of you probably remember the uname command which also shows you similar information, but uname confirms the running kernel of your OS and not the CPU capability: if you're booted into 32bit mode, it will not help you to recognize the 64bit potential of your system.

Obtaining CPU information from /proc/cpuinfo

Most Linux distros will have the special /proc/cpuinfo file which contains a textual description of all the features your processors have. This is a very useful file – depending on your task it may help you identify any features of your processors, as well as confirm the overall number of CPUs your system has installed.

Most commonly, the following information is obtained from /proc/cpuinfo:

• processor model name and type
• processor speed in Mhz
• processor cache size
• instruction flags supported by CPU

Here's how the typical output will look:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      :                   Intel(R) Xeon(TM) CPU 3.20GHz
stepping        : 3
cpu MHz         : 3192.320
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts
acpi mmx fxsr sse sse2 ss ht tm syscall nx lm pni monitor ds_cpl cid cx16 xtpr
bogomips        : 6388.78
clflush size    : 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

The same block of information will be shown for each CPU visible to your system. There will be 2 processor instances for each physical CPU if hyper-treading is enabled, and there will be 2 or 4 processor entries for each physical CPU on dual- and quad-core systems configurations.

How to confirm the 64bit capability of your CPU in Linux

Based on /proc/cpuinfo file, it is quite easy to confirm whether your CPU is capable of 64bit or not. All you have to do is look at the flags which tell you what instruction sets your CPU is capable of.

All  the CPUs on your system will have the same type and therefore support the same instruction sets, that's why in this example the grep command returns 4 similar lines – for the 4 CPU instances found on my system:

newserver# grep flags /proc/cpuinfo
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm pni monitor ds_cpl cid cx16 xtpr
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm pni monitor ds_cpl cid cx16 xtpr
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm pni monitor ds_cpl cid cx16 xtpr
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm pni monitor ds_cpl cid cx16 xtpr

What you're looking for is the following flag: lm. It stands for X86_FEATURE_LM, the Long Mode (64bit) support. If you can find the "lm" flag among your CPU flags, this means you're looking at a 64bit capable processor.

As you can see from the example about, the processors in question are 64bit capable.

And this is how /proc/cpuinfo will look on an older system with only 32bit capable CPUs, there's no lm flag as you can see:

oldserver# grep flags /proc/cpuinfo
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm

That's it, hope this little tip helps you next time you're puzzled about your CPU capabilities!

See also:

• How to install and run 32bit packages on 64bit Debian system
• Confirming whether you're using a 64bit OS
• Unix Glossary
  

useradd and userdel logs in Ubuntu

Both useradd and userdel commands keep logs in many Unix-like systems. This means that every newly created user gets the whole procedure documented in appropriate logs with lines similar to this (it's an Ubuntu example, /var/log/auth.log file):

Jan  6 04:24:27 simplyunix useradd[1456]: new group: name=mike, GID=1006
Jan  6 04:24:27 simplyunix useradd[1456]: new user: name=mike, UID=1006, GID=1006, home=/home/mike, shell=/bin/sh

Similarly, deleting a file doesn't go unnoticed neither:

Jan  6 04:29:21 simplyunix userdel[1516]: delete user `mike'
Jan  6 04:29:21 simplyunix userdel[1516]: delete `mike' from group `admin'
Jan  6 04:29:21 simplyunix userdel[1516]: removed group `mike' owned by `mike'

So, there's a chance that by simply going through /var/log/auth.log you will find the userid of a local Unix user which was recently removed. But the reason I won't say "there's a really good chance" is because most of the logs in /var/log are rotated on a weekly and monthly basis, and this means the information about new users created or deleted may not be there at the time you go looking for it – anyone who was added or deleted more than few months ago will not show up.

useradd and userdel in RedHat Enterprise Linux

Similar to Ubuntu, you can find recent user management activity logged in RHEL system, in /var/log/secure file.

useradd will produce something link this:

Jan  8 00:18:36 rhel5 useradd[2674]: new group: name=newuser, GID=501
Jan  8 00:18:36 rhel5 useradd[2674]: new user: name=newuser, UID=501, GID=501, home=/home/newuser, shell=/bin/bash

… while userdel will document its actions with the following:

Jan  8 00:18:40 rhel5 userdel[2682]: delete user `newuser'
Jan  8 00:18:40 rhel5 userdel[2682]: removed group `newuser' owned by `newuser'

How to check if any users were added on your Unix system

Based on the information above, all you have to do is something like this:

ubuntu$ grep useradd /var/log/* 

This is bound to return you a list of all the recently added users.

How to confirm local users which were recently removed

Similarly, use a command like this to find out if any users were recently removed:

ubuntu$ grep userdel /var/log/* 

Hope this helps! Enjoy!

See also:

• What to do if numerid userids are shown instead of usernames in file ownership
• Creating new users in Unix with useradd
  

Showing processes tree with ptree

In Solaris, there's quite a few commands which make the life of any system administrator much easier, they're the process commands (p-commands). One of them which I particularly like is the ptree command which shows you a list of processes.

As you run the command, you get a hierarchical list of all the processes running on your Solaris system, along with process IDs (PIDs). To me, this is a very useful command, because it shows you how exactly each process relates to others in your system.

Here's a fragment of the ptree output:

bash-3.00$ ptree
7     /lib/svc/bin/svc.startd
  250   /usr/lib/saf/sac -t 300
    268   /usr/lib/saf/ttymon
  260   -sh
    5026  -csh
9     /lib/svc/bin/svc.configd
107   /usr/lib/sysevent/syseventd
136   /usr/lib/picl/picld
140   /usr/lib/crypto/kcfd
159   /usr/sbin/nscd
227   /usr/sbin/rpcbind
234   /usr/lib/nfs/statd
235   /usr/sbin/keyserv
236   /usr/lib/netsvc/yp/ypserv -d
  237   rpc.nisd_resolv -F -C 8 -p 1073741824 -t udp
241   /usr/lib/nfs/lockd
247   /usr/lib/netsvc/yp/ypbind
263   /usr/lib/utmpd
286   /usr/sadm/lib/smc/bin/smcboot
  287   /usr/sadm/lib/smc/bin/smcboot
  288   /usr/sadm/lib/smc/bin/smcboot

Processes tree with pstree

In most Linux distributions, you can find a pstree command, very similar to ptree.

That's how you may use it (-p is an option to show PIDs and -l uses long output format):

ubuntu$ pstree -pl
init(1)─┬─NetworkManager(5427)
        ├─NetworkManagerD(5441)
        ├─acpid(5210)
        ├─apache2(6966)─┬─apache2(2890)
        │               ├─apache2(2893)
        │               ├─apache2(7163)
        │               ├─apache2(7165)
        │               ├─apache2(7166)
        │               ├─apache2(7167)
        │               └─apache2(7168)
        ├─atd(6369)
        ├─avahi-daemon(5658)───avahi-daemon(5659)
        ├─bonobo-activati(7816)───{bonobo-activati}(7817)
...

Showing processes tree with ps –forest

ps command found in Linux has a –forest option, which shows you a tree structure of processes.

The best in my experience is to use it like this:

ubuntu$ ps -aef --forest
UID        PID  PPID  C STIME TTY          TIME CMD
...
107       5473     1  0 10037  4600   0 Apr28 ?        00:00:02 /usr/sbin/hald
root      5538  5473  0  5511  1288   0 Apr28 ?        00:00:00  \_ hald-runner
root      5551  5538  0  6038  1284   0 Apr28 ?        00:00:01      \_ hald-addon-input: Listening on /dev/input
107       5566  5538  0  4167   992   1 Apr28 ?        00:00:00      \_ hald-addon-acpi: listening on acpid socke
root      5600  5538  0  6038  1272   1 Apr28 ?        00:00:15      \_ hald-addon-storage: polling /dev/scd0 (ev
root      5476     1  0 10272  2532   0 Apr28 ?        00:00:00 /usr/sbin/console-kit-daemon
root      5627     1  0 12728  1176   1 Apr28 ?        00:00:00 /usr/sbin/sshd
root      9151  5627  0 17536  3032   0 10:53 ?        00:00:00  \_ sshd: greys [priv]
greys     9162  9151  0 17538  1892   1 10:54 ?        00:00:00      \_ sshd: greys@pts/3
greys     9168  9162  0  5231  3820   1 10:54 pts/3    00:00:00          \_ -bash
greys     9584  9168  0  3802  1124   0 11:27 pts/3    00:00:00              \_ ps -aeF --forest

This output is for demonstration purpose only, and so I've taken the first lines of the output out because they weren't serving the purpose of this example very well.

For thins fragment of the output you can see how you get all the vital information about each process. I really like this way of running the ps command.

That's it for today! Do you know any other neat way of looking at processes tree? Let me know!

From Linux Standard Base article on Wikipedia:

The goal of the LSB is to develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.

One of the immediate benefits of LSB compliancy is ability to confirm the exact information about your Linux release using the lsb_release command. By exact information I mean the release version, vendor name and most interestingly the codename of your current Linux release.

Red Hat Enterprise Linux LSB information

Here's how a Red Hat Enterprise Linux 4 update 4 description will look:

bash-3.00$ lsb_release -a
LSB Version:    :core-3.0-amd64:core-3.0-ia32:core-3.0-noarch:graphics-3.0-amd64:graphics-3.0-ia32:graphics-3.0-noarch Distributor ID: RedHatEnterpriseWS
Description:    Red Hat Enterprise Linux WS release 4 (Nahant Update 4)
Release:        4
Codename:       NahantUpdate4

And here is RHEL5 LSB information:

bash-3.1$ lsb_release -a
LSB Version:    :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: RedHatEnterpriseClient
Description:    Red Hat Enterprise Linux Client release 5 (Tikanga)
Release:        5
Codename:       Tikanga

SUSE Linux Enterprise Desktop (SLED10) LSB

For SUSE Linux Enterprise Desktop, LSB release information will look like this:

sled10~> lsb_release -a
LSB Version:    core-2.0-noarch:core-3.0-noarch:core-2.0-x86_64:core-3.0-x86_64:desktop-3.1-amd64:desktop-3.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch
Distributor ID: SUSE LINUX
Description:    SUSE Linux Enterprise Desktop 10 (x86_64)
Release:        10
Codename:       n/a

Ubuntu LSB release information

In Ubuntu, I find the lsb_release information to be most informational – it's concise but tells you everything you need:

ubuntu$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 7.04
Release:        7.04
Codename:       feisty

See also:

• How to Find Out the Release Version of Your Unix
• Bash: Find The Version of Your Shell

RedHat release

If you simply want to confirm whether you're using a RHEL4, RHEL5 or any of the previous RedHat Linux releases, this is the first place to look:

bash-3.1$ cat /etc/redhat-release
Red Hat Enterprise Linux Client release 5 (Tikanga)

RedHat kernel version and type

Next step is to find out the exact Linux kernel version on your system, and also confirm whether it's 64-bit or not:

bash-3.1$ uname -a
Linux rhserver123 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 x86_64 x86_64 GNU/Linux

RedHat kernel build

For the most curious ones, here's the last command. Use it to confirm who and when compiled the RedHat kernel you're using, and what gcc compiler was used in the build process.

bash-3.1$ cat /proc/version
Linux version 2.6.18-8.el5 (brewbuilder@ls20-bc1-14.build.redhat.com) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Fri Jan 26 14:15:14 EST 2007

See also:

• How To Find Out the Release Version of Your Unix

Enabling TCP connections to X11

In order to make your RHEL4 system accept TCP connections for X11, here's what you need to do:

In /etc/X11/gdm/gdm.conf, uncomment the

#DisallowTCP=true

line and change it to

DisallowTCP=false

That's it! Restart gdm and enjoy!