Don’t get confused with WAM (Web Access Management). For now just treat this as a tool which will protect your website. Let say for example, I have a web site called (www.kalyan.com), but i don’t want to publish this name to all of my customers. That time i will publish a different name to customers saying access (www.SecurityfromKalyan.com). When the customers access published DNS, that time the WAM tool will redirect customer request to (www.Kalyan.com). This is just securing the actual DNS.

We have some great tools in the market like Novell Access Manager, CA SiteMinder etc.

So let see what all the above keywords actually means.

Web access management (WAM) software controls what users can access when using a web browser to interact with web-based enterprise assets. This type of technology is continually becoming more robust and experiencing increased deployment. This is because of the increased use of e-commerce, online banking, content providing, web services, and more. The Internet only continues to grow and its importance to businesses and individuals increases as more and more functionality is provided. We just can’t seem to get enough of it.
Basic components and activities in a web access control management process.
1. User sends in credentials to web server.
2. Web server validates user’s credentials.
3. User requests to access a resource (object).
4. Web server verifies with the security policy to determine if the user is allowed to carry out this operation.
5. Web server allows access to the requested resource.

This is a simple example. More complexity comes in with all the different ways a user can authenticate (password, digital certificate, token, and others), the resources and services that may be available to the user (transfer funds, purchase product, update profile, and so forth), and the necessary infrastructure components. The infrastructure is usually made up of a web server farm (many servers), a directory that contains the users’ accounts and attributes, a database, a couple of firewalls, and some routers, all laid out in a tiered architecture. But let’s keep it simple right now.

The WAM software is the main gate between users and the corporate web-based resources. It is commonly a plug-in for a web server, so it works as a front-end process. When a user makes a request for access, the web server software will query a directory (described in the last section), an authentication server, and potentially a back-end
database before serving up the resource the user requested. The WAM console allows the administrator to configure access levels, authentication requirements, and account setup workflow steps, and to perform overall maintenance.

WAM tools usually also provide a single sign-on capability so that once a user is authenticated at a web site, she can access different web-based applications and resources without having to log in multiple times. When a product provides a single sign-on capability in a web environment, the product must keep track of the user’s authentication state and security context as the user moves from one resource to the next.

For example, if Kathy logs on to her online bank web site, the communication is taking place over the HTTP protocol. This protocol itself is stateless, which means it will allow a web server to pass the user a web page and then the connection is closed and the user is forgotten about. Many web servers work in a stateless mode because they have so many requests to fulfill and they are just providing users with web pages. Keeping a constant connection with each and every user who is requesting to see a web page would exhaust the web server’s resources. When a user has to log on to a web site is when “keeping the user’s state” is required and a continuous connection is needed.

When Kathy first goes to her bank’s web site, she is viewing publicly available data that do not require her to authenticate before viewing. A constant connection is not being kept by the web server, thus it is working in a stateless manner. Once she clicks Access My Account, the web server sets up a secure connection (SSL) with her browser and requests her credentials. After she is authenticated, the web server sends a cookie (small text file) that indicates she has authenticated properly and the type of access she should be allowed. When Kathy requests to move from her savings account to her checking account, the web server will assess the cookie on Kathy’s web browser to see if she has the rights to access this new resource. The web server continues to check this cookie during Kathy’s session to ensure no one has hijacked the session and that the web server is continually communicating with Kathy’s system and not someone else’s. The web server continually asks Kathy’s web browser to prove she has been authenticated, which the browser does by providing the cookie information. (The cookie information could include her password, account number, security level, browsing habits, and/or personalization information.) As long as Kathy is authenticated, the web server software will keep track of each of her requests, log her events, and make changes that she requests that can take place in her security context. Security context is the authorization level she is assigned based on her permissions, entitlements, and access rights. Once Kathy ends the session, the cookie is usually erased from the web browser’s memory and the web server no longer keeps this connection open or collects session state information on this user.

NOTE A cookie can be in the format of a text file stored on the user’s hard drive (permanent) or it can be only held in memory (session). If the cookie contains any type of sensitive information, then it should only be held in memory and be erased once the session has completed.

As an analogy, let’s say I am following you in a mall as you are shopping. I am marking down what you purchase, where you go, and the requests you make. I know everything about your actions; I document them in a log, and remember them as you continue. (I am keeping state information on you and your activities.) You can have access to all of these stores if every 15 minutes you show me a piece of paper that I gave you. If you fail to show me the piece of paper at the necessary interval, I will push a button and all stores will be locked—you no longer have access to the stores, I no longer collect information about you, and I leave and forget all about you. Since you are no longer able to access any sensitive objects (store merchandise), I don’t need to keep track of you and what you are doing.

As long as the web browser serves up the cookie to the web browser, Kathy does not have to provide credentials as she asks for different resources. This is what single sign on(SSO) is. You only have to provide your credentials once and the continual validation that you have the necessary cookie will allow you to go from one resource to another. If you end your session with the web server and need to interact with it again, you must re authenticate and a new cookie will be sent to your browser and it starts all over again.

Hope you guys are clear with all the above keywords.

Nice article, Thanks to shon Harris.

LUM.pdf

After searching for so many days we figure out the solution for this. Still I can say this is not the best way to do it, but an alternative for the problem to resolve it quickly. Any comments can be appreciated.

Abstraction:

One of the biggest trends in IT today revolves around consolidating multiple physical servers to virtual environments. Virtualization not only reduces the hardware and the maintenance cost, without effecting the performance of the applications but it also helps in simulating a high level testing infrastructure which otherwise would have needed a big infrastructure. With the growing use of virtualization, the big challenge that emerged for the testing world is to test the virtualized operating system. As the market still in the process of finding the best framework for testing the virtualized operating system or an application which is hosted on a Virtual Machine(VM), which can validate the functionality as well as the performance of the Virtualized OS/applications. This paper will describe the best practices that can be used while testing the virtualized OS or an application. On a whole this gives you brief idea on virtualization and the best practices while testing the applications which are hosted on a Virtual Machine (VM).

