In the shortest possible form, the Linux boot sequence looks something like this:
1. Computer gets powered on, BIOS runs whatever it finds in the Master Boot Record (MBR), usually lilo or GRUB
2. lilo, in turn, starts up the Linux kernel
3. The Linux kernel starts up the primal process, init. Since init is always started first, it always has PID of 1.
4. init then runs your boot scripts, also known as "rc files". These are similar in concept to DOS's autoexec.bat and config.sys, if those had been developed to a fine art. These rc files, which are generally shell scripts, spawn all the processes that make up a running Unix system.
One interesting consequence of this multi-step booting process is that it's very flexible. Once lilo has been loaded, and control over the boot process has been passed to it, it can run any sort of arbitrary (but self-contained) program that you'd care to run. This means that you can use lilo to boot into multiple operating systems.
Once lilo has started to run whatever operating system you've chosen (Linux would be a good choice ;-), it is no longer running.The lilo config file is usually located at /etc/lilo.conf; and you can find the grub.conf in /boot/grub/grub.conf remember to run the lilo command after editing it to save your changes to the master boot record on disk.
The next step in the Linux boot process is for the Linux kernel to run. This does all sorts of things, but the most important thing that we're interested in is that kernel spawns a copy of init, the First Process. Being the First Process, init will be assigned a PID of 1.
init is in charge of starting all of the normal processes that a running Linux system needs, including the mingetty processes that give your virtual consoles (ALT-F1 through ALT-F6 on most default Linux installations), starting up any needed services (like networking), and anything else that you might want to do while booting. These are controlled by shell scripts known as "rc files", which are started by commands in the init config file. The config file is usually located at /etc/inittab, and you'll have to tell init to re-read its config file by running telinit q as root. You can find a lot more information on this under the man pages for inittab and init (man inittab and man init).
There are two types of rc files that could be used: System V style or BSD style. Most Linux distributions use System V system, so that is what will be covered here. In general, System V rc files are considered more powerful than BSD ones, at the expense of simplicity. BSD rc files are generally stored in the /etc directory, while System V expects to find its files in the/etc/rc.d directory (and any subdirectories from there).
The idea behind System V rc files is that you may want to boot in different ways. For example, you may want to boot into single-user mode to fix a hard drive problem, or you may want regular multi-user console mode, or perhaps you want to boot straight to the X window system. All of these different types of boot sequences can be automated into "run levels"; Red Hat's convention is:
* Run Level 1 (directory: /etc/rc.d/rc1.d) - Single user mode
* Run Level 2 (directory: /etc/rc.d/rc2.d) - Same as 3, but without NFS
* Run Level 3 (directory: /etc/rc.d/rc3.d) - Regular multi-user and networking mode
* Run Level 4 (directory: /etc/rc.d/rc4.d) - Unused
* Run Level 5 (directory: /etc/rc.d/rc5.d) - Same as 3, but boots straight to the X window system
Of course, this convention is arbitrary and other distributions can (and do!) vary. The most common variations are for run level 2 to be the default mode (but have it operate the same as run level 3 in the chart above), and for X to be run level 4 rather than 5. There is also a special run level 6 that isn't really a run level, its a shortcut for rebooting.
Note: To change the run level that you're operating under, use the telinit command. For example, for a quick reboot, you can use telinit 6. Naturally, you have to be root to do this.
Note: The default runlevel is decided in /etc/inittab. The line that controls it looks like this: id:3:initdefault:
Inside the /etc/rc.d/init.d directory are all of the shell scripts that do the actual work. The rc#.d directories simply contain symbolic links to the scripts in the init.d directory.
In the /etc/rc.d directory there is also a file called rc.local, which is the rc file that init will run after everything else is done. You can add simple things to the end of it if you don't want to go through the process of setting up a full script in the /etc/rc.d/init.d directory, but it's not a good idea if you want an easy to understand and consistent boot process.
Knowing a bit about how the System V boot process works now, it's easer to understand how the boot sequence operates:
* Once the Linux kernel has been loaded by lilo, it looks in "all the usual places" for init and runs the first copy it finds
* In turn, init runs the shell script found at /etc/rc.d/rc.sysinit
* Next, rc.sysinit does a bunch of necessary things to make System V rc files possible
* init then runs all the scripts for the default runlevel
o It knows the default run level by examing /etc/inittab
o Symbolic links to the real scripts (in /etc/rc.d/init.d) are kept in each of the run level directories (/etc/rc.d/rc1.d through rc6.d)
* Lastly, init runs whatever it finds in /etc/rc.d/rc.local (regardless of run level). rc.local is rather special in that it is executed every time that you change run levels.
Note: There's some trickery in how the symbolic links in the rc#.d directories work. Link names that start with an "S" are scripts that "started", while links that begin with a "K" are scripts that are "killed", or stopped. The number that follows is simply a way to determine the order that the scripts run in: lower numbered scripts run first.
Note: There's also some trickery done with rc.sysinit for a file called rc.serial, used to set up your serial ports, but the file does not exist by default on most Linux distributions and is not often used.
Monday, August 16, 2010
Backup and Restore Linux Partitions Using Partimage
Partition Image is a Linux/UNIX utility which saves partitions in many formats (see below) to an image file. The image file can be compressed in the GZIP/BZIP2 formats to save disk space, and split into multiple files to be copied on removable floppies (ZIP for example), … Partitions can be saved across the network since version 0.6.0.When using Partimage, the partitions must be unmounted.
Partimage is veryuseful in the following situations
First you can restore your linux partition if there is a problem (virus, file system errors, manipulation error) . When you have a problem, you just have to restore the partition, and after 10 minutes, you have the original partition. You can write the image to a CD-R if you don’t want the image to use hard-disk space.
This utility can be used to install many identical computers. For example, if you buy 50 PCs, with the same hardware, and you want to install the same linux systems on all 50 PCs, you will save a lot of time. Indeed, you just have to install on the first PC and create an image from it. For the 49 others, you can use the image file and Partition Image’s restore function.
Supported file systems
ext2fs/ext3fs,Reiser3,FAT16/32,NTFS,HPFS,JFS,XFS,UFS(beta),HFS(beta)
Install Partimage in Ubuntu
First you need to make sure in your /etc/apt/sources.list file universe source list is enabled.
sudo apt-get install partimage
Install Partimage in Debian
#apt-get install partimage
This will complete the installation now
Before starting application you can check the all the available partitions using the following command
For Ubuntu Users
sudo fdisk -l
For debian users
#fdisk -l
Backup Partition
if you want to run the application use the following command
For Ubuntu Users
sudo partimage
For debian users
#partimage
Once it opens the application you should see similar to the following screen
Once you launch PartImage, use the Up and Down arrows to select which partition to back up.
Type the name of the path and file where you’re going to back up the partition.In this example I mounted the backup partition at /backup, I have to type /backup/serverbackup and not just serverbackup.
Action to be done should be Save partition into a new image file.
On the next screen, use no compression if you want the backup to be quicker. You really should use the Gzip or Bzip2 options only if your external hard drive or other backup partition is too small to hold the contents of the partition you’re backing up.
Now you should remember that the backup will save only the used space on the partition.So, if you have a 100 GB partition you’re backing up and only 11 GB of it is used, the partition image will be only 11 GB.
Now you press F5 to Continue for next screen here you need to enter a description of the save partition.
After PartImage examines the partition data for a while, it’ll give a summary of the partition.Here select ok and press enter
PartImage will start saving your partition to an image file on the backup partition and you can see the progress in the following screen.
Now you can see in the following screen backup partition operation completed successfully.
Then, you’ll be back to the terminal prompt.
Restore Partition
if you want to run the application use the following command
For Ubuntu Users
sudo partimage
For debian users
#partimage
Once it opens the application you should see similar to the following screen here you need to select the partition to restore,image file to use in my case i have saved my partition image file as serverbackup.000 if you want to menction .img extension at the time of backup it will save as .img file otherwise it will save as .000 extension,select restore partition from an image file option under action to be done select F5 for next screen
You should see the following screen select ok and press enter
Now you should see the following screen here you need to select the options The only extra option you can choose is Erase free blocks with zero values. If this option is enabled, all blocks which are not used are erased with zero bytes. This may be useful if you want to be sure that the data which were on the partition before this operation are fully erased. If this option is disabled, old data which was on currently unused blocks can be accessed (with some difficulty), because nothing is written on these blocks. These old data can be read with tools such as dd (GNU convert and copy) and press F5 to continue.
The partition to restore must have the same size as the saved partition. If the partition is smaller than the original one, the operation will fail. If it is bigger, space can be lost.
Now you should see the summary of restore partition information select ok and press enter
Now you should see the summary of restore partition information select ok and press enter
Confirm the image file you want to restore
Restore partition from an image file is in progress
Restore partition from an image file is completed successfully completed select ok and press enter Then, you’ll be back to the terminal prompt.
TCP Connections: The Three-Way Handshake
The three-way handshake in Transmission Control Protocol (also called the three message handshake) is the method used to establish and tear down network connections. This handshaking technique is referred to as the 3-way handshake or as “SYN-SYN-ACK” (or more accurately SYN, SYN-ACK, ACK). The TCP handshaking mechanism is designed so that two computers attempting to communicate can negotiate the parameters of the network connection before beginning communication. This process is also designed so that both ends can initiate and negotiate separate connections at the same time.
3-Way Handshake Description
Below is a (very) simplified description of the TCP 3-way handshake process. Refer to the diagram on the right as you examine the list of events on the left.
| EVENT | DIAGRAM |
Host A sends a TCP SYNchronize packet to Host B Host B receives A’s SYN Host B sends a SYNchronize-ACKnowledgement Host A receives B’s SYN-ACK Host A sends ACKnowledge Host B receives ACK. TCP connection is ESTABLISHED. |  |
SYNchronize and ACKnowledge messages are indicated by a bit inside the TCP header of the segment.
TCP knows whether the network connection is opening, synchronizing or established by using theSYNchronize and ACKnowledge messages when establishing a network connection.
When the communication between two computers ends, another 3-way communication is performed to tear down the TCP connection. This setup and teardown of a TCP connection is part of what qualifies TCP a reliable protocol.
Note that UDP does not perform this 3-way handshake and for this reason, it is referred to as an unreliable protocol.
Protocols Encapsulated in TCP
Note that FTP, Telnet, HTTP, HTTPS, SMTP, POP3, IMAP, SSH and any other protocol that rides over TCP also has a three way handshake performed as connection is opened. HTTP web requests, SMTP emails, FTP file transfers all manage the messages they each send. TCP handles the transmission of those messages.
TCP rides on top of Internet Protocol (IP) which is why it is called TCP/IP (TCP over IP). TCP segments are passed inside the payload section of the IP packets. IP handles addressing and routing and gets the packets from one place to another, but TCP handles the actual communication between hosts.
Linux Boot Process
In the shortest possible form, the Linux boot sequence looks something like this:
1. Computer gets powered on, BIOS runs whatever it finds in the Master Boot Record (MBR), usually lilo or GRUB
2. lilo, in turn, starts up the Linux kernel
3. The Linux kernel starts up the primal process, init. Since init is always started first, it always has PID of 1.
4. init then runs your boot scripts, also known as "rc files". These are similar in concept to DOS's autoexec.bat and config.sys, if those had been developed to a fine art. These rc files, which are generally shell scripts, spawn all the processes that make up a running Unix system.
One interesting consequence of this multi-step booting process is that it's very flexible. Once lilo has been loaded, and control over the boot process has been passed to it, it can run any sort of arbitrary (but self-contained) program that you'd care to run. This means that you can use lilo to boot into multiple operating systems.
Once lilo has started to run whatever operating system you've chosen (Linux would be a good choice ;-), it is no longer running.The lilo config file is usually located at /etc/lilo.conf; and you can find the grub.conf in /boot/grub/grub.conf remember to run the lilo command after editing it to save your changes to the master boot record on disk.
The next step in the Linux boot process is for the Linux kernel to run. This does all sorts of things, but the most important thing that we're interested in is that kernel spawns a copy of init, the First Process. Being the First Process, init will be assigned a PID of 1.
init is in charge of starting all of the normal processes that a running Linux system needs, including the mingetty processes that give your virtual consoles (ALT-F1 through ALT-F6 on most default Linux installations), starting up any needed services (like networking), and anything else that you might want to do while booting. These are controlled by shell scripts known as "rc files", which are started by commands in the init config file. The config file is usually located at /etc/inittab, and you'll have to tell init to re-read its config file by running telinit q as root. You can find a lot more information on this under the man pages for inittab and init (man inittab and man init).
There are two types of rc files that could be used: System V style or BSD style. Most Linux distributions use System V system, so that is what will be covered here. In general, System V rc files are considered more powerful than BSD ones, at the expense of simplicity. BSD rc files are generally stored in the /etc directory, while System V expects to find its files in the/etc/rc.d directory (and any subdirectories from there).
The idea behind System V rc files is that you may want to boot in different ways. For example, you may want to boot into single-user mode to fix a hard drive problem, or you may want regular multi-user console mode, or perhaps you want to boot straight to the X window system. All of these different types of boot sequences can be automated into "run levels"; Red Hat's convention is:
* Run Level 1 (directory: /etc/rc.d/rc1.d) - Single user mode
* Run Level 2 (directory: /etc/rc.d/rc2.d) - Same as 3, but without NFS
* Run Level 3 (directory: /etc/rc.d/rc3.d) - Regular multi-user and networking mode
* Run Level 4 (directory: /etc/rc.d/rc4.d) - Unused
* Run Level 5 (directory: /etc/rc.d/rc5.d) - Same as 3, but boots straight to the X window system
Of course, this convention is arbitrary and other distributions can (and do!) vary. The most common variations are for run level 2 to be the default mode (but have it operate the same as run level 3 in the chart above), and for X to be run level 4 rather than 5. There is also a special run level 6 that isn't really a run level, its a shortcut for rebooting.
Note: To change the run level that you're operating under, use the telinit command. For example, for a quick reboot, you can use telinit 6. Naturally, you have to be root to do this.
Note: The default runlevel is decided in /etc/inittab. The line that controls it looks like this: id:3:initdefault:
Inside the /etc/rc.d/init.d directory are all of the shell scripts that do the actual work. The rc#.d directories simply contain symbolic links to the scripts in the init.d directory.
In the /etc/rc.d directory there is also a file called rc.local, which is the rc file that init will run after everything else is done. You can add simple things to the end of it if you don't want to go through the process of setting up a full script in the /etc/rc.d/init.d directory, but it's not a good idea if you want an easy to understand and consistent boot process.
Knowing a bit about how the System V boot process works now, it's easer to understand how the boot sequence operates:
* Once the Linux kernel has been loaded by lilo, it looks in "all the usual places" for init and runs the first copy it finds
* In turn, init runs the shell script found at /etc/rc.d/rc.sysinit
* Next, rc.sysinit does a bunch of necessary things to make System V rc files possible
* init then runs all the scripts for the default runlevel
o It knows the default run level by examing /etc/inittab
o Symbolic links to the real scripts (in /etc/rc.d/init.d) are kept in each of the run level directories (/etc/rc.d/rc1.d through rc6.d)
* Lastly, init runs whatever it finds in /etc/rc.d/rc.local (regardless of run level). rc.local is rather special in that it is executed every time that you change run levels.
Note: There's some trickery in how the symbolic links in the rc#.d directories work. Link names that start with an "S" are scripts that "started", while links that begin with a "K" are scripts that are "killed", or stopped. The number that follows is simply a way to determine the order that the scripts run in: lower numbered scripts run first.
Note: There's also some trickery done with rc.sysinit for a file called rc.serial, used to set up your serial ports, but the file does not exist by default on most Linux distributions and is not often used.
1. Computer gets powered on, BIOS runs whatever it finds in the Master Boot Record (MBR), usually lilo or GRUB
2. lilo, in turn, starts up the Linux kernel
3. The Linux kernel starts up the primal process, init. Since init is always started first, it always has PID of 1.
4. init then runs your boot scripts, also known as "rc files". These are similar in concept to DOS's autoexec.bat and config.sys, if those had been developed to a fine art. These rc files, which are generally shell scripts, spawn all the processes that make up a running Unix system.
One interesting consequence of this multi-step booting process is that it's very flexible. Once lilo has been loaded, and control over the boot process has been passed to it, it can run any sort of arbitrary (but self-contained) program that you'd care to run. This means that you can use lilo to boot into multiple operating systems.
Once lilo has started to run whatever operating system you've chosen (Linux would be a good choice ;-), it is no longer running.The lilo config file is usually located at /etc/lilo.conf; and you can find the grub.conf in /boot/grub/grub.conf remember to run the lilo command after editing it to save your changes to the master boot record on disk.
The next step in the Linux boot process is for the Linux kernel to run. This does all sorts of things, but the most important thing that we're interested in is that kernel spawns a copy of init, the First Process. Being the First Process, init will be assigned a PID of 1.
init is in charge of starting all of the normal processes that a running Linux system needs, including the mingetty processes that give your virtual consoles (ALT-F1 through ALT-F6 on most default Linux installations), starting up any needed services (like networking), and anything else that you might want to do while booting. These are controlled by shell scripts known as "rc files", which are started by commands in the init config file. The config file is usually located at /etc/inittab, and you'll have to tell init to re-read its config file by running telinit q as root. You can find a lot more information on this under the man pages for inittab and init (man inittab and man init).
There are two types of rc files that could be used: System V style or BSD style. Most Linux distributions use System V system, so that is what will be covered here. In general, System V rc files are considered more powerful than BSD ones, at the expense of simplicity. BSD rc files are generally stored in the /etc directory, while System V expects to find its files in the/etc/rc.d directory (and any subdirectories from there).
The idea behind System V rc files is that you may want to boot in different ways. For example, you may want to boot into single-user mode to fix a hard drive problem, or you may want regular multi-user console mode, or perhaps you want to boot straight to the X window system. All of these different types of boot sequences can be automated into "run levels"; Red Hat's convention is:
* Run Level 1 (directory: /etc/rc.d/rc1.d) - Single user mode
* Run Level 2 (directory: /etc/rc.d/rc2.d) - Same as 3, but without NFS
* Run Level 3 (directory: /etc/rc.d/rc3.d) - Regular multi-user and networking mode
* Run Level 4 (directory: /etc/rc.d/rc4.d) - Unused
* Run Level 5 (directory: /etc/rc.d/rc5.d) - Same as 3, but boots straight to the X window system
Of course, this convention is arbitrary and other distributions can (and do!) vary. The most common variations are for run level 2 to be the default mode (but have it operate the same as run level 3 in the chart above), and for X to be run level 4 rather than 5. There is also a special run level 6 that isn't really a run level, its a shortcut for rebooting.
Note: To change the run level that you're operating under, use the telinit command. For example, for a quick reboot, you can use telinit 6. Naturally, you have to be root to do this.
Note: The default runlevel is decided in /etc/inittab. The line that controls it looks like this: id:3:initdefault:
Inside the /etc/rc.d/init.d directory are all of the shell scripts that do the actual work. The rc#.d directories simply contain symbolic links to the scripts in the init.d directory.
In the /etc/rc.d directory there is also a file called rc.local, which is the rc file that init will run after everything else is done. You can add simple things to the end of it if you don't want to go through the process of setting up a full script in the /etc/rc.d/init.d directory, but it's not a good idea if you want an easy to understand and consistent boot process.
Knowing a bit about how the System V boot process works now, it's easer to understand how the boot sequence operates:
* Once the Linux kernel has been loaded by lilo, it looks in "all the usual places" for init and runs the first copy it finds
* In turn, init runs the shell script found at /etc/rc.d/rc.sysinit
* Next, rc.sysinit does a bunch of necessary things to make System V rc files possible
* init then runs all the scripts for the default runlevel
o It knows the default run level by examing /etc/inittab
o Symbolic links to the real scripts (in /etc/rc.d/init.d) are kept in each of the run level directories (/etc/rc.d/rc1.d through rc6.d)
* Lastly, init runs whatever it finds in /etc/rc.d/rc.local (regardless of run level). rc.local is rather special in that it is executed every time that you change run levels.
Note: There's some trickery in how the symbolic links in the rc#.d directories work. Link names that start with an "S" are scripts that "started", while links that begin with a "K" are scripts that are "killed", or stopped. The number that follows is simply a way to determine the order that the scripts run in: lower numbered scripts run first.
Note: There's also some trickery done with rc.sysinit for a file called rc.serial, used to set up your serial ports, but the file does not exist by default on most Linux distributions and is not often used.
Subscribe to:
Posts (Atom)