[8:20 PM | 0 comments ]

Note: All the commands tested on CentOs 5.x.

Your output may be vary depending on distribution and version, so your results may not always look exactly like the listings and figures shown here. Almost all everything works well on RHEL/CentOs/Fedora.

Why to check signature of an rpm:
The signature confirms that the package was signed by an authorized party and also confirm the integrity and origin of your file. It is extremely important to verify the signature of the RPM files before installing them to ensure that they have not been altered from the original source of the packages.

Checking a package's Signature:
The --checksig(or -K) option checks all the digests and signatures contained in PACKAGE_FILE to ensure the integrity and origin of the package. Note that signatures are now verified whenever a package is read, and --checksig is useful to verify all of the digests and signatures associated with a package.

If you wish to verify that a package has not been corrupted or tampered with, examine only the md5sum by typing the following command at a shell prompt (where is the file name of the RPM package):

rpm -K --nosignature

The message : md5 OK is displayed. This brief message means that the file was not corrupted by the download. To see a more verbose message, replace -K with -Kvv in the command.

For demonstration purpose I downloaded createrepo package from CentOs mirror and used in examples.

[root@localhost ~]# rpm -K --nosignature createrepo-0.4.11-3.el5.noarch.rpm createrepo-0.4.11-3.el5.noarch.rpm: sha1 md5 OK

On the other hand, how trustworthy is the developer who created the package? If the package is signed with the developer's GnuPG key,you know that the developer really is who they say they are.

An RPM package can be signed using Gnu Privacy Guard (or GnuPG), to help you make certain your downloaded package is trustworthy. GnuPG is a tool for secure communication; it is a complete and free replacement for the encryption technology of PGP, an electronic privacy program. With GnuPG, you can authenticate the validity of documents and encrypt/decrypt data to and from other recipients. GnuPG is capable of decrypting and verifying PGP 5.x files as well.

During installation,GnuPG is installed by default. That way you can immediately start using GnuPG to verify any packages that you receive from CentOs(RHEL/Fedor a). Before doing so, you must first import CentOs's public key. If you not imported correct public key, you will get following error message.

[root@localhost ~]# rpm -K createrepo-0.4.11-3.el5.noarch.rpm
createrepo-0.4.11-3.el5.noarch.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#e8562897)

Here the GPG in parentheses indicates that there's a problem with the signature, and the message at the end of the line (MISSING KEYS) shows what the problem is. Basically, RPM asked GPG to verify the package against a key(GPG#e8562897) that GPG didn't have, and GPG complained. It means you missed the correct public key.

How to import public keys:
Digital signatures cannot be verified without a public key. An ascii armored public key can be added to the rpm database using --import. An imported public key is carried in a header, and key ring management is performed exactly like package management. For example, all currently imported public keys can be displayed by:

rpm -qa gpg-pubkey*

To verify CentOs (RHEL/Fedora) packages, you must import the CentOs(RHEL/Fedora) GPG key. To do so, execute the following command at a shell prompt:

[root@localhost ~]# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
This will create duplicate copies if one already exists.

To display a list of all keys installed for RPM verification,execute the command
[root@localhost ~]# rpm -qa gpg-pubkey*
gpg-pubkey-e8562897-459f07a4

or

RPM has the capacity to retrieve the key from a Mirror:
[root@ ~]# rpm --import http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
[root@ ~]# rpm -qa gpg-pubkey*
gpg-pubkey-e8562897-459f07a4
gpg-pubkey-e8562897-459f07a4
Note: Depending on distribution and version, you have to change mirror link.

OK, public key imported, now check signature of the createrepo rpm.

[root@localhost ~]# rpm -K createrepo-0.4.11-3.el5.noarch.rpm
createrepo-0.4.11-3.el5.noarch.rpm: (sha1) dsa sha1 md5 gpg OK
This means that the signature of the package has been verified, and that it is not corrupted. If you want to know public key builder's name , execute the command:

[root@~]# rpm -qa gpg-pubkey\* --qf "%{name}-%{version}-%{release}-%{summary}\n"
gpg-pubkey-e8562897-459f07a4-gpg(CentOS-5 Key (CentOS 5 Official Signing Key))
gpg-pubkey-e8562897-459f07a4-gpg(CentOS-5 Key (CentOS 5 Official Signing Key))
gpg-pubkey-2689b887-42315a9a-gpg(Hewlett-Packard Company (HP Codesigning Service ))

Note: For showing difference I imported HP GPG key.
If you're the curious type and you want to know more information about imported
GPG key, use the following command.

rpm -qi

[root@localhost data]# rpm -qi gpg-pubkey-e8562897-459f07a4
Name : gpg-pubkey Relocations: (not relocatable)
Version : e8562897 Vendor: (none)
Release : 459f07a4 Build Date: Fri 07 Oct 2011 05:53:03 PM IST
Install Date: Fri 07 Oct 2011 05:53:03 PM IST Build Host: localhost
Group : Public Keys Source RPM: (none)
Size : 0 License: pubkey
Signature : (none)
Summary : gpg(CentOS-5 Key (CentOS 5 Official Signing Key) )
Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: rpm-4.4.2.3 (NSS-3)

