RAID levels - http://www.acnc.com/04_01_00.html
What is RAID and LVM
RAID is usually defined as Redundant Array of Inexpensive disks. It is normally used to spread data among several physical hard drives with enough redundancy that should any drive fail the data will still be intact. Once created a RAID array appears to be one device which can be used pretty much like a regular partition. There are several kinds of RAID but I will only refer to the two most common here.
The first is RAID-1 which is also known as mirroring. With RAID-1 it's basically done with two essentially identical drives, each with a complete set of data. The second, the one I will mostly refer to in this guide is RAID-5 which is set up using three or more drives with the data spread in a way that any one drive failing will not result in data loss. The Red Hat website has a great overview of the RAID Levels.
There is one limitation with Linux Software RAID that a /boot partition can only reside on a RAID-1 array.
Linux supports both several hardware RAID devices but also software RAID which allows you to use any IDE or SCSI drives as the physical devices. In all cases I'll refer to software RAID.
LVM stands for Logical Volume Manager and is a way of grouping drives and/or partition in a way where instead of dealing with hard and fast physical partitions the data is managed in a virtual basis where the virtual partitions can be resized. The Red Hat website has a great overview of the Logical Volume Manager.
There is one limitation that a LVM cannot be used for the /boot.
# tune2fs -l /dev/hda1 = to see the superblocks
http://www.freeos.com/articles/3921/
http://www.uic.edu/depts/accc/security/os/rhlinux.html
http://www.cyberciti.biz/tips/understanding-unixlinux-filesystem-inodes.html
The inode (index node) is a fundamental concept in the Linux filesystem. Each object in the filesystem is represented by an inode. But what are the objects? Let us try to understand it in simple words. Each and every file under Linux (and UNIX) has following attributes:
=> File type (executable, block special etc)
=> Permissions (read, write etc)
=> Owner
=> Group
=> File Size
=> File access, change and modification time (remember UNIX or Linux never stores file creation time, this is favorite question asked in UNIX/Linux sys admin job interview)
=> File deletion time
=> Number of links (soft/hard)
=> Extended attribute such as append only or no one can delete file including root user (immutability)
=> Access Control List (ACLs)
All the above information stored in an inode. In short the inode identifies the file and its attributes (as above) . Each inode is identified by a unique inode number within the file system. Inode is also know as index number.
$ ls -i /etc/passwd
$ stat /etc/passwd
Linux supports numerous file system types
- Ext2: This is like UNIX file system. It has the concepts of blocks, inodes and directories.
- Ext3: It is ext2 filesystem enhanced with journalling capabilities. Journalling allows fast file system recovery. Supports POSIX ACL (Access Control Lists).
- Isofs (iso9660): Used by CDROM file system.
- Sysfs: It is a ram-based filesystem initially based on ramfs. It is use to exporting kernel objects so that end user can use it easily.
- Procfs: The proc file system acts as an interface to internal data structures in the kernel. It can be used to obtain information about the system and to change certain kernel parameters at runtime using sysctl command. For example you can find out cpuinfo with following command:
# cat /proc/cpuinfo
- Or you can enable or disable routing/forwarding of IP packets between interfaces with following command:
# cat /proc/sys/net/ipv4/ip_forward
# echo "1" > /proc/sys/net/ipv4/ip_forward
# echo "0" > /proc/sys/net/ipv4/ip_forward
- NFS: Network file system allows many users or systems to share the same files by using a client/server methodology. NFS allows sharing all of the above file system.
- Linux also supports Microsoft NTFS, vfat, and many other file systems. See Linux kernel source tree Documentation/filesystem directory for list of all supported filesystem.
You can find out what type of file systems currently mounted with mount command:
$ mount
OR
$ cat /proc/mounts
The blocks used for two different purpose:
- Most blocks stores user data aka files (user data).
- Some blocks in every file system store the file system's metadata. So what the hell is a metadata?
In simple words Metadata describes the structure of the file system. Most common metadata structure are superblock, inode and directories. Following paragraphs describes each of them.
Superblock
Each file system is different and they have type like ext2, ext3 etc. Further each file system has size like 5 GB, 10 GB and status such as mount status. In short each file system has a superblock, which contains information about file system such as:
- File system type
- Size
- Status
- Information about other metadata structures
If this information lost, you are in trouble (data loss) so Linux maintains multiple redundant copies of the superblock in every file system. This is very important in many emergency situation, for example you can use backup copies to restore damaged primary super block. Following command displays primary and backup superblock location on /dev/sda3:
# dumpe2fs /dev/hda3 | grep -i superblock
Exploring the ext3 Filesystem
What is Journaling?
Bill von Hagen
Friday, April 5, 2002 09:53:55 AM
Running fsck on a number of large filesystems can take quite a bit of time, which is not a good thing given today's high-availability assumptions. The reason that inconsistencies may exist in a filesystem that is not cleanly unmounted is that writes to the disk may have been in progress when the system went down. Applications may have been updating the data contained in files and the system may have been updating filesystem metadata, which is "data about filesystem data" - on other words, the information about which blocks are allocated to which files, which files live in which directories, and so on. Inconsistencies in file data are bad enough, but inconsistencies in filesystem metadata are the stuff of which lost files and other operational nightmares are made.
In order to minimize filesystem inconsistencies and minimize system restart time, journaling filesystems keep track of the changes that they will be making to the filesystem before they actually make them to the filesystem. These records are stored in a separate part of the filesystem, typically known as the "journal" or "log". Once these journal records (also commonly known as "log" records) are safely written, a journaling filesystem applies those changes to the filesystem and then purges those entries from the log. Journal records are organized into sets of related filesystem changes, much like changes made to a database are organized into transactions.
Journaling filesystems maximize filesystem consistency because log records are written before filesystem changes are made, and because the filesystem saves these records until they have been safely and completely applied to the filesystem. When rebooting a computer that uses journaling filesystems, the mount program can guarantee the consistency of the filesystem by simply checking the log for pending changes that are not marked as being done and applying them to the filesystem. In most cases, the system doesn't have to check filesystem consistency, meaning that computers using journaling filesystems are available almost instantly after rebooting them. The chances of losing data due to filesystem consistency problems are similarly reduced.
There are a number of journaling filesystems available for Linux. The best known of these are XFS, a journaling filesystem originally developed by Silicon Graphics but now released as open source, the ReiserFS, a journaling filesystem developed especially for Linux, JFS, a journaling filesystem originally developed by IBM but now released as open source, and the ext3 filesystem, developed by Dr. Stephen Tweedie at Red Hat and a host of other contributors.
http://www.cyberciti.biz/tips/howto-flash-your-system-bios-under-linux.html
http://www.thinkwiki.org/wiki/BIOS_Upgrade
# mknod /dev/nvram c 10 144
# insmod nvram
all boot loaders work in a similar way to fulfill a common purpose. But LILO and GRUB do have a number of differences:
* LILO has no interactive command interface, whereas GRUB does.
* LILO does not support booting from a network, whereas GRUB does.
* LILO stores information regarding the location of the operating systems it can to load physically on the MBR. If you change your LILO config file, you have to rewrite the LILO stage one boot loader to the MBR. Compared with GRUB, this is a much more risky option since a misconfigured MBR could leave the system unbootable. With GRUB, if the configuration file is configured incorrectly, it will simply default to the GRUB command-line interface.
What is a file? It is a record in a file system, which
points to a disk area, where data is stored.
1.When You create a hard glink, You create a new entry in the SAME
file system, which points to the same data area.
If You delete, the file, only first entry is erased. The second
entry remains in the filesystem, and file is not deleted.
It may be used, if You want to share some file between some users
So, You cannot distinguish between old file and the hard link.
There is no difference at all!
Limitations: You can make a hard link only on the same device.
If You delete a file, and create it again, You'll have two
different files.
When You create a soft link, You create a new entry, that points
to a disk area, where the name of Your file lays.
If You delete the file, it is deleted and disk area is freed.
The soft link begins pointing to an unexistent file.
Limitations: If You don't have rights to the file, changing rights
to a link cannot help You. So, the example for hard link is
impossible to be solved with soft links.
soft or symbolic is more of a short cut to the original file....if you delete the original the shortcut fails and if you only delete the short cut nothing happens to the original.
hard link is more of a mirror copy....do something to file1 and it appears in file 2
deleting one still keeps the other ok
Hard links share the same inode. Soft links do not.
Hard links can't cross file systems. Soft links do.
Pgrep and pkill
pgrep looks through the currently running processes and lists the process
IDs which matches the selection criteria to stdout. All the criteria have
to match. For example,
pgrep -u root sshd
will only list the processes called sshd AND owned by root. On the other hand,
pgrep -u root,daemon
will list the processes owned by root OR daemon.
pkill will send the specified signal (by default SIGTERM) to each process
instead of listing them on stdout
killall - kill processes by name
WWW prefix in Web addresses
The letters "www" are commonly found at the beginning of Web addresses because of the long-standing practice of naming Internet hosts (servers) according to the services they provide. So for example, the host name for a Web server is often "www"; for an FTP server, "ftp"; and for a USENET news server, "news" or "nntp" (after the news protocol NNTP). These host names appear as DNS subdomain names, as in "www.example.com".
This use of such prefixes is not required by any technical standard; indeed, the first Web server was at "nxoc01.cern.ch",[29] and even today many Web sites exist without a "www" prefix. The "www" prefix has no meaning in the way the main Web site is shown. The "www" prefix is simply one choice for a Web site's host name.
Some Web browsers will automatically try adding "www." to the beginning, and possibly ".com" to the end, of typed URLs if no host is found without them. Internet Explorer, Firefox, Safari, and Opera will also prefix "http://www." and append ".com" to the address bar contents if the Control and Enter keys are pressed simultaneously. For example, entering "example" in the address bar and then pressing either just Enter or Control+Enter will usually resolve to "http://www.example.com", depending on the exact browser version and its settings.
inittab This file describes how the INIT process should set up the system in a certain run-level.
# man init
If init finds that it is continuously respawning an entry more than 10 times in 2 minutes, it will assume that there is an error in the command string, generate an error message on the system console, and refuse to respawn this entry until either 5 minutes has elapsed or it receives a signal. This prevents it from eating up system resources when someone makes a typographical error in the /etc/inittab file or the pro-gram for the entry is removed.
An introduction to services, runlevels, and rc.d scripts
By on January 11, 2006 (8:00:00 AM)
What's the first thing that you do once you've logged onto Linux? Is it to manually start up a processes such as Apache or MySQL, or even start your network connection? Or do you have to stop applications that have started up without your telling them to, and which are overloading your machine? If you have unwanted processes starting at boot time, or find yourself starting necessary services manually, let's make your life a little bit easier by introducing you the world of Linux services.
A Linux service is an application (or set of applications) that runs in the background waiting to be used, or carrying out essential tasks. I've already mentioned a couple of typical ones (Apache and MySQL). You will generally be unaware of services until you need them.
How can you tell what services are running, and more importantly, how can you set up your own?
| System V vs. BSD |
| In this article I'm dealing with System V (derived from AT&T System V) based distributions. This is the most common Linux init system. Another is based on BSD (Berkeley Software Distribution). What's the difference between the two? Basically BSD doesn't have any runlevels. This means that System V gives a lot more flexibility to a system administrator. Most Linux distros put startup scripts in the rc subdirectories (rc1.d, rc2.d, etc.), whereas BSD systems house the system scripts in /etc/rc.d. Slackware's init setup is similar to BSD systems, though Slackware does have runlevels and has had System V compatibility since Slackware 7. |
Let's start by looking at how the system is set up, and in particular at the directory /etc/rc.d. Here you will find either a set of files named rc.0, rc.1, rc.2, rc.3, rc.4, rc.5, and rc.6, or a set of directories named rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, and rc6.d. You will also find a file named /etc/inittab. The system uses these files (and/or directories) to control the services to be started.
If you look in the file /etc/inittab you will see something like:
id:4:initdefault:
l0:0:wait:/etc/rc.d/rc.0
l6:6:wait:/etc/rc.d/rc.6
x1:4:wait:/etc/rc.d/rc.4
The boot process uses these parameters to identify the default runlevel and the files that will be used by that runlevel. In this example, runlevel 4 is the default and the scripts that define runlevel 4 can be found in /etc/rc.d/rc.4.
And what is a runlevel? You might assume that this refers to different levels that the system goes through during a boot up. Instead, think of the runlevel as the point at which the system is entered. Runlevel 1 is the most basic configuration (simple single user access using an text interface), while runlevel 5 is the most advanced (multi-user, networking, and a GUI front end). Runlevels 0 and 6 are used for halting and rebooting the system.
There are, however, differences between Linux distributions. For instance, Fedora uses runlevel 5 for X-based logins, whereas Slackware uses runlevel 4 to do the same job. Therefore, you should check your documentation before making any changes. This table shows a generic list of configurations (and some examples of different distros) taken from Linux - The Complete Reference (R.Peterson, Osbourne/McGraw-Hill).
| Run Level | Generic | Fedora Core | Slackware | Debian | | 0 | Halt | Halt | Halt | Halt | | 1 | Single-user mode | Single-user mode | Single-user mode | Single-user mode | | 2 | Basic multi-user mode (without networking) | User definable (Unused) | User definable - configured the same as runlevel 3 | Multi-user mode | | 3 | Full (text based) multi-user mode | Multi-user mode | Multi-user mode - default Slackware runlevel |
| | 4 | Not used | Not used | X11 with KDM/GDM/XDM (session managers) | Multi-user mode | | 5 | Full (GUI based) multi-user mode | Full multi-user mode (with an X-based login screen) - default runlevel | User definable - configured the same as runlevel 3 | Multi-user mode | | 6 | Reboot | Reboot | Reboot | Reboot | |
As you can see there are slight (but important) differences between Linux distributions. One thing is common between them -- if you want to change the default level, you must edit /etc/initab. You will need to be root or use sudo to edit this file, naturally.
Why would you want to change the runlevel? Normally you will only use full GUI or text multi-user mode -- runlevels 4 or 5. You'd only want runlevels 1 or 2 if you have some system problems and you want the most basic access. Runlevels 0 and 6 should never be used as a default (for obvious reasons -- you don't want the system to shutdown or reboot as soon as you turn it on). You can, of course, change mode whilst the system is running. Type init followed by the required runlevel e.g.:
init 6
This will reboot the system.
The boot process, or to be more accurate the init command, will decide the runlevel to select (in the example above it's 4) and from that will decide the rc.d script files to be run. In this case either the file /etc/rc.d/rc.4 or any files in the directory /etc/rc.d/rc4.d. Let's look at an example rc.d script file. Here's the default rc.4 file for Slackware 10.2:
# Try to use GNOME's gdm session manager:
if [ -x /usr/bin/gdm ]; then
exec /usr/bin/gdm -nodaemon
fi
# Not there? OK, try to use KDE's KDM session manager:
if [ -x /opt/kde/bin/kdm ]; then
exec /opt/kde/bin/kdm -nodaemon
fi
# If all you have is XDM, I guess it will have to do:
if [ -x /usr/X11R6/bin/xdm ]; then
exec /usr/X11R6/bin/xdm -nodaemon
fi
| A quick guide to the boot process |
| When you boot your computer, the first thing that it will do is load the bootloader -- either GRUB or LILO in most cases. The bootloader will then load the Linux kernel -- the core operating system. Next, a process called init starts. This process reads the file /etc/inittab to establish the runlevel to use. The runlevel is the start mode for the computer. Once init knows the runlevel it will look for the appropriate files or directories as defined in /etc/initab. Init will then either run the script files defined by /etc/initab, or run the script files in the directories defined by /etc/initab (depending on the set up of your system). Finally, init will present you with the logon mode that you've selected. |
As you would expect, since runlevel 4 is the Slackware X11 mode, the commands are all concerned with the setting up of the graphical interface.
In the other distros (such as Fedora and Debian) you'll find that the scripts to be run are actually symbolic links to files in the directory /etc/init.d -- the central repository for all startup scripts. So all you have to do is to write your startup script, place it in /etc/init.d, and then create a symbolic link to it from the appropriate runlevel directory (or runlevel file, if that's what your system uses).
For example, runlevel 2 is the default runlevel for Debian in non-GUI mode. If you're running Apache 2 on Debian, you'd find an init script for Apache 2 under /etc/init.d called apache2. A symlink, S91apache2, points to /etc/init.d/apache2 from /etc/rc2.d -- this tells init to start Apache 2 in runlevel 2, but only after other services with lower S numbers.
When the system is shut down, there is another symlink in the /etc/rc0.d and /etc/rc6.d directories (halt and reboot, respectively) that starts with a K instead of an S, which tells init to shut down the process.
If this all still sounds a bit too complicated, you can instead simply make use of the /etc/rc.d/rc.local file. This script file is run once, before all other scripts have run but before the logon prompt appears. By default it looks something like:
#!/bin/bash
#
# /etc/rc.local - run once at boot time
# Put any local setup commands in here:
You can append your instructions onto the end of the file by defining another script to be run:
/root/bin/start_bb
Or you can modify rc.local by adding the commands themselves:
modprobe -r uhci
modprobe usb-uhci
eciadsl-start
iptable -F
iptables -A INPUT -i ppp0 -p tcp --syb -j DROP
netdate time.nist.gov
Here a USB modem is initialized, a connection set up to a broadband network, some basic security is set up, and then the local time is synchronized with a time server. You can also start Apache or MySQL:
apachectl start
echo "/usr/bin/mysqld_safe &" | su mysql
Note that some distros, such as Debian, do not use rc.local for startup scripts. See the Debian FAQ if you'd like to add startup scripts for Debian or Debian-derived distros.
One final thought -- in addition to startup scripts (for rc.local), try to remember to write close-down scripts to be added to rc.0 and rc.6. This ensures that your services are shut down neatly and not left in strange states when the system halts.
About shutting down -- how do you stop a service from starting when you reboot? It's just the reverse of what we've already looked at. Either edit the relevant runlevel file (comment the lines out rather than removing them) or remove the link from the runlevel directory. Note that it may not be necessary to do this manually, as many distros include tools to manage services. For example, Red Hat and Fedora use chkconfig, while Debian uses update-rc.d.
From this brief discussion, I hope you can see how useful rc.d scripts can be when it comes to controlling the services to be run on your PC. You can now add your own as required, as well as look at existing ones that you may not require and which are slowing down your logon or overloading your PC.
In this section I'll briefly describe some of the commonly used diagnostic tools that are available for your Linux network and how you might use them to identify the cause of your network problems, or to teach yourself a bit more about how tcp/ip networking works. I'll gloss over some of the detail of how the tools work because this document is not an appropriate forum for describing that sort of detail, but I hope I'll have presented enough information that you'll have an understanding of how to use the tool and to better understand the relevant man page or other documentation.
The ping tool is located in the NetKit-B distribution as detailed above in the `Network Applications' section. ping, as the name implies, allows you to transmit a datagram at another host that it will reflect back at you if it is alive and working ok and the network in between is also ok. In its simplest form you would simply say:
# ping gw
PING gw.vk2ktj.ampr.org (44.136.8.97): 56 data bytes
64 bytes from 44.136.8.97: icmp_seq=0 ttl=254 time=35.9 ms
64 bytes from 44.136.8.97: icmp_seq=1 ttl=254 time=22.1 ms
64 bytes from 44.136.8.97: icmp_seq=2 ttl=254 time=26.0 ms
^C
--- gw.vk2ktj.ampr.org ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 22.1/28.0/35.9 ms
#
What ping has done is resolved the hostname to an address and using the icmp protocol has transmitted an icmp echo request datagram to the remote host periodically. For each echo request that the remote host receives it will formulate an icmp echo reply datagram which it will transmit back to you. Each line beginning with `64 bytes from ...' represents an echo reply received in response to an echo request. Each line tells you the address of the host that sent you the reply, the sequence number to which the reply was for, the time to live field and the total round trip time that was taken. The round trip time is the time between when the echo request datagram is transmitted and the corresponding echo reply is received. This can be used as a measure of how fast or slow the network connection between the two machines is.
The last two lines tell you how many datagrams were transmitted, how many valid responses were received and what percentage of the datagrams were lost. The percentage lost figure is a measure of how good or error free the network connection is. High percentage lost figures indicate such problems as a high error rate on a link somewhere between the hosts, exhausted capacity on a router or link somewhere, or high collision rate on an ethernet lan. You can use ping to identify where this problem might be by running ping sessions to each of the routed points that make up the network path. When you find that you can ping somewhere without any datagram loss, but pinging anywhere past there causes you packet loss, you can deduce that the problem lies somewhere between those two points.
The traceroute tool is found in the NetKit-A distribution detailed earlier. traceroute is primarily used for testing and displaying the path that your network connection would take to a destination host. traceroute also uses the icmp protocol, but it uses a clever trick to get each point along the path to send it back a reply as it creeps its way along. Its trick is to manually manipulate the time to live field of the datagrams it transmits. The time to live field is a mechanism that ensures that rogue datagrams do not get caught in a routing loop. Each time a datagram passes through a router it decrements the time to live field by one. If the time to live reaches zero then that router or host sends an icmp time to live expired message back to the host who transmitted the datagram to let it know the datagram has expired. traceroute uses this mechanism by sending a series of udp datagrams with the time to live beginning set at one and incrementing each step it takes. By recording the addresses from the icmp time to live expired replies it receives in response to the datagrams dying it can determine the path taken to get to the destination. An example of its use would look something like:
# traceroute minnie.vk1xwt.ampr.org
traceroute to minnie.vk1xwt (44.136.7.129), 30 hops max, 40 byte packets
1 gw (44.136.8.97) 51.618 ms 30.431 ms 34.396 ms
2 gw.uts (44.136.8.68) 2017.322 ms 2060.121 ms 1997.793 ms
3 minnie.vk1xwt (44.136.7.129) 2205.335 ms 2319.728 ms 2279.643 ms
#
The first column tells us how many hops away (what the ttl value was), the second column is the hostname and address that responded if it could be resolved or just its address if it could not. The third, fourth and fifth columns are the round trip time for three consecutive datagrams to that point. This tells us that the first hop in the network route is via gw.vk2ktj and the three figures following are the round trip times to that router. The next hop was via gw.uts.ampr.org and minnie.vk1xwt.ampr.org is one hop further away. You can deduce information about the network route by looking at the difference in times between each step in the route. You can see that the round trip times to gw are fairly fast, it is an ethernet connected host. gw.uts is substantially slower to get to than gw, it is across a low speed radio link, so you have the ethernet time plus the radio link time added together. minnie.vk1xwt is only slightly slower than gw.uts, they are connected via a high speed network.
If you perform a traceroute and you see the string !N appear after the time figure, this indicates that your traceroute program received a network unreachable response. This message tells you that the host or router who sent you the message did not know how to route to the destination address. This normally indicates that there is a network link down somewhere. The last address listed is as far as you get before you find the faulty link.
Similarly if you see the string !H this indicates that a host unreachable message has been received. This might suggest that you got as far as the ethernet that the remote host is connected to, but the host itself is not responding or is faulty.
Adam Caldwell has ported the tcpdump utility to linux. tcpdump allows you to take traces of network activity by intercepting the datagrams on their way in and out of your machine. This is useful for diagnosing difficult to identify network problems.
You can find the source and binaries at: 103mor2.cs.ohiou.edu
tcpdump decodes each of the datagrams that it intercepts and displays them in a slightly cryptic looking format in text. You would use tcpdump if you were trying to diagnose a problem like protocol errors, or strange disconnections, as it allows you to actually see what has happened on the network. To properly use tcpdump you would need some understanding of the protocols and how they work, but it is useful for simpler duties such as ensuring that datagrams are actually leaving your machine on the correct port if you are trying to diagnose routing problems and for seeing if you are receiving datagrams from remote destinations.
A sample of tcpdump output looks like this:
# tcpdump -i eth0
tcpdump: listening on eth0
13:51:36.168219 arp who-has gw.vk2ktj.ampr.org tell albert.vk2ktj.ampr.org
13:51:36.193830 arp reply gw.vk2ktj.ampr.org is-at 2:60:8c:9c:ec:d4
13:51:37.373561 albert.vk2ktj.ampr.org > gw.vk2ktj.ampr.org: icmp: echo request
13:51:37.388036 gw.vk2ktj.ampr.org > albert.vk2ktj.ampr.org: icmp: echo reply
13:51:38.383578 albert.vk2ktj.ampr.org > gw.vk2ktj.ampr.org: icmp: echo request
13:51:38.400592 gw.vk2ktj.ampr.org > albert.vk2ktj.ampr.org: icmp: echo reply
13:51:49.303196 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: S 700506986:700506986(0) win 512
13:51:49.363933 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: . ack 1103372289 win 14261
13:51:49.367328 gw.vk2ktj.ampr.org.telnet > albert.vk2ktj.ampr.org.1104: S 1103372288:1103372288(0) ack 700506987 win 2048
13:51:49.391800 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: . ack 134 win 14198
13:51:49.394524 gw.vk2ktj.ampr.org.telnet > albert.vk2ktj.ampr.org.1104: P 1:134(133) ack 1 win 2048
13:51:49.524930 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: P 1:28(27) ack 134 win 14335
..
#
When you start tcpdump without arguments it grabs the first (lowest numbered) network device that is not the loopback device. You can specify which device to monitor with a command line argument as shown above. tcpdump then decodes each datagram transmitted or received and displays them, one line each, in a textual form. The first column is obviously the time the datagram was transmitted or received. The remainder of the line is then dependent on the type of datagram. The first two lines in the sample are what an arp request from albert.vk2ktj for gw.vk2ktj look like. The next four lines are two pings from albert.vk2ktj to gw.vk2ktj, note that tcpdump actually tells you the name of the icmp datagram transmitted or received. The greater-than (>) symbol tells you which way the datagram was transmitted, that is, from who, to who. It points from the sender, to the receiver. The remainder of the sample trace are the establishment of a telnet connection from albert.vk2ktj to gw.vk2ktj.
The number or name at the end of each hostname tells you what socket number is being used. tcpdump looks in your /etc/services file to do this translation.
tcpdump explodes each of the fields and so you can see the values of the window and mss parameters in some of the datagrams.
The man page documents all of the options available to you.
Note for PPP users: The version of tcpdump that is currently available does not support the PPP suite of protocols. Al Longyear has produced a pair of patches to correct this, but these have not been built into a tcpdump distribution yet. The patch files are located in the same directory on sunsite.unc.edu as the tcpdump package.
ICMP then Internet Control Message Protocol conveys useful information about the health of your IP network. Often ICMP messages are received and acted on silently with you never knowing of their presence. icmpinfo is a tool that will allow you to view ICMP messages much like tcpdump does. Laurent Demailly
Version 1.10 is available from:
hplyot.obspm.fr
/net/icmpinfo-1.10.tar.gz
Compilation is as simple as:
# cd /usr/src
# cd icmpinfo-1.10
# gzip -dc icmpinfo-1.10.tar.gz | tar xvf -
# make
You must be root to run icmpinfo. icmpinfo can either decode to the tty it was called from or send its output to the syslog utility.
To test out how it works, try running icmpinfo and starting a traceroute to a remote host. You will see the icmp messages that traceroute uses listed on the output.
Antivirus Solution for linux
With proper setup and administration, viruses in Linux are the least of your worries, but you still need to worry about Windows clients that connect to your Linux servers. I have been looking at anti-virus programs, designed to run on Linux servers, that can keep viruses from infecting Windows clients on the networks I administer.
There are a growing number of companies and GNU Projects coming forward to provide Linux antivirus products. The Open Antivirus Project aims to provide open source solutions to multiple antivirus needs, including squid-vscan (virus scanning with squid), samba-vscan (on-access virus scanning with Samba), and VirusHammer (a standalone virus scanner to be run by end users). Many other features and projects are planned, like rescue disks and remote management. The Open Antivirus Project also has a project page at http://sourceforge.net/projects/openantivirus/.
Commercial products are becoming available in the mainstream for Linux. McAfee, Trendmicro, Panda Software, Sophos, and Central Command all have products for home Linux users as well as enterprise networks.
Installation for all of these products is straightforward and quite easy. Even novice users should be able to follow along without confusion. Most products provide the same basic capabilities, but some provided additional features, such as mail gateway server protection or file server protection. One thing I found disturbing with most products was the lack of SMP support. I run dual processor servers for better performance. Most of the antivirus programs gave a warning during install about not supporting SMP machines, while some simply would not function after installation under SMP. Trend Micro's ServerProtect, for example, installed nicely on my dual processor Red Hat Linux box, but failed to run. Only after trying to start the daemon manually did I discover that the application would not function on a dual processor box.
Panda Software
Panda Antivirus for Linux
Panda Software provides a free 'command line only' version of their software for use on Red Hat systems. The software can be automated easily by creating a script and then scheduling it to run scans at scheduled times, but real time protection is not possible. Updates to the engine are installed manually after downloading new definition files. If you are going to run a Linux workstation this provides a nice cost-effective solution, but too many features are missing to consider it for deployment for on commercial servers.
Central Command
Vexira Antivirus for Linux
Central Command Vexira Antivirus for Linux provides real time protection for workstations as well as servers with the ability to scan email, files, and downloads from external sites. Updates can be downloaded automatically via the Internet, relieving some administration chores. Vexira also has the ability to scan files automatically as they are accessed, and it offers configurable path protection. It also provides email virus notification, blocks access to infected files, and has options for repair - move - rename - deletion of infected files. Vexira provides a command-line scanner, scans archives (.zip, .gz, .tar, etc), and allows for scalable concurrent scanning. Vexira does not provide support for SMP.
RAV Antivirus
RAV Antivirus Desktop
RAV Antivirus Desktop provides a clean graphic user interface for configuring scan engine settings. With the control center you can modify settings for scheduled scans, scan actions such as clean, ignore, rename, delete, or copy to a quarantine folder, and even automated updates.
RAV Antivirus for Mail Servers provides support for most email servers including Sendmail, Qmail, Postfix, and CommuniGate Pro.
Trend Micro
ServerProtect
Trend Micro's ServerProtect provides virus protection for Linux servers in a mixed Windows environment. Administration is handled through a Web based interface, and allows administrator the ability to run on demand scans, set scan options for real time and on demand scans, and even automatic updates. Because the management console is web based, remote management is made easy. ServerProtect allows administrators to configure automated alerts via email, and SNMP. The logs are easy to read and provide adequate information for dealing with file infections. The down side of this product is its lack of support for newer kernels, and SMP systems.
Sophos
Sophos Antivirus
Sophos Antivirus provides a "command line" version of their software for use on Linux systems. Creating and scheduling scripts can automate scans. Updates must be downloaded and installed manually. This product does a great job of finding and removing viruses, but lacks many features needed by network administrators.
13.4. Taking a Backup Using Snapshots
Following on from the previous example we now want to use the extra space in the "ops" volume group to make a database backup every evening. To ensure that the data that goes onto the tape is consistent we use an LVM snapshot logical volume.
A snapshot volume is a special type of volume that presents all the data that was in the volume at the time the snapshot was created. For a more detailed description, see Section 3.8, Snapshots. This means we can back up that volume without having to worry about data being changed while the backup is going on, and we don't have to take the database volume offline while the backup is taking place.
| 
| In LVM1, this type of volume was read-only, but LVM2 creates read/write snapshots by default. |
13.4.1. Create the snapshot volume
There is a little over 500 Megabytes of free space in the "ops" volume group, so we will use all of it to allocate space for the snapshot logical volume. A snapshot volume can be as large or a small as you like but it must be large enough to hold all the changes that are likely to happen to the original volume during the lifetime of the snapshot. So here, allowing 500 megabytes of changes to the database volume which should be plenty.
# lvcreate -L592M -s -n dbbackup /dev/ops/databases lvcreate -- WARNING: the snapshot must be disabled if it gets full lvcreate -- INFO: using default snapshot chunk size of 64 KB for "/dev/ops/dbbackup" lvcreate -- doing automatic backup of "ops" lvcreate -- logical volume "/dev/ops/dbbackup" successfully created |
| 
| Full snapshot are automatically disabled |
| | If the snapshot logical volume becomes full it will be dropped (become unusable) so it is vitally important to allocate enough space. The amount of space necessary is dependent on the usage of the snapshot, so there is no set recipe to follow for this. If the snapshot size equals the origin size, it will never overflow. |
13.4.2. Mount the snapshot volume
We can now create a mount-point and mount the volume
# mkdir /mnt/ops/dbbackup # mount /dev/ops/dbbackup /mnt/ops/dbbackup mount: block device /dev/ops/dbbackup is write-protected, mounting read-only |
If you are using XFS as the filesystem you will need to add the nouuid option to the mount command:
# mount /dev/ops/dbbackup /mnt/ops/dbbackup -onouuid,ro |
13.4.3. Do the backup
I assume you will have a more sophisticated backup strategy than this!
# tar -cf /dev/rmt0 /mnt/ops/dbbackup tar: Removing leading `/' from member names |
13.4.4. Remove the snapshot
When the backup has finished you can now unmount the volume and remove it from the system. You should remove snapshot volume when you have finished with them because they take a copy of all data written to the original volume and this can hurt performance.
# umount /mnt/ops/dbbackup # lvremove /dev/ops/dbbackup lvremove -- do you really want to remove "/dev/ops/dbbackup"? [y/n]: y lvremove -- doing automatic backup of volume group "ops" lvremove -- logical volume "/dev/ops/dbbackup" successfully removed |