Virtualization:

Virtualization essentially lets one computer do the job of multiple computers, by sharing the resources of a single computer across multiple environments. There are several ways to implement virtualization. Two leading approaches are full virtualization and Para-virtualization. Full Virtualization & Para virtualization: VMWARE and XEN respectively will support these two types of virtualizations

Full Virtualization:

Full virtualization is designed to provide total abstraction of the underlying physical system and creates a complete virtual system in which the guest operating systems can execute.

Pros and Cons of Full Virtualization:

Pros:

No modification is required in the guest OS or application.
The guest OS or application is not aware of the virtualized environment so they have the capability to execute on the VM just as they would on a physical system.

Cons:

Full virtualization may incur a performance penalty. The VM monitor must provide the VM with an image of an entire system, including virtual BIOS, virtual memory space, and virtual devices

Para Virtualization:

Para-virtualization presents each VM with an abstraction of the hardware that is similar but not identical to the underlying physical hardware. Para-virtualization techniques require modifications to the guest operating systems that are running on the VM’s. As a result, the guest operating systems are aware that they are executing on a VM

Virtualization Challenges:

 Speed
 Performance
 Security, Resource isolation
 Functionality

What is a Virtual Machine (VM)?

A virtual machine is a tightly isolated software container that can run its own operating systems and applications as if it were a physical computer. A virtual machine behaves exactly like a physical computer and contains it own virtual (i.e., software-based) CPU, RAM hard disk and network interface card (NIC).

Hypervisor (Virtual Machine Manager):

In Computing, a hypervisor is a virtualization platform that allows multiple OS’s to run on a host computer at the same time. The virtualization software (i.e. hypervisor) presents an emulated hardware environment that guest operating systems operate upon. This emulated hardware environment is typically referred to as a virtual machine monitor or VMM.

Hypervisor Classifications:

 Hypervisors are currently classified in two types:
 A Type 1 (or native or bare-metal) hypervisor is software that runs directly on a given hardware platform (as an operating system control program). A guest operating system thus runs at the second level above the hardware.
Examples include VMWARE ESX and XEN
 A Type 2 (or hosted) hypervisor is software that runs within an Operating System environment. A “guest” operating system thus runs at the third level above the hardware.
Examples include VMWARE Server(Formally called as GSX), VMWARE Workstation

How virtualization can be integrated and utilized for Testing:

In a world of multiple operating systems, each with various versions, no application has the luxury of supporting single OS. Every application needs to ensure that it will function correctly on all the OS configurations used by today’s heterogeneous IT environments. Because dedicating physical test systems for each target environment is out of most development teams’ budgets, virtual machines (VM’s) are the right solution at the right time.