mQGiBEWfB6MRBACrnYW6yKMT+MwJlCIhoyTxGf3mAxmnAiDEy6HcYN8rivssVTJk
CFtQBlBOpLV/OW2YtKrCO2xHn46eNfnMri8FGT8g+9JF3MUVi7kiV1He4iJynHXB
+F2ZqIvHf3IaUj1ys+p8TK64FDFxDQDrGQfIsD/+pkSGx53/877IrvdwjwCguQcr
Ioip5TH0Fj0OLUY4asYVZH8EAIqFHEqsY+9ziP+2R3/FyxSllKkjwcMLrBug+cYO
LYDD6eQXE9Mq8XKGFDj9ZB/0+JzK/XQeStheeFG75q3noq5oCPVFO4czuKErIRAB
qKbDBhaTj3JhOgM12XsUYn+rI6NeMV2ZogoQCC2tWmDETfRpYp2moo53NuFWHbAy
XjETA/sHEeQT9huHzdi/lebNBj0L8nBGfLN1nSRP1GtvagBvkR4RZ6DTQyl0UzOJ
RA3ywWlrL9IV9mrpb1Fmn60l2jTMMCc7J6LacmPK906N+FcN/Docj1M4s/4CNanQ
NhzcFhAFtQL56SNyLTCk1XzhssGZ/jwGnNbU/aaj4wOj0Uef5LRGQ2VudE9TLTUg
S2V5IChDZW50T1MgNSBPZmZpY2lhbCBTaWduaW5nIEtleSkgPGNlbnRvcy01LWtl
eUBjZW50b3Mub3JnPohkBBMRAgAkBQJFnwekAhsDBQkSzAMABgsJCAcDAgMVAgMD
FgIBAh4BAheAAAoJEKikR9zoViiXKlEAmwSoZDvZo+WChcg3s/SpNoWCKhMAAJwI
E2aXpZVrpsQnInUQWwkdrTiL5YhMBBMRAgAMBQJFnwiSBYMSzAIRAAoJEDjCFhY5
bKCk0hAAn134bIx3wSbq58E6P6U5RT7Z2Zx4AJ9VxnVkoGHkVIgSdsxHUgRjo27N
F7kBDQRFnwezEAQA/HnJ5yiozwgtf6jt+kii8iua+WnjqBKomPHOQ8moxbWdv5Ks
4e1DPhzRqxhshjmub4SuJ93sgMSAF2ayC9t51mSJV33KfzPF2gIahcMqfABe/2hJ
aMzcQZHrGJCEX6ek8l8SFKou7vICzyajRSIK8gxWKBuQknP/9LKsoczV+xsAAwUD
/idXPkk4vRRHsCwc6I23fdI0ur52bzEqHiAIswNfO521YgLk2W1xyCLc2aYjc8Ni
nrMX1tCnEx0/gK7ICyJoWH1Vc7//79sWFtX2EaTO+Q07xjFX4E66WxJlCo9lOjos
Vk5qc7R+xzLDoLGFtbzaTRQFzf6yr7QTu+BebWLoPwNTiE8EGBECAA8FAkWfB7MC
GwwFCRLMAwAACgkQqKRH3OhWKJfvvACfbsF1WK193zM7vSc4uq51XsceLwgAoI0/
9GxdNhGQEAweSlQfhPa3yYXH
=o/Mx
-----END PGP PUBLIC KEY BLOCK-----
You can view above PGP public key block directly by:

vi /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

Depending on distribution, change file path.

Linux Crontab: Cron Job Examples

[9:00 PM | 0 comments ]

An experienced Linux sysadmin knows the importance of running the routine maintenance jobs in the background automatically.

Linux Cron utility is an effective way to schedule a routine background job at a specific time and/or day on an on-going basis.

Linux Crontab Format

MIN HOUR DOM MON DOW CMD

Table: Crontab Fields and Allowed Ranges (Linux Crontab Syntax)
Field	Description	Allowed Value
MIN	Minute field	0 to 59
HOUR	Hour field	0 to 23
DOM	Day of Month	1-31
MON	Month field	1-12
DOW	Day Of Week	0-6
CMD	Command	Any command to be executed.

1. Scheduling a Job For a Specific Time Every Day

The basic usage of cron is to execute a job in a specific time as shown below. This will execute the Full backup shell script (full-backup) on 10th June 08:30 AM.

Please note that the time field uses 24 hours format. So, for 8 AM use 8, and for 8 PM use 20.

30 08 10 06 * /home/ramesh/full-backup

30 – 30th Minute
08 – 08 AM
10 – 10th Day
06 – 6th Month (June)
* – Every day of the week

2. Schedule a Job For More Than One Instance (e.g. Twice a Day)

The following script take a incremental backup twice a day every day.

This example executes the specified incremental backup shell script (incremental-backup) at 11:00 and 16:00 on every day. The comma separated value in a field specifies that the command needs to be executed in all the mentioned time.

00 11,16 * * * /home/ramesh/bin/incremental-backup

00 – 0th Minute (Top of the hour)
11,16 – 11 AM and 4 PM
* – Every day
* – Every month
* – Every day of the week

3. Schedule a Job for Specific Range of Time (e.g. Only on Weekdays)

If you wanted a job to be scheduled for every hour with in a specific range of time then use the following.

Cron Job everyday during working hours

This example checks the status of the database everyday (including weekends) during the working hours 9 a.m – 6 p.m

00 09-18 * * * /home/ramesh/bin/check-db-status

00 – 0th Minute (Top of the hour)
09-18 – 9 am, 10 am,11 am, 12 am, 1 pm, 2 pm, 3 pm, 4 pm, 5 pm, 6 pm
* – Every day
* – Every month
* – Every day of the week

Cron Job every weekday during working hours

This example checks the status of the database every weekday (i.e excluding Sat and Sun) during the working hours 9 a.m – 6 p.m.

00 09-18 * * 1-5 /home/ramesh/bin/check-db-status

