Articles

Hardware Life Cycle Management(Part II)

Articles /

There are a number of financial planning exercises that can help you determine if capital expenses for PC hardware with complete parts and service contracts for the life of the unit are best suited for your IT infrastructure.

Alternatively, leased IT equipment may be more cost effective and would assist in maintaining a more comprehensive IT equipment life-cycle program.

As we dig further into this topic, you will see that hardware and software deployment planning is just the start of discussion for the IT group. Migration planning raises more questions than answers and these questions start with equipment and software life-cycle management. For example, planning discussions can start with these questions:

•    What is your IT department’s roadmap for equipment management?
•    How about the users you support, does your roadmap align with their needs?
•    What requirements have inter-company business owners or department managers contributed to the overall equipment management policy? Are any of the suggested requirements based on some of the above mentioned methods? (i.e., does the accounting department determine the life-cycle or does the OEM warranty determine the life-cycle, or is the policy just to “run the equipment into the ground”?)

Visualising the product map of the software your organisation uses and planning your major equipment purchases within a timeline helps structure your hardware retirement strategy.   By synchronising your hardware purchases with your software investment, you can minimise large capital expenditures and stagger departmental purchases so that you can qualify for volume discounts.

Additionally, if your organisation qualifies for specific licensing models, you may be able to plan your software purchasing on alternate years from your hardware purchasing. Take Microsoft’s core software products as an example (Fig. 1).

Figure 1: Recent Microsoft software product launches

hardware life cycle 2
It is tempting to think that only hardware equipment has a life-cycle, yet the above example clearly shows that software too has a life-cycle. Could your IT infrastructure benefit from synchronising your life-cycle management of both PC hardware units and software licenses? Where does your organisation envision product adoption and integration with respect to manufacturer rollout? Finally, does your PC hardware for servers, desktops, and laptops or notebooks align with or complement that vision?

Hardware Life Cycle Management(Part II) Read More »

Hardware Life Cycle Management(Part III)

Articles /

Planning for a migration
Planning for product life-cycles necessitates an implementation strategy. Migration of computer systems has evolved from the manual process of a complete rebuild and then copying over the data files to an intelligent method of transferring the settings of a particular system and then the data files.

Many IT professionals can attest to the fact that there is a large investment in time and fine tuning of new servers. Whether it’s complexity of domain controllers, user and group policies, security policies, operating system patches, and additional services to users – all of these require time to set up. Fine tuning the server after the rollout can be time consuming as well. Once completed, a computer system administrator wants to have the confidence that the equipment and operating system are going to operate normally.

Thought needs to be given as well to the settings and other customization that users have done on their workstations. Some users are allowed to have a number of rights over their machine and can thus customize software installations, default file locations to alternate locations, or can have a number of programs that are unknown to the IT department. This can make a unilateral migration unsuccessful because of all of the unique user settings. The aftereffect is a disaster with users having missing software and data files, lost productivity as they re-customize their workstations, and worst of all, overwritten or lost files.

Deployment test labs are a must for migration preparation. A test lab should include, at a minimum, a domain controller, one or two sample production file servers, and enough workstations, sample data, and users to simulate a user environment. Virtualization software can assist with testing automated upgrades and migrations. The software tools to do the actual migration are varied – some are from operating system software vendors, others may be third party applications or enterprise software suites that provide other archiving functions. There are a number of documents and suggestions for migration techniques (some are listed in the references).

The success of a migration rests on analysis, planning, and testing before rolling out changes. For example, one company with over 28,000 employees has a very detailed migration plan for its users. The IT department used a lab, separate from the corporate network infrastructure, to test deployments and had a team working specifically on migration. The team had completed the test-lab phase of their plan and the migration was successful in that controlled environment.

The next phase was to roll out a test case on some of the smaller departments within the company.  The test case migration was scheduled to run automatically when the users logged in. The migration of the user computers to a new operating system started as planned. After the migration, the user computers automatically started downloading and installing software updates (a domain policy). Unfortunately, one of these updates had not been tested. The unexpected result was that user computers in the test case departments were inoperable.

