Sysfs and Device Management

As devices initialize, the practice is to use a certain data structure, a kobject, to track its existence. Kobjects aren’t objects in the Yourdon and Coad3 sense of the word; they’re data structures used throughout the kernel that are exposed through the sysfs file system mounted at /sys. If your desktop is running a 2.6 kernel and doesn’t have a file system mounted at /sys, do the following to make this file system available:

# mkdir /sys
# mount -t sysfs none /sys
$ cd /sys

One of the purposes of kobjects when they were introduced was creating a uniform, dependable way for a process in userland to see the device drivers loaded by the kernel. Their use has been expanded over the years to include keeping track of more types of kernel-level data. The notion of kobjects makes it very easy for devices to register and be queried from userland in order to create the device nodes files in the /dev directory, and that is why kobjects are important in the boot-up process.

The typical desktop machine has a Linux distribution designed to work on some computer, but not necessarily your computer. During the boot-up process, the kernel probes the hardware and attempts to load drivers for that hardware. When those drivers load, they create a kobject in their tracking data structures that is registered by the kernel. The kobject is a data structure exposed in the sysfs file system. In user space, another process runs, called udevd, which inspects the sysfs file system to create the necessary entries in /dev for the device drivers that have been loaded. This is how the /dev file system gets populated with all those device nodes without your direct intervention. This process ensures that the /dev directory has device nodes for all the drivers-and that means the hardware is accessible to the system for use.

Most embedded systems have a fixed set of devices that doesn’t change; the overhead of the sysfs file system and udevd is wasteful, because the set of device nodes necessary could be created once and stored on the root file system. This is worth mentioning at this point because it’s important to understand what happens during the startup process. When the book discusses reducing boot time and root file system size, udev and the /dev and /sys directories are low-hanging fruit.

Device nodes are an interesting concept if you’re new to embedded Linux. Linux has a Unix heritage, in that a file establishes the semantics for how things communicate. A hardware device like a USB drive, mouse, or serial port uses a file for communication as well; however, these aren’t real files but rather placeholders in the file system (device node files) that look like files. They serve as proxies for communicating with device drivers in the
kernel. By writing or reading these things that look like files, the device driver calls functions that handle getting data from userland (the result of a write) or sending data to userland (the result of a read).

Source of Information : Pro Linux Embedded Systems

The Kernel Entry Point

The kernel’s entry point is located in init/main.c in the routine start_kernel. The architecturespecific code jumps to this address after the hardware setup is complete. The sure way you know you’ve arrived at this step is when the following appears:

Linux version 2.6.17 (built@by.you) (gcc version 4.2.1)

The code here starts the interrupt handlers, process scheduler, virtual memory management system, and power management; it also scans the PCI bus for peripherals, enables networking, and performs other housekeeping tasks. While this activity is occurring, the device drivers print out information that documents the current state of the system:

CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ)
Machine: ARM-IntegratorCP
Memory policy: ECC disabled, Data cache writeback
CPU0: D VIVT write-through cache
CPU0: I cache: 4096 bytes, associativity 4, 32 byte lines, 32 sets
CPU0: D cache: 65536 bytes, associativity 4, 32 byte lines, 512 sets
Built 1 zonelists
Kernel command line: console=ttyAMA0 mem=128M ip=192.168.20.100:::::eth0:off

The kernel command-line printing is an important milestone: if the kernel has made it this far, then the scheduler (the part of the kernel that decides what software should be running) has started and is ready to handle threads started by the kernel itself as well as the initial user process. The output from the kernel startup process is available from the command line by using the dmesg command immediately after the kernel boots. dmesg prints out the contents of the kernel’s temporary buffer, which is overwritten with newer data as the system runs. For example, on a desktop machine, try

$ dmesg | less

That command sends the results of dmesg to the less program, which lets you control the file’s scrolling.

Hardware initialization continues, ending with the configuration of the network adapter:

eth0: link up
Sending DHCP requests ...... timed out!
IP-Config: Reopening network devices...
eth0: link up
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 10.0.2.2, my address is 10.0.2.15
IP-Config: Complete:
device=eth0, addr=10.0.2.15, mask=255.255.255.0, gw=10.0.2.2,
host=10.0.2.15, domain=, nis-domain=(none),
bootserver=10.0.2.2, rootserver=10.0.2.2, rootpath=

These messages show an adapter that attempts to get an address via Dynamic Host Configuration Protocol (DHCP) and succeeds on the second attempt. DHCP is a protocol in which the board sends out a packet to the entire network requesting an address and waits for a reply. Because the board doesn’t know if it will get a reply, it makes several attempts before giving up.

The kernel initialization of the hardware interface is necessary for kernels that will attempt to mount a root file system over the network using NFS or PXE, both of which were covered earlier in the book. If the kernel doesn’t need to mount a remote file system as root, it doesn’t need to configure the network adapter at this point, because this may happen later in the boot process; doing so results in the system getting to userland slightly faster, and you have more control over the assignment of the IP address if the operation is deferred until a userland scripting language can be used.

Source of Information : Pro Linux Embedded Systems

Kernel Startup

Getting the kernel loaded into memory isn’t even half the fun of starting a Linux system. The boot loader’s job is to get the operating system from storage (flash, TFTP) into a place where it can be executed (RAM) and then go away. Most of the time, the kernel is stored as compressed data. To
uncompress the data, the kernel build process tacks a decompression code on the front of the kernel image, so the first output visible to you is like this:

Uncompressing
Linux..........................................................................
done,

This isn’t really the kernel running; it’s the decompression program for the kernel. These dots are
quickly followed by

booting the kernel.

That output means the kernel has finished going through the processor and board-specific initialization code and is now in the kernel_start or main entry point for the kernel. It’s important to know what happens in this area, even though you’ll probably never touch this code.

After decompression, the next code that runs is in the head.S used to build the kernel. For example, if you use a PowerPC 32-bit processor, you find this code at

arch/powerpc/kernel/head_32.S

The processor family is the one selected during the configuration of the kernel. If you’re building an ARM-based system, the entry-point file later links to a file containing the processor-specific initialization:

arch/arm/kernel/head.S

Both of these files do the same thing; they perform processor-specific configuration:
1. Initialize the MMU.
2. If the processor is multicore, get the second processor ready to run.
3. Get the kernel command line from the boot loader (before it’s overwritten), and copy the command line into memory where it can be safely passed to the kernel’s entry point.
4. Configure hooks for hardware debuggers.
5. Flush the processor’s cache.

Looking in the directory for the architecture reveals many more files than those mentioned. The kernel type you choose during the configuration step specifies what additional files are linked into the final initialization object code. No matter what initialization code happens to run, all initialization programs end by jumping to start_kernel.

Source of Information : Pro Linux Embedded Systems