Having one machine to hold all types of OS, will enable us to do testing an application on multiple platforms will reduce the effort utilization and cost of hardware. The ability to host two or more operating systems side-by-side means that programmers can test new releases of software without the need for dedicated test machines. If beta software corrupts a given operating system, a parallel operating system running on the same computer can still be used for Testing. In addition, virtualization can help extend support for legacy applications and operating systems to new hardware. By running both legacy and new operating systems on the same PC or embedded controller (e.g. Windows 95 and Vista), engineers can reuse legacy applications and reduce the need to port programs to different operating systems. Another problem with dedicating a physical computer to each environment is that setting up your target environments can be quite time-consuming. In this situation, virtual machines can save you time. If you need to duplicate a particular environment, you can create a library of virtual hard disks that are pre-loaded with specific sets of software. You and other members of your development and test team can clone the disks that you need and quickly replicate a particular environment in a virtual machine. This type of setup can save lots of time when you need to start over with a clean installation, or duplicate the same environment in several virtual machines. During the Testing phase, if the Testers have any problems with beta releases, they can directly share the VM to the developer on which they are seeing the issues, so that they can check in the fixes for all the issues without having the much discussion with Testers.
Are we really utilizing the hardware effectively? If a System was equipped with Dual core processor, are we really making use of the Dual core? Answer is simply “no”. So the main benefit that we can get with the virtualization is better utilization of the hardware. This can be achieved through better utilization of care. As the hardware functional support is increasing day by day we are not in a position to utilize the hardware effectively. So to avoid these, virtualization is the better solution to make use of hardware effectively.
Virtualization tools, lets users snapshot the system at a last known good version. We can create a rollback that allows us to restore the system to that previous good state within minutes. The alternative has to re-image the computer or re-build the environment, which can take hours. This is a tremendous time saver. The ability to snapshot, and restore a working image within minutes, rather than wait hours for a rebuilt system, is particularly important. You’re often looking at bugs where you have to spend a day or two to set up the environment just to reproduce a bug, so the time you spend having to rebuild again and again—that’s a time waster. That is loss of productivity. Snapshots also support in training environments because administrators need only to return to the snapshot to recover the original state of any training machine. For example, when a bug causes a system crash, the developer has to work backward to identify the point where the system crashed. “People often initially set breakpoints too far into the process and the system crashes again. Since a developer can easily be crashing the system several times a day, being able to restore quickly and then re-run the debugging session while the problem is still fresh in their minds is a great benefit. When you’re troubleshooting a complicated bug, it’s good to stay in that groove. Another example, Start with an operations on a system and once you are successful in that, then take a snapshot of it and do the second step, even if you are not successful with the second step, nothing to worry, just we need to restore the snapshot, which saves lot of time in rebuilding the complete system and the completed initial tasks/first steps. Once the VM is restored, that allows us to start something different for second step directly.
With Virtualization we have the ability to test dozen different scenarios simultaneously to ensure a consistent user experience. This enables to complete the testing tasks in less amount of time, which means the time spent for completion on test cycles is very less. Even if we have multiple beta build for bug fixes will not take much time to regress them. With this we can release the product/applications within the target dates.
Manual configuration of a test infrastructure will increase the test cycle time. Virtualization can reduce the time for setting test infrastructure by which we can achieve better productivity in less amount of time. Setting up the test infrastructure has become a serious bottleneck. Which increases the test cycle life time, applications can’t be tested with the timeframe (deadlines). Which causes the unstable products may come into the market. While a huge product / application under testing, setting up the lab with manual configuration requires huge IT support, enough capacity to support required testing, must be co-located with the test teams and it’s very Expensive, hard to manage. Virtualization will help in reducing the efforts for setting up the lab for test environments, In which, once the VM ready to use, use the same for as many times as it required just by taking the snapshot of the same.
Virtual Machine (VM) are isolated from other VM’s, this is because of the physical server network capabilities. So even though one VM is crashed will not affect the other VM’s. Taking snapshot of a VM will help to restore and use it easily. Data is not going to be leaked across the VM’s, as they have independent network connections for each VM. While testing the application tester concentrate on data leakage from the application, but from virtualization point of view there is no problems found as of now with data leakage from virtualization tools, but if testers concentrate on this than that would be really great and if they find any issues that will help virtualization leaders to concentrate on the same. Once the applications are hosted on the virtualization, they are going to be accessible with the allocated IP addresses.
Another befit with virtualization was each VM is going to be saved as a single file. So it’s easy to save, copy, move and restore the VM’s.
Let’s have a look on how virtualization can be used for different Testing Types
Functionality Testing: Deploy a variety of destination environments for functionality testing, using minimal hardware. Set up a library of test environments in virtual machines for rapid deployment. Just copy the .vhd file, attach it to a virtual machine, and boot up. (You can create a “base” virtual machine with the operating system and applications you want, and then copy its .vhd file to use for other virtual machines. When you do this, it’s important to run a tool called Sysprep (From Windows) on the base virtual machine. That way, when you start a virtual machine that uses a copy of the base virtual machine’s .vhd file, the guest operating system will be assigned a new SID, GUID, MAC address, and so forth when it starts up. This way you won’t end up with network conflicts between different virtual machines that use the same copied .vhd file.)
Configuration Testing: Configuration testing, in which testers needs to test the application on different combinations of software and hardware. To do this huge amount of physical resources are required to host multiple OS’s, browsers and other software. Virtualization allows you to create multiple VM’s to test the application on different platforms or OS at a time by this hardware utilization would be more effective.
Performance Testing: performances are the greatest concern while approaching Virtualization. Verifying the Virtual Machines performance against Physical servers is mandatory, we also in need of exploring how different virtualization technologies perform. The first aspect you should test is I/O performances: physical raw partitions, proprietary file systems, remote SAN systems, and local virtual IDE or SCSI disk subsystem. All of these configurations should be tested and compared with each other and against physical machines I/O performances.
Another important aspect that we need to test is network performance because the virtual network adapter devices handle the traffic in different ways.
Load and Stress Testing: Load is usually conducted to understand the behavior of the application under a specific expected load where as stress test is normally used to break the application. Double the numbers of users are added to the application and the test is run again until the application breaks down. The best way to stress test or a load test is to use the standard tools for physical machines stress and load testing.
Examples for different Virtualization platforms
Server Virtualization:
VMware ESX 3i
VMware Server 1.X
Xen Enterprise
Microsoft Virtual Server R2
Microsoft 2008 Viridian
Virtual Iron
Client Virtualization:
VMware Workstation 6
VMware Virtual Player
Microsoft Virtual PC 2007
QEMU
Application Virtualization
Altris AppStream
Altris SVT
Microsoft SoftGrid
Hardware Virtualization
Intel VT
AMD-V

Reference materials:
Online reference.
Author’s biography:
Kalyan Ch working as a Sr. Software Engineer for Applabs for more than 3 years, and have total 6 years of experience in Testing different web applications, Products like Novell Netware and virtualized Netware and SLES OS.

Anti-Virus

An anti-virus software program is a computer program that can be used to scan files to identify and eliminate computer viruses and other malicious software (malware).

Anti-virus software typically uses two different techniques to accomplish this:

1. Examining files to look for known viruses by means of a virus dictionary
2. Identifying suspicious behavior from any computer program which might indicate infection

Most commercial anti-virus software uses both of these approaches, with an emphasis on the virus dictionary approach.

Virus Dictionary approach:
In the virus dictionary approach, when the anti-virus software examines a file, it refers to a dictionary of known viruses that have been identified by the author of the anti-virus software. If a piece of code in the file matches any virus identified in the dictionary, then the anti-virus software can then either delete the file, quarantine it so that the file is inaccessible to other programs and its virus is unable to spread, or attempt to repair the file by removing the virus itself from the file. The virus dictionary approach requires periodic online downloads of updated virus dictionary entries.

Dictionary-based anti-virus software typically examines files when the computer’s operating system creates, opens, and closes them; and when the files are e-mailed. In this way, a known virus can be detected immediately upon receipt. The software can also typically be scheduled to examine all files on the user’s hard disk on a regular basis.

Problems: Detecting viruses is often insufficient due to the continual creation of new viruses.

Suspicious behavior approach:
The suspicious behavior approach, by contrast, doesn’t attempt to identify known viruses, but instead monitors the behavior of all programs. If one program tries to write data to an executable program, for example, this is flagged as suspicious behavior and the user is alerted to this, and asked what to do.