Some of the users in the test case contacted the IT Help Desk for assistance. IT immediately started troubleshooting the operational issues of the problem without realizing that this was caused by a migration test case error. Other users in the department who felt technically savvy tried solving the problem themselves. This made matters worse when one user reformatted and reinstalled the operating system and overwrote a large portion of original data files.

Fortunately for this company, their plan was built in phases and had break-points along the way so that the success of the migration could be measured. The failure in this case was two-fold in that there were some domain policies that had not been implemented on test lab servers, and the effect of a migration plus the application of software updates had not been fully tested. The losses were serious for some users, yet minimal for the entire organization.

For other migration rollouts, the losses can be much more serious. For example, one company’s IT department created a logon script to apply software updates. However, an un-tested line of the script started a reinstall of the operating system. So as users were logging into their computers at the start of the week, most noticed that the startup was taking longer than usual. When they finally were able to access their computer desktop, they noticed that all of their user files and settings were gone.

The scripting problem was not seen during the test lab phase, IT staff said. Over 300 users were affected and nearly 100 computers required data recovery services.

This illustrates the importance of the planning and testing phases of a migration. Creating a test environment that mirrors the IT infrastructure will go a long way toward anticipating and fixing problems. But despite the most thought-out migration, the most experienced data professionals know that they can expect the unexpected. Where can you turn if your migration rollout results in a disaster?

Hardware Life Cycle Management(Part III) Read More »

Hardware Life Cycle Management(Part IV)

Articles /

Migration disaster-recovery options
Even the best planning for any deployment can result in disaster for users and critical data. In order to be completely prepared, include data recovery planning within your plan. Questions for your team to ask are:

•    How do we handle an unexpected event during the deployment process?
•    Do we have enough break-points within the automation to catch errors?
•    Can a backup be performed before the deployment?
•    How much time or resources would it take to recover from migration disaster?
•    What alternatives do we have if there is a hardware failure during the migration?
•    What data recovery vendors do we have relationships with that can get back our data in a timely way and also maintain quality?

Being prepared for the worst ensures the greatest success. Think seriously about the disaster recovery side of the project and build in data safety processes so that data loss is minimized.

In the event that a deployment causes widespread accidental data loss, or that key systems or workstations are affected, know when to stop and get professional data recovery assistance.

Many times data loss goes from serious to disastrous because inexperienced IT staff work to resolve the problem. After running software found on the Internet in a panic, the data loss becomes more severe. When all internal options are exhausted, a professional data recovery firm is finally engaged. Not only has precious time been lost, the damage to the data has increased or becomes unrecoverable.

All data recovery companies and offerings are not the same. Data recovery companies that claim to specialize in data recovery, yet in reality use off-the-shelf recovery tools are far more limited in their capabilities.

Hardware Life Cycle Management(Part IV) Read More »

Avoiding storage system failures

Articles /

There are many ways to reduce or eliminate the impact of storage system failures. You may not be able to prevent a disaster from happening, but you may be able to minimize the disruption of service to your clients.

There are many ways to add redundancy to primary storage systems. Some of the options can be quite costly and only large business organizations can afford the investment. These options include duplicate storage systems or identical servers, known as ‘mirror sites’. Additionally, elaborate backup processes or file-system ‘snapshots’ that always have a checkpoint to restore to, provide another level of data protection.

Experience has shown there are usually multiple or rolling failures that happen when an organization has a data disaster. Therefore, to rely on just one restoration protocol is shortsighted. A successful storage organization will have multiple layers of restoration pathways.

We has heard thousands of IT horror stories of initial storage failures turning into complete data calamities. In an effort to bring back a system, some choices can permanently corrupt the data. Here are several risk mitigation policies that storage administrators can adopt that will help minimize data loss when a disaster happens:

• Offline storage system: Avoid forcing an array or drive back on-line. There is usually a valid reason for a controller card to disable a drive or array, forcing an array back on-line may expose the volume to file system corruption.

• Rebuilding a failed drive: When rebuilding a single failed drive, it is import to allow the controller card to finish the process. If a second drive fails or go off-line during this process, stop and get professional data recovery services involved. During a rebuild, replacing a second failed drive will change the data on the other drives.