00 – 0th Minute (Top of the hour)
09-18 – 9 am, 10 am,11 am, 12 am, 1 pm, 2 pm, 3 pm, 4 pm, 5 pm, 6 pm
* – Every day
* – Every month
1-5 -Mon, Tue, Wed, Thu and Fri (Every Weekday)

4. How to View Crontab Entries?

View Current Logged-In User’s Crontab entries

To view your crontab entries type crontab -l from your unix account as shown below.

ramesh@dev-db$ crontab -l
@yearly /home/ramesh/annual-maintenance
*/10 * * * * /home/ramesh/check-disk-space

[Note: This displays crontab of the current logged in user]

View Root Crontab entries

root@dev-db# crontab -l
no crontab for root

Crontab HowTo: View Other Linux User’s Crontabs entries

To view crontab entries of other Linux users, login to root and use -u {username} -l as shown below.

root@dev-db# crontab -u sathiya -l
@monthly /home/sathiya/monthly-backup
00 09-18 * * * /home/sathiya/check-db-status

5. How to Edit Crontab Entries?

Edit Current Logged-In User’s Crontab entries

To edit a crontab entries, use crontab -e as shown below. By default this will edit the current logged-in users crontab.

ramesh@dev-db$ crontab -e
@yearly /home/ramesh/centos/bin/annual-maintenance
*/10 * * * * /home/ramesh/debian/bin/check-disk-space
~
"/tmp/crontab.XXXXyjWkHw" 2L, 83C

[Note: This will open the crontab file in Vim editor for editing.
Please note cron created a temporary /tmp/crontab.XX... ]

When you save the above temporary file with :wq, it will save the crontab and display the following message indicating the crontab is successfully modified.

~
"crontab.XXXXyjWkHw" 2L, 83C written
crontab: installing new crontab

Edit Root Crontab entries

root@dev-db# crontab -e

Edit Other Linux User’s Crontab File entries

To edit crontab entries of other Linux users, login to root and use -u {username} -e as shown below.

root@dev-db# crontab -u sathiya -e
@monthly /home/sathiya/fedora/bin/monthly-backup
00 09-18 * * * /home/sathiya/ubuntu/bin/check-db-status
~
~
~
"/tmp/crontab.XXXXyjWkHw" 2L, 83C

6. Schedule a Job for Every Minute Using Cron.

Ideally you may not have a requirement to schedule a job every minute. But understanding this example will will help you understand the other examples mentioned below in this article.

* * * * * CMD

The * means all the possible unit — i.e every minute of every hour through out the year. More than using this * directly, you will find it very useful in the following cases.

When you specify */5 in minute field means every 5 minutes.
When you specify 0-10/2 in minute field mean every 2 minutes in the first 10 minute.
Thus the above convention can be used for all the other 4 fields.

7. Schedule a Background Cron Job For Every 10 Minutes.

Use the following, if you want to check the disk space every 10 minutes.

*/10 * * * * /home/ramesh/check-disk-space

It executes the specified command check-disk-space every 10 minutes through out the year. But you may have a requirement of executing the command only during office hours or vice versa. The above examples shows how to do those things.

Instead of specifying values in the 5 fields, we can specify it using a single keyword as mentioned below.

There are special cases in which instead of the above 5 fields you can use @ followed by a keyword — such as reboot, midnight, yearly, hourly.

Table: Cron special keywords and its meaning
Keyword	Equivalent
@yearly	0 0 1 1 *
@daily	0 0 * * *
@hourly	0 * * * *
@reboot	Run at startup.

8. Schedule a Job For First Minute of Every Year using @yearly

If you want a job to be executed on the first minute of every year, then you can use the @yearly cron keyword as shown below.

This will execute the system annual maintenance using annual-maintenance shell script at 00:00 on Jan 1st for every year.

@yearly /home/ramesh/red-hat/bin/annual-maintenance

9. Schedule a Cron Job Beginning of Every Month using @monthly

It is as similar as the @yearly as above. But executes the command monthly once using @monthly cron keyword.

This will execute the shell script tape-backup at 00:00 on 1st of every month.

@monthly /home/ramesh/suse/bin/tape-backup

10. Schedule a Background Job Every Day using @daily

Using the @daily cron keyword, this will do a daily log file cleanup using cleanup-logs shell scriptat 00:00 on every day.

@daily /home/ramesh/arch-linux/bin/cleanup-logs "day started"

11. How to Execute a Linux Command After Every Reboot using @reboot?

Using the @reboot cron keyword, this will execute the specified command once after the machine got booted every time.

@reboot CMD

12. How to Disable/Redirect the Crontab Mail Output using MAIL keyword?

By default crontab sends the job output to the user who scheduled the job. If you want to redirect the output to a specific user, add or update the MAIL variable in the crontab as shown below.

ramesh@dev-db$ crontab -l
MAIL="ramesh"

@yearly /home/ramesh/annual-maintenance
*/10 * * * * /home/ramesh/check-disk-space

[Note: Crontab of the current logged in user with MAIL variable]

If you wanted the mail not to be sent to anywhere, i.e to stop the crontab output to be emailed, add or update the MAIL variable in the crontab as shown below.

MAIL=""

13. How to Execute a Linux Cron Jobs Every Second Using Crontab.

You cannot schedule a every-second cronjob. Because in cron the minimum unit you can specify is minute. In a typical scenario, there is no reason for most of us to run any job every second in the system.

14. Specify PATH Variable in the Crontab

All the above examples we specified absolute path of the Linux command or the shell-script that needs to be executed.

For example, instead of specifying /home/ramesh/tape-backup, if you want to just specify tape-backup, then add the path /home/ramesh to the PATH variable in the crontab as shown below.

ramesh@dev-db$ crontab -l

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/home/ramesh