The suspicious behavior approach therefore provides protection against brand-new viruses that do not yet exist in any virus dictionaries. However, it also sounds a large number of false positives, and users probably become desensitized to all the warnings. If the user clicks “Accept” on every such warning, then the anti-virus software is obviously useless to that user. This problem has especially been made worse over the past 7 years, since many more non malicious program designs chose to modify other .exes without regards to this false positive issue. Thus, most modern antivirus software uses this technique less and less. L

Problems: The suspicious behavior approach is ineffective due to the false positive problem.

Sandbox approach:

A sandbox emulates the operating system and runs the executable in this simulation. After the program has terminated, the sandbox is analyzed for changes which might indicate a virus.

Because of performance issues this type of detection is normally only performed during on-demand scans.

Other ways to detect viruses:

Some antivirus-software will try to emulate the beginning of the code of each new executable that is being executed before transferring control to the executable. If the program seems to be using self-modifying code or otherwise appears as a virus (it immediately tries to find other executables), one could assume that the executable has been infected with a virus. However, this method results in a lot of false positives.

The core of an anti virus program is its engine, to which the respective scanner forwards a suspicious file. Most times, a file must be unpacked before the detection routines identify the malware. Uploading the engine and dates base scanning is must.

On-Demand Scan:

In an on-Demand scan, a user actively checks individual files or an entire hard disk for malware. He specifies the settings for this in the user interface of the antivirus program.

1. A user triggers a scan.
2. The scanner instructs the OS with corresponding commands to read and send files from the medium to the AV engine.
3. Files are then sent one after the other.
4. The Program reports whether the file is OK or infected.

On-Access Scan:

The virus guard is permanently active in the background and works at the OS level. It intercepts all data accesses by application and examines the actions for malicious intent.

1. The On-Access guard is activated as soon as a program accesses a file.
2. The guard forwards the result to the AV engine for checking.
3. Access is then either granted or blocked.

Data Base:

The Data base holds all the dictionary items, Antivirus engine will use them to find a specific virus is present or now.

Note: The Antivirus manufacturer will keep on sending the patch just to update the data base with the latest routines/dictionary items. We need to update the Antivirus software for every few weeks, so that we will be getting the new dictionary items into our database that enables us to avoid some malware and virus attack in our system.

Update Routines:

When an Antivirus engine gets a request from user to perform On-Access scan, the AV engine will start the process in the background and it will look for all the .exe files at OS level which are trying to modify the other “.exe” files. That time AV engine will try to stop the process by raising the false alarms and at the same time it will send an update to the manufacturer about the .exe file which is trying to modify the other .exe files.

Benefit: When the manufacturer gets the update from the AV engine, they will try to find out the possible causes with that modification. Based on that they will be sending that into a data base as a dictionary item and try to stop the damage what it is doing or it allows the modifications that it is doing. With this we will be having the updated data base with all possible dictionary items which will enable us to avoid all the virus attacks and from malwares.

Virus Signature:

All antivirus companies use their signature database to identify the most popular viruses around the world. Here’s how signature works.

Character String: The simplest form of a signature is a static one, where its pattern corresponds exactly to that of a signature pre-recorded in a database. For instance a ‘CIH v1.2 TTIT’ character string which resides in the code of a Win32/CIH virus. All infected programs having this specific signature can be easily detected.

Wildcards: Since there are various versions of any infection, only taking one version—such as the v1.2 mentioned above-into account is obviously pointless. Therefore, wildcards are used for instance when searching for CIH v1.2 TTIT, the AV scanner would use ‘CIH V TTIT’. Here the * sign automatically replaces one, two or more characters that might fall between the CIH V and TTIT. Now any version of that infection is detectable with this method.

A Narrower Search: Only searching for a character string can prove to be time consuming with numerous results popping up. Therefore, to avoid false alarms and to speed up the process, additional characteristics of a virus are added to the database.

Terminology Used in AV:

1. “Camouflaged” viruses:

There are various methods of encrypting and packing malicious software which will make even well-known viruses undetectable to anti-virus software.

Detecting these viruses requires a powerful unpacking engine, which can decrypt the files before examining.

Unfortunately, many popular anti-virus programs do not have this and thus are often unable to detect encrypted viruses.

1. Root Kit:

A Root kit is a series of programs which are primarily intended for hiding or disguising active malware on a user’s PC. Here’s how an attacker user them to his advantage; a root kit is a good stealth weapon for replacing the crucial and genuine system files with infected ones. The replaced files act as masks that hide the malware infection in the system. This makes the malware invisible to an antivirus scanner, hence making it difficult to detect and remove.

1. False Positives:

A false positive is another way of saying ‘mistake’. As applied to the field of anti-virus programs, a false positive occurs when the program mistakenly flags an innocent file as being infected. This may seem harmless enough, but false positives can be a real irritation. L But this problem is usually fixed in the next virus signature file release.

Tips to avoid from Viruses:

1. User education is as important as anti-virus software; simply training users in safe computing practices, such as not downloading and executing unknown programs from the Internet, would slow the spread of viruses, without the need of anti-virus software.
2. Computer users should not always run with administrator access to their own machine. If they would simply run in user mode then some types of viruses would not be able to spread.

Example: /nss /StorageAlarmThreshold=value Lets you set the threshold for a low storage space warning. The default is 10. The range is 0 to 1000000

Source: Novell Doc.

Note: This is just for my reference

The purpose of this document is to help network administrators become more proactive in resolving critical server issues (abends and hangs). In the past, recommended procedures for handling server crashes have not been clearly set down in writing. By creating this document, Novell Support hopes to minimize miscommunication when dealing with customers and educate them as to how they can best help Novell resolve server issues. This document provides a standardized way to obtain valuable feedback to questions that will help prioritize the issue, gain some historical perspective on the problem, and improve resolution time.