• Storage system architecture: Plan the storage system’s configuration carefully. We have seen many cases with multiple configurations used on a single storage array. For example, three RAID 5 arrays (each holding six drives) are striped in a RAID 0 configuration and then spanned. Keep a simple storage configuration and document each aspect of it.

• During an outage: If the problem escalates up to the OEM technical support, always ask “Is the data integrity at risk?” or, “Will this damage my data in any way?” If the technician says that there may be a risk to the data, stop and get professional data recovery services involved.

Avoiding storage system failures Read More »

Unique data protection schemes

Articles /

Storage system manufacturers are pursuing unique ways of processing large amounts of data while still being able to provide redundancy in case of disaster. Some large SAN units incorporate intricate device block-level organization, essentially creating a low-level file system from the RAID perspective. Other SAN units have an internal block-level transaction log in place so that the control processor of the SAN is tracking all of the block-level writes to the individual disks. Using this transaction log, the SAN unit can recover from unexpected power failures or shutdowns.

Some computer scientists specializing in the storage system field are proposing adding more intelligence to the RAID array controller card so that it is ‘file system aware.’ This technology would provide more recoverability in case disaster struck, the goal being the storage array would become more self-healing.

Other ideas along these lines are to have a heterogeneous storage pool where multiple computers can access information without being dependant on a specific system’s file system. In organizations where there are multiple hardware and system platforms, a transparent file system will provide access to data regardless of what system wrote the data.

Other computer scientists are approaching the redundancy of the storage array quite differently. The RAID concept is in use on a vast number of systems, yet computer scientists and engineers are looking for new ways to provide better data protection in case of failure. The goals that drive this type of RAID development are data protection and redundancy without sacrificing performance.

Unique data protection schemes Read More »

The ever-changing storage system technology

Articles /

Today’s storage technology encompasses all sorts of storage media. These could include WORM systems, tape library systems and virtual tape library systems. Over the past few years, NAS and SAN systems have provided excellent reliability. What is the difference between the two?

• NAS (Network Attached Storage) units are self-contained units that have their own operating system, file system, and manage their attached hard drives. These units come in all sorts of different sizes to fit most needs and operate as file servers.

• SAN (Storage Area Network) units can be massive cabinets – some with 240 hard drives in them! These large 50+ Terabyte storage systems are doing more than just powering up hundreds of drives. These systems are incredibly powerful data warehouses that have versatile software utilities behind them to manage multiple arrays, various storage architecture configurations, and provide constant system monitoring.

For some time, large-scale storage has been out reach of the small business. Serial ATA (SATA) hard disk drive-based SAN systems are becoming a cost-effective way of providing large amounts of storage space. These array units are also becoming main stream for virtual tape backup systems – literally RAID arrays that are presented as tape machines; thereby removing the tape media element completely.

Other storage technologies such as iSCSI, DAS (Direct Attached Storage), Near-Line Storage (data that is attached to removable media), and CAS (Content Attached Storage) are all methods for providing data availability. Storage architects know that just having a ‘backup’ is not enough. In today’s high information environments, a normal nightly incremental or weekly full backup is obsolete in hours or even minutes after creation. In large data warehouse environments, backing up data that constantly changes is not even an option. The only method for those massive systems is to have storage system mirrors – literally identical servers with the exact same storage space.

How does one decide which system is best? Careful analysis of the operation environment is required. Most would say that having no failures at all is the best environment – that is true for users and administrators alike! The harsh truth is that data disasters happen every day despite the implementation of risk mitigation policies and plans.

The ever-changing storage system technology Read More »

Linux File Management and Viewing

Articles /

File and Directory management

apropos
Search the whatis database for files containing specific strings.

bdflush
Kernel daemon that saves dirty buffers in memory to the disk.

cd
Change the current directory. With no arguments “cd” changes to the users home directory.

