Cron and Anacron has its own advantages and disadvantages. Depending on your requirement, use one of them.
* Minimum granularity is minute (i.e Jobs can be scheduled to be executed every minute)
* Cron job can be scheduled by any normal user ( if not restricted by super user )
* Cron expects system to be running 24 x 7. If a job is scheduled, and system is down during that time, job is not executed.
* Ideal for servers.
* Use cron when a job has to be executed at a particular hour and minute.
* Minimum granularity is only in days.
* Anacron can be used only by super user ( but there are workarounds to make it usable by normal user ).
* Anacron doesn’t expect system to be running 24 x 7. If a job is scheduled, and system is down during that time, it start the jobs when the system comes back up.
* Ideal for desktops and laptops.
* Use anacron when a job has to be executed irrespective of hour and minute.
Press the power button on your system and after few moments you may see the Linux login prompt. Have you ever wondered what happens behind the scenes from the time you press the power button until the Linux login prompt appears. The Booting process starts when the system/machine power is switched “On”.
The processor will execute the codes contained in BIOS [Basic Input and Output System]. The BIOS is actually a program stored in ROM [Read Only Memory]. The processor runs the instruction located at the memory location CS:IP FFFF:0000 of the BIOS, which is located at the 0xFFFF0 address. This memory location is close to the end of the 1MB of system memory accessible in real mode. It typically contains a jump instruction that transfers execution to the location of the BIOS start-up program. The BIOS will next run POST [power on self test] to find certain hardware and its working at the basic level. It compares the hardware settings in the CMOS [Complementary Metal Oxide Semiconductor] to what is physically on the system. It then initializes the hardware devices. Once the POST is completed, the processor jumps to a specific, predefined location in RAM. The instructions located here are relatively simple and basically tell the hardware to go look for a boot device.
MBR stands for Master Boot Record. It is located in the 1st sector of the bootable disk. Typically /dev/hda or /dev/sda, MBR is less than 512 bytes in size. This has three components:-
1) primary boot loader info in 1st 446 bytes.
2) partition table info in next 64 bytes.
3) mbr validation check in last 2 bytes.
It contains information about GRUB (or LILO in old systems). So, in simple terms MBR loads and executes the GRUB boot loader. When a boot device is found (let’s assume that it’s a hard disk), the hardware is told to go to the 0th (first) sector (cylinder 0, head 0, sector 0), then load and execute the instructions there. This is the master boot record, or MBR . So, in simple terms BIOS loads and executes the MBR boot loader.
LILO or GRUB allows the root user to set up the boot process as menu-driven or command-line, and permits the user to choose from amongst several boot options. It also allows for a default boot option after a configurable timeout, and current versions are designed to allow booting from broken Level 1 (mirrored) RAID arrays. It has the ability to create a highly configurable, “GUI-fied” boot menu, or a simple, text-only, command-line prompt.
Due to the very small amount of data the BIOS can access, most boot loaders load in two stages. In the first stage of the boot, the BIOS loads a part of the boot loader known as the initial program loader, or IPL. The IPL interrogates the partition table and subsequently is able to load data wherever it may exist on the various media. This action is used initially to locate the second stage boot loader, which holds the remainder of the loader.
The second stage boot loader is the real meat of the boot loader; many consider it the only real part of the boot loader. This contains the more disk-intensive parts of the loader, such as user interfaces and kernel loaders. These user interfaces can range from a simple command line to the all-singing, all-dancing GUIs.
GRUB stands for GRand Unified Bootloader.
If you have multiple kernel images installed on your system, you can choose which one to be executed. GRUB displays a splash screen, waits for few seconds, if you don’t enter anything, it loads the default kernel image as specified in the grub configuration file. GRUB has the knowledge of the filesystem (the older Linux loader LILO didn’t understand filesystem). Grub configuration file is /boot/grub/grub.conf (/etc/grub.conf is a link to this). The following is sample grub.conf of CentOS.
title CentOS (2.6.18-194.el5PAE)
kernel /boot/vmlinuz-2.6.18-194.el5PAE ro root=LABEL=/
As you notice from the above info, it contains kernel and initrd image. So, in simple terms GRUB just loads and executes Kernel and initrd images. Depending on the kernel boot option chosen or set as default, lilo or grub will load that kernel.
When the kernel is loaded, it immediately initializes and configures the computer’s memory and configures the various hardware attached to the system, including all processors, I/O subsystems, and storage devices. It then looks for the compressed initrd image in a predetermined location in memory, decompresses it, mounts it, and loads all necessary drivers.
Next, it initializes virtual devices related to the file system, such as LVM or software RAID before unmounting the initrd disk image and freeing up all the memory the disk image once occupied. The kernel then creates a root device, mounts the root partition read-only, and frees any unused memory. At this point, the kernel is loaded into memory and operational.
Looks at the /etc/inittab file to decide the Linux run level, Following are the available run levels
0 – halt
1 – Single user mode
2 – Multiuser, without NFS
3 – Full multiuser mode
4 – unused
5 – X11
6 – reboot
Init identifies the default initlevel from /etc/inittab and uses that to load all appropriate program. Execute ‘grep initdefault /etc/inittab’ on your system to identify the default run level If you want to get into trouble, you can set the default run level to 0 or 6. Since you know what 0 and 6 means, probably you might not do that. Typically you would set the default run level to either 3 or 5.
The first thing the kernel does after completing the boot process is to execute init program. The /sbin/init program (also called init) coordinates the rest of the boot process and configures the environment for the user. Init is the root/parent of all processes executing on Linux which becomes process number 1.
The first few process Ids are given below:-
1 – Init Process
2 – kflushd(bdflush) : Started by update – does a more imperfect sync more frequently
3 – kupdate : Does a sync every 30 seconds
4 – kpiod
5 – kswapd
6 – mdrecoveryd
Processes 2, 3, 4, 5 and 6 are kernel daemons. The kernel daemons are started after init, so they get process numbers like normal processes do. But their code and data lives in the kernel’s part of the memory.
Kflushd and Kupdate :- Input and output is done via buffers in memory. This allows things to run faster and the data in the buffer are written to disk in larger more efficient chunks.The daemons kflushd and kupdate handle this work. kupdate runs periodically (5 seconds) to check whether there are any dirty buffers. If there are, it gets kflushd to flush them to disk.
Kswap and Kpiod :- System memory can be better managed by shifting unused parts of running programs out to the swap partition(s) of the hard disk. Moving this data in and out of memory as needed is done by kpiod and kswapd. Every second or so, kswapd wakes up to check out the memory situation, and if something on the disk is needed in memory, or there is not enough free memory, kpiod is called in.
Mdrecoveryd :- mdrecoveryd is part of the Multiple Devices package used for software RAID and combining multiple disks into one virtual disk Basically it is part of the kernel. It can be removed from the kernel by deselecting it (CONFIG_BLK_DEV_MD) and recompiling the kernel.
Stage – 6 Run Level programs
When the Linux system is booting up, you might see various services getting started. For example, it might say “starting sendmail …. OK”. Those are the runlevel programs, executed from the run level directory as defined by your run level. Depending on your default init level setting, the system will execute the programs from one of the following directories.
Run level 0 – /etc/rc.d/rc0.d/
Run level 1 – /etc/rc.d/rc1.d/
Run level 2 – /etc/rc.d/rc2.d/
Run level 3 – /etc/rc.d/rc3.d/
Run level 4 – /etc/rc.d/rc4.d/
Run level 5 – /etc/rc.d/rc5.d/
Run level 6 – /etc/rc.d/rc6.d/
Please note that there are also symbolic links available for these directory under /etc directly. So, /etc/rc0.d is linked to /etc/rc.d/rc0.d. Under the /etc/rc.d/rc*.d/ directories, you would see programs that start with S and K. Programs starts with S are used during startup. S for startup. Programs starts with K are used during shutdown. K for kill. There are numbers right next to S and K in the program names. Those are the sequence number in which the programs should be started or killed. For example, S12syslog is to start the syslog deamon, which has the sequence number of 12. S0 sendmail is to start the sendmail daemon, which has the sequence number of 80. So, syslog program will be started before sendmail.
There you have it. That is what happens during the Linux boot process.
edit /etc/profile and Set TMOUT to the time in seconds
# vim /etc/profile
TMOUT = 7200
1. Edit /etc/inittab and add the following line on the top of runlevel entries
–> add this line “~:S:wait:/sbin/sulogin”
# vim /etc/inittab
add the following line on the top of run level entries
RHEL/CentOS 6.X (Works in 6.1/6.2/6.3/6.4 Only) uses pam module called pam_succeed_if.so. This module is designed to succeed or fail authentication based on characteristics of the account belonging to the user being authenticated. One use is to select whether to load other modules based on this test. This module blocks root login using GUI.
1. Log in as normal user
2. Then open GUI terminal (bash prompt) and type the following command to become root user:
$ su –
3. Type your root password. Next, make a backup of /etc/pam.d/gdm, enter:
# cp /etc/pam.d/gdm /root
4. Now open /etc/pam.d/gdm using gedit or vi text editor, Find and Comment out line by prefixing # or remove this line into your gdm file like below:
# vim /etc/pam.d/gdm
auth required pam_succeed_if.so user != root quiet
5. Save and close the file. Logout from terminal and from GUI itself. Now you should be able login as root user using GDM GUI login manager.
Although it is a security risks, it is possible to make OpenSSH listens on multiple port. To do that, you need to edit file and enable the “GatewayPorts” option.
# vim /etc/ssh/sshd_config
1. Look for the line that contain “Port 22”, and uncomment it if necessary, and add additional Port line to enable OpenSSH to listen to other ports. Like this:
2. The example will enable OpenSSH to listen to port 22,80,1025 simultaneously. Don’t forget to restart SSH service to enable the change by running:
# /etc/init.d/sshd restart
Warning: Running SSH on multiple port may cause security risk, you have been warned!