Introduction
What is an Abend?
Server Hangs or Lockups
Steps for Troubleshooting NetWare Servers
Appendix: Memory Images (Core Dumps)

What is a Critical Server Issue?
For the purposes of this AppNote, we define a “critical server issue” as a situation in which the server ceases operation unexpectedly. The server may simply stop running or become unusable, thus preventing any work from being done by clients connected to the server or with applications running at the server. Such conditions are generally described as server crashes, hangs, or “abends.”

Few events strike terror into the hearts of network administrators as much as a server going down unexpectedly. But with sufficient troubleshooting information and a few advance precautions, you’ll be better prepared to handle server problems proactively.

This AppNote presents recommended guidelines and procedures for customers to follow when resolving critical server issues. It begins with a discussion of server abends and lockups and their possible causes. It then gives some troubleshooting steps to follow to identify and resolve these types of server problems. An appendix gives instructions for capturing a server memory image for analysis by Novell.

By creating this document, Novell Support hopes to minimize miscommunication when dealing with customers and educate them as to how they can best help Novell resolve server issues. This document provides a standardized way to obtain valuable feedback to questions that will help prioritize the issue, gain some historical perspective on the problem, and improve resolution time.

What is an Abend?
The NetWare 3 and 4 operating systems continually monitor the status of various server activities to ensure proper operation. If NetWare detects a condition that threatens the integrity of its internal data (such as an invalid parameter being passed in a function call, or certain hardware errors), it abruptly halts the active process and displays an “abend” message on the screen. (“Abend” is a computer science term signifying an ABnormal END of program.)

The primary reason for abends in NetWare is to ensure the stability and integrity of the internal operating system data. For example, if the operating system detected invalid pointers to cache buffers and yet continued to run, data would soon become unusable or corrupted. Thus an abend is NetWare’s way of protecting itself and users against the unpredictable effects of data corruption.

There are two basic types of errors that can cause abend messages to be generated:

- Errors detected by the CPU
- onsistency check errors (detected by the operating system)
- CPU-Detected Errors

When the server’s CPU detects an error, the processor can interrupt program execution by issuing an interrupt or an exception.

Intel defines an interrupt as “an asynchronous event typically triggered by an external device needing attention.”

Paging and Segmentation Exceptions

NetWare 4 takes advantage of Intel’s segmentation and paging architecture. Each page of memory can be flagged present or not present, read-protected, write-protected, readable, or writable. These changes in NetWare 4 intoduce new exceptions that are not seen in NetWare 3. One good example is the “Abend: Page Fault” error.

Exceptions caused by segmentation and paging problems are handled differently than interrupts. Normally, the contents of the program counter (EIP register) are saved when an exception or interrupt is generated. However, exceptions resulting from segmentation and paging give the operating system the opportunity to fix the page fault by restoring the contents of some of the processor registers to their state before interpretation of the instruction began. NetWare 4 provides SET parameters to enable and disable page fault emulation, giving you the choice between continuing program execution or abending.
Intel defines an exception as “a synchronous event which is the response of the processor to a certain condition detected during the execution of an instruction.”

Exceptions are classified as faults, traps, or aborts based on how they are reported and whether restart of the failed instruction is possible.

Here is a list of exceptions and interrupts:

1. Divide Error
2. Debugger Call
3. Nonmaskable Interrupt (NMI)
4. Breakpoint
5. INT 0-detected Overflow
6. BOUND Range Exceeded
7. Invalid Opcode
8. Device Not Available
9. Double Fault
10. Invalid Task State Segment
11. Segment Not Present
12. Stack Exception
13. General Protection
14. Page Fault
15. Floating-Point Error
16. Alignment Check
17. Maskable Interrupts

the types of exceptions that are related to abends are the nonmaskable interrupt (NMI) and the processor-detected exceptions.

For more complete details about exceptions and interrupts, refer to Chapter 9 of the Intel486 Microprocessor Family Programmer’s Reference Manual.

Consistency Check Errors

Consistency checks are internal tests which Novell software engineers have placed in the NetWare operating system code. The primary function of consistency checks is to ensure the stability and integrity of internal operating system data. Numerous consistency checks are interlaced throughout NetWare to validate critical disk, memory, and communications processes. The abend errors that result from failed consistency checks are code-detected errors, as opposed to CPU-detected errors.

As an example of a consistency check, imagine a function called XYZFreeMemory that is used to release a portion of memory so it will be available for other programs. To guard against possible problems, the programmer includes a check to see whether the pointer passed into the function points to a valid memory buffer. If this check fails, the system will generate an abend.

A failed consistency check is always a serious error because it indicates some degree of memory corruption. Consistency check errors might be caused by a corrupt operating system file, corrupt or outdated drivers and NLMs (NetWare Loadable Modules), bad packets formed at the client, or hardware failures. These errors can also be associated with defective memory chips, static electricity discharges, faulty power supplies, or fluctuations in commercial power (see NetWare System Messages manual, page 1).

Analyzing Abend Messages

Before NetWare displays an abend message on the file server screen, several steps occur depending on whether the error was CPU-detected (exception generated) or code-detected (consistency checks). The type of information provided on the screen is identical in both cases:

(Line 1) Date and time the system halted
(Line 2) Abend message
(Line 3) Operating system version
(Line 4) Current running process
(Line 5) Current stack dump

For ease of reference, we’ll refer to line numbers 1, 2, 3, 4, and 5 in the sample abend message screens below.

Note: In the NetWare 3.12 operating system, EIP was added to the information on exceptions generated by the CPU.

Line 1: Date and Time. NetWare first posts the date and time at which the system was halted.

Line 2: Abend Message String. The text of the abend message itself will help you determine whether it is a CPU-detected abend or a code-detected error. In many cases, it’s easy to tell whether the message contains only information provided by the CPU or information from the operating system.