chmod
chmod <specification> <filename> – Effect: Change the file permissions.
Ex: chmod 751 myfile        Effect: change the file permission to rwx for owner, re for group
Ex: chmod go=+r myfile        Effect: Add read permission for the owner and the group
character meanings u-user, g-group, o-other, + add permission, – remove, r-read, w-write,x-exe
Ex: chmod a +rwx myfile        Effect: Allow all users to read, write or execute myfile
Ex: chmod go -r myfile        Effect: Remove read permission from the group and others
chmod +s myfile – Setuid bit on the file which allows the program to run with user or group privileges of the file.
chmod {a,u,g,o}{+,-}{r,w,x} (filenames) – The syntax of the chmod command.

chown
chown <owner1> <filename> Effect: Change ownership of a file to owner1.

chgrp
chgrp <group1> <filename> Effect: Change group.

cksum
Perform a checksum and count bytes in a file.

cp
cp <source> <destination> Copy a file from one location to another.

dd
Convert and copy a file formatting according to the options. Disk or data duplication.

dir
List directory contents.

dircolors
Set colors up for ls.

file
Determines file type. Also can tell type of library (a.out or ELF).

find
Ex: find $Home –name readme Print search for readme starting at home and output full path.

How to find files quickly using the find command:
Ex: find ~ -name report3 –print

* “~” = Search starting at the home directory and proceed through all its subdirectories
* “-name report3” = Search for a file named report3
* “-print” = Output the full path to that file

install
Copy multiple files and set attributes.

ln
Make links between files.

locate
File locating program that uses the slocate database.

losetup
Loopback device setup.

ls
List files. Option -a, lists all, see man page “man ls”
Ex: “ls Docum Projects/Linux” – The contents of the directories Docum and Projects/Linux are listed.
To list the contents of every subdirectory using the ls command:

1. Change to your home directory.
2. Type: ls -R

mkdir
Make a directory.

mknod
Make a block or character special file.

mktemp
Make temporary filename.

mv
Move or rename a file. Syntax: mv <source> <destination> Ex: mv filename directoryname/newfilename

pathchk
Check whether filenames are valid or portable.

pwd
Print or list the working directory with full path (present working directory).

rm
Ex: “rm .*” – Effect: Delete system files (Remove files) –i is interactive option.

rmdir
rmdir <directory> – Remove a directory. The directory must be empty.

slocate
Provides a secure way to index files and search for them. It builds a database of files on the system.

stat(1u)
Used to print out inode information on a file.

sum
Checksum and count the blocks in a file.

test
Check file types and compare values.

touch
Change file timestamps to the current time. Make the file if it doesn’t exist.

update
Kernel daemon to flush dirty buffers back to disk.

vdir
List directory contents.

whatis
Search the whatis database for complete words.

wheris
Locate the binary, source and man page files for a command.

which
Show full path of commands where given commands reside.

File viewing and editing

ed
Editor

emacs
Full screen editor.

gitview
A hexadecimal or ASC file viewer.

head
head linuxdoc.txt – Look at the first 10 lines of linuxdoc.txt.

jed
Editor

joe
Editor

less
q-mandatory to exit, Used to view files.

more
b-back q-quit h-help, Used to view files.

pico
Simple text editor.

tail
tail linuxdoc.txt – Look at the last 10 lines of linuxdoc.txt.

vi
Editor with a command mode and text mode. Starts in command mode.

File compression, backing up and restoring

ar
Create modify and extract from archives.

bunzip2
Newer file decompression program.

bzcat
Decompress files to stdout.

bzip2
Newer file compression program.

bzip2recover
Recovers data from damaged bzip2 files.

compress
Compress data.

cpio
Can store files on tapes. to/from archives.

dump
Reads the filesystem directly.

gunzip
unzip <file> – unzip a gz file.

gzexe
Compress executable files in place.

gzip
gzip <file> – zip a file to a gz file.

mt
Control magnetic tape drive operation.

tar
Can store files on tapes.
Usage: tar cvf <destination> <files/directories> – Archive copy groups of files
Ex: tar /dev/fdo temp Effect: Copy temp to drive A:

uncompress
Expand data.

unzip
unzip <file> – unzip a zip file. Files ending in “.gz” or “.zip” are compressed.

zcat
Used to restore compressed files.

zcmp
Compare compressed files.

zdiff
Compare compressed files.

zforce
Force a .gz extension on all gzip files.