The Upstart Event-Based init Daemon (FEDORA)

The Upstart Event-Based init Daemon Because the traditional System V init daemon (SysVinit) does not deal well with modern hardware, including hotplug devices, USB hard and flash drives, and network-mounted filesystems, Fedora replaced it with the Upstart init daemon (fedoraproject.org/wiki/Features/Upstart). RHEL still uses xinetd, a successor to the init daemon.

Several other replacements for SysVinit are also available. One of the most prominent, initng (www.initng.org), is available for Debian and runs on Ubuntu. In addition, Solaris uses SMF (Service Management Facility) and MacOS uses launchd. Over time, Upstart will likely incorporate features of each of these systems.

The runlevel-based SysVinit daemon (sysvinit package) uses runlevels (single-user, multiuser, and more) and links from the /etc/rc?.d directories to the init scripts in /etc/init.d to start and stop system services. The event-based Upstart init daemon uses events to start and stop system services. With version 9, Fedora switched to the Upstart init daemon and began the transition from the SysVinit setup to the Upstart setup. This section discusses Upstart and the parts of SysVinit that remain: the /etc/rc?.d and /etc/init.d directories and the concept of runlevels.

The Upstart init daemon is event based and runs specified programs when something on the system changes. These programs, which are frequently scripts, start and stop services. This setup is similar in concept to the links to init scripts that Sys-Vinit calls as a system enters runlevels, except Upstart is more flexible. Instead of starting and stopping services only when the runlevel changes, Upstart can start and stop services upon receiving information that something on the system has changed. Such a change is called an event. For example, Upstart can take action when it learns from udev that a filesystem, printer, or other device has been added or removed from the running system. It can also start and stop services when the system boots, when the system is shut down, or when a job changes state.

Future of Upstart. Changing from SysVinit to Upstart involves many parts of the Linux system. To make the switch smoothly and to introduce as few errors as possible, the Upstart team elected to make this transition over several releases.

Over time, Fedora will move away from the SysVinit setup and toward the cleaner, more flexible Upstart setup. As more system services are put under the control of Upstart, entries in the /etc/event.d directory will replace the contents of the /etc/init.d and /etc/rc?.d directories. Runlevels will no longer be a formal feature of Fedora, although they will be maintained for compatibility with third-party software. Eventually Upstart will also replace crond.

Software package. The Upstart system uses the upstart package, which is installed by default. Some of the files Upstart uses are found in the initscripts package, which is also installed by default.

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition

config: The SELinux Configuration File

The /etc/selinux/config file, which has a link at /etc/sysconfig/selinux, controls the state of SELinux on the local system. Although you can modify this file, it may be more straightforward to work with system-config-selinux. In the following example, the policy is set to targeted, but that setting is of no consequence because SELinux is disabled:

$ cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted

To put SELinux in enforcing mode, change the line containing the SELINUX assignment to SELINUX=enforcing. Similarly, you can change the policy by setting SELINUXTYPE.

If you will use SELinux in the future
If you will use SELinux in the future but not now, turn it on when you install Linux, and run it inpermissive state with the policy set to the policy you will eventually use. Permissive state writes the required extended information to inodes, but it does not stop you from doing anything on the system.

If you turn on SELinux after it has been disabled, when you reboot the system SELinux has to add extended attributes to the files in the filesystem. This process can take a long time on a large filesystem. If you are never going to use SELinux, disable it.

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition

SELinux

Traditional Linux security, called Discretionary Access Control (DAC), is based on users and groups. Because a process run by a user has access to anything the user has access to, fine-grained access control is difficult to achieve. Fine-grained access control is particularly important on servers, which often hold programs that require root privileges to run.

SELinux (Security Enhanced Linux), which was developed by the U.S. National Security Agency (NSA), implements Mandatory Access Control (MAC) in the Linux kernel. MAC enforces security policies that limit what a user or program can do. It defines a security policy that controls some or all objects, such as files, devices, sockets, and ports, and some or all subjects, such as processes. Using SELinux, you can grant a process only those permissions it needs to be functional, following the principle of least privilege. MAC is an important tool for limiting security threats that come from user errors, software flaws, and malicious users. The kernel checks MAC rules after it checks DAC rules.

SELinux can be in one of three states (modes):
• Enforcing—The default state, wherein SELinux security policy is enforced. No user or program will be able to do anything not permitted by the security policy.

• Permissive—The diagnostic state, wherein SELinux sends warning messages to a log but does not enforce the security policy. You can use the log to build a security policy that matches your requirements.

• Disabled—SELinux does not enforce a security policy because no policy is loaded.

Running SELinux in permissive or enforcing state degrades system performance somewhat. Although SELinux usually does not provide benefit on a single-user system, you may want to consider using SELinux on a server that connects to the Internet. If you are unsure whether to use SELinux, selecting permissive state allows you to easily change to disabled or enforcing state at a later date.

SELinux implements one of the following policies:
• Targeted—Applies SELinux MAC controls only to certain (targeted) processes (default).

• MLS—Multilevel Security protection.

• Strict—Applies SELinux MAC controls to all processes (RHEL).

This section discusses the targeted policy. With such a policy, daemons and system processes that do not have a specified policy are controlled by traditional Linux DACs. With the strict policy, all processes are controlled by SELinux (MACs). There is always a tradeoff between security and usability. The targeted policy is less secure than the strict policy, but it is much easier to maintain. When you run the strict policy, you will likely have to customize the policy so that users can do their work and the system can function appropriately.

You can switch from one policy to the other (as explained shortly). Dispite this flexibility, it is not a good idea to switch from a targeted to a strict policy on a production system. If you do so, some users may not be able to do their work. You would need to customize the policy in such a case. Changing from a strict to a targeted policy should not create any problems.

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition

Avoiding a Trojan Horse

A Trojan horse is a program that does something destructive or disruptive to a system while appearing to be benign. As an example, you could store the following script in an executable file named mkfs:

while true
do
echo 'Good Morning Mr. Jones. How are you? Ha Ha Ha.' > /dev/console
done

If you are running as Superuser when you run this command, it would continuously write a message to the console. If the programmer were malicious, it could do worse. The only thing missing in this plot is access permissions. A malicious user could implement this Trojan horse by changing Superuser’s PATH variable to include a publicly writable directory at the start of the PATH string. (The catch is that you need to be able to write to /etc/profile-where the PATH variable is set for root-and only root can do that.) Then you would need to put the bogus mkfs program file in that directory. Because the fraudulent version appears in a directory mentioned earlier than the real one in PATH, the shell would run it rather than the legitimate version. The next time Superuser tries to run mkfs, the fraudulent version would run.