Here is an example of a CPU-generated abend:

(1) System halted Friday, July 22, 1994 3:32:42 pm MDT
(2) Abend: Page Fault Processor Exception (Error code 00000000)
(3) OS version: Novell NetWare v4.02 June 8, 1994
(4) Running Process: Server 03 Process
(5) Stack: 02 72 00 00 D7 BB 02 F8 AC B9 EE 00 C0 B9 EE 00
60 70 2B 00 78 B9 EE 00 58 92 05 F1 D0 FF 08 00
94 B9 EE 00 97 D6 00 F1 D0 FF 08 00 00 00 00 00

Press “Y” to copy diagnostic image to disk. Otherwise

Power off and back on to restart.

Notice the text of the message on line 2, “Abend: Page Fault Processor Exception (Error code 00000000)”. This information is provided to the operating system by the CPU. The error code in the message is used to help determine additional information about the exception. Error codes are produced only for some exceptions.

Under certain conditions, exceptions which produce error codes may not be able to report an accurate code.

Here is an example of a code-generated abend:

(1) System halted Tuesday, October 4, 1994 9:59:08 am PDT
(2) Abend: SERVER-4.00-3128: SubAllocFreeSectors given invalid FAT chain end that was already free.
(3) OS version: Novell NetWare v4.02 June 8, 1994
(4) Running Process: Console Command Process
(5) Stack: 3C 9E 0D F8 AB 57 27 00 01 00 00 00 20 00 01 00
01 00 00 00 00 00 00 00 10 B7 B5 0E A0 3E 56 00
01 00 00 00 15 20 01 F8 01 00 00 00 00 00 00 81

Press “Y” to copy diagnostic image to disk. Otherwise

Power off and back on to restart.

Notice how this abend message is different from the CPU-detected abend above which was generated by an exception. The message in line 3 refers to a consistency check found in the NetWare 4 operating system code (“SERVER-4.00-3128″), along with a short description of what that check was. In this example message, the error was found in the SubAllocFreeSectors routine which checks the FAT chain to see if it is a valid SubAlloc block.

Line 3: Operating System Version. This line identifies the version of the NetWare operating system running in the server.

Line 4: Running Process. This line indicates which process was running at the time of the abend. A “process” is a thread or path of execution that runs in the operating system. It can be an internal OS process or a process belonging to an NLM. Internal server processes can be referred to as OS worker threads. These are processes that take on a wide variety of tasks, such as handling packets, processing NCP requests, and performing work from the work-to-do list. Some of these tasks can be scheduled by other NLMs and carried out by file service processes. NLMs can also have their own dedicated threads.

Although the server message indicates which process was currently running at the time of the abend, you can’t assume that the running process is the cause of the abend. It may or may not be involved.

A good example of a case in which the running process is not the cause is when a process (call it Process A) receives an invalid pointer from a corrupt memory area and then tries to use this pointer. The memory area possibly became corrupt because some other process (Process B) issued a write over a valid structure or pointer. The running process simply tries to execute this pointer, which results in the abend. So even though Process A is identified as the running process in the abend message, the problem actually lies with Process B.
Another example is when the running process is passed invalid information from another NLM. File service processes fall under this scenario because they carry out work for other NLMs and service incoming packets that can pass invalid or corrupt information to the server process to execute.

Note: In abend messages, file service processes are identified as “Server XXX Process” where XXX can be any number between 0 and 100.

stack: an area of memory set aside for the temporary storage of values in a computing environment.

Line 5: Stack. The 30 hexadecimal bytes displayed at the bottom of the abend screen represent part of the CPU’s stack at the time of the abend for the current running process. All three lines of the stack dump may be useful to technical support people in diagnosing the cause of the abend.

Server Hangs or Lockups
In the computer industry, people describe a machine that suddenly stops working with a variety of frightful terms. They say the computer has crashed, frozen, hung, or locked up. For the purposes of this discussion, we’ll distinguish between full and partial server lockups.

When a full server lockup occurs, no processes are allowed to run. No one can log in to do work on the server. Connections that are currently logged in or attached are dropped. Nothing can be done at the server console or other NLM screens, and there may be no response at all from the server keyboard.

The Nonpreemptive Environment
Because the NetWare opera-ting system is nonpreemptive, it allows threads to access and control the CPU as they choose. The underlying assumption is that NLM processes will cooperate with each other and not monopolize the processor. In this type of environment, threads need not worry about being forced off the CPU unless they monopolize it. However, they can and should relinquish control frequently to allow other threads a chance to run.

After a partial server lockup, users might still be able to log in to the server and accomplish work. In some cases, you may be able to toggle to different server or NLM screens and do work. Partial hangs may eventually clear themselves up, or they may lead to a full system lockup.

One possible cause of a server lockup is a server or NLM thread which becomes caught in a tight loop and does not relinquish control of the CPU. The cause for this type of lockup can be related to either software or hardware problems.

Another example is a process which locks up resources (volumes, cache buffers, and so on) by blocking access to these resources. Other processes waiting on the release of these resources will not run until they are available. Again, the cause for this type of lockup can be software or hardware.

Server lockups can also be caused by some of the same problems that cause abends: corrupt operating system files, corrupt or outdated drivers and NLMs, bad packets formed at the client, or hardware failures.

Here’s a sample case that involved the use of outdated software. The customer was using the BNETX NetWare shell on the client for packet burst communications with a NetWare 4.02 server. (The BNETX shell was developed for use with the original pburst.nlm and was intended for use only with NetWare 3.11.) Because BNETX was out of date, the client was not communicating properly with the server. This miscommunication caused the server to hold resources and not release them for long periods of time. The longest period of delay time experienced was two hours. During that time, all any other processes could do was wait for the server resources to be freed up.