@yearly annual-maintenance
*/10 * * * * check-disk-space

[Note: Crontab of the current logged in user with PATH variable]

15. Installing Crontab From a Cron File

Instead of directly editing the crontab file, you can also add all the entries to a cron-file first. Once you have all thoese entries in the file, you can upload or install them to the cron as shown below.

ramesh@dev-db$ crontab -l
no crontab for ramesh

$ cat cron-file.txt
@yearly /home/ramesh/annual-maintenance
*/10 * * * * /home/ramesh/check-disk-space

ramesh@dev-db$ crontab cron-file.txt

ramesh@dev-db$ crontab -l
@yearly /home/ramesh/annual-maintenance
*/10 * * * * /home/ramesh/check-disk-space

Note: This will install the cron-file.txt to your crontab, which will also remove your old cron entries. So, please be careful while uploading cron entries from a cron-file.txt.

Refer to http://raj-kumar-linux.blogspot.com/

Linux System Administration and Configuration

[8:57 PM | 0 comments ]

After installation, Linux requires configuration and systems administration. Corporate systems need monitoring, backups, updates, as well as system and user management. Ubuntu (apt), CentOS, Fedora and Red Hat (rpm/YUM) Linux server administration and desktop systems adminstration are covered in this tutorial.

This tutorial covers managing, modifying and monitoring a Linux based computer.

Monitor the system:
- # Monitor the system.
- # Process management.
# Memory Usage.
# Filesystems and Storage Devices.
# Mounting CD's, Floppies etc.
# Mounting Network Drives: SMB, NFS
System Users:
- # User Info.
- # User Greetings.
- # Creating a new system user account.
- # Restrict user.
- # SELinux security policies.
- # Operating as root (System Administrator).
System Updates:
- Ubuntu / Debian package management:
  - # APT/dpkg: Adding, updating software.
- Red Hat / Fedora / CentOS / Suse package management:
- # RDIST: Remotely distributing and installing software/files
System Logs:
- # System log files.
- # logrotate - Rotate log files.
Finding files:
- # FIND: Using the find command
- # Finding files on the system.
# File Information/Status/Ownership/Security.
Scheduling tasks:
- # CRON: Scheduling a task
- # AT: Scheduling a task
# Managing Time
# "You have new mail."
# Text Terminal Configuration
# System Hardware Information.
# PERL Administration/Maintenance
# File compression/decompression utilities
# Linux File Packing/Archiving:
- # Linux Backups using TAR (Tape Archive)
# System Fixes
# Admin Scripts
# Links

Refer to http://www.yolinux.com

Understanding Linux configuration files

[3:40 AM | 0 comments ]

Introduction

Every Linux program is an executable file holding the list of opcodes the CPU executes to accomplish specific operations. For instance, the ls command is provided by the file /bin/ls, which holds the list of machine instructions needed to display the list of files in the current directory onto the screen. The behaviour of almost every program can be customized to your preferences or needs by modifying its configuration files.

Is there a standard configuration file format in Linux?

In a word, no. Users who are new to Linux (rightly) feel frustrated that each configuration file looks like a new challenge to figure out. In Linux each programmer is free to choose the configuration file format he or she prefers. Format options range from the /etc/shells file, which contains a list of possible shells separated by a newline, to Apache's complex /etc/httpd.conf file.

What are system configuration files?

The kernel itself may be considered a "program." Why does the kernel need configuration files? The kernel needs to know the list of users and groups in the system, and manage file permissions (that is, determine if a file can be opened by a specific user, according to the permissions, UNIX_USERS). Note that these files are not specifically read by programs, but by a function provided by a system library, and used by the kernel. For instance, a program needing the (encrypted) password of a user should not open the /etc/passwd file. Instead, it should call the system library function getpw(). This kind of function is also known as a system call. It is up to the kernel (through the system library) to open the /etc/passwd file and after that, search for the password of the requested user.

Most of the configuration files in the Red Hat Linux system are in the /etc directory unless otherwise specified. The configuration files can be broadly classified into the following categories:

Access files

*/etc/host.conf*	Tells the network domain server how to look up hostnames. (Normally /etc/hosts, then name server; it can be changed through netconf.)
*/etc/hosts*	Contains a list of known hosts (in the local network). Can be used if the IP of the system is not dynamically generated. For simple hostname resolution (to dotted notation), /etc/hosts.conf normally tells the resolver to look here before asking the network nameserver, DNS or NIS.
*/etc/hosts.allow*	Man page same as hosts_access. Read by tcpd at least.
*/etc/hosts.deny*	Man page same as hosts_access. Read by tcpd at least.

Booting and login/logout

*/etc/issue & /etc/issue.net*	These files are read by mingetty (and similar programs) to display a "welcome" string to the user connecting from a terminal (issue) or through a telnet session (issue.net). They include a few lines stating the Red Hat release number, name, and Kernel ID. They are used by rc.local.
*/etc/redhat-release*	Includes one line stating the Red Hat release number and name. Used by rc.local.
*/etc/rc.d/rc*	Normally run for all run levels with level passed as argument. For example, to boot your machine in the Graphics mode (X-Server), run the following command from your command line: `init 5`. The runlevel 5 is starts the system in graphics mode.
*/etc/rc.d/rc.local*	Not official. May be called from rc, rc.sysinit, or /etc/inittab.
*/etc/rc.d/rc.sysinit*	Normally the first script run for all run levels.
*/etc/rc.d/rc/rcX.d*	Scripts run from rc (X stands for any number from 1 to 5). These directories are "run-level" specific directories. When a system starts up, it identifies the run-level to be initiated, and then it calls all the startup scripts present in the specific directory for that run-level. For example, the system usually starts up and the message "entering run-level 3" is shown after the boot messages; this means that all the init scripts in the directory /etc/rc.d/rc3.d/ will be called.

