Ghost system restore data loss

Case:Ms. Zhang’s home computer made the GHOST restoration system. Later, the data backup in the hard disk was not successful, which caused the data to be lost now. Solution:In order to avoid damage to data, Ms. Zhang quickly contacted the data recovery company and the data recovery center.Learn the relevant information through telephone consultation, and…

Read More

Linux Configuration Files

linux Configuration filesprofile
System wide environment and startup script program.

/dev/MAKEDEV
The /dev/MAKEDEV file is a script written by the system administrator that creates local only device files or links such as device files for a non-standard device driver.

/etc/aliases
Where the user’s name is matched to a nickname for e-mail.

/etc/bootptab
The configuration for the BOOTP server daemon.

/etc/crontab
Lists commands and times to run them for the cron deamon.

/etc/dhcpd.conf
The configuration file for the DHCP server daemon.

/etc/ethers
File for RARP mapping from hardware addresses to IP addresses. See the man page ethers(5).

/etc/exports
The file describing exported filesystems for NFS services.

/etc/fdprm
The floppy disk parameter table. Describes the formats of different floppy disks. Used by setfdprm.

/etc/filesystems
Can be used to set the filesystem probe order when filesystems are mounted with the auto option. The nodev parameter is specified for filesystems that are not really locally mounted systems such as proc, devpts, and nfs systems.

/etc/fstab
Lists the filesystems mounted automatically at startup by the mount -a command (in /etc/rc or equivalent startup file).

/etc/group
Similar to /etc/passwd but for groups rather than users.

/etc/groups
May contain passwords that let a user join a group.

/etc/gshadow
Used to hold the group password and group administrator password information for shadow passwords.

/etc/host.conf
Specifies how host names are resolved.

/etc/hosts
List hosts for name lookup use that are locally required.

/etc/HOSTNAME
Shows the host name of this host. Used for support of older programs since the hostname is stored in the /etc/sysconfig/network file.

/etc/inittab
Configuration file for init, controls startup run levels, determines scripts to start with.

/etc/inetd.conf
Sets up the services that run under the inetd daemon.

/etc/issue
Output by getty before the login prompt. Description or welcoming message.

/etc/issue.net
Output for network logins with LINUX version

/etc/ld.so.conf
Configuration file for ld.so, the run time linker.

/etc/lilo.conf
Configuration file for LILO.

/etc/limits
Limits users resources when a system has shadow passwords installed.

/etc/localtime
In Debian the system time zone is determined by this link.

/etc/login.defs
Sets user login features on systems with shadow passwords.

/etc/logrotate.conf
Configures the logrotate program used for managing logfiles.

/etc/magic
The configuration file for file types. Contains the descriptions of various file formats for the file command.

/etc/motd
The message of the day, automatically output by a successful login.

/etc/mtab
A list of currently mounted file systems. Setup by boot scripts and updated by the mount command.

/etc/named.conf
Used for domain name servers.

/etc/networks
Lists names and addresses of your own and other networks, used by the route command.

/etc/nologin
If this file exists, non-root logins are disabled. Typically it is created when the system is shutting down.

/etc/nsswitch.conf
Name service switch configuration file.

/etc/passwd
The user database with fields giving the username, real name, home directory, encrypted password and other information about each user.

/etc/printcap
A configuration file for printers.

/etc/profile, /etc/cshlogin,/etc/csh/cshrc
Files executed at login or startup time by the Bourne or C shells. These allow the system administrator to set global defaults for all users.

/etc/protocols
Describes DARPA internet protocols available from the TCP/IP subsystem. Maps protocol ID numbers to protocol names.

/etc/rc or /etc/rc.d or /etc/rc?.d
Scripts or directories of scripts to run at startup or when changing run level.

/etc/rc.d/rc0.d
Contains files used to control run level 0. Usually these files are softlink files.

/etc/rc.d/rc1.d
Contains files to control run level 1. Scripts beginning with an S are for start, K for kill.

/etc/rc.d/rc.sysinit
Init runs this when it starts.

/etc/resolv.conf
Configures the name resolver, specifying the address of your name server and your domain name.

/etc/securetty
Identifies secure terminals from which root is allowed to log in.

/etc/services
Lists the network services that the system supports.

/etc/shadow
Shadow password file on systems with shadow password software installed. Shadow passwords move the encrypted password files from /etc/passwd to /etc/shadow which can only be read by root.