Trojan horses that lie in wait for and take advantage of the misspellings that most people make are among the most insidious types. For example, you might type sl instead of ls. Because you do not regularly execute a utility named sl and you may not remember typing the command sl, it is more difficult to track down this type of Trojan horse than one that takes the name of a more familiar utility.

A good way to help prevent the execution of a Trojan horse is to make sure that your PATH variable does not contain a single colon (:) at the beginning or end of the PATH string or a period (.) or double colon (::) anywhere in the PATH string. This precaution ensures that you will not execute a file in the working directory by accident. To check for a possible Trojan horse, examine the filesystem periodically for files with setuid permission. The following command lists these files:

# find / -perm -4000 -exec ls -lh {} \; 2> /dev/null
-rws--x--x. 1 root root 30K Oct 5 12:10 /usr/sbin/userhelper
-r-s--x---. 1 root apache 11K Aug 21 07:15 /usr/sbin/suexec
-rws--x--x. 1 root root 1.9M Oct 4 21:38 /usr/bin/Xorg
-rws--x--x. 1 root root 15K Oct 5 08:28 /usr/bin/chsh
-rwsr-xr-x. 1 root root 23K Sep 14 05:14 /usr/bin/passwd
-rws--x--x. 1 root root 16K Oct 5 08:28 /usr/bin/chfn
---s--x--x. 2 root root 169K Aug 21 04:24 /usr/bin/sudoedit
-rwsr-sr-x. 1 root root 45K Aug 21 03:26 /usr/bin/crontab
---s--x--x. 2 root root 169K Aug 21 04:24 /usr/bin/sudo
-rwsr-xr-x. 1 root root 60K Sep 7 08:04 /usr/bin/gpasswd
-rwsr-xr-x. 1 root root 51K Sep 29 11:58 /usr/bin/at
...

This command uses find to locate all files that have their setuid bit set (mode 4000). The hyphen preceding the mode causes find to report on any file that has this bit set, regardless of how the other bits are set. The output sent to standard error is redirected to /dev/null so that it does not clutter the screen.

You can also set up a program, such as AIDE (Advanced Intrusion Detection Environment; part of the aide package), that will take a snapshot of the system and check it periodically. See sourceforge.net/projects/aide for more information.

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition

Rescue Mode

Rescue mode is an environment you can use to fix a system that does not boot normally. To bring a system up in rescue mode, boot the system from the first installation CD, the Net Boot CD, or the install DVD. From the install DVD, select Rescue installed system from the Welcome menu (page 56). From the first installation CD and the Net Boot CD, enter the rescue (FEDORA) or boot rescue (RHEL) boot parameter. The boot process may take several minutes. The system then comes up in rescue mode.

In rescue mode, you can change or replace configuration files, check and repair partitions using fsck, rewrite boot information, and more. The rescue screen first asks if you want to set up the network interface. This interface is required if you want to copy files from other systems on the LAN or download files from the Internet. When you choose to set up the network interface, you need to decide whether to have DHCP automatically configure the network connection or to manually supply the IP address and netmask of the interface, as well as the IP addresses of the gateway and DNS server(s).