File system

The kernel provides an interface to display some of its data structures that can be useful for determining the system parameters like interrupts used, devices initialised, memory statistics, etc. This interface is provided as a separate but dummy filesystem known as the /proc filesystem. Many system utilities use the values present in this filesystemf or displaying the system statistics. For example, the file /proc/modules lists the currently loaded modules in the system. This information is read by the command lsmod, which then displays it in a human readable format. In the same way, the file mtab specified in the following table reads the /proc/mount file, which contains the currently mounted filesystems.

*/etc/mtab*	This changes continuously as the file /proc/mount changes. In other words, when filesystems are mounted and unmounted, the change is immediately reflected in this file.
*/etc/fstab*	Lists the filesystems currently "mountable" by the computer. This is important because when the computer boots, it runs the command `mount -a`, which takes care of mounting every file system marked with a "1" in the next-to-last column of fstab.
*/etc/mtools.conf*	Configuration for all the operations (mkdir, copy, format, etc.) on a DOS-type filesystem.

System administration

*/etc/group*	Contains the valid group names and the users included in the specified groups. A single user can be present in more than one group if he performs multiple tasks. For example, is a "user" is the administrator as well as a member of the project group "project 1", then his entry in the group file will look like: `user: * : group-id : project1`
*/etc/nologin*	If the file /etc/nologin exists, login(1) will allow access only to root. Other users will be shown the contents of this file and their logins refused.
*etc/passwd*	See "man passwd". Holds some user account info including passwords (when not "shadowed").
*/etc/rpmrc*	rpm command configuration. All the rpm command line options can be set together in this file so that all of the options apply globally when any rpm command is run on that system.
*/etc/securetty*	Contains the device names of tty lines (one per line, without leading /dev/) on which root is allowed to login.
*/etc/usertty* */etc/shadow*	Contains the encrypted password information for users' accounts and optionally the password aging information. Included fields are: Login name Encrypted password Days since Jan 1, 1970 that password was last changed Days before password may be changed Days after which password must be changed Days before password is to expire that user is warned Days after password expires that account is disabled Days since Jan 1, 1970 that account is disabled
*/etc/shells*	Holds the list of possible "shells" available to the system.
*/etc/motd*	Message Of The Day; used if an administrator wants to convey some message to all the users of a Linux server.

Networking

*/etc/gated.conf*	Configuration for gated. Used only by the gated daemon.
*/etc/gated.version*	Contains the version number of the gated daemon.
*/etc/gateway*	Optionally used by the routed daemon.
*/etc/networks*	Lists names and addresses of networks accessible from the network to which the machine is connected. Used by route command. Allows use of name for network.
*/etc/protocols*	Lists the currently available protocols. See the NAG (Network Administrators Guide) and man page. C interface is getprotoent. Should never change.
*/etc/resolv.conf*	Tells the kernel which name server should be queried when a program asks to "resolve" an IP Address.
*/etc/rpc*	Contains instructions/rules for RPC, which can be used in NFS calls, remote file system mounting, etc.
*/etc/exports*	The file system to be exported (NFS) and permissions for it.
*/etc/services*	Translates network service names to port number/protocol. Read by inetd, telnet, tcpdump, and some other programs. There are C access routines.
*/etc/inetd.conf*	Config file for inetd. See the inetd man page. Holds an entry for each network service for which inetd must control daemons or other servicers. Note that services will be running, but comment them out in /etc/services so they will not be available even if running. Format:
*/etc/sendmail.cf*	The Mail program sendmail's configuration file. Cryptic to understand.
*/etc/sysconfig/network*	Indicates NETWORKING=yes or no. Read by rc.sysinit at least.
/etc/sysconfig/network-scripts/if*	Red Hat network configuration scripts.

System commands

System commands are meant exclusively to control the system, and make everything work properly. All the programs like login (performing the authentication phase of a user on the console) or bash (providing the interaction between a user and the computer) are system commands. The files associated with them are therefore particularly important. This category has the following files of interest to users and administrators.

*/etc/lilo.conf*	Contains the system's default boot command line parameters and also the different images to boot with. You can see this list by pressing Tab at the LILO prompt.
*/etc/logrotate.conf*	Maintains the log files present in the /var/log directory.
*/etc/identd.conf*	Identd is a server that implements the TCP/IP proposed standard IDENT user identification protocol as specified in the RFC 1413 document. identd operates by looking up specific TCP/IP connections and returning the user name of the process owning the connection. It can optionally return other information instead of a user name. See the identd man page.
*/etc/ld.so.conf*	Configuration for the Dynamic Linker.
*/etc/inittab*	This is chronologically the first configuration file in UNIX. The first program launched after a UNIX machine is switched on is init, which knows what to launch, thanks to inittab. It is read by init at run level changes, and controls the startup of the main process.
*/etc/termcap*	A database containing all of the possible terminal types and their capabilities.

Daemons

A daemon is a program running in non-interactive mode. Typically, daemon tasks are related to the networking area: they wait for connections, so that they can provide services through them. Many daemons are available for Linux, ranging from Web servers to ftp servers.