/etc/shadow.group
Systems with shadow passwords may have this file.

/etc/shells
Lists trusted shells. The chsh command allows users to change their login shell to shells listed only in this file.

/etc/skel/.profile
Can be used by administrator to set the editor environment variable to some editor that is friendly to new users.

/etc/sudoers
A list of users with special privileges along with the commands they can execute.

/etc/smb.conf
The configuration file for setting up Samba services.

/etc/sysconfig/amd
Used to configure the auto mount daemon.

/etc/sysconfig/clock
Used to configure the system clock to Universal or local time and set some other clock parameters.

/etc/sysconfig/i18n
Controls the system font settings.

/etc/sysconfig/init
This file is used to set some terminal characteristics and environment variables.

/etc/sysconfig/keyboard
Used to configure the keyboard.

/etc/sysconfig/mouse
This file is used to configure the mouse.

/etc/sysconfig/network-scripts/ifcfg-interface
Defines a network interface.

/etc/sysconfig/pcmcia
Used to configure pcmcia network cards.

/etc/sysconfig//routed
Sets up dynamic routing policies.

/etc/sysconfig/static-routes
Configures static routes on a network.

/etc/sysconfig/tape
Used for backup tape device configuration.

/etc/X11/XF86Config
The configuration file for the X server.

/etc/syslog.conf
Configuration file for the syslogd daemon.

/etc/termcap
The terminal capability database. Describes by what “escape sequences” various terminals can be controlled. See terminfo, termcap, curs_termcap man pages.

/etc/terminfo
Details for terminal I/O.

/etc/usertty
This file is used to impose special access restrictions on users.

$HOME/.bashrc
User aliases, path modifier, and functions.

$HOME/.bash_profile
Users environment stuff and startup programs.

$HOME/.bash_logout
User actions to be done at logout.

$HOME/.hushlogin
When this file exists in the user’s home directory, it will prevent check for mail, printing of the last login time, and the message of the day when the user logs in.

$HOME/.inputrc
Contains keybindings and other bits.

$HOME/Xrootenv.0
Has networking and environment info.

/proc/cpuinfo
Information about the processor such as its type, make and performance.

/proc/devices
A list of devices configured into the currently running kernel.

/proc/dma
Shows which DMA channels are being used at the moment.

/proc/filesystems
Filesystems that are configured into the kernel. The file used to detect filesystems if the /etc/filesystems does not exist.

/proc/ioports
Shows which I/O ports are in use at the moment.

/proc/interrupts
Shows which interrupts are in use and how many of each there have been.

/proc/kcore
An image of the physical memory of the system.

/proc/kmsg
Messages output by the kernel. These are also routed to syslog.

/proc/ksyms
Symbol table for the kernel.

/proc/loadavg
The load average of the system.

/proc/meminfo
Information about memory usage, both physical and swap.

/proc/modules
Which kernel modules are currently loaded.

/proc/mounts
Contains information on filesystems currently mounted, similar to /etc/mtab

/proc/net
Contains status information about network protocols.

/proc/self
A symbolic link to the process directory of the program that is looking at /proc. When 2 process look at proc, they get different links.

/proc/stat
Various statistics about the system such as the number of page faults since the system was booted.

/proc/uptime
The time the system has been up.

/proc/version
The kernel version.

/tmp/fvwmrca01339
FVWM-M4 defines. Contains networking, Xwindows, other setup info.

/usr/lib/zoneinfo
Time zone datafiles are stored here on the Debian system

/var/log/lastlog
Used by finger to tell when a user was last logged in.

/var/log/wtmp
Binary info on users that have been logged on. The last command uses this info.

/var/run/utmp
Contains information about users currently logged in. Who and w commands use this file.

/var/named/root.hints
Used for domain name server. Placed here optionally, but this is the normal location.

/var/named/*
Files used by domain name server. Placed here optionally, but this is the normal location.

/var/log/btmp
Used to store information about failed logins. This file must be first created to activate it.

/var/log/lastlog
Contains information about the last time a login was done on the system. Works with lastb(1).

/var/log/maillog
The normal system mail log file.

/var/log/messages
The main system message log file.

var/log/secure
System tracking of user logins. Check this file periodically.

/var/spool/mail
Where mailboxes are usually stored.

Read More

Hardware Life Cycle Management(Part III)

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?

Read More