In diagnosing the cause of a server lockup, it is sometimes useful to generate a memory image file (or core dump) that lists the entire contents of server RAM. The steps for doing this are outlined in the Appendix of this AppNote.

Steps for Troubleshooting NetWare Servers

Like any sophisticated piece of software, the NetWare operating system is very complex and dynamic. In a network, a large number of components work together to form a functional whole. Each component has one or more specific relationships to other components in the system. A network is dynamic because it is subject to change. These characteristics of a network can make it difficult to pinpoint the exact cause of problems.

By following the troubleshooting steps outlined below, you can eliminate some of the obvious problems and provide more accurate information for the support technician if needed.

Server Troubleshooting Steps

1. Gather information about the problem.
2. Understand the problem and identify probable causes.
3. Test possible solutions.
4. Use debugging tools, if necessary.
5. Resolve the problem.

Step 1. Gather Information About the Problem

When faced with a critical server issue, you should gather the following facts:

A. All error messages that are generated.
B. Complete hardware configuration of the server.
C. Disk and LAN driver information for the server.
D. Listing of current NLMs and NCF files on the server.
E. The most recent changes made to the system.
F. Events that occurred prior to the crash.

A. Error Messages. All error messages need to be gathered and analyzed near the time of the system crash. There are many places to gather error information. One of the first is the abend information screen. Another is the server console screen where some console message might still be displayed.

After the server is brought back up, the system error log is a good place to look for date and time information. Another often overlooked area is the volume error logs.

B. Hardware Configuration. List all hardware components that make up the server. Find certification and testing information on these components.

C. Disk and LAN Drivers. Put together a complete listing of LAN and disk drivers running on the server, along with their date and version information.

D. NLMs and NCF Files on the Server. Put together a complete listing of NLMs running on the server, along with their date and version information. Also obtain a listing of both the startup.ncf and autoexec.ncf files to show how the NLMs were loaded.

E. Recent Changes to the System. Network administrators should maintain a log for each server to record both hardware and software changes. These records can help determine if the system has a history of stable operation, and whether or not this is a problem seen before on this system. This information could be very important in resolving the problem.

F. Events Occurring Prior to the Crash. Gather a sampling of what activities were taking place on the network at the time of the abend or hang. These might include events such as system maintenance (backups, database rebuilds, and so on), installation or changes in software or hardware, system failures, errors and warnings. Also make a note of user activities (high workload, atypical activities such as month-end closing, and so on).

Using CONFIG.NLM. To help in the gathering of this information, Novell Support provides an NLM called config.nlm. Config.nlm creates a text file called config.txt in SYS:SYSTEM. This file contains a list of all modules loaded on the server at the time config.nlm is run. It also contains the contents of the startup.ncf, autoexec.ncf, config.sys, and autoexec.bat files for the server. A directory of SYS:SYSTEM and your local drive is also placed in config.txt.

Download this NLM from the NSD area of NetWire. The self-extracting file is named config.exe. (For more information on config.nlm, refer to Technical Information Document TID021808 entitled “CONFIG.NLM”; the Research Index at the back of this AppNote issue gives availability information on Novell technical bulletins.) To run this module, you must have the latest clib.nlm loaded on your server. (Updates to CLIB can be found on NetWire in libupx.exe.)

Step 2. Understand the Problem and Identify Probable Causes

Understanding the problem comes by answering questions about the information and facts gathered in Step 1. Some of the types of questions you might ask are the following:

Can I draw any conclusions from the information gathered?

What information from the server error log file, volume error log file, and other audit-type files, could relate to the abend message or hang?

Is the hardware configuration different from one that has been certified and tested?

How are the drivers and NLMs loaded for this hardware configuration?

Are the drivers and NLMs on the file server up to date and current?

Have all the tested and approved patches been applied to the operating system?

When did this problem occur? For example, did it occur while trying to boot the file server, and if so, at what point did the failure occur?

What can I still do at the server? For example, if the system is in a hung state, can I toggle to different screens? Is the server partially or totally locked up?

Once you have a good understanding of the problem, try to identify some probable causes by drawing conclusions from the information gathered and forming one or more hypotheses.

As an example, suppose you just finished adding a new network card to the server and the server hangs next time you bring it up. After going through the information-gathering suggestions listed above, you arrive at two possible causes:

Hypothesis 1. Since you’ve just added a new network card, there’s a pretty good chance that this is the cause of the problem.

Hypothesis 2. The server might be experiencing file corruption resulting from a power outage or drive failure.

The above questions and hypotheses are just a few examples of many that could be determined from the information provided. Step 3. Test Possible Solutions

There are several methods or techniques you can use to test your hypotheses. Following are some of the most common ones.

Apply Known Patches and Fixes. Over half of the server abends and lockups reported to Novell Support are resolved by patches that have already been written. This should be one of the first areas to check in testing possible solutions to a problem, as it can save you many hours of troubleshooting previously resolved issues.

Be sure to apply all approved and tested operating system patches, regardless of the problem. A self-extracting EXE file for each operating system is available on NetWire and on the NSEPro CD-ROM. Novell uses the following naming convention for these files: The first three digits represent the OS version, followed by PT or IT (which stand for Passed Test or In Test), and a revision number. For example, 311PTD.EXE, 312PT1.EXE, 401PT1.EXE, and so on.

Component Swapping. One technique that is often used is swapping or replacing the suspected faulty component with a similar component that is known to be good. This method is most effective when you are familiar with the expected behavior of each component and already have a good idea of what could be causing the problem.

It’s vital that you swap out only one component at a time. This technique is effective for both hardware and software problems.