*/etc/syslogd.conf*	The configuration file for the syslogd daemon. syslogd is the daemon that takes care of logging (writing to disk) messages coming from other programs to the system. This service, in particular, is used by daemons that would not otherwise have any means of signaling the presence of possible problems or sending messages to users.
*/etc/httpd.conf*	The configuration file for Apache, the Web server. This file is typically not in /etc. It may be in /usr/local/httpd/conf/ or /etc/httpd/conf/, but to make sure, you need to check the particular Apache installation.
*/etc/conf.modules or /etc/modules.conf*	The configuration file for kerneld. Ironically, it is not the kernel "as a daemon". It is rather a daemon that takes care of loading additional kernel modules "on the fly" when needed.

User programs

In Linux (and UNIX in general), there are countless "user" programs. A most common user program config file is /etc/lynx.cfg. This is the configuration file for lynx, the well-known textual browser. Through this file you can define the proxy server, the character set to use, and so on. The following code sample shows a part of the lynx.cfg file that can be modified to change the proxy settings of the Linux system. These settings apply (by default) to all the users running lynx in their respective shells, unless a user overrides the default config file by specifying --cfg = "mylynx.cfg.

Proxy settings in /etc/lynx.cfg

.h1 proxy
.h2 HTTP_PROXY
.h2 HTTPS_PROXY
.h2 FTP_PROXY
.h2 GOPHER_PROXY
.h2 NEWS_PROXY
.h2 NNTP_PROXY
# Lynx version 2.2 and beyond supports the use of proxy servers that can act as
# firewall gateways and caching servers. They are preferable to the older
# gateway servers. Each protocol used by Lynx can be mapped separately using
# PROTOCOL_proxy environment variables (see Lynx Users Guide). If you have
# not set them externally, you can set them at run time via this configuration file.
# They will not override external settings. The no_proxy variable can be used
# to inhibit proxying to selected regions of the Web (see below). Note that on
# VMS these proxy variables are set as process logicals rather than symbols, to
# preserve lowercasing, and will outlive the Lynx image.
#
.ex 15
http_proxy:http://proxy3.in.ibm.com:80/
ftp_proxy:http://proxy3.in.ibm.com:80/
#http_proxy:http://penguin.in.ibm.com:8080
#ftp_proxy:http://penguin.in.ibm.com:8080/

.h2 NO_PROXY
# The no_proxy variable can be a comma-separated list of strings defining
# no-proxy zones in the DNS domain name space.  If a tail substring of the
# domain-path for a host matches one of these strings, transactions with that
# node will not be proxied.
.ex
no_proxy:demiurge.in.ibm.com, demiurge

Changing configuration files

When changing a configuration file, make sure that the program using that configuration is restarted if it's not controlled by the system administrator or the kernel. A normal user doesn't usually have privileges to start or stop system programs and/or daemons.

The kernel

Changing configuration files in the kernel immediately affects the system. For example, changing the passwd file to add a user immediately enables that user. Also there are some kernel tunable parameters in the /proc/sys directory on any Linux system. The write-access to all these files is given only to the super-user; other users have only readonly access. The files in this directory are classified in the same manner as the Linux kernel source. Every file in this directory represents a kernel data structure that can be dynamically modified to change the system performance.

Note: Before changing any value in any of these files, make sure you know everything about the file to avoid irreparable damage to the system.
Files in the /proc/sys/kernel/ directory

File name	Description
threads-max	The maximum number of tasks the kernel can run.
ctrl-alt-del	If 1, then pressing this key sequence cleanly reboots the system.
sysrq	If 1, then Alt-SysRq is active.
osrelease	Displays the release of the operating system.
ostype	Displays the type of the operating system.
hostname	The host name of the system.
domainname	Network domain of which the system is a part.
modprobe	Specifies whether modprobe should be automatically run at startup, and load the necessary modules.

Daemons and system programs

A daemon is a program that is always running in background, quietly carrying out its task. Common ones are in.ftpd (ftp server daemon), in.telnetd (telnet server daemon), and syslogd (system logging daemon). Some daemons, while running, keep a close watch on the configuration file and reload it automatically when it changes. But most of the daemons do not reload automatically. We need to "tell" them somehow that the configuration file has changed and that it should be reloaded. This can be achieved (on Red Hat Linux systems) by restarting the services using the service command.

For example, if we have changed the network configuration, we need to issue:
service network restart.