zgrep
Search possibly compressed files for a regular expression.

zmore
File filter for crt viewing of compressed text.

znew
Recompress .z files to .gz files.

zip
zip <file> – make a zip file.

Extra control and piping for files and other outputs

basename
Strip directory and suffix information from filenames.

cat
Ex: cat < filename — Effect: put keyboard input into the file. CTRL-D to exit (end).

cmp
Compare two files.

colrm
Remove columns from a file.

column
Columnate lists.

comm
Ex: comm file1 file2 — Effect compare the contents of file1 and file2 produces 3 columns of output. Lines in the first file, lines in second file, lines in both files.

csplit
Split a file into sections determined by context lines.

cut
Remove sections from each line of files.

diff
Show the differences between files. Ex: diff file1 file2

diff3
Find differences between 3 files.

dirname
Strip the non-directory suffix from a filename.

echo
Display a line of text.

egrep
Similar to grep -E, compatible with UNIX egrep.

expand
Convert tabs to spaces.

expr
Evaluate expressions.

false
Do nothing. Exit with a status indicating failure.

fgrep
Same as grep -F.

fold
Wrap each input line to fit in specified width.

join
Join lines of two files in a common field.

grep
grep pattern filename.
Ex: grep ” R ” — Effect: Search for R with a space on each side
Ex: ls –a |grep R — Effect: List all files with an R in them or their info listing.

hexdump
asc, decimal, hex, octal dump.

logname
Print user’s login name.

look
Display lines beginning with a given string.

mkfifo
Create named pipes with the given names.

nl
Write each file to standard output with line numbers added.

od
Dump files in octal and other formats.

patch
Apply a diff file to an original.

paste
Combines from 2 or more files. Ex: paste file1 file 2

printf
Print and format data.

rev
Reverses lines in a file.

script
Make a typescript of a terminal session.

sdiff
Find differences between 2 files and merge interactively.

sed
A stream editor. Used to perform transformations on an input stream.

sleep
Delay for a specified amount ot time.

sort
Sort a file alphabetically.

split
Split a file into pieces.

strings
Print the strings of printable characters in files.

tac
Concatenate and print files in reverse.

tee
Read from standard input and write to standard output and files.

tr
Translate or delete characters.

true
Do nothing. Exit with a status indicating success.

tsort
Perform topological sort.

ul
Do underlining.

unexpand
Convert tabs to spaces.

uniq
Remove duplicate lines from a sorted file.

uudecode
Used to transform files encoded by uuencode into their original form.

uuencode
Encode a binary file to be sent over a medium that doesn’t support non-ASC data.

wc
Count lines, words, characters in a file. Ex: wc filename.

xargs
Build and execute command lines from standard input.

yes
Output the string “y” until killed.

Linux File Management and Viewing Read More »

Linux Filesystem Management

Articles /

badblocks
Used to search a disk or partition for badblocks.

cfdisk
Similar to fdisk but with a nicer interface.

debugfs
Allows direct access to filesystems data structure.

df
Shows the disk free space on one or more filesystems.

dosfsck
Check and repair MS-Dos filesystems.

du
Shows how much disk space a directory and all its files contain.

dump
Used to back up an ext2 filesystem. Complement is restore.

dumpe2fs
Dump filesystem superblock and blocks group information. Ex: dumpe2fs /dev/hda2

e2fsck
Check a Linux second extended filesystem.

e2label
Change the label on an ext2 filesystem.

exportfs
Used to set up filesystems to export for nfs (network file sharing).

fdisk
Used to fix or create partitions on a hard drive.

fdformat
Formats a floppy disk.

fsck
Used to add new blocks to a filesystem. Must not be run on a mounted file system.

hdparm
Get/set hard disk geometry parameters, cylinders, heads, sectors.

mkfs
Initializes a Linux filesystem. This is a front end that runs a separate program depending on the filesystem’s type.

mke2fs
Create a Linux second extended filesystem.

mkswap
Sets up a Linux swap area on a device or file.

mount
Used to mount a filesystem. Complement is umount.

rdev
Query/set image root device, swap device, RAM disk size of video mode. What this does is code the device containing the root filesystem into the kernel image specified.