Divide and Conquer. To make it easier to isolate a problem, remove components from the system. For example, unload unneeded NLMs and hardware components to simplify the system. Discuss the Problem with Others. A good way to gain valuable feedback about a problem is to discuss possible solutions with other experienced CNEs and Novell support engineers.

Step 4. Use Debugging Tools

If you have not been able to gather enough information to make conclusions about the abend or hang, the use of additional debugging tools such as network analyzers, along with a memory image from the server, can help in resolving server abends or hangs.

Network Analyzers. Network analyzers (such as Novell’s LANalyzer, Network General’s Sniffer, and so on) are great tools for gathering troubleshooting information. In many cases, knowing about the behavior of protocols and packets on the network can help speed up the resolution of the problem.

Memory Image File. If the problem still exists after you have taken all of the above steps, there is another useful tool available to you. That is to create a memory image or “core dump” of the server and send it to Novell Technical Support for analysis. This memory image provides a snapshot of your server at the time of the abend.

Note: Before sending in a memory image, make sure all the tested and approved NetWare patches have been applied to the server.

Although a memory image shows what was occurring at the time of the abend, it does not provide much of a history. Often, though not always, the memory image provides enough information for Novell engineers to correctly diagnose your problem. Sometimes they can learn enough from the memory image to duplicate the issue on an identical machine in Novell’s server lab.

The Appendix of this AppNote contains information on how to obtain a memory image file and how to send it to be analyzed.

The Information Sheet. To assist in the problem resolution process, an Information Sheet is included with this AppNote. Fill in the information requested and send it in along with your server memory image and LANalyzer or Sniffer trace. If you can recreate the problem and describe exactly what steps led up to the abend, record this on the Information Sheet as well. This information will help speed up resolution time, reduce the chance of miscommunication, and keep the technical representative focused on the problem.

If Novell’s engineers are able to correct the problem, and if the problem has been caused by a software bug in the operating system, they will debug the program and send you a patch for the problem.

Step 5. Resolve the Problem

Once the problem has been isolated and you have proven your hypothesis correct, it is time to resolve the issue. For software issues, you can resolve problems with patches, workarounds, new drivers, and so on. For hardware, repair or replacement are the options.

The troubleshooting steps outlined above can be used for most abend errors on a NetWare server. If these steps do not resolve the problem, contact your Novell Authorized Dealer or Novell Technical Support for assistance.

Note: I added this document is just for my reference

1. Map a drive to the SYS: volume on your Managed Server
2. Run the install program from your PC
3. Reply to the prompts to select install directories
4. From the Netware console, add a search path SEARCH ADD SYS:/MSHSM/ or whatever directory you used
5. Enter MSSTART to start up the MS-HSM NLM(you use MSSTOP to stop MSHSM)

Apart from that we will be having the “setup” file under GUI folder is going to be used to install the HMS on Windows client machine. This will display you all the feature for Migrations/demigrations/Deletions and lot more on a Netware server from Windows.

Mapping a Drive
The first and most transparent occurs when a client starts their computer and responses to the Novell login dialog.   Various drives are mapped to the computer via a login script based on the client’s properties.  For instance, drive H: is normally mapped to the client’s home directory.  Other drive letters can be mapped to other locations either permanently or only for the current session using the file explore tool.  This facility also works for those off site, if the client enters the server’s full DNS name into the server field in the advanced option tab, while logging in.  For example, most central site clients should enter “cisnov11.lbl.gov” into this field.  As for onsite clients, the Novell login script will map the appropriate volumes to drive letters.

NetStorage
A second approach to access files is called NetStorage.  In this case, using Win98 through XP, the client can configure access to Netware Volumes.  Access to home directories and group-shared information is supported.

iFolder
The third method to access files is called iFolder.  It operates quite different then the above three methods.  Its purpose is to synchronize data that is accessed and updated from many locations.  This data is not part of a client’s home directory and is not sharable.  The data is encrypted and backed up (all Novell data is backed up) however restores cannot be done for a subset of files.  It is necessary to restore all data for a particular client.

The security benefits of running VSes are many, including:

• Isolation – Running an OS in a VM helps secure it from other apps, you can have each application in it’s own OS container, keeps bad things that happen to the individual VM from spreading to others
• Rollback – Experienced sys admins know how important it is to be able to rollback changes that don’t work, getting the system to a previous stable state is paramount for production machines, and VM’s are much easier to rollback, being software only
• Abstraction – The VM’s have limited access to the physical hardware, the drivers are easier to manage and there is less chance of physical issues with the VM’s than with an OS that runs directly on the hardware
• Portability – The ease of which you can take the running VM and either migrate it to a new VS or get that VM up and running on another server can make the difference for disaster recovery. With the ability to virtualize the OS and data, it’s much easier to swap out to replacement machines, making patch testing and upgrading much easier too
• Deployment – Deploying instances of individual servers is 10x easier with VM technologies, physical machine deployments are much more dependent on the physical hardware. Individual machine and OS security settings on the VS are important and the ability to surround the VM’s with appropriate security from the VS is also important (such as using AppArmor to wrap a VM, allowing only a set number of functions) to the security of each VM instance

Security Drawbacks of Virtualization

The chief security drawback of Virtualization is anything that could affect the functioning of the VS, which include any applications, services or activities that might negatively affect the VS’s ability to provide services to and properly host it’s VMs. You would not believe the things we have seen running on VS hardware, everything from BitTorrent to MP3 Shoutcast Radio Stations to very intensive file and print sharing.

It’s important to pare down the VS’s processes to the bare minimum, remove or disable all daemons that might be running, using chkconfig or the YaST Runlevel Editor. The typical VS might have up to 100 running daemons in runlevels 3 and 5, most of which are not necessary. Running the VS in runlevel 3 (no X started by default) will save a number of MB or RAM used, and decrease the load on the CPU for graphical tasks.