Linux Unix Umask

Umask :
The umask (UNIX shorthand for "user file-creation mode mask") is a four-digit octal number that UNIX uses to determine the file permission for newly created files.
Every process has its own umask, inherited from its parent process.
The umask specifies the permissions you do not want given by default to newly
created files and directories. umask works by doing a bitwise AND with the bitwise complement of the umask. Bits that are set in the umask correspond to permissions that are not automatically assigned to newly created files.
By default, most UNIX versions specify an octal mode of 666 (any user can read or write the file) when they create new files. Likewise, new programs are created with a mode of 777 (any user can read, write, or execute the program).
The most common umask values are 022, 027, and 077. A umask value of 022 lets the owner both read and write all newly created files, but everybody else can only read them:
0666 default file-creation mode
(0022) umask
0644 resultant mode
A umask value of 077 lets only the file's owner read all newly created files:
0666 default file-creation mode
(0077) umask
0600 resultant mode
A simple way to calculate umask values is to remember that the number 2 in the
umask turns off write permission, while 7 turns off read, write, and execute
permission.

A umask value of 002 is commonly used by people who are working on group
projects. If you create a file with your umask set to 002, anyone in the file's group will be able to read or modify the file. Everybody else will only be allowed to read it:
0666 default file-creation mode
(0002) umask
0664 resultant mode
On many UNIX systems, the default umask is 022. This is inherited from the init
process, as all processes are descendants of init. Some systems may be configured to use another umask value, or a different value may be set in the startup files.
The designers of these systems chose this umask value to foster sharing, an open computing environment, and cooperation among users. Most prototype user accounts shipped with UNIX operating systems specify 022 as the default umask, and many computer centers use this umask when they set up new accounts. Unfortunately, system administrators frequently do not make a point of explaining the umask to novice users, and many users are not aware that most of the files they create are readable by every other user on the system.
A recent trend among computing centers has been to set up new accounts with a
umask of 077, so a user's files will, by default, be unreadable by anyone else on the system unless the user makes a conscious choice to make them readable.
Common umask settings and their effects:
umask User Access Group Access Other
0000 all all all
0002 all all read, execute
0007 all all none
0022 all read, execute read, execute
0027 all read, execute none
0077 all none none

Migrating to Open Source 90% Less than Upgrading Microsoft

Migrating to Open Source 90% Less than Upgrading Microsoft
To tide us over until that more comprehensive analysis is undertaken, we have found a recently released independent study by the Dutch government. In that report10, the researchers found that migrating to an open source desktop productivity platform was 90% less expensive than migrating to the new version of the Microsoft productivity platform.
This included accounting for all the costs of migration, such as retraining,
redevelopment of macros and addon applications, any conversion costs for existing documents etc. As this is only a single data point, it would be impossible to rely on the results as a template for all Microsofttoopen source migrations. However, it is independent research, undertaken by a public sector organisation which has no vested interest in either Microsoft's nor Linux's position in this matter. This research was also based on a large scale migration, involving over 2000 desktops. Certainly within the realm of organisational size we are considering in this TCO, There is another important point to consider when modelling your organisation's cost of upgrading to a newer version of Microsoft products versus the cost of migrating to Linux and open source. Most rganisations will likely factor in the costs associated with a single upgradeversusmigration cycle. By this we mean an organisation calculating the cost of upgrading to the next version of the Microsoft product versus migrating to Linux, rather than including the subsequent upgrades as well.
Many of the costs of upgrading to newer versions of Microsoft platforms (licences,
software assurance etc.) have to be borne again and again. Most of the costs of migrating to Linux are borne once, during the initial migration. Any subsequent upgrades for that Linux platform occur with no licence costs nor software assurance costs. Therefore, to provide a more realistic appraisal and model of this scenario, you should include two or three full refresh lifecycles, stretching over a period of 510 years. Therefore rather than an upgrade versus migration, you contrast costs of an upgradeupgradeupgrade versus migrationupgradeupgrade
process.

LILO and the x86 Boot Process

This section will discuss in more detail the specic role LILO plays when booting an x86 system. For
a detailed look at the overall boot process, see Section 3.2.
LILO loads itself into memory almost identically to GRUB, except it is only a two stage loader.
1. The Stage 1 or primary boot loader is read into memory by the BIOS from the MBR2. The
primary boot loader exists on less than 512 bytes of disk space within the MBR. The only thing
it does is load the Stage 2 boot loader and pass to it disk geometry information.
2. The Stage 2 or secondary boot loader is read into memory. The secondary boot loader displays
the Red Hat Linux initial screen. This screen allows you to select which operating system or
Linux kernel to boot.
3. The Stage 2 boot loader reads the operating system or kernel and initrd into memory. Once LILO determines which operating system to start, it loads it into memory and hands control of the machine to that operating system.
Once the Stage 2 boot loader is in memory, LILO displays the initial Red Hat Linux screen with the different operating systems or kernels it has been congured to boot. If you only have Red Hat Linux installed and have not changed anything in LILO's conguration le, you will see only linux as an option. If you install SMP kernel support, you will see linux-up as an option. If you have set up LILO
to boot other operating systems as well, this screen is your chance to select what operating system will boot. Use your arrow keys to highlight the operating system and press If you would like to have a command prompt to enter a command to LILO, press [Ctrl]-[X]. LILO
displays a LILO: prompt on the screen and waits for input from the user.

Linux Virtual File System

Under Linux, all data are stored as les. Most users are familiar with the two primary types of les:
text and binary. But the /proc/ directory contains another type of le called a virtual le. It is for this reason that /proc/ is often referred to as a virtual le system.
These virtual les have unique qualities. Most of them are listed as zero bytes in size and yet when one is viewed, it can contain a large amount of information. In addition, most of the time and date settings on virtual les reect the current time and date, indicative of the fact they constantly changing.
Virtual les such as interrupts, /proc/meminfo, /proc/mounts, and /proc/partitions provide an up-to-the-moment glimpse of the system's hardware. Others, like /proc/filesystems and the /proc/sys/ directory provide system conguration information and interfaces.
For organizational purposes, les containing information on a similar topic are grouped into virtual directories and sub-directories. For instance, /proc/ide/ contains information for all physical IDE devices. Likewise, process directories contain information about each running process on the system.