rdump
Same as dump.

rmt
Remote magtape protocol module.

restore

Used to restore an ext2 filesystem.

setfdprm
Set floppy drive parameters.

swapoff(8)
Used to de-activate a swap partition.

swapon(8)
Used to activate a swap partition.

sync

Forces all unwritten blocks in the buffer cache to be written to disk.

tune2fs
Adjust tunable filesystem parameters on second extended filesystems.

umount
Unmounts a filesystem. Complement is mount.

Linux Filesystem Management Read More »

Linux File Formats

Articles /

linux File formats/etc/crontab
The syntax of each line in this file is:

minute, hour, day of month, Month, day of week, (user name), command

/etc/fstab
Columns are: device file to mount, directory to mount on, filesystem type, options, backup frequency, and fsck pass number (To specify the order in which filesystems should be checked on boot; 0 means no check.) The noauto option stops this mount from being done automatically on boot. Below is a detailed list of what is on each column.

1. The name of the device such as “/dev/hda1”
2. The mount point. Use “/” for root. Other typical mount points are “/dos” for DOS, “swap” or “none” for the swap partition, and “/mnt/floppy” for “/dev/fd0” (the floppy drive).
3. The type of filesystem. They are: mini, ext, ext2(linux native), xiafs, msdos, hpfs, ntfs, fat32, iso9660(CD-ROM), NFS, swap (for swap space).
4. The mount options for use with the filesystem. Each filesystem type has different mount options. Read the mount man page to see possible options. ro= read only, user- allows normal users to mount the device.
5. The frequency the filesystem needs to be dumped (backed up) by the dump command. For ext2, normally make it 1, for others make it 0. 0 or nothing means it is not dumped. If 1, it is backed up during a system backup.
6. A number telling the order in which the filesystems should be checked at reboot time by the fsck program. Your root should be 1, others are in ascending order or 0 to not be checked.

/etc/hosts
Sets up host address information for local use. The format is:

IPaddress name1 name2…

/etc/inetd.conf
Sets the services under the inetd daemon. The fields of this file are:

1. service name
2. socket type
3. protocol
4. wait or nowait
5. user
6. server program name
7. server program command line arguments

/etc/inittab
Sets the init configuration. An entry in the inittab file has the following format:

id:runlevels:action:process

/etc/lilo.conf
Tells LILO how to boot
The lilo.conf file below is for a system which has a Linux root partition on /dev/hda1 and a MS-DOS partition on /dev/hda2. See the “How Linux Works” guide and the “Linux User’s Guidel” for more information.

boot = /dev/hda        # Tell LILO to install the boot loader on the /dev/hda disk boot record
vga = normal        # Set a normal video mode
delay = 60        # The time in tenths of seconds to press <SHIFT> to get the LILO prompt
# Equivalent would be “prompt” on one line, and “timeout=60” on
# another line.
default=msdos        # Sets the default boot to DOS, Without this line, the default is the first stanza
install = /boot/boot.b        # The file containing the boot sector to use
compact        # Have LILO perform some optimization.
map = /boot/map        #Specifies the map file LILO creates when installed
# Section for Linux root partition on /dev/hda2.
image = /vmlinuz        # Location of kernel
label = linux         # Name of the OS that is displayed in the LILO boot menu
root = /dev/hda1         # Location of root partition, if this isn’t here the kernel image must have
# this set using the rdev command
read-only         # Mount read only on startup, Can also be set by rdev
# Section for MSDOS partition on /dev/hda1.
other = /dev/hda2         # Location of partition
table = /dev/hda         # Location of partition table for /dev/hda2
label = msdos         # Name of OS (for boot menu)

if the command “vga= ask” is given, LILO will prompt the user for a video mode at boot time.

/etc/passwd
The file has one line per username, and is divided into seven colon-delimited fields:

1. Username.
2. Password, in an encrypted form.
3. Numeric user id.
4. Numeric group id.
5. Full name or other description of account. This is called gecos.
6. The user’s home directory.
7. The user’s login shell (program to run at login).

The format is explained in more detail on the passwd manual page.

