Ubuntu - How to disable extra TTYs in upstart

You have to edit /etc/default/console-setup file. This file defines how many ttys should you get. Change ACTIVE_CONSOLES="/dev/tty[1-6]" to the number of consoles you want. Lets say, 2 ttys, then change it to "/dev/tty[1-2]".

And then goto /etc/event.d/ and change the ttyx files that you DONOT want. Edit them and comment lines starting with "start on runlevel". So, in this case, you'll comment the start line in tty3..tty6 files.
NOTE: X will still on Alt-F7.

Perl - change first letter to upper case

echo $name | perl -pe 's/^(.{0})(.)/$1\U$2/;'`

Linux Booting Procedure

The boot sequence varies in details among systems but can be roughly divided to the following steps: (i) hardware boot, (ii) OS loader, (iii) kernel startup, (iv) init and inittab, (v) boot scripts. We will describe each of these in more detail below.

Hardware-boot
After power-on or hard reset, control is given to a program stored on read only memory (normally PROM). In PC we usually call this program the BIOS.

This program normally makes a basic self-test of the machine and accesses non-volatile memory to read further parameters. This memory in the PC is battery-backed CMOS memory, so most people refer to it as the CMOS, although outside of the PC world, it is usually called nvram (non-volatile ram).

The parameters stored in the nvram vary between systems, but as a minimum, the hardware boot program should know what is the boot device, or which devices to probe as possible boot devices.

Then the hardware boot stage accesses the boot device, loads the OS Loader, which is located on a fixed position on the boot device, and transfers control to it.

OS Loader
In PC, the OS Loader is located in the first sector of the boot device - this is the MBR (Master Boot Record).

In most systems, this primary loader is very limited due to various constraints. Even on non-PC systems there are some limitations to the size and complexity of this loader, but the size limitation of the PC MBR (512 bytes including the partition table) makes it almost impossible to squeeze a full OS Loader into it.

Therefore, most operating systems make the primary loader call a secondary OS loader which may be located on a specified disk partition.

In Linux the OS loader is normally lilo(8) or grub(8). Both of them may install either as secondary loaders (where the DOS installed MBR points to them), or as a two part loader where they provide special MBR containing the bootstrap code to load the second part of the loader from the root partition.

The main job of the OS Loader is to locate the kernel on the disk, load it and run it. Most OS loaders allow interactive use, to enable specification of alternative kernel (maybe a backup in case the last compiled one isn’t functioning) and to pass optional parameters to the kernel.

Kernel Startup
When the kernel is loaded, it initializes the devices (via their drivers), starts the swapper (it is a "kernel process", called kswapd in modern Linux kernels), and mounts the root file system (/).

Some of the parameters that may be passed to the kernel relate to these activities (e.g: You can override the default root file system). For further information on Linux kernel parameters read bootparam(7).

Only then the kernel creates the first (user land) process which is numbered 1. This process executes the program /sbin/init, passing any parameters that weren’t handled by the kernel already.

init and inittab
When init starts it reads /etc/inittab for further instructions. This file defines what should be run in different run-levels.

This gives the system administrator an easy management scheme, where each run-level is associated with a set of services (e.g: S is single-user, on 2 most network services start, etc.). The administrator may change the current run-level via init(8) and query the current run-level via runlevel(8).

However, since it is not convenient to manage individual services by editing this file, inittab only bootstraps a set of scripts that actually start/stop the individual services.

Boot Scripts
Note: The following description applies to System V release 4 based system, which currently covers most commercial Unices (Solaris, HP-UX, Irix, Tru64) as well as the major Linux distributions (RedHat, Debian, Mandrake, Suse, Caldera). Some systems (Slackware Linux, FreeBSD, OpenBSD) have a somewhat different scheme of boot scripts.

For each managed service (mail, nfs server, cron, etc.) there is a single startup script located in a specific directory (/etc/init.d in most versions of Linux). Each of these scripts accepts as a single argument the word ’start’ -- causing it to start the service, or the word ’stop’ -- causing it to stop the service. The script may optionally accept other "convenience" parameters (e.g: ’restart’, to stop and then start, ’status’ do display the service status). Running the script without parameters displays the possible arguments.

Sequencing Directories
To make specific scripts start/stop at specific run-levels and in specific order, there are sequencing directories. These are normally in /etc/rc[0-6S].d. In each of these directories there are links (usually symbolic) to the scripts in the init.d directory.

A primary script (usually /etc/rc) is called from inittab(5) and calls the services scripts via the links in the sequencing directories. All links with names that begin with ’S’ are being called with the argument ’start’ (thereby starting the service). All links with names that begin with ’K’ are being called with the argument ’stop’ (thereby stopping the service).

To define the starting or stopping order within the same run-level, the names of the links contain order-numbers.
Also, to make the names clearer, they usually end with the name of the service they refer to. Example: the link /etc/rc2.d/S80sendmail starts the sendmail service on runlevel 2. This happens after /etc/rc2.d/S12syslog is run but before /etc/rc2.d/S90xfs is run.

To manage the boot order and run-levels, we have to manage these links. However, on many versions of Linux, there are tools to help with this task (e.g: chkconfig(8)).

Boot Configuration
Usually the daemons started may optionally receive command line options and parameters. To allow system administrators to change these parameters without editing the boot scripts themselves, configuration files are used.
These are located in a specific directory (/etc/sysconfig on RedHat systems) and are used by the boot scripts.

In older Unices, these files contained the actual command line options for the daemons, but in modern Linux systems (and also in HP-UX), these files just contain shell variables. The boot scripts in /etc/init.d source the configuration files, and then use the variable values.

GRUB v/s LILO

• LILO has no interactive command interface, whereas GRUB does.
• LILO does not support booting from a network, whereas GRUB does.
• LILO stores information about the location of the kernel or other operating system on the Master Boot Record (MBR). Every time a new operating system or kernel is added to the system, the Stage 1 LILO bootloader has to be manually overwritten, otherwise there is no way to boot the new OS or kernel. This method is more risky than the method used by GRUB because a mis-configured LILO configuration file may leave the system unbootable (a popular way to fix this problem is to boot from Knoppix or another live CD, chroot into the partition with mis-configured lilo.conf and correct the problem). On the other hand, correcting a mis-configured GRUB is comparatively simple as GRUB will default to its command line interface where the user can boot the system manually. This flexibility is probably the main reason why many users nowadays prefer GRUB over LILO.

Runlevels on Linux

• Runlevel 0 The halt runlevel - this is the runlevel at which the system shuts down. For obvious reasons it is unlikely you would want this as your default runlevel.
• Runlevel 1 Single runlevel. This causes the system to start up in a single user mode under which only the root user can log in. In this mode the system does not start any networking or X windowing, X or multi-user services. This run level is ideal for system administrators to perform system maintenance or repair activities.
• Runlevel 2 Boots the system into a multi-user mode with text based console login capability. This runlevel does not, however, start the network.
• Runlevel 3 Similar to runlevel 2 except that networking services are started. This is the most common runlevel for server based systems that do not require any kind of graphical desktop environment.
• Runlevel 4 Undefined runlevel. This runlevel can be configured to provide a custom boot state.
• Runlevel 5 Boots the system into a networked, multi-user state with X Window System capability. By default the graphical desktop environment will start at the end of the boot process. This is the most common run level for desktop or workstation use.
• Runlevel 6 Reboots the system. Another runlevel that you are unlikely to want as your default.

To enable rpmforge repo for yum

in Fedora Core 4
rpm -Uvh http://ftp.belnet.be/packages/dries.ulyssis.org/fedora/fc4/i386/RPMS.dries/rpmforge-release-0.2-2.2.fc4.rf.i386.rpm


in CentOS 4.4
rpm -Uhv http://apt.sw.be/packages/rpmforge-release/rpmforge-release-0.3.6-1.el4.rf.i386.rpm

To install sar (System Activity Report) on CentOS


# yum install sysstat


:)

Issues in passwordless ssh (using ssh-keygen) to remote host !!

If after the configuration, still it asks for password, check the permissions of authorized_keys (should be 600) and ~/.ssh (should be 700).

:)

Creating SSL Certificates for Apache

Create a folder, say ssl
[root@host ~]# mkdir /root/ssl
[root@host ~]# cd /root/ssl

Creating your new private key (privkey.pem) and server.csr

It will ask you for a PEM pass phrase. Enter a pass phrase, confirm it and remember it !!!
Then it will ask you for few informations.
The most important is to set Common Name (eg, your name or your server's hostname) exactly as your hostname

[root@host ssl]# openssl req -config /usr/share/ssl/openssl.cnf -new -out server.csr
Generating a 1024 bit RSA private key
............++++++
...................++++++
writing new private key to 'privkey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:
State or Province Name (full name) [Berkshire]:
Locality Name (eg, city) [Newbury]:
Organization Name (eg, company) [My Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: <--- Dont type anything here. Press Enter
An optional company name []: <--- Dont type anything here. Press Enter
[root@hostssl]#

Creating the server.key file
You must enter the PEM pass phrase

[root@host ssl]# openssl rsa -in privkey.pem -out server.key
Enter pass phrase for privkey.pem:
writing RSA key
[root@hostssl]#

Creating server.crt

[root@host ssl]# openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 1825
Signature ok
subject=/C=US/ST=Maryland/L=Annapolis/O=CompanyName/OU=Department/CN=host.domain.com/emailAddress=mailid@domain.com
Getting Private key

Now take the backup of old files and copy the newly created files

[root@host ssl]# cp /etc/httpd/conf/ssl.crt/server.crt /etc/httpd/conf/ssl.crt/server.crt.orig
[root@host ssl]# cp /etc/httpd/conf/ssl.key/server.key /etc/httpd/conf/ssl.key/server.key.orig
[root@host ssl]# cp server.crt /etc/httpd/conf/ssl.crt/
cp: overwrite `/etc/httpd/conf/ssl.crt/server.crt'? y
[root@hostssl]# cp server.key /etc/httpd/conf/ssl.key/
cp: overwrite `/etc/httpd/conf/ssl.key/server.key'? y

Now restart apache

[root@hosts ssl]#/etc/init.d/httpd restart