If the rescue setup finds an existing Linux installation, you can choose to mount it under /mnt/sysimage, optionally in readonly mode. With the existing installation mounted, once the system displays a shell prompt (similar to sh-3.2#), you can give the command chroot /mnt/sysimage to access the existing installation as it would be if you booted normally, with the existing installation’s root directory available as / (root). If you choose not to mount the existing installation, you are running a rescue system with standard tools mounted in standard locations (/bin, /usr/bin, and so on). Partitions from your local installation are available for fixing or mounting. When you exit from the rescue shell, the system reboots. Remove the CD or DVD if you want to boot from the hard drive.

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition

consolehelper: Runs Programs as root

The consolehelper utility can make it easier for someone who is logged in on the system console but not logged in as root to run system programs that normally can be run only by root. PAM, which authenticates users, can be set to trust all console users, to require user passwords (not the root password), or to require the root password before granting trust. The concept underlying consolehelper is that you may want to consider as trustworthy anyone who has access to the console. For example, Alex can log in on the console as himself and run halt without knowing the root password.

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition

su: Gives You Another User’s Privileges

The su (substitute user) utility can create a shell or execute a program with the identity and permissions of a specified user. Follow su on the command line with the name of a user; if you are working with root privileges or if you know the user’s password, you take on the identity of that user. When you give an su command without an argument, su defaults to Superuser so that you take on the identity of root (you have to know the root password).

To ensure that you are using the system’s official version of su (and not one planted on your system by a malicious user), specify su’s absolute pathname (/bin/su) when you use it. (Of course, if someone has compromised your system enough that you are running a fake su command, you are in serious trouble anyway-but using an absolute pathname for su is still a good idea.)

When you give an su command to become Superuser, you spawn a new shell, which displays the # prompt. You return to your normal status (and your former shell and prompt) by terminating this shell: Press CONTROL-D or give an exit command. Giving an su command by itself changes your user and group IDs but makes minimal changes to your environment. You still have the same PATH you did when you logged in as yourself. When you run a utility that is normally run by root (the utilities in /sbin and /usr/sbin), you may need to specify an absolute pathname for the utility (such as /sbin/service). When you give the command su - (you can use -l or --login in place of the hyphen), you get a root login shell: It is as though you logged in as root. Not only are your user and group IDs the same as those of root, but your entire environment is that of root. The login shell executes the appropriate startup scripts before displaying a prompt, and your PATH is set to what it would be if you had logged in as root, typically including /sbin and /usr/sbin.

Use the id utility to display the changes in your user and group IDs and in the groups you are associated with. In the following example, the information that starts with context pertains to SELinux:

$ id
uid=500(alex) gid=500(alex) groups=500(alex) context=user_u:system_r:unconfined_t
$ su
Password:
# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys), ...

You can use su with the -c option to run a single command with root privileges, returning to your original shell when the command finishes executing. The following example first shows that a user is not permitted to kill a process. With the use of su -c and the root password, the user is permitted to kill (page 409) the process. The quotation marks are necessary because su -c takes its command in the form of a single argument.

$ kill -15 4982
-bash: kill: (4982) - Operation not permitted
$ su -c "kill -15 4982"
Password:
$

Superuser, PATH, and security
The fewer directories you keep in your PATH when you are working with root privileges, the less likely you will be to execute an untrusted program as root. If possible, keep only the default directories, along with /sbin and /usr/sbin, in root’s PATH. Never include the working directory (as . or : : anywhere in PATH, or : as the last element of PATH).

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition

System Administrator and Superuser

Much of what a system administrator does is work that ordinary users do not have permission to do. When performing one of these tasks, the system administrator logs in as root (or uses another method; see the list starting on page 406) to have systemwide powers that are beyond those of ordinary users: A user with root privileges is referred to as Superuser. The username is root by default. Superuser has the following powers and more:

• Some commands, such as those that add new users, partition hard drives, and change system configuration, can be executed only by root. Superuser can use certain tools, such as sudo, to give specific users permission to perform tasks that are normally reserved for Superuser.

• Read, write, and execute file access and directory access permissions do not affect root: Superuser can read from, write to, and execute all files, as well as examine and work in all directories.

• Some restrictions and safeguards that are built into some commands do not apply to root. For example, root can change any user’s password without knowing the old password.

When you are running with root (Superuser) privileges, the shell by convention displays a special prompt to remind you of your status. By default, this prompt is or ends with a pound sign (#).

When you are working on the computer, especially when you are working as the system administrator, perform any task while using the least privilege possible. When you can perform a task logged in as an ordinary user, do so. When you must be logged in as Superuser, do as much as you can as an ordinary user, log in or use su so you have root privileges, complete the part of the task that has to be done as Superuser, and revert to being an ordinary user as soon as you can. Because you are more likely to make a mistake when you are rushing, this concept becomes more important when you have less time to apply it.

You can gain or grant Superuser privileges in a number of ways:

1. When you bring the system up in single-user mode, you are Superuser.

2. Once the system is up and running in multiuser mode, you can log in as root. When you supply the proper password, you will be Superuser.

3. You can give an su (substitute user) command while you are logged in as yourself and, with the proper password, you will have Superuser privileges.

4. You can use sudo selectively to give users Superuser privileges for a limited amount of time on a per-user and per-command basis. The sudo utility is controlled by the /etc/sudoers file, which must be set up by root. Refer to the sudo man page for more information.

5. Any user can create a setuid (set user ID) file. Setuid programs run on behalf of the owner of the file and have all the access privileges that the owner has. While you are running as Superuser, you can change the permissions of a file owned by root to setuid. When an ordinary user executes a file that is owned by root and has setuid permissions, the program has full root privileges. In other words, the program can do anything root can do and that the program does or allows the user to do. The user’s privileges do not change. When the program finishes running, all user privileges revert to the way they were before the program started. Setuid programs that are owned by root are both extremely powerful and extremely dangerous to system security, which is why a system contains very few of them. Examples of setuid programs that are owned by root include passwd, at, and crontab. The following example shows two ways for Superuser to give a program setuid privileges:

# ls -l my*
-rwxr-xr-x 1 root other 24152 Apr 29 16:30 myprog
-rwxr-xr-x 1 root other 24152 Apr 29 16:31 myprog2
# chmod 4755 myprog
# chmod u+s myprog2
# ls -l my*
-rwsr-xr-x 1 root other 24152 Apr 29 16:30 myprog
-rwsr-xr-x 1 root other 24152 Apr 29 16:31 myprog2

The s in the owner execute position of the ls -l output (page 203) indicates that the file has setuid permission.

6. Some programs ask you for a password (either your password or the root password, depending on the particular command and the configuration of the system) when they start. When you provide the root password, the program runs with root privileges. When a program requests the root password when it starts, you stop running as the privileged user when you quit using the program. This setup keeps you from remaining logged in as Superuser when you do not need or intend to do so.

Some techniques limit the number of ways to become Superuser. For example, PAM controls the who, when, and how of logging in. The /etc/securetty file controls which terminals (ttys) a user can log in on as root. The /etc/security/access.conf file adds another dimension to login control (see the file for details).


root-owned setuid programs are extremely dangerous
Because root-owned setuid programs allow someone who does not know the root password to exercise the powers of Superuser, they are tempting targets for a malicious user. A system should have as few of these programs as possible. You can disable setuid programs at the filesystem level by mounting a filesystem with the nosuid option. You can also use SELinux to disable setuid programs.


Do not allow root access over the Internet
Prohibiting root logins using login over a network is the default policy of Fedora/RHEL and is implemented by the PAM securetty module. The /etc/security/access.conf file must contain the names of all users and terminals/workstations that you want a user to be able to log in on as root. Initially every line in access.conf is commented out.

You can, however, log in as root over a network using ssh. As shipped by Fedora/RHEL, ssh does not follow the instructions in securetty or access.conf. Also, in /etc/ssh/sshd_config, Fedora/RHEL sets PermitRootLogin to YES (it is set by default) to permit root to log in using ssh.

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition

Using Init.d in Ubuntu

As the system boots, kernel drivers are loaded into memory and the init process begins setting the runlevel.At each runlevel, different software drivers and services are started. Which ones are started and the order in which they are started is determined by /etc/init.d/ and the rc script. There are eight rc directories: /etc/rc0.d, /etc/rc1.d, ... /etc/rc6.d, and /etc/rcS.d. These correspond with the different runlevels: 0 through 6, and S for system startup.

In each of these directories are symbolic links to files in /etc/init.d/. The name of the symbolic link determines whether the script is called when starting (S) or leaving (K for kill) the runlevel (see Listing 3-2). Each name also has a number, used to order when the service is started. This way,
dependent processes can be started in the right order. For example, S13gdm is started before S99rmnologin since the Gnome Display Manager (gdm) should be started before the user login prompt.

The directory /etc/init.d/ contains the actual control scripts (without the S/K and number). Each script has a start, stop, and restart option. So, for example, if you want to restart the network and stop the cron server, you can run:

sudo /etc/init.d/networking restart
sudo /etc/init.d/cron stop

To make system changes happen after the next reboot, add the appropriate S or K script to the appropriate runlevel directory.

Listing 3-2: Directory Contents of /etc/rc6.d
$ ls /etc/rc6.d
K01gdm K20zvbi
K01usplash K21postgresql-8.3
K01xdm K25hwclock.sh

Listing 3-2: Directory Contents of /etc/rc6.d (continued)
K09apache2 K25mdadm
K16dhcdbd K50alsa-utils
K19aumix K59mountoverflowtmp
K20apport K80nfs-kernel-server
K20avahi-daemon K99laptop-mode
K20cpufreqd README
K20dkim-filter S01linux-restricted-modules-common
K20dkms_autoinstaller S15wpa-ifupdown
K20libvirt-bin S20sendsigs
K20nas S30urandom
K20nfs-common S31umountnfs.sh
K20nvtv S32portmap
K20postfix S40umountfs
K20privoxy S51dmraid
K20snort S60umountroot
K20sysstat S90reboot
K20xinetd

RUNNING RAGGED
Ubuntu includes seven different runlevels: 0-6 and S. Many of the runlevels provide very specific services. For example, level 0 is a system halt, 1 provides for single-user mode, 6 reboots the system, and S provides services that are needed to start the system regardless of runlevel. The remaining runlevels provide different types of multi-user support. Usually the system uses level 2. This provides a graphical user interface (when available) and network support. The default level 3 provides support for accessibility devices, such as a Braille TTY display. Finally, levels 4 and 5 usually look like level 2, but you can modify them if you need customized run-time environments.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Starting Services in Ubuntu

After the device driver is loaded into the kernel, it usually needs to be configured. Each device driver has its own set of tools for doing the configuration. For example, the network uses ifconfig to configure addresses, and PCMCIA support uses cardmgr to notify the operating system when a new card is added or removed. Each driver is different. Some software drivers are only needed once to configure the system (for example, network, audio, and system clock); others are needed continually, while the device is in use (for example high-resolution graphics and the mouse). A few KLM drivers require no additional assistance—keyboard, hard drives, and USB fall into this category.

In addition to configuring and managing kernel drivers, some software drivers are software-only (no KLM needed). These services include virtual file systems, displays, and schedulers. Finally, application and network services, such as Secure Shell (SSH) and the web, can be configured. While kernel modules are managed by the LKM subsystem, the Init and Upstart systems manage the configuration and management of application and network services.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Optimizing Modules in Ubuntu

If you’re trying to streamline your system, you may not want to have all of the various modules installed or accessible. Although unused modules take virtually no resources (even if they are loaded into memory), systems with limited capacity or that are hardened for security may not want unnecessary LKMs. Between the lsmod and modprobe -l commands, you can identify which modules are unnecessary and either remove them from the system or just not load them.

For example, if you do not have a printer on your parallel port, then you probably do not need the lp module loaded. Similarly, if you want to disable the floppy disk, you can remove that driver, too.

sudo modprobe -r lp
sudo modprobe -r floppy

You can make these changes permanent by removing lp from /etc/modules and adding both lp and floppy to /etc/modprobe.d/blacklist (or blacklist.conf). Alternately, if you need the disk space, then you can just delete the drivers from the system (use modinfo -F filename lp and modinfo -F filename floppy to find the files).

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Installing and Removing Modules in Ubuntu

Modules are relatively easy to install. The insmod command loads modules, and rmmod removes modules. The modprobecommand actually uses insmod and rmmod but adds a little more intelligence. The modprobe command can resolve dependencies and search for modules.

As an example, let’s look at the suni.ko ATM driver (you probably do not have it installed, and you probably don’t need it). Listing 3-1 shows different queries for the driver, installing the driver, and removing it.

Asynchronous transfer mode (ATM) network cards are uncommon on home PCs, so this is a good type of device driver to play with when learning how to
load and unload LKMs. If we used a common driver for this example, then you could end up disabling your hard drive, printer, or other device. If you do happen to have a Saturn User Network Interface (SUNI) ATM card, then consider using a different driver for this example, such as pppoatm.

Listing 3-1: Sample LKM Queries and Management
$ modinfo suni # information about the module
filename: /lib/modules/2.6.24-26-generic/kernel/drivers/atm/suni.ko
license: GPL
srcversion: 4F4DC0C890932441A81CC12
depends:
vermagic: 2.6.24-26-generic SMP mod_unload 586
$ lsmod | grep suni # see if it is installed
[none found]
$ modprobe -l -t atm # show all ATM modules
/lib/modules/2.6.24-26-generic/kernel/drivers/usb/atm/cxacru.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/usb/atm/usbatm.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/usb/atm/speedtch.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/usb/atm/ueagle-atm.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/usb/atm/xusbatm.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/idt77252.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/iphase.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/he.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/atmtcp.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/fore_200e.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/nicstar.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/lanai.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/suni.ko
...
$ modprobe -l '*suni*' # Show only the suni.ko module
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/suni.ko
$ modprobe -l -a 'suni’ # Show all suni modules
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/suni.ko
$ sudo modprobe -a suni # install all suni modules
$ lsmod | grep suni # show it is installed
suni 7504 0
$ sudo modprobe -r suni # remove it
$ lsmod | grep suni # show it is removed
[none found]

Using modprobe -l without any other parameters will list every module on the system.

The installation step could also be accomplished using

sudo insmod /lib/modules/2.6.24-26-generic/kernel/drivers/atm/suni.ko

Similarly, removal could also use any of the following commands:

sudo rmmod /lib/modules/2.6.24-26-generic/kernel/drivers/atm/suni.ko
sudo rmmod suni.ko
sudo rmmod suni

To make the installation permanent, you can add the module name to either /etc/modules or /etc/modprobe.d/. (See the man pages for modules and modprobe.conf.) In general, /etc/modules is simpler for adding a new module, since it just lists onemodule per line.However, the /etc/modprobe.d/ configuration files permit more configuration options.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Viewing Modules in Ubuntu

The basic command to see what modules are currently loaded is lsmod. Running lsmod displays the LKM’s common name, size of the LKM, and any other LKMs that depend on it. For example:

$ lsmod | head
Module Size Used by
floppy 64676 0
rfcomm 43604 0
l2cap 28192 5 rfcomm
bluetooth 54084 4 rfcomm,l2cap
ppdev 9668 0
speedstep_lib 4580 0
cpufreq_userspace 6496 0
cpufreq_stats 6688 0
freq_table 4928 1 cpufreq_stats

This shows that the bluetooth module is loaded and is in use by the rfcomm and l2cap modules. A second command, modprobe, can be used to show the actual LKM files.

$ modprobe -l bluetooth
/lib/modules/2.6.24-26-generic/kernel/net/bluetooth/bluetooth.ko

The modprobe command can also list available modules-not just ones that are loaded. For example, to see all the asynchronous transfer mode (ATM) network drivers, you can use:

$ modprobe -l -t atm
/lib/modules/2.6.24-26-generic/kernel/drivers/usb/atm/cxacru.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/usb/atm/usbatm.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/usb/atm/speedtch.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/usb/atm/ueagle-atm.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/usb/atm/xusbatm.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/idt77252.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/iphase.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/he.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/atmtcp.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/fore_200e.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/nicstar.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/lanai.ko
/lib/modules/2.6.24-26-generic/kernel/drivers/atm/suni.ko
...

The -t atm parameter shows all modules with the ATM tag. LKMs are stored in an organized directory, so the tag indicates the directory name. This is different from using modprobe -l '*atm*’, since that will only show modules containing ‘‘atm’’ in the LKM file name.

Along with modprobe, you can use modinfo to learn more about a particular LKM. The modinfo command lists information about a module, or it can be used to retrieve specific information. For example:

$ modinfo lp # list information about the lp module
filename: /lib/modules/2.6.31-15-generic/kernel/drivers/char/lp.ko
license: GPL
alias: char-major-6-*
srcversion: 84EA21D13BD2C67171AC994
depends: parport
vermagic: 2.6.31-15-generic SMP mod_unload modversions 586
parm: parport:array of charp
parm: reset:bool

If you only need to see a particular field from the modinfo output, then you can use the -F parameter with any of the listed fields. For example, -F filename only displays the file name for the module.

$ modinfo -F filename lp # only list the filename field
/lib/modules/2.6.31-15-generic/kernel/drivers/char/lp.ko

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Loading Modules in Ubuntu

Very early versions of Linux had all the necessary kernel drivers compiled into the kernel. This meant that the kernel knew exactly what was supported. If you needed to add a new device, you would need to compile a new kernel. Unfortunately, including every driver in the kernel led to a big problem: the kernel became too large. Back in the days of floppy disks, it would take two 1.44-MB disks to boot Linux—one for the kernel and the other for the rest of the operating system. The kernel developers introduced compressed kernels, but even those became too large for floppy disks.

Fortunately, the barbaric days of compiling all desired modules into the kernel are long gone. Today, Linux uses loadable kernel modules (LKMs). Each LKM can be placed in the kernel as needed. This keeps the kernel small and fast. Some LKMs can even perform a check to see if they are required. If you don’t have a SCSI card on your computer, then the SCSI LKM driver won’t load and won’t consume kernel resources. Usually, hardware is found through device identifiers, but sometimes you need to tell the operating system to enable the device.

Ubuntu includes a healthy selection of common and uncommon kernel modules. If the device has any type of stable Linux support, then it is very likely that Ubuntu has the LKM on the system.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

USEFUL PROGRAMS

Many computer peripherals and add-ons are either pointer or video devices. There are two programs that are very useful when trying to test these devices. The first is the GNU Image Manipulation Program or gimp (www.gimp.org), a very powerful drawing tool that supports most types of pointer devices and can also capture input from video devices such as cameras, scanners, and TV cards.

The second useful program is called Scanner Access Now Easy or sane (www.sane-project.org). This is strictly used for capturing images from a video device such as a scanner, digital still camera, digital video camera, or TV card. The xsane program provides an X-Windows front end for sane. As with gimp, xsane can capture images from a variety of input devices.

The sane, xsane, and gimp programs are installed by the default Ubuntu desktop configuration.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Working with Device Drivers

Under Linux, there are a couple of required elements forworkingwith devices. First, you need a kernel driver that can recognize the device. This is usually a low-level driver, such as a parallel port driver for use with parallel printers or USB support (regardless of the USB device).

The second element depends on the type of hardware—some devices need software support for managing the device. The kernel driver only knows how to address the device; the software driver actually speaks the right language. This means that different versions of the same device may speak different languages but communicate over the same kernel driver. Printers are one such example. A printer may use PostScript, HP PCL, oki182, or some other format to communicate data. The kernel driver knows how to send data to the printer, but the software driver knows what data to send. The same is true for most scanners, cameras, pointer devices, and even keyboards.

The final element is the user-level application that accesses the device. This is the program that says ‘‘print’’ or the audio system that says ‘‘play.’’

There are four steps needed before using any device:
1. Install a device driver, if one is not already installed.
2. Create a device handle if one is not created automatically.
3. Load any required software drivers and configuration parameters.
4. Configure applications as necessary for using the device.

In some cases, some or all of these steps are automated. In other cases, devices will need manual configuration.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Altering the Login Screen

Now that you have your desktop configured, it is time to do something about that login screen. Every Ubuntu version has a different default login screen. How you change it depends on the version of Ubuntu.

With every Ubuntu version up through Jaunty Jackalope, including Dapper Drake (6.06 LTS) and Hardy Heron (8.04 LTS), you can open up the Login
Window Preferences applet (System ? Administration ? LoginWindow). This lets you select different styles, themes, backgrounds, colors, and even security
options such as an automatic login and the list of users who are permitted to log in.

Beginning with Karmic Koala (9.10), the login screen settings have become significantly feature limited. The only thing you can do is enable or disable the automatic login.Under Karmic, you will need to change the login configuration manually. You can change the background, colors, widget set, and fonts by running the gnome-appearance-properties applet as the Gnome Display Manager (user gdm).

sudo -u gdm dbus-launch gnome-appearance-properties

Alternately, you can change specific properties using gconftool-2. For example, you can get and set the login screen’s background image using:

# Get the current background image filename
sudo -u gdm gconftool-2 -g /desktop/gnome/background/picture_filename
# Set the background image to a new file
sudo -u gdm gconftool-2 -s /desktop/gnome/background/picture_filename \
-t string /path/to/background.png

The other aspect of the login screen that I usually change is the user list. By
default, it lists every user on the system. However, if you want your privacy
(and to not show every name on your system) or have dozens of users on the
system and don’t want a long scroll window, then you will need to disable the
user list.

# Get the current user list setting
sudo -u gdm gconftool-2 -g /apps/gdm/simple-greeter/disable_user_list
# Set the value to true for disabling the list
sudo -u gdm gconftool-2 -s /apps/gdm/simple-greeter/disable_user_list \
-t bool true

You can alter other options using the graphical gconf-editor. I suggest
looking under the configuration path /apps/gdm/simple-greeter. This is
where you can find options to set the greeter text message, change language
settings, and even disable the login screen’s restart button.

sudo -u gdm dbus-launch gconf-editor

After you make these changes, log out and view your handiwork.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Helping with Big Fonts

I have a couple of coworkers who wear reading glasses when sitting at the computer. More than once, they have come over to my work area and had to run back to get their glasses. To help them (and tease them), I created a Grandpa Mode macro that increases the screen font size-just for them. Permanently
setting up the ability to use Grandpa Mode requires four commands. The first two define custom commands that change the dpi value. The second two bind the commands to key sequences.

gconftool-2 -t str-set /apps/metacity/keybinding_commands/command_7 \
'gconftool-2 -t float-set /desktop/gnome/font_rendering/dpi 200’
gconftool-2 -t str-set /apps/metacity/keybinding_commands/command_8 \
'gconftool-2 -t float-set /desktop/gnome/font_rendering/dpi 96’
gconftool-2 -t str-set /apps/metacity/global_keybindings/run_command_7 \
'F7’
gconftool-2 -t str-set /apps/metacity/global_keybindings/run_command_8 \
'F8’

Now pressing Ctrl+F7 changes the resolution to 200 dpi and makes the fonts appear large (and coworkers can read it without glasses). Ctrl+F8 returns the
screen to the system default of 96 dpi.

If you want to remove Grandpa Mode, you can use the gconftool-2-unset option:

# reset default dpi
gconftool-2 -t float-set /desktop/gnome/font_rendering/dpi 96
# unset key mappings
gconftool-2-unset /apps/metacity/keybinding_commands/command_7
gconftool-2-unset /apps/metacity/keybinding_commands/command_8
gconftool-2-unset /apps/metacity/global_keybindings/run_command_7
gconftool-2-unset /apps/metacity/global_keybindings/run_command_8

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Changing the DPI in Ubuntu

Different output devices render the fonts at different resolutions. Increasing the font size will make it appear larger on all devices, including the screen and printer. On the other hand, if you change the rendering resolution for a single device, then the same font size will be larger or smaller.

The default desktop fonts are rendered at 96 dpi. You can change the dpi value by opening the System-> Preferences -> Appearance applet, selecting the Fonts tab, and clicking the Details button.

Although the Font applet is good for one-time changes, it cannot be easily automated. The dpi value can also be set through the gconf-edit registry under /desktop/gnome/font_rendering/dpi. This value can be adjusted to match your screen. For example, if you change the screen resolution or use a different size monitor, then fonts may appear larger or smaller.

To change the dpi value, use:

gconftool-2 -t float—set /desktop/gnome/font_rendering/dpi 96

Values larger than 96 will make the fonts appear larger (but not change the actual font size), whereas a smaller number decreases the rendered size. In general, changing the dpi setting only changes how fonts are rendered on the screen. It does not change the size of the application windows nor impact how documents will print.

With Dapper Drake (6.06 LTS), use System -> Preferences -> Font. Later versions of Ubuntu use the Appearance applet.

Changing the rendering resolution only alters fonts rendered by the desktop. For example, the Gnome terminal (Applications -> Accessories -> Terminal) and Gnome Text Editor (gedit) both will change sizes, but an xterm window will not; xterm uses px, not pt. Also, some applications, such as xchat, use hard-coded window heights, so the tops or bottoms of large fonts may be brutally cropped.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

MAKING A POINT

There are three metrics for determining font size. First, there are pixels (px). These are the active elements on the screen. Screen coordinates such as 1024x768 usually describe absolute pixel values.

The dots-per-inch (dpi) describes the density of the pixels. A monitor that is 14 inches across at 1024x768 has approximately 73 horizontal pixels per inch (73 dpi), while a 20-inch wide screen at the same resolution has 51 pixels per inch (51 dpi).

Finally, a point (pt) is used to describe a portable density. There are 72 pt per inch. When rendering, a 12-pt font should have letters that are 0.17 inches wide (12 pt ÷ 72 pt per inch). If the screen is 96 dpi, then the letters should be 16 pixels wide (12 pt ÷ 72 pt per inch × 96 dpi = 16 px).

When rendering the font, the system maps the font pt to the known dpi. If the screen is not configured with the correct dpi value, then the font on a printed document may appear at a different size than in the same document on the screen. Usually people don’t change the screen dpi setting, but that doesn’t mean that you can’t.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Changing Sounds under Karmic Koala

With Karmic Koala (9.10), modifying the system sounds is a little more complicated. The System -> Preferences -> Sound menu options permit you to change the entire sound theme, but you cannot alter specific sounds. Moreover, the desktop login sound is not even listed.

The startup sound is actually found under System -> Preferences -> Startup Applications. To disable the desktop login sound, uncheck the GNOME Login Sound item.

Creating your own audio theme is more complicated in Karmic because there is no GUI interface.

1. Open a terminal window and go to the /usr/share/sounds/ directory.

cd /usr/share/sounds

2. Copy the Ubuntu default audio theme to your own theme:

sudo cp -r ubuntu newtheme

3. In your newtheme directory is a file called index.theme. Change the theme’s name from name=Ubuntu to your own theme name (for example, name=My Cool Audio Theme).

4. Under newtheme/stereo/ are a bunch of OGG sound files. The file name tells you when each is used. For example, desktop-login.ogg is played when the GNOME Login Sound plays. Replace these OGG fileswith your own OGG files. You can use sox to convert other audio formats to OGG.

5. When you are finished, go to System -> Preferences -> Sound and select your new sound theme from the list.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Modifying Audio Files in Ubuntu

Most WAV files are longer than a few seconds, and you probably do not want a three-minute song playing every time you click a button. The sox program can be used to trim audio files, but you will need to know the starting time for the sound you want and the length. For example, to start 3 seconds into the file and keep a 2.31 second duration, use:

sox fileIN.mp3 fileOUT.wav trim 3 2.31

Trim times can be written in a variety of formats. You can specify seconds (and fractions of a second) or actual time values. The value 125.6 can be written as 2:05.6 or 0:2:5.6. The notations indicate seconds (with fractions), minutes, and hours. Also, if you do not specify the duration, then it goes to the end of the file.

The sox command can also add effects such as echos, high-pass and low-pass filtering, stretching, and reversing. For a full list of functions, refer to the sox man page (man sox).

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Changing Sounds under Karmic Koala

With Karmic Koala (9.10), modifying the system sounds is a little more complicated. The System -> Preferences -> Sound menu options permit you to change the entire sound theme, but you cannot alter specific sounds. Moreover, the desktop login sound is not even listed.

The startup sound is actually found under System -> Preferences -> Startup Applications. To disable the desktop login sound, uncheck the GNOME Login Sound item.

Creating your own audio theme is more complicated in Karmic because there is no GUI interface.

1. Open a terminal window and go to the /usr/share/sounds/ directory.

cd /usr/share/sounds

2. Copy the Ubuntu default audio theme to your own theme:

sudo cp -r ubuntu newtheme

3. In your newtheme directory is a file called index.theme. Change the theme’s name from name=Ubuntu to your own theme name (for example, name=My Cool Audio Theme).

4. Under newtheme/stereo/ are a bunch of OGG sound files. The file name tells you when each is used. For example, desktop-login.ogg is played when the GNOME Login Sound plays. Replace these OGG fileswith your own OGG files. You can use sox to convert other audio formats to OGG.

5. When you are finished, go to System -> Preferences -> Sound and select your new sound theme from the list.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

SOX AIN’T LAME

The sox application is a great tool for converting and modifying sound files, but it does not support all formats for all functions. In particular, even though it can read MP3 files, it cannot be used to create MP3 files without additional libraries. To resolve this constraint, you can use the lame package to encode MP3 files from WAV files.

Just as GNU is a recursive acronym, GNU is Not Unix, LAME uses a recursive name: LAME Ain’t an MP3 Encoder. Ignoring the name, lame is a powerful tool for creating MP3 files. First, make sure that the package is installed: sudo apt-get install lame. Then, convert your WAV file to an MP3 file: lame fileIN.wav fileOUT.mp3.


The MP3 file from LAME cannot be used for system sounds (because system sounds do not support MP3 files) but can be used by other audio applications and portable music devices.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Converting Audio Files in Ubuntu

You may select anyWAV audio file for any of the audio events. If you want to use a different audio format, such as MP3 or OGG, you will need to convert it to aWAV file. The easiestway to convert audio files iswith sox—the universal sound exchanger.

1. The sox package comes from the universe repository, but this repository is not enabled by default. As root, you will need to edit /etc/apt/ sources.list and uncomment the two universe lines. These should be near the top of the file and look similar to:

deb http://us.archive.ubuntu.com/ubuntu/ hardy universe
deb-src http://us.archive.ubuntu.com/ubuntu/ hardy universe

You will also need to update the repository cache:

sudo apt-get update

2. Install sox if it is not already installed.
sudo apt-get install sox

3. Use sox to convert the audio file. By default, sox determines file types by the file extension.

sox fileIN.mp3 fileOUT.wav

4. Test the sound file using the play command:

play fileOUT.wav

5. From the Sound Preferences applet, select the pull-down menu for the desired system sound, for example, ‘‘Login’’ and click ‘‘Select Sound File’’.

6. Select the WAV file you just created.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

CONFIGURING GRUB UNDER KARMIC KOALA

GRUB’s configuration was very consistent though all versions of Ubuntu . . . until Karmic Koala (9.10) showed up. While GRUB essentially works the same way, all of the configuration files moved.

For example, earlier Ubuntu versions use /boot/grub/menu.lst for setting the timeout, default operating system, and associated parameters. With Karmic, the configuration has been split. The file /etc/default/grub contains generic settings, including the timeout (GRUB_TIMEOUT) and default parameters (GRUB_DEFAULT and GRUB_CMDLINE_LINUX_DEFAULT).

Additional configuration scripts have been moved under /etc/grub.d/. For example, the actual Linux boot command is stored in /etc/grub.d/10_linux, and the memory tester is in 20_memtest86+.

The final significant change comes from the list of kernels and operating systems. With earlier versions of GRUB, the kernel list was automatically detected from the /boot/ directory and then added to the final automated section of the menu.lst file. The new version of GRUB still automatically discovers all installed kernels, but the list is now stored in /boot/grub/grub.cfg. This configuration file is completely auto-generated. Do not edit this file. Instead, make any configuration changes to the /etc/default/grub and /etc/grub.d/ files.

When you finish customizing GRUB, be sure to run sudo update-grub to refresh the automatically generated files and update the boot loader.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Configuring GRUB

When you first boot your Ubuntu system, there is a small text screen that says GRUB Loading, and you have three seconds to press Esc before it boots the default operating system. GRUB is the GRand Unified Bootloader and determines which operating system you want to run. If you press Esc during the boot loader screen, you can select alternate operating systems, kernels, and kernel parameters.

If you don’t press Esc in three seconds, then GRUB will boot the default operating system. You can change the GRUB configuration by editing /boot/grub/menu.lst. For example, if you change the timeout value to 15 (from timeout 3 to timeout 15), then GRUB will wait 15 seconds before booting the default operating system. This is very useful if your monitor takes a few seconds to wake up from power-save mode or if you are just slow to press Esc.

Similarly, menu.lst file includes the list of known kernels and operating systems at the end of the file. The first one listed is item 0, the second is item 1, and so on. At the beginning of menu.list is a line that says Default 0. This identifies the default operating system configuration as the first one in the list. If you change it to Default 3, then the fourth system listed will become the default.



Altering Boot Parameters
The /boot/grub/menu.lst file contains three main sections. The first section, found at the top of the file, contains basic parameters such as timeout and default.

The second section is denoted by a line that says BEGIN AUTOMAGIC KERNELS LIST. This section contains parameters used for automatic kernel configuration. Each of these lines begins with one or two hash signs (# or ##). Usually a hash sign denotes a commented line. However, the automated script actively removes the first hash in order to obtain customized kernel parameters. Real comments have two hash signs; configuration parameters have one.

For example, one ofmycomputers requires the kernel parameter pci=nobios in order to boot properly. Rather than pressing Esc and manually entering it each time I reboot, I can add it to the boot options line. It needs to have one hash character so that it becomes a configuration parameter.

## additional options to use with the default boot option, but not with
## the alternatives
## e.g. defoptions=vga=791 resume=/dev/hda5
# defoptions=pci=nobios

The final section of the file comes after the line that says End Default Options. Do not modify anything below this line. Whenever you update the system and install a new kernel or make changes to GRUB, this section is\ regenerated. Anything manually changed after this line will be lost the next time you install a kernel upgrade.



Updating GRUB
The boot loader does not actually reside in the Linux partition. Instead, it is hooked into the sector containing the partition table on the hard drive. After you make any changes to the GRUB configuration files, you need to update the installed boot loader:

sudo update-grub

This command regenerates the /boot/grub/menu.lst file and updates the boot loader on the hard drive.

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations

Upgrading Issues with Ubuntu

Ubuntu upgrades are not always painless. (I have not yet had a simple upgrade.) Although upgrading from a new Dapper install (with no additions) to Edgy toHardy workswell, you are unlikely to be running a new installation of Dapper or Edgy. Customizations lead to upgrade complications. For example:

Custom system files—Customizing files, such as /etc/gdm/gdb.conf, will prompt you to resolve installation conflicts. You can either overwrite or keep the old file, but you cannot merge changes.

Proprietary drivers—Binary and custom drivers, ranging from the Macromedia Flash player to wireless network support, may break. You will need to uninstall and reinstall the software.

Shared Libraries—Different versions of Ubuntu use different linked libraries. For example, Jaunty uses newer libraries than Hardy. Code that is compiled for one set of libraries may break under the new system; be prepared to recompile as needed.

Moving files—Required system files may move between upgrades. For example, the w32codec files may be located in /usr/lib/win32/, /usr/lib/codec/, or some other directory, depending on when and how you installed it. You may even have different versions of the same files in different directories, leading to run-time compatibility issues.

The time required to do an upgrade is another significant issue. An upgrade usually takes at least three times longer than a clean install. This is because the upgrade checks files before modifying the system. While a 2-GHz computer may install in 15 minutes and upgrade in under an hour, a slower computer can take many hours. My 2-GHz PC upgraded over the network from Dapper to Hardy in roughly 5 hours. The same computer completed a network install ofHardy in less than 30 minutes.

Finally, your graphical desktop may not look like a new installation. Menus and applications change between Ubuntu versions, but upgrades do not receive the changes, For example, if you migrated from HardyHeron to Jaunty Jackalope to Karmic Koala, then you will still have the System -> Preferences -> Removable Drives and Media menu, even though the popup window no longer describes any settings for removable drives or media. Under a clean install of Karmic, this menu option does not exist.

Be prepared to devote time to upgrading. Because you may be prompted occasionally to resolve conflicts, you cannot walk away and expect the upgrade to finish without your intervention. If the upgrade takes two hours, you should be near the computer for two hours. After the upgrade has been completed, you may need to spend additional time fixing broken drivers and recompiling software. (Be sure to stock up on coffee and order in for lunch.)

Source of Information : Wiley Ubuntu Powerful Hacks And Customizations