/usr/X11R6/lib/X11/XF86Config
The main XFree86 configuration file. Type “man XF86Config”

* The first section is “Files”
RgbPath        Sets the path to the X11R6 RGB color database
FontPath        Sets the path to a directory containing X11 fonts
* The second section is “ServerFlags”, all lines are commented out
* The third section is “Keyboard”
* The fourth section is “Pointer”
Protocol        Specifies the mouse protocol
Device        Specifies the device file by which the mouse can be accessed.

* The fifth section is “Monitor” which specifies the characteristics of your monitor
ModeLine        Specifies resolution modes for your monitor

The file, VideoModes.doc describes in detail how to determine the ModeLine values for each resolution mode. Two files, modeDB.txt and Monitors,may have ModeLine information for your monitor. They are located in /usr/X11R6/lib/X11/doc.

* The sixth section is “Screen” describing the video/monitor card configuration for the particular server.
The Driver line specifies the X server that you will be using. Valid Driver values are:

_ Accel: For the XF86 S3, XF86 Mach32, XF86 Mach8, XF86 8514,

XF86 P9000, XF86 AGX,and XF86 W32 servers;
_ SVGA: For the XF86 SVGA server;
_ VGA16: For the XF86 VGA16 server;
_ VGA2: For the XF86 Mono server;
_ Mono: For the non-VGA monochrome drivers in the XF86 Mono and XF86 VGA16 servers.
Be sure that /usr/X11R6/bin/X is a symbolic link to this server.

The Device line specifies the Identifier of the Device section that corresponds to the video card to use for this server. Above, we created a Device section with the line Identifier “#9 GXE 64”

Therefore, we use “#9 GXE 64” on the Device line here. Similarly, the Monitor line specifies the name of the Monitor section to be used with this server. Here, “CTX 5468 NI” is the Identifier used in the Monitor section described above.

*Subsection “Display” defines several properties of the XFree86 server corre-sponding to your monitor/video card combination. The XF86Config file describes all of these options in detail. Most of them are not necessary to get the system working.

The options that you should know about are:

o_ Depth. Defines the number of color planes; that is, the number of bits per pixel. Usually, Depth is set to 16. For the VGA16 server, you would use a depth of 4, and for the monochrome server a depth of 1. If you use an accelerated video card with enough memory to support more bits per pixel, you can set Depth to 24, or 32.

o _ Modes. This is the list of mode names that have been defined using the ModeLine directive(s) in the Monitor section. In the above section, we used ModeLines named “1024×768”, “800×600”,and “640×48″0. Therefore, we use a Modes line of

Modes “1024×768” “800×600” “640×480”

The first mode listed on this line is the default when XFree86 starts. After XFree86 is running, you can switch between the modes listed here using the keys Ctrl – Alt –Numeric + and Ctrl – Alt – Numeric – .
It might be best, when you initially configure XFree86, to use lower resolution video modes like 640×480, which tend to work with most systems. Once you have the basic configuration working, you can modify XF86Config to support higher resolutions.

o_ Virtual. Set the virtual desktop size. XFree86 can use additional memory on your video card to extend the size of the desktop. When you move the mouse pointer to the edge of the display, the desktop scrolls, bringing the additional space into view. Even if you run the server at a lower video resolution like 800×600, you can set Virtual to the total resolution that your video card can support. A 1-megabyte video card can support 1024×768 at a depth of 8 bits per pixel; a 2-megabyte card 1280×1024 at depth 8, or 1024×768 at depth 16. Of course, the entire area will not be visible at once, but it can still be used. The Virtual feature is rather limited. If you want to use a true virtual desktop, fvwm and similar window managers allow you to have large, virtual desktops by hiding windows and using other techniques, instead of storing the entire desktop in video memory. See the manual pages for fvwm for more details about this. Some Linux systems use fvwm by default.

o_ ViewPort. If you are using the Virtual option that is described above, ViewPort sets the coordinates of the upper-left-hand corner of the virtual desktop when XFree86 starts up. Virtual 0 is often used. If this is unspecified, then the desktop is centered on the virtual desktop display, which may be undesirable to you.

Linux File Formats Read More »

Scroll to Top