Note: The services are most commonly the scripts present in the /etc/rc.d/init.d/* directory and are started by the init when the system is booted. So, to restart the service you can also do the following:
/etc/rc.d/init.d/ start | stop | status
start, stop, and status are the values that these scripts take as input to perform the action.

User programs

A user or system program reads its configuration file every time it is launched. Remember, though, that some system programs are spawned when the computer is turned on, and their behaviour depends on what they read in the configuration files in /etc/. So, the first time a user program is started, the default configuration is read from the files present in the /etc/ directory. Later, the user can customise the programs by using rc and . (dot) files as explained in the next section.

User configuration files: . (dot) files and rc files

We have seen how programs can be easily configured. But what if someone does not like the way a program has been configured in /etc/? A "normal" user cannot simply go into /etc and change the configuration files; they are owned -- from the filesystem's point of view -- by root! This is why most user programs define two configuration files: the first one at a "system" level, located in /etc/; and the other one, "private" to the user, that can be found in his or her home directory.

For example, in my system I have installed the very useful wget utility. In /etc/ there is an /etc/wgetrc file. In my home directory, there is a file named .wgetrc, which describes my customised configuration (which will be loaded only when I, the user run the wget command). Other users may also have the .wgetrc file in their home directory (/home/other); this file will be read, of course, only when the user runs the wget command. In other words, the /etc/wgetrc file provides "default" values for wget, while the /home/xxx/.wgetrc file lists the "customisations" for a certain user. It is important to understand that this is the "general rule," and is not necessarily true for all cases. A program like pine, for instance, does not have any files in /etc/, but only the custom configuration in the users' home directory, in a file named .pinerc. Other programs may only have a default configuration file in /etc/, and may not let users "customize" them (it's the case with only a few of the config. files in the /etc dir.).

Commonly used rc and . (dot) files

Filename	Description
~/.bash_login	Look at "man bash". Treated by bash like ~/.bash_profile if that doesn't exist.
~/.bash_logout	Look at "man bash".Sourced by bash login shells at exit.
~/.bash_profile	Sourced by bash login shells after /etc/profile.
~/.bash_history	The list of commands executed previously.
~/.bashrcÂ	Look at "man bash". Sourced by bash non-login interactive shells (no other files are). Non-interactive shells source nothing unless BASH_ENV or ENV are set.
~/.emacs	Read by emacs at startup.
~/.forward	If this contains an e-mail address, then all mail to owner of ~ will be forwarded to that e-mail address.
~/.fvwmrc ~/.fvwm2rc	Config files for fvwm and fvwm2 (the basic X Window manager).
~/.hushlogin	Look at "man login". Causes a "quiet" login (no mail notice, last login info, or MOD).
~/.mail.rc	User init file for mail program.
~/.ncftp/	Directory for ncftp program; contains bookmarks, log, macros, preferences, trace. See man ncftp. The purpose of ncftp is to provide a powerful and flexible interface to the Internet standard File Transfer Protocol. It is intended to replace the stock ftp program that comes with the system.
~/.profile	Look at "man bash". Treated by bash like ~/.bash_profile if that and ~/.bash_login don't exist, and used by other Bourn-heritage shells too.
~/.pinerc	Pine configuration
~/.muttrc	Mutt configuration
~/.exrc	Configuration of vi can be controlled by this file. Example: set ai sm ruler Writing the above line in this file makes vi set the auto-indentation, matching brackets and displaying line number and rows-columns options.
~/.vimrc	Default "Vim" configuration file. Same as .exrc.
~/.gtkrc	GNOME Toolkit.
~/.kderc	KDE configuration.
~/.netrc	Default login names and passwords for ftp.
~/.rhosts	Used by the r-tools: rsh, rlogin, etc. Very weak security since host impersonation is easy. Must be owned by user (owner of ~/) or superuser. Lists hosts from which users may access this account. Ignored if it is a symbolic link.
~/.rpmrc	See "man rpm". Read by rpm if /etc/rpmrc is not present.
~/.signature	Message text that will be appended automatically to the mail sent from this account.
~/.twmrc	Config file for twm (The Window Manager).
~/.xinitrc	Read by X at startup (not by xinit script). Mostly starts some progs. Example: exec /usr/sbin/startkde If the above line is present in this file, then the KDE Window Manager is started in when the startx command is issued from this account.
~/.xmodmaprc	This file is passed to the xmodmap program, and could be named anything (~/.Xmodmap and ~/.keymap.km, for example).
~/.xserverrc	Run by xinit as the X server if it can find X to execute.
~/News/Sent-Message-IDs	Default mail history file for gnus.
~/.Xauthority	Read and written by xdm program to handle authorization. See the X, xdm, and xauth man pages.
~/.Xdefaults, ~/.Xdefaults-hostname	Read by X applications during startup on hostname. If the -hostname file can't be found, .Xdefaults is looked for.
~/.Xmodmap	Points to .xmodmaprc; Red Hat had (has) .xinitrc using this name.
~/.Xresources	Usually the name for the file passed to xrdb to load the X resources database, to avoid the need for applications to read a long .Xdefaults file. (~/.Xres has been used by some.)
~/mbox	User's old mail.

Resources

Browse more Linux resources on developerWorks.
Browse more Open source resources on developerWorks.

About the author

Subodh Soni has a bachelor of engineering degree in Computer Science and Technology Regional Engineering from College Surat, India. He works for IBM Global Services (IBM Software Labs) in India; he is also a member of the IBM Linux Technology Center, where he concentrates on Linux RAS (Reliability, Availability, and Serviceability). Other areas of interest are operating system internals, Linux system administration, and troubleshooting. You can reach him at subodh@in.ibm.com.

How To Get System Info In Linux

[3:38 AM | 0 comments ]

Here's a list of commands, tips and info that I've compiled from several different sources. I use this as a quick reference when I need to find info about my computer or my operating system.

General System Info

Note: Most hardware info commands should be run as root. Some even show more info when run as root.

Run qtparted or GParted for hard drive and partition info!!!
Also, see KDiskFree. And fdisk -l for info on all partitions.

hardinfo - good report to run; also, check the Details tab.

Ko's Method For Getting A Hardware Report:
This report runs a series of reports, some of which are listed individually further on in this document.
Install through Synaptic the package installation-report.
Then run in a maximized konsole:
report-hw
or
report-hw > hwreport (Sends the output to a textfile called hwreport in your home folder)

sysinfo a nice graphical display, run it from a terminal.

hal-device-manager
kde-hal-device-manager
These packages can be installed from Synaptic. Use kde-hal-device-manager by clicking KMenu > System > Device Manager.

dmidecode -t memory (as root) The dmidecode tool dumps your system’s DMI (Desktop Management Interface) table contents in a human-readable format. This table contains information regarding system’s hardware components, as well as BIOS revisions etc. dmidecode output not only describes system current configuration, but also reports the BIOS limitations on supported CPU speed, Maximum Memory allowed and more.
dmidecode | less (as root) BIOS info and system info (space to page down, q to quit)

uname -a (info on your server)
uname -m machine number (i.e. - i686)
uname -r kernel version

lshw (as root) - list hardware; might want to run lshw | less (space to page-down, q to quit)
lshw-gtk (as root) - download this from Synaptic; it can be started from the terminal; click on any item for info; double click on the the items in bold to drill down; excellent front-end for lshw.

lsb_release -a (release info) (don't forget the underscore) (or see /etc/lsb_release)
***In Mepis Linux 6.5, this command returns:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 6.06.1 LTS
Release: 6.06
Codename: dapper

In Mepis 6.5, one solution for finding the version that you're running is to go to take a look at the login screen.

lspci (as root) (controllers, etc.) (VERY good report; -v is verbose, -vv is very verbose
lspci -tv (as root) shows tree
lsusb, lsusb -tv - list usb devices
lsmod (at root, shows kernel modules currently loaded. Also try lsmod | less)

/proc - there's important info located in this directory! cd /proc, then ls; use cat to read the files in /proc such as cpuinfo, devices, filesystems, meminfo, partitions, swaps, uptime, version, etc.; also, you can cd into the subdirectories in /proc, for example cd driver.
Examples:
cat /proc/cpuinfo (or cat cpuinfo from inside /proc)
cat /proc/version (or cat verson from inside /proc) - version info
cat /proc/swaps (or cat swaps from inside /proc) will show info on each swap partition.

top - display Linux tasks, real-time; system summary info and a list of tasks currently being managed by the kernel - includes a live report on swap being used; type Shift-f to get sort options while running (default sort is k - CPU usage)

htop - even better than top; interactive process viewer can be used to kill processes.

ctrl-esc (from anywhere in KDE) - brings up the ProcessTable

procinfo – procinfo is a small program that gathers some system information from diverse files under /proc and prints it to the screen. It duplicates some of the functionality of free(1) and uptime(1). This also includes lsdev for displaying information about installed hardware and socklist for displaying a list of open sockets.

Other Ways To List Processes:
ps aux
ps -e

swapon -s shows swap partitions and info
swapon -a makes all swap partitions available as indicated in /etc/fstab.

fdisk -l gives all partition info on hard disk(s).

/etc/fstab (the fstab file contains file system configuration information)

free (memory usage, in kilobytes.
free -m (memory usage, in MB).

ksysguard application and ksysguard tray applet both show memory usage

df -h (disk info about all mounted file systems, human-readable)
df -hT (disk info about all mounted file systems, human-readable, showing file system type)

du / -bh | more detailed diskusage for each subdirectory starting at root, human readable; use space to page down, q to quit.
du -s /var/log/* - displays space usage of all the files in /var/log

hdparm -t /dev/hda (as root) - display disk performance of hda

This shows what the cpu identifies itself as:
arch (but it could be wrong, see command below)
rpm --showrc| grep " arch" (if rpm is installed)

ifconfig -a – displays IP address and other info

Time Info Commands:
date
uptime

Package Info

apt-show-versions > InstalledPkgs (as root) - outputs the text file InstalledPkgs to your home directory. This shows all packages on your system. This list won't be alphabetized. You can copy and paste it into a spreadsheet and then sort it. You can download apt-show-versions with Synaptic. See man apt-show-versions for more info. Another option is to look at the installed packages in Synaptic.

ls /var/cache/apt/archives > AddedPkgs outputs the text file AddedPkgs to your home directory. This shows all of the packages that you've added to your system (unless you've deleted this info, or unless Synaptic has been set to delete it!). There's also a "partial" directory, so
ls /var/cache/apt/archives/partial > PartialPkgs to output a text file called PartialPkgs.

To get a package list sorted by size:
dpkg-query -W --showformat='${Installed-Size} ${Package}\n' | sort -n

Here's a section that I tacked on, just so I'd have a quick reference to some helpful bash commands.

Bash Info

echo $PATH show the content of the environmental variable named PATH
echo $? shows the exit code of the last command

help shows a list of shell builtin commands, and help name shows help on the command name; also, see the section on Shell Builtin Commands in man bash

whereis locates the binary, source, and manual page files for a command.

which returns the pathnames of the files which would be executed in the current environment, had its arguments been given as commands in a strictly POSIX-conformant shell. It does this by searching the PATH for executable files matching the names of the arguments. Note: In Mepis Linux, which is an alias for type -path. Although that command is not explicitly defined, try the command help type for more info on the type command. which=type -path may be the same as type -P. In practice, the which command and the type -path command may be equivalent. To see the true which command in action in Mepis Linux, type "which" (use quotes) (or unalias which to permanently remove the alias).

type (name) indicates how it would be interpreted if used as a command name

alias shows a list of all aliases
unalias will remove an alias permanently
"command" quoting the command will run the "true" command (if it exists) instead of the alias

file guesses what type of file
file file
file -i file for more info
file -iz file for compressed files
file -s file for block or special character files

tree – list directory structure and content in a tree-like format; by default lists the contents of the directory that you're in.

cal - current month
cal -3 - last month, current month, and next month
cal [month] year - specify month, or month and year [examples: cal august 2007; cal 2006]

NOTE: This is a Guest Article on the ComputerBob.com Web site. Guest Articles contain reviews, opinions, tips, and other material written by guest authors. Articles may be submitted for possible publication to the email address listed on the Contact page (a Contact link appears at the bottom of every article). ComputerBob edits all submitted articles before publishing them. By submitting an article to ComputerBob, the submitter implicitly grants ComputerBob the right to edit it and to publish it as a Guest Article on the ComputerBob.com web site. Guest Articles reflect the views of their authors only. ComputerBob is not responsible for the accuracy or reliability of Guest Articles.

Refer to http://www.